Re: Re: Undo in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg105136] Re: [mg105098] Re: Undo in Mathematica*From*: "David Park" <djmpark at comcast.net>*Date*: Sun, 22 Nov 2009 06:08:41 -0500 (EST)*References*: <200911191225.HAA19386@smc.vnet.net> <he5vcq$3it$1@smc.vnet.net> <27835764.1258795258120.JavaMail.root@n11>

There is also another slant on Workbench/DocuTools that has little to do with code development and debugging (rather nerdy things!) and that is as a method for organizing and consolidating your work. Consider an "Application" that has one or more packages with documentation, and sets of "finished notebooks". In addition there may be "developmental notebooks" of various types that are associated with the application but not part of its permanent content. Examples of such applications might be: writing a dynamic book using Mathematica; college courseware; a major research project; a study project of some book or subject. Don't think of an Application as a package, but think of it as some kind of unified project. It is difficult for me to conceive of any such projects that would not involve writing special routines and putting them in a package. If one is going to do that, one might as well give them paclet documentation. This may seem like a lot of work (when many users would balk at even writing a usage message) but is your work important or not? If it is important, it should be consolidated, preserved, documented and put in an accessible place. In the deployed application, in addition to the packages, style sheets, palettes, documentation and finished notebooks, you can add a Workbooks, say, folder to contain the developmental notebooks. You can do most of your work in regular Mathematica using the deployed application. When some developmental notebook becomes finished, or some new routines have been developed and tested, you can make a trip to Workbench and incorporate them into the permanent part of the application. This won't be horribly time consuming because most of the content, including routine examples, should already exist in the developmental notebooks and can be copied in. Once the basic structure is there everything is incremental. When the application is redeployed from Workbench it will not disturb the Workbooks folder so you can just continue working in Mathematica. If you send the application to another person you can just delete the Workbooks folder from the zip file. I've been using this for several project and it works very smoothly. Again, if your work is important (and I'm certain it is) then this is a way to consolidate and preserve it. It also uses standard WRI programs and meshes with standard Mathematica usage. If you want to take advantage of the Workbench code editing and debugging features - all the better. I tend not to use Workbench for initial code development but I do use it for fix-ups and it has many nice features. You can also edit code using the frontend editor (where you can add sectional grouping and Text cells) or in the Workbench editor and easily switch between them. Anyone doing major projects with Mathematica should definitely consider using Workbench. David Park djmpark at comcast.net http://home.comcast.net/~djmpark/ From: TWJ [mailto:twj at wolfram.com] > I am really curious how people develop large libraries in M. People use all sorts of different tools and practices. But a lot of people do use Wolfram Workbench -- this includes a lot of developers at Wolfram Research who use it for Mathematica development, and Mathematica is full of huge Mathematica libraries. The same is true for Wolfram Alpha. For large (and small) library development, the Workbench gives a tremendous number of useful features, completely too many to list in a posting like this. It has a project based approach, so you can work with multiple files, this is useful to separate different components. One example, of its functionality is that all the syntax/semantic warnings and errors (and there are very many classes of these) found in any files are all summarized in one report. This is much more useful than only seeing just those problems in the part of the file you happen to have open. Also, you get an integrated debugger, unit tester, profiler and source control. And it does have a nice multi-stage undo. You can get more idea of its features from the website (there are a bunch of screencasts)... http://www.wolfram.com/products/workbench/ When you say: 'but my understanding is that the workbench currently is not as interactive as the notebook editor' I'd be curious to know what you mean. Usually the types of things that the Workbench is not so good for is free-form mathematical explorations that mix typesetting, visualizations, etc... The FrontEnd is very good for this. But for producing Mathematica packages, applications etc..., the Workbench is very appealing. Tom Wickham-Jones Wolfram Research

**References**:**Re: Re: Undo in Mathematica***From:*John Fultz <jfultz@wolfram.com>

**Re: Re: Mathematica scoping / contexts / variable localization**

**Re: I broke the sum into pieces**

**Re: Undo in Mathematica**

**Re: Re: Undo in Mathematica**