Transition to Wolfram Workbench
in [Mathematica]
|
From: Hannes Kessler on 24 Feb 2010 06:19 Hello, could you give some recommendations for a smooth transition to the workbench for packages developed in a standard mathematica notebook environment? Starting a completely new project in the workbench is one thing, but at least as important is the question how to continue to work on existing packages created previously by other means. Up to now I wrote code in input cells of a mathematica notebook, added explanations in text cells, marked the input cells with package code as initialization cells to create the .m file automatically upon saving the notebook. I never looked into the .m files themselves. Should one / could one import the notebook (or the .m file) to a workbench project, or copy it to a work space directory, or work directly on the files in the user base directory, or what else ... ? Are there tutorials deeling with this problem? Best regards, Hannes Kessler
From: John Fultz on 25 Feb 2010 01:53 If take your notebook and you do... * File->Save As... * Choose "Mathematica Package" under the file type * Save as any .m file...but not using the same name as your .nb file (because your .nb file is already writing a companion package, and so will keep destroying and recreating the like-named package every time you save your notebook). You'll now end up with a package file which has some interesting properties. * If you open it in Mathematica, it looks much like a notebook, even preserving the cell structure and most of the properties of the notebook. * If you open it in Workbench (or any text editor), it will be completely readable, and all of that work you put into commenting your code in Text cells will *still* be there in clearly readable comments. * If you decide to make changes in Workbench (or any text editor), it will be pretty clear how to do so without destroying any structure that would allow you to reopen the package in the Mathematica front end and continue to see the same structure. When we designed the package editor in Mathematica (i.e., the mode you're put in when you open a .m file), one of the chief goals was to have it stream out to a file which is completely readable in any text editor, and which can be co-developed using any combination of Mathematica, Workbench, and text editor. By following this procedure, you'll be making absolutely no irreversible commitment to Workbench, and this will allow you to transition as quickly or slowly (or not at all) as you wish. Incidentally, something else which you might wish to know...Mathematica has an alternate evaluatable cell style known as "Code" (Alt+8 or Cmd+8). Code is like Input, but with the following differences... * Much less automatic formatting (e.g., auto-indent, auto-line-wrap) * InitializationCell->True is set by default * Differing background color so you can easily distinguish from Input cells This can be a much easier and more visible way of tagging package code than using the Initialization Cell menu item, and it's the style which is used by the package editor for package code by default. Sincerely, John Fultz jfultz(a)wolfram.com User Interface Group Wolfram Research, Inc. On Wed, 24 Feb 2010 06:18:42 -0500 (EST), Hannes Kessler wrote: > Hello, > > could you give some recommendations for a smooth transition to the > workbench for packages developed in a standard mathematica notebook > environment? Starting a completely new project in the workbench is > one thing, but at least as important is the question how to continue > to work on existing packages created previously by other means. Up to > now I wrote code in input cells of a mathematica notebook, added > explanations in text cells, marked the input cells with package code > as initialization cells to create the .m file automatically upon > saving the notebook. I never looked into the .m files themselves. > Should one / could one import the notebook (or the .m file) to a > workbench project, or copy it to a work space directory, or work > directly on the files in the user base directory, or what else ... ? > > Are there tutorials deeling with this problem? > > Best regards, > Hannes Kessler
From: Albert Retey on 25 Feb 2010 01:54 Hi, > could you give some recommendations for a smooth transition to the > workbench for packages developed in a standard mathematica notebook > environment? Starting a completely new project in the workbench is > one thing, but at least as important is the question how to continue > to work on existing packages created previously by other means. Up to > now I wrote code in input cells of a mathematica notebook, added > explanations in text cells, marked the input cells with package code > as initialization cells to create the .m file automatically upon > saving the notebook. I never looked into the .m files themselves. > Should one / could one import the notebook (or the .m file) to a > workbench project, or copy it to a work space directory, or work > directly on the files in the user base directory, or what else ... ? all this is possible, there is an import wizard that will import notebooks and create package files from them but you can just as well copy the notebook files to the project directory of a new project and keep editing the notebook and create the package file automatically. This approach might need some more work to get the configuration right but you will need to learn only those features of the workbench that you want to use. I would recommend to create a dummy application project to see how the directory structure and configuration files need to be set up for the workbench utilities to work alright. You could also crate a new application project an then just replace the templates that are generated with your already existing files, if these meet the suggested conventions... If you are only writing pure mathematica package files, the added value of the workbench is IMHO limited, it really can help you to save a lot of work only if you either plan to provide documentation that you want to integrate into the Documentation Center or if you want to combine mathematica code with java, webMathematica and/or probably GridMathematica (which I have no experience with). It also is nice when you are using or plan to use additional tools like a version control system or a ticket/task repository which all can be integrated with appropriate eclipse plugins. Files will always be stored in the "workspace", a special directory that contains your project directories but the workbench takes care that $Path is set so that you can load the package you are developing. You can configure the workspace to be at any location you want to. The workbench has an application tool view which lets you export your application/package with a mouseclick to e.g. the user base directory so you can test it without the workbench environment. > Are there tutorials deeling with this problem? there is documentation for the workbench and it also deals with the import of existing projects. Some of the material is not really exhaustive though. If you consider to work with the workbench, I would recommend to also take a few hours to get familiar with eclipse. hth, albert
From: Adam Berry on 25 Feb 2010 01:58 On 2/24/10 5:18 AM, Hannes Kessler wrote: > Hello, > > could you give some recommendations for a smooth transition to the > workbench for packages developed in a standard mathematica notebook > environment? Starting a completely new project in the workbench is > one thing, but at least as important is the question how to continue > to work on existing packages created previously by other means. Up to > now I wrote code in input cells of a mathematica notebook, added > explanations in text cells, marked the input cells with package code > as initialization cells to create the .m file automatically upon > saving the notebook. I never looked into the .m files themselves. > Should one / could one import the notebook (or the .m file) to a > workbench project, or copy it to a work space directory, or work > directly on the files in the user base directory, or what else ... ? > > Are there tutorials deeling with this problem? > > Best regards, > Hannes Kessler > > > Hello, the best approach is to create a project in the workbench, and then copy the .m package file into that project. Once you have done that you will edit the file using the workbench, and will no longer need the notebook with its generated .m file. See; http://reference.wolfram.com/workbench/topic/com.wolfram.eclipse.help/html/tasks/applications/mathematicaapps.html for ideas on how to structure the project. Adam Berry Wolfram Workbench Development Team Wolfram Research, Inc
From: E. Martin-Serrano on 25 Feb 2010 07:46 Please, May I ask which version of Workbench do these directions apply to? E. Martin-Serrano -----Original Message----- From: John Fultz [mailto:jfultz(a)wolfram.com] Sent: Thursday, February 25, 2010 7:53 AM Subject: Re: Transition to Wolfram Workbench If take your notebook and you do... * File->Save As... * Choose "Mathematica Package" under the file type * Save as any .m file...but not using the same name as your .nb file (because your .nb file is already writing a companion package, and so will keep destroying and recreating the like-named package every time you save your notebook). You'll now end up with a package file which has some interesting properties. * If you open it in Mathematica, it looks much like a notebook, even preserving the cell structure and most of the properties of the notebook. * If you open it in Workbench (or any text editor), it will be completely readable, and all of that work you put into commenting your code in Text cells will *still* be there in clearly readable comments. * If you decide to make changes in Workbench (or any text editor), it will be pretty clear how to do so without destroying any structure that would allow you to reopen the package in the Mathematica front end and continue to see the same structure. When we designed the package editor in Mathematica (i.e., the mode you're put in when you open a .m file), one of the chief goals was to have it stream out to a file which is completely readable in any text editor, and which can be co-developed using any combination of Mathematica, Workbench, and text editor. By following this procedure, you'll be making absolutely no irreversible commitment to Workbench, and this will allow you to transition as quickly or slowly (or not at all) as you wish. Incidentally, something else which you might wish to know...Mathematica has an alternate evaluatable cell style known as "Code" (Alt+8 or Cmd+8). Code is like Input, but with the following differences... * Much less automatic formatting (e.g., auto-indent, auto-line-wrap) * InitializationCell->True is set by default * Differing background color so you can easily distinguish from Input cells This can be a much easier and more visible way of tagging package code than using the Initialization Cell menu item, and it's the style which is used by the package editor for package code by default. Sincerely, John Fultz jfultz(a)wolfram.com User Interface Group Wolfram Research, Inc. On Wed, 24 Feb 2010 06:18:42 -0500 (EST), Hannes Kessler wrote: > Hello, > > could you give some recommendations for a smooth transition to the > workbench for packages developed in a standard mathematica notebook > environment? Starting a completely new project in the workbench is > one thing, but at least as important is the question how to continue > to work on existing packages created previously by other means. Up to > now I wrote code in input cells of a mathematica notebook, added > explanations in text cells, marked the input cells with package code > as initialization cells to create the .m file automatically upon > saving the notebook. I never looked into the .m files themselves. > Should one / could one import the notebook (or the .m file) to a > workbench project, or copy it to a work space directory, or work > directly on the files in the user base directory, or what else ... ? > > Are there tutorials deeling with this problem? > > Best regards, > Hannes Kessler
|
Next
|
Last
Pages: 1 2 3 4 5 6 7 Prev: NDSolve with Boundary Condition Next: Must tell Compile that Clip returns a number. |