Re: Re: Transition to Wolfram Workbench
- To: mathgroup at smc.vnet.net
- Subject: [mg107983] Re: [mg107775] Re: Transition to Wolfram Workbench
- From: Adam Berry <adamb at wolfram.com>
- Date: Thu, 4 Mar 2010 05:30:15 -0500 (EST)
- References: <hm56oh$k8n$1@smc.vnet.net> <201002252237.RAA17052@smc.vnet.net>
On 2/25/10 4:37 PM, Hannes Kessler wrote: > 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... at 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... at 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 >>> > > Hello, could you detail how you attempted to open this .m file in the Workbench. If you also send me the .m I can step you through transitioning and starting to work in the workbench. Thanks, Adam Berry Wolfram Workbench Development Team