MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Transition to Wolfram Workbench

  • To: mathgroup at smc.vnet.net
  • Subject: [mg107775] Re: Transition to Wolfram Workbench
  • From: Hannes Kessler <HannesKessler at hushmail.com>
  • Date: Thu, 25 Feb 2010 17:37:09 -0500 (EST)
  • References: <hm56oh$k8n$1@smc.vnet.net>

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


  • Prev by Date: Re: Controlling Memory Usage from JLink
  • Next by Date: Re: Re: Re: does it make sense ?
  • Previous by thread: Re: Transition to Wolfram Workbench
  • Next by thread: Re: Transition to Wolfram Workbench