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 ]] }]

**Multiple sum with iterators that cannot equal**

**Re: Control Function With NDsolve**

**Re: Multiple sum with iterators that cannot equal**

**Help: How can I set the insertion cursor in a certain cell?**