Re: Wolfram Workbench and package development

*To*: mathgroup at smc.vnet.net*Subject*: [mg68454] Re: [mg68413] Wolfram Workbench and package development*From*: "Chris Chiasson" <chris at chiasson.name>*Date*: Sat, 5 Aug 2006 03:46:59 -0400 (EDT)*References*: <200608040759.DAA01056@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

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/

**References**:**Wolfram Workbench and package development***From:*"John Jowett" <John.Jowett@cern.ch>