Re: Re: Wolfram Workbench and package development

*To*: mathgroup at smc.vnet.net*Subject*: [mg68654] Re: [mg68623] Re: Wolfram Workbench and package development*From*: "Chris Chiasson" <chris at chiasson.name>*Date*: Mon, 14 Aug 2006 06:44:40 -0400 (EDT)*References*: <200608040759.DAA01056@smc.vnet.net> <eb1l2a$egq$1@smc.vnet.net> <200608130952.FAA06223@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

I can think of at least two reasons for breaking up one's package files. Of course, there are several reasons to not do so as well. 1) The package needs to use code that is generated from a calculation that would be prohibitive to run at package load time. 2) The package is being developed by multiple people using a revision control system that would make conflicts more likely if there were not several files. On 8/13/06, John Jowett <John.Jowett at cern.ch> wrote: > 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/ > > > -- http://chris.chiasson.name/

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

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