WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2006

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

Search the Archive

Re: Wolfram Workbench and package development

  • To: mathgroup at smc.vnet.net
  • Subject: [mg68623] Re: Wolfram Workbench and package development
  • From: "John Jowett" <John.Jowett at cern.ch>
  • Date: Sun, 13 Aug 2006 05:52:32 -0400 (EDT)
  • Organization: CERN - European Laboratory for Particle Physics
  • References: <200608040759.DAA01056@smc.vnet.net> <eb1l2a$egq$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com
Thanks Chris and Pratik for the helpful replies.   I also had another one 
directly from Wolfram Technical Support.

I gather from these that Workbench does not do anything in particular to 
facilitate package documentation - I had somehow not noticed or forgotten 
that AuthorTools helps with this.

There's no particular reason to break packages up over more than one .m file 
in WW.

I suppose I have to try out WW as a new way of working - it's always an 
effort to change one's habits.

My experience of package code being saved with unwanted characters (item 4) 
was already after saving initialisation cells from a notebook.  I gather 
from the Technical Support reply that this is considered a bug.  It may be 
that this happens with notebooks that were created years ago in older 
versions of the Front End although they have been revised and re-saved many 
times since.  I need to check that when I get some time.

John Jowett


"Chris Chiasson" <chris at chiasson.name> wrote in message 
news:eb1l2a$egq$1 at smc.vnet.net...
I saw your message on the group this morning. I waited for it to come
in via my email account. This evening, I found it in my spam folder...

1)
People have probably mentioned this to you by now, but just in case:

Help files are (supposedly) authored using the author tools palette
and the Help stylesheet. You add help to the browser by using front
end commands in a special file:

one of:

$UserBaseDirectory, $BaseDirectory, $InstallationDirectory

appended with:

\Applications\RandomAppName\Documentation\English(or your
language)\BrowserCategories.m

Where BrowserCategories.m contains nested BrowserCategory front end
functions. The syntax of this command may be looked up in the help
browser. If you search the MathGroup for this function name or the
BrowserCategories.m file name, you will find more information.

As noted above, Help files are actually notebooks. Therefore, you
can't edit them directly in Workbench. However, you can certainly
manage the help files as part of a Project in Workbench.

The part of the project that you give to users is the subfolder with
the application name - tell them to put it in (one of:
$UserBaseDirectory, $BaseDirectory,
$InstallationDirectory)\Applications\.

You may be wondering what will happen to the init.m file in
YourWorkspace\YourProject\AppName\Kernel if you copy the AppName
folder to your Mathematica Applications directory. The answer is as
follows: Nothing will happen unless you execute <<AppName`. When you
do that, the init.m file will be executed (it usually just calls the
main AppName.m file).

2)
Who knows what they'll do for future version of Mathematica? :-]

3)
Packages may import other packages in the standard way, by appending
the other package contexts to the BeginPackage function call.

4)
Yes, I have noticed this problem as well. A workaround is to use the
Front End's initialization cells autosave package. Mark all the cells
you want as initialization cells, then save. You will get a version of
the text that is pretty good. Alternatively you could cut and paste
using the "plain text" option. Neither of these options are ideal.
Unless someone knows a better way, we may have to wait for WRI to
produce a better importer.

5)
As you say, it is exactly a matter of putting Get commands in the
appropriate place. No context switching takes place unless you issue
the appropriate commands, AFAIK. I have tested this.

6)
In Workbench, doing that would be prohibitively difficult and also
unnecessary if you learn to use the Debug perspective. In fact, it's
unnecessary in Mathematica as well, if you use the Dialog (and
related) command(s).

The debug perspective as seen when launching a notebook in Debug mode
from Workbench:

The debug subwindow allows you to see the stack (similar to Stack[]
executed in a Mathematica Dialog). The variables subwindow allows you
to see (context free!) symbols that are inside your scope (ie,
variables in a Module statement). There is also an arbitrary
Expressions subwindow ( the help on this window may be out of date).
You can set breakpoints on messages and on arbitrary sections of code
so that you get a chance to actually use those aforementioned
subwindows. You can "step into" arbitrary expressions (think of adding
to the Stack or going to a sublist in Trace's output). You can also
"step over" expressions (think of evaluating the next part of a larger
expression like CompoundExpression[a=2+z,Solve[a==x-r,r]] where
Solve[a==x-r,r] is the next part [literally] or moving to the next
item in a list of Trace's output).

I've seen you talk about some pretty advanced stuff on the list, so I
am sure I oversimplified/overexplained.

Anyway, I hope I helped,

On 8/4/06, John Jowett <John.Jowett at cern.ch> wrote:
> I've installed and taken a look at Wolfram Workbench (WW).  Before 
> deciding
> to adopt it for my work,  I'd like to raise a few questions concerning how
> one might use it for package development.   It would be interesting to 
> hear
> other people's thoughts.
>
> 1. WW is clearly an alternative to the traditional workflow for package
> development in a notebook (which I learned from Roman Maeders' book
> "Programming in Mathematica"). In that scheme, package functions are 
> created
> in initialisation cells and the notebook can hold documentation, examples
> and so on.  I've been doing this for years but somehow never got round to
> the next step which is to write additional documentation notebooks for
> integration in the Help Browser.   Presumably this can be done in WW,
> perhaps more efficiently.   It may seem fairly obvious but it would be
> useful if someone would spell out an authoritative recipe for doing so 
> (and
> ideally put it into the help for WW).   Which files should you finally
> "export" from the project and give to people to install in their
> $(User)BaseDirectory Applications folder?
>
> 2. Is the above still the right way to put together and provide Help 
> Browser
> documentation for application packages, even for future versions of
> Mathematica ?
>
> 3. What about packages that import other packages, contexts and
> sub-contexts, etc.?
>
> 4. When I try to use the Mathematica Import Wizard to bring existing
> notebook-generated packages into WW, I tend to end up with a lot of
> non-InputForm syntax ("\[Rule], "\!\(", "\<","\[InvisibleSpace]" etc.). 
> It
> would be nice to automatically fix/delete these (although perhaps it 
> should
> be the Front End's job).
>
> 5. Is it a good or a bad idea to break a single large package over several
> .m files in WW?  If good, is it just a mattering of putting Get[...]
> commands between the BeginPackage and EndPackage ?
>
> 6. In debugging or improving a function from an existing, loaded package, 
> I
> often find myself working on a slightly-renamed version that has been 
> copied
> to the Global context (this avoids repeatedly re-launching the kernel,
> particularly when it takes some time to get to the point where the new
> version of the function can be tested).  This method is a little messy,
> especially when it uses private functions.   How would I do this in WW ?
>
> John Jowett
>
>
>
>
>


-- 
http://chris.chiasson.name/
  • Prev by Date: RE: need mathematica's help for exploring a certain type of mapping
  • Next by Date: No output or In[n] prompt appearing
  • Previous by thread: Re: Wolfram Workbench and package development
  • Next by thread: Re: Re: Wolfram Workbench and package development