[Date Index]
[Thread Index]
[Author Index]
Comments in 2-D cells yield corrupt packages
*To*: mathgroup at smc.vnet.net
*Subject*: [mg19360] Comments in 2-D cells yield corrupt packages
*From*: jsobel at sdav01.seinf.abb.se (Jarl R Sobel)
*Date*: Fri, 20 Aug 1999 23:09:38 -0400
*Organization*: ABB Automation Products
*Sender*: owner-wri-mathgroup at wolfram.com
Hi package developers and others,
Here is a rather nasty bug in Mathematica 4.0.0, which has been haunting me
for the past couple of weeks. I have reported it to Wolfram Research.
A Cell with comments, such as the one below, is handeled OK when entered in
ordinary one-dimensional notation.
test := Module[{x = 1/10},
(* Everything OK with one dimensional notation *)
x]
The same cell can also be written using two dimensional notation (i.e. 1/10
is written as 10\^-1 with a superscript). This is the preferred style in
Mathematica. Two dimensional notation is also what you get if a cell is
converted into Standard Form using the menu command: CellConvert
ToStandard Form. Note that you can use this even if the cell is input
in
StandardForm, in order to get the nice two dimensional typesetting, and
have all your "[[" turned into \[LeftDoubleBracket] etc. Note, however,
that this removes all comments from your cell.
\!\(test1 :=
Module[{x = 10\^\(-1\)}, \[IndentingNewLine]\[IndentingNewLine] (*\
This\ comment\ ruins\ everything\ *) \[IndentingNewLine]\
\[IndentingNewLine]x]\)
This definition reads correctly by the Kernel when executed directly
from the Notebook. However, if the cell is turned into an initialization
cell and Mathematica is made to auto generate a Package from the
corresponding file (i.e. a file with the file extension .m) the resulting
Auto Generated Package is corrupt.
Unfortunately, this is not always the case. On some occations the file is
read without syntax errors, but the code is interpreted incorrectly by the
Kernel. On one occation I have had a Null expression included in the output
from a particular function, which caused strange behaviour when a complex
program was executed.
On another occation, it may even work. For example, if you move the comma
in the two dimensional Cell above, to the position immediately following the
comment, the corresponding package reads correctly.
When the same expressions are typed into Mathematica 3.0, only \n (\[NewLine])
and \t (\[RawTab]) are used, and everything is fine. When you type in
Mathematica 4.0 this is replaced by \[IndentingNewLine], which gives the
very nice auto indenting of complicated expressions in 4.0, but apparently
also this nasty bug.
A package written in Mathematica 3.0 with comments in two dimensional cells
can therefore be read by Mathematica 4.0 without problems. However, simply
editing the line breaks in 4.0, and regenerating the package, can cause the
package to become corrupt.
Fortunately, Mathematica indicates on which line of the package the problem
is, so opening the .m file in a text editor, you can easily locate which
cell is causing the problem. Then you must either remove the comments, or
rewrite the cell in one dimensional notation.
A safer way to comment your code in Mathematica is therefore to put all
comments in Text cells above or below the actual code, and refrain from
inline comments using (* comment *).
See also an earlier posting of mine regarding how inline comments colored
in red, can yield corrupt notebooks (not only packages) in 4.0.
To illustrate the behaviour with corrupt packages, follow the steps in the
notebook below.
Bye
Jarl
Notebook[{
Cell[CellGroupData[{
Cell["Comments in 2-D cells yield corrupt packages", "Section"],
Cell["The following cells are initialization cells.", "Text"],
Cell[BoxData[
\(test :=
Module[{x = 1/10}, \[IndentingNewLine]\[IndentingNewLine] (*\
Everything\ OK\ with\ one\ dimensional\ notation\ \
*) \[IndentingNewLine]\[IndentingNewLine]x]\)], "Input",
InitializationCell->True],
Cell[BoxData[
\(test1 :=
Module[{x = 10\^\(-1\)}, \[IndentingNewLine]\[IndentingNewLine] (
*\
This\ comment\ ruins\ everything\ *) \[IndentingNewLine]\
\[IndentingNewLine]x]\)], "Input",
InitializationCell->True],
Cell["\<\
If the definitions are sent directly to the Kernel from the \
Notebook, everything is fine\
\>", "Text"],
Cell[CellGroupData[{
Cell[BoxData[
\(test\)], "Input"],
Cell[BoxData[
\(1\/10\)], "Output"]
}, Open ]],
Cell[CellGroupData[{
Cell[BoxData[
\(test1\)], "Input"],
Cell[BoxData[
\(1\/10\)], "Output"]
}, Open ]],
Cell["Save the file.", "Text"],
Cell[BoxData[
\(NotebookSave[EvaluationNotebook[]]\)], "Input"],
Cell["Clear the old definitions", "Text"],
Cell[BoxData[
\(Clear[test, test1]\)], "Input"],
Cell["\<\
and try reading them from the package file (replace the name of the \
package file with the appropriate one)\
\>", "Text"],
Cell[CellGroupData[{
Cell[BoxData[
\(<< "\<Mac OS 8:Desktop Folder:Untitled-1.m\>"\)], "Input"],
Cell[BoxData[
\(Syntax::"sntxb" \(\(:\)\(\ \)\)
"Expression cannot begin with \"\!\(\(\(\(\({x = 10\^\(-1\)}\)\),
\)\) x\
\)\".\!\(\"\"\)"\)], "Message"],
Cell["\<\
Syntax::sntx:
Syntax error in or before \"\[IndentingNewLine]x]\\) \".
^
(line 34 of \"Mac OS 8:De<<13>>Untitled-1.m\")\
\>", "Message"]
}, Open ]],
Cell["\<\
We can see that the definition of test1 went wrong by executing the \
definitions again.\
\>", "Text"],
Cell[CellGroupData[{
Cell[BoxData[
\(test\)], "Input"],
Cell[BoxData[
\(1\/10\)], "Output"]
}, Open ]],
Cell[CellGroupData[{
Cell[BoxData[
\(test1\)], "Input"],
Cell[BoxData[
\(test1\)], "Output"]
}, Open ]],
Cell["\<\
A cell entered in ordinary one dimensional notation is handled \
correctly:\
\>", "Text"],
Cell["\<\
However if two dimensional notation is used in an initialization \
cell, the resulting Auto Generated Package is corrupt.\
\>", "Text"]
}, Open ]]
}]
Prev by Date:
**Multiple sum with iterators that cannot equal**
Next by Date:
**Re: Control Function With NDsolve**
Previous by thread:
**Re: Multiple sum with iterators that cannot equal**
Next by thread:
**Help: How can I set the insertion cursor in a certain cell?**
| |