[Date Index]
[Thread Index]
[Author Index]
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
Prev by Date:
**Re: Re: Mathematica scoping / contexts / variable localization**
Next by Date:
**Re: I broke the sum into pieces**
Previous by thread:
**Re: Undo in Mathematica**
Next by thread:
**Re: Re: Undo in Mathematica**
| |