[Date Index] [Thread Index] [Author Index]
Re: Two Version 6.0 Package Problems
David, In response to 1), this is a bug. Notation in subscripts using paired ASCII brackets works fine, but notation using \[LeftDoubleBracket] and \[RightDoubleBracket] does not. I'll look at this ASAP. For your second point, you can omit non-initialization cells when doing Save As->Package File by clicking the Options... button in the Save dialog and checking the "Only save Code cells" checkbox. Code, incidentally, refers to thenew style bound to Alt+8 which is, by default, an initialization cell and will save out to packages. It also has automatic line-wrapping and indentation turned off so that you can see exactly what the cell will look like when writtenout to the package file. The behavior of omitting non-initialization cells probably ought to be done automatically in auto-generated packages. But I think the inclusion of non-initialization cells is considerably useful when working with Package files directly (i.e. File->New->Package). Sincerely, John Fultz jfultz at wolfram.com User Interface Group Wolfram Research, Inc. On Mon, 4 Jun 2007 03:46:04 -0400 (EDT), David Park wrote: > I write packages by using a regular notebook with Initialization cells and > saving it as an AutoGeneratedPackage. I have come across the following two > problems while converting a 5.2 package to 6.0. > > 1) Part expressions in the subscripted form (for example from the > BasicMathInput palette, 6th row right) do not parse from the generated .m > file. Packages that contain these expressions will not load correctly. > Nor are these expressions detected as an incompatibility issued when > checking the source notebook. I think this subscripted form came in > with Version 4. For a long time I resisted it but finally decided that it > was easier to read and was here to stay. If one looks at the .m file, > these expressions are flagged in red but it appears that the only way to > correct them is to go back to the original notebook, tracked them down, > and write them as nonsubscripted Part expressions. I think that these > expressions should be accepted and parsed in the package files. > > 2) All cells in the source notebook are now automatically Initialization > cells and there is no way to change any of them. This is quite bad because > there are a number of reasons for having nonitialization cells in a > package > source notebook. I often put in Text cell comments that give the date and > reason that some change was made. I don't want these comments to be in the > ..m package file. Also, I often make a new version of a routine but do not > want to immediately throw out the old routine code. I could formerly do > this > by making the old code cell a noninitialization cell but can no longer do > that. This is a serious loss of development capability. I believe this is > a > bug because one can select a cell and use Menu -> Cell -> Cell Properties > -> > Initialization Cell and this will be either checked or unchecked. It will > toggle when one selects it. However, it does not affect the Initialization > character of the cell in the source notebook. And even when the menu item > is > unchecked the cell still goes into the .m file and causes problems.