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

Re: Two Version 6.0 Package Problems

• To: mathgroup at smc.vnet.net
• Subject: [mg77185] Re: [mg77112] Two Version 6.0 Package Problems
• From: John Fultz <jfultz at wolfram.com>
• Date: Tue, 5 Jun 2007 06:47:47 -0400 (EDT)
• Reply-to: jfultz at wolfram.com

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.