Re: Re: Viewing packages in mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg102805] Re: [mg102757] Re: Viewing packages in mathematica
- From: "David Park" <djmpark at comcast.net>
- Date: Thu, 27 Aug 2009 06:38:10 -0400 (EDT)
- References: <h6tv6v$drb$1@smc.vnet.net> <28628601.1251289850830.JavaMail.root@n11>
Well thanks to the original poster for starting this thread because I for one have learned a lot from it. There has always been a lot of confusion about writing packages because the methods have somewhat shifted over the years, new facilities have been added, and WRI has provided a number of alternative methods. Not wanting to favor one method or another they never seem to put out anything that a beginning package writer can grab onto. Packages are a very useful feature and more users should be able to take advantage of them. So let me outline what I now think the picture is. I'm sure people will add things or correct me where I am wrong. 1) Simple undocumented packages. Use regular notebooks, which you are already familiar with. Use Initialization cells and the Auto Generated Package mechanism. You can have Titles, Sections, Text cells and all that. The main problem beginners have is that they don't know where to put the package. Put it in a folder in your $UserBaseDirectory/Applications folder. Use "folder`packagename`" in your BeginPackage statement and in the Needs statement. 2) Simple undocumented packages - alternative. Create a new .m file and edit it with the Front End editor. This maintains just a single file. Although you wouldn't know it at first (if your only experience is opening someone's .m file) you can also have a Title, Sections and Text cells in the .m file. It has Sections and Functions drop-down menus that let you to quickly go to some specific part of the file. It has debugging facilities but I don't really know how they work. Maybe someone can tell me. The one disadvantage is that the package file contains Code cells instead of Input cells, and Code cells don't wrap. As far as I am concerned, this is nearly fatal as far as editing and maintenance goes. But I think there is a way around this. Select all the Code cells (Alt-Click a Code cell) and change their style to Input cells. These do wrap, you are back in familiar territory and you can do your editing. Then switch all the Input cells back to Code cells. They have to be Code cells to function as a package. 3) Packages with paclet documentation. Here I believe the clear choice is to use Workbench. (I think there is some method to write documentation outside of Workbench using DocuTools but I have no idea how this works or whether it has any advantages. Maybe someone can tell us about that.) The advantage of Workbench is all the extra useful features it has. In Workbench there is something of a competition between editors. Again you have a single package.m file. One would normally edit it with the Notebook Source Editor and this is done in a pane within Workbench. This editor has a lot of nice features, which are described in Workbench Help under Mathematica Development User Guide, Tasks, Mathematica Code. One feature is that you can use the context menu and go to Source, Format and this will format the code with line returns and indentations. Although this isn't the same as line wrapping it does make the code more accessible. You can also insert your own line returns and the editor will preserve the proper indentation. But one could also use the normal FE editor by using Open With: System Editor. Here you could do things like adding Text cells or Sectional grouping. You could switch to Input cells, edit there and then switch back to Code cells. But since FE editing is done outside of Workbench you have to "Refresh" the project after closing the file. And one has to use Open With to get back to the Notebook Source Editor. If you use the Workbench Import mechanism to create a package.m file from an existing package.nb notebook with Initialization cells, then the code will not wrap and run off the page. But if you copy and paste code from a notebook into Workbench then it will preserve line returns and indentations (I think). Where does most package code come from? Probably from a regular notebook where the routine was first developed and tested. So it can just be copied into a Workbench file with no problem. You can also maintain your own set of notebooks with their own style sheet within Workbench along with associated packages. So once we learn how to use it properly it seems to me that it can be a very convenient framework for writing extended applications and we will be able to spend our time thinking about the interesting stuff. David Park djmpark at comcast.net http://home.comcast.net/~djmpark/ From: Yves Klett [mailto:yves.klett at googlemail.com] John, if linewrapping is just a rendering option in the editor, why not let the user decide if he likes it or not? If no permanent changes were made to the m-file itself, there should be no harm done. Enabling line-wrapping in any old editor usually does not change the file as such... The non-existent linewrapping for "Code" cells makes editing complex long cells quite painful and seems for my taste something that would people put off using the otherwise very nice new package editing features in the frontend. As for workbench, surely there is an option there to enable line-wrapping (dunno, though)? Regards, Yves John Fultz schrieb: > I should make it clear that none of your reasons apply to the package > editor in the Mathematica front end (available by opening a package > file or through the menu item File->New->Package). You can edit > packages directly using that editor with all of the formatting, syntax > coloring, cell types and grouping on package files which are completely > interchangeable with Workbench or any other text editor you might favor > for working with package files. > > There are a couple of things that you don't get which you would get > with regular notebooks. As the original post points out, you don't get > line-wrapping in Code cells. This was a deliberate design decision on > our part. We wanted to create a package editor which would be completely > interchangeable with Workbench and other systems. Therefore, two of the > design goals were to limit the automatic formatting changes introduced by > the front end when displaying/editing a package file, and to minimize the > markup introduced into the package file by the front end when encoding > cell group structure, cell styles, etc. > > I personally think we've struck a pretty good balance, although there > are a few suggestions for features which remain to be implemented. > Others on this forum (and perhaps even within Wolfram) may disagree, > and that's fine. There are many options for editing package files. > Some people are very happy with Workbench, some with their own text > editors, some with the FE's package editor, and some with notebooks > auto-saved as packages. All will continue to be supported for as far > in the future as I can predict. > > Sincerely, > > John Fultz > jfultz at wolfram.com > User Interface Group > Wolfram Research, Inc. > > > On Sun, 23 Aug 2009 05:32:59 -0400 (EDT), David Park wrote: >> I agree with you that I would much prefer to have Mathematica notebooks as >> the primary source for package code. The reasons are: >> >> 1) You get the automatic formatting. >> 2) You get syntax coloring. >> 3) You can include Text cells for notes on the code. >> 4) You can use sectional grouping so you don't have just one long scroll. >> 5) You're not completely committed to Workbench. >> >> One of the major problem with creating .m files in Workbench is that if >> you Import the code from a regular existing package then the .m code does >> not line wrap. This makes it very difficult to read and to modify. >> However, if you copy and paste code from an existing notebook then it >> does line wrap. >> >> Making .m files the primary source of package definitions is a significant >> obstacle to users who would prefer to stay closer to mathematics than to >> computer programming. >> >> It would be nice if Workbench included a mechanism similar to the auto >> generated package mechanism that would generate line wrapping .m files. >> But there is a method that I've found, just in the last two days, that >> works and is fairly convenient. >> >> 1) In your Workbench application folder create package.nb and package.m >> files. >> >> 2) The package.nb notebook will look just like a regular package notebook >> done outside of Workbench except: don't make it an auto generated package >> and don't even use Initialization cells. (Making it an auto generated >> package will get Workbench all confused!) This will be your primary >> package >> source file. >> >> 3) To create the package.m file: Select all the Input cells in >> package.nb, and copy them; go to the package.m file select everything and >> paste. (To select all the Input cells in package.nb hold down Alt and >> click on one of the brackets.) With this method the code will line wrap >> in the .m file. You can also just copy and paste a single routine. This >> 'hand' method is quite quick and easy. You don't have to much look at the >> .m file. >> >> I believe that once the kinks are smoothed out, and there is better >> documentation and examples Workbench can be a very useful working >> interface for regular Mathematica users. One advantage is that it is a >> regular WRI supported feature of the Mathematica system, and it blends >> with the rest of Mathematica. As I've mentioned before, some of the >> things it could be used for are: >> >> 1) Writing an electronic book. >> 2) Writing university courseware. >> 3) Working on a major research project. >> 4) Self-study of a textbook or some subject matter. >> >> All of these things are likely to generate routines that could be put >> into a package, and if you are going to do that it might as well be >> documented. It's not that much work if you confine it to major useful >> routines. Then a Mathematica Application is a good way to organized >> relatively finished material, package routines and subject matter >> notebooks, so it is easy to get at it again. It's a lot better than >> having a lot of loose notebooks with an undocumented routine here and >> another there. It's a major fruit of your labor so it's worthwhile to >> have it documented and organized. >> >> >> David Park >> djmpark at comcast.net >> http://home.comcast.net/~djmpark/ >> >> >> From: Bill Rowe [mailto:readnews at sbcglobal.net] >> >> Also, there is Wolfram Workbench. Others have found this useful. >> As for myself, I've not found Wolfram Workbench to be that >> useful. I much prefer keeping a Mathematica notebook and >> generating the .m file from it. > > > >