Transition to Wolfram Workbench
in [Mathematica]
|
From: dr DanW on 25 Feb 2010 17:33 John, I have been trying to figure out how to preserve expository and sectioning cells in package files for years. I never realized that Save As > Mathematica Package (*.m) saved in a special format that was different from the AutoSaved package files of initialization cells. I was annoyed that I would loose all my text format comments and had to keep all comments that I wanted to appear in a package file in (* *) brackets. These, then, would disappear anytime I reformatted the cell (Convert To > StandardForm), which I do every so often to make them pretty. Thanks for the tip. I have flagged your posting with 5 stars to mark it as an important and useful tip. Daniel
From: Adam Griffith on 25 Feb 2010 17:35 Hi Hannes, http://www.wolfram.com/products/workbench/ is a great resource for learning about everything you're mentioning. Also, if you enjoy developing in a notebook environment, take a look in the front end at File > New > Package (opens the fantastic front end package editor which provides the means to easily write a .m file in a notebook environment). Cheers, -Adam 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: Hannes Kessler on 25 Feb 2010 17:35 What you said works for saving a Mathematica notebook as a package under a different name and re-opening it in Mathematica. I'll probably look now more on .m files in Mathematica during package development and debugging. But when I re-opened the created .m file in the Workbench I got an error "Could not open the editor. An unexpected exception was thrown." followed by at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java: 3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java: 2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java: 332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java: 493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java: 149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java: 113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java: 194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java: 110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java: 79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java: 179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) I don't know what to do with it. Best regards, Hannes Kessler On 25 Feb., 07:53, John Fultz <jfu...(a)wolfram.com> wrote: > 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 > jfu...(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: Hannes Kessler on 26 Feb 2010 04:04 Hello Albert, I tried to create some test documentation using the workbench but failed to use the documentation tools palette when Mathematica was called because some of its elements were hidden and I could not increase the size of the palette window. In the workbench I had problems using the help system as the font size is really tiny, but no possibility to change it. I am afraid such elementary difficulties will discourage newcomers like me to use the workbench. Best regards, Hannes On 25 Feb., 07:54, Albert Retey <a...(a)gmx-topmail.de> wrote: > 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: David Park on 27 Feb 2010 03:12
On my system (Windows Vista, IE8) the Workbench 2.0 Help comes up in the IE8 Browser and there it is possible to adjust the magnification in the right hand pane where the descriptive material is contained. The left hand pane (TOC) does not seem to adjust but is fairly good size (and I'm also one to complain about non-adjustable small font sizes.) On my system the DocuTool palette fills the vertical height of the screen and there is enough room for all the buttons on the palette. But I think they should really make it adjustable height with scrolling. David Park djmpark(a)comcast.net http://home.comcast.net/~djmpark/ From: Hannes Kessler [mailto:HannesKessler(a)hushmail.com] Hello Albert, I tried to create some test documentation using the workbench but failed to use the documentation tools palette when Mathematica was called because some of its elements were hidden and I could not increase the size of the palette window. In the workbench I had problems using the help system as the font size is really tiny, but no possibility to change it. I am afraid such elementary difficulties will discourage newcomers like me to use the workbench. Best regards, Hannes On 25 Feb., 07:54, Albert Retey <a...(a)gmx-topmail.de> wrote: > 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 |