Package development
t...@tt.com
desperatly needed! Been using (sporadically) and reading about Mathematica
since version 3 (including 2nd edition of Maeder's book), but there is
nothing like hearing someone (Wellin) focusing you on the important
stuff. Even if given online, this was a great thing to follow. I am
surprised that these formations are not discussed more often in this
newsgroup. I guess that many would find answers to their question by
taking this short formation (if they have a good boss that can cover
the expense...).
Now the question. I have written a few packages in the past. More
recently, I am always questioning myself to know if I should develop
it directly in an ASCII .m file or use the notebook format and rely
on the autosave package feature (initialization cells). I like the
idea of developing the package in the notebook format to have all the
formatting features that ease reading, but at the same time, I hate to
loose all the comments I put in when the *.m file is created. Of
course I could put comments in the input lines of the notebook, but
then I am better writing the ASCII file. Also, I could save the
notebook as a package through "Save as Special" (that puts all the
headers and text in comments, which is not done with the autosave
package feature), but this is not an automated way of doing things. I
am just seeking opinions from Mathematica power users. Which way do you
develop packages?
Cordially.
GL
Jean-Marie Thomas
> develop packages?
>
I use the Notebook interface :
- it provides the ability to generate .m files ;
- tests are written in notebooks ; so notebook as a working fomat is
consistent ;
- documentation requires notebook format ;
- notebooks can be easily versioned with modern versioning tools like
subversion.
And writing, debugging, etc. is much easier using the notebook interface !
jmt
David Annetts
> seeking opinions from Mathematica power users. Which way do
> you develop packages?
I haven't written anything using an ASCII editor since V3.0 which was when
the front end became available for Windows systems. The advantage (to me
anyway) of using the front end is that I can prototype each of the functions
that will end up in the package as I go. With ASCII editors (then BRIEF,
now CRISP), it's a little more difficult.
I don't find lack of comments in autogenerated packages a problem since such
files tend to be barely readable because they are formatted for an 80-column
display. Things get even more interesting if you use a lot of special
characters.
Regards,
Dave.
David Park
My view is that one should write packages in a regular Mathematica notebook,
using Initialization cells and the Generate AutoSave Package feature. One
should never look at a .m file - unless you're trying to examine someone
else's code.
But the question of comments, (* comment *), is important. I do not think
that WRI has adequately addressed this issue. Recently I was developing a
routine in a testing notebook. I had commented out a section of the code.
The routine worked. When I moved the routine to the package notebook, there
were parsing errors. When I removed the commented code the package routine
worked. However sometimes I have put comments in package code without
trouble. (It makes one wonder how many different parsers Mathematica uses.)
I think that the vast majority of package writers would like to be able to
use unrestricted comments in their code. Such use is good practice, and Text
cells outside the code are not an adequate substitute. The fact that it is
unreliable is an annoyance and tends to discourage comment use.
Furthermore, if one converts a cell from one form to another, say
StandardForm to InputForm, the comments are discarded. This is also an
annoyance.
COMMENTS SHOULD BE CONSIDERED AN ESSENTIAL PART OF CODE. THEY SHOULD BE
HANDLED ROBUSTLY AND NEVER DISCARDED. WRI WOULD VASTLY IMPROVE THE
USEFULNESS OF MATHEMATICA IF THEY ATTENDED TO THIS.
David Park
dj...@earthlink.net
http://home.earthlink.net/~djmp/
From: t...@tt.com [mailto:t...@tt.com]
Now the question. I have written a few packages in the past. More
recently, I am always questioning myself to know if I should develop
it directly in an ASCII .m file or use the notebook format and rely
on the autosave package feature (initialization cells). I like the
idea of developing the package in the notebook format to have all the
formatting features that ease reading, but at the same time, I hate to
loose all the comments I put in when the *.m file is created. Of
course I could put comments in the input lines of the notebook, but
then I am better writing the ASCII file. Also, I could save the
notebook as a package through "Save as Special" (that puts all the
headers and text in comments, which is not done with the autosave
package feature), but this is not an automated way of doing things. I
am just seeking opinions from Mathematica power users. Which way do you
develop packages?
Cordially.
GL
Bill Rowe
>Now the question. I have written a few packages in the past. More
>recently, I am always questioning myself to know if I should
>develop it directly in an ASCII .m file or use the notebook format
>and rely on the autosave package feature (initialization cells). I
>like the idea of developing the package in the notebook format to
>have all the formatting features that ease reading, but at the same
>time, I hate to loose all the comments I put in when the *.m file
>is created. Of course I could put comments in the input lines of
>the notebook, but then I am better writing the ASCII file. Also, I
>could save the notebook as a package through "Save as Special"
>(that puts all the headers and text in comments, which is not done
>with the autosave package feature), but this is not an automated
>way of doing things. I am just seeking opinions from Mathematica
>power users. Which way do you develop packages?
I started out writing .m files directly in a text editor using the template in one of Maeder's books as a starting point. But I have since migrated to using a notebook relying on initialization cells. But in making this switch, I've not given up including comments.
What I do is create a separate cell for the comments, formatting this cell as a text cell (Format->Style->Text). True, the comments do not appear in the created .m file, but so what? With this method, there is no need to edit the .m file directly. So, the lack of comments in the generated .m file is rather unimportant.
--
To reply via email subtract one hundred and four
Gerry Flanagan
using the notebook interface as an editor. About once a year I give that
a try and decide its hopeless. I'm a big fan of using line-breaks, tabs,
and other pretty-print tricks to add some clarity to the functions. The
automated features in the notebook are clever, but not good enough for
something I want to release within the company. So I end up with
developmental notebooks that feed (copy/paste) a text .m file over time.
BTW, I like a product called UltraEdit for my programming. It allows me
to set up a file of Mathematica keywords so that I can use color syntax
highlighting while editing.
Gerry F.
David Bailey
use the autogenerated package mechanism using initialization cells.
Since all my packages come with help files (or at least meaningful usage
statements) I don't really need comments in the .m file, which I hardly
ever look at. The .m files can be fairly unreadable - but so are JAVA
class files or .EXE files!
David Bailey
http://www.dbaileyconsultancy.co.uk
Jens-Peer Kuska
you are not alone. I usual develop a single function in a notebook and
finaly I copy it into the plane ASCII *.m file. This avoid the "pretty
print"/"smart format" of the frontend. The main problem when developing
a package in a notbook are the BeginPackage[] ... EndPackage[] brackets
because, every time you change a function in the Begin["`Private`"] ..
End[] part you has to evaluate several cells and one tend to forgot this.
The results are strange because your new function is not in the proper
context and will not overwrite the old one ..
Regards
Jens
"Gerry Flanagan" <flan...@materials-sciences.com>
schrieb im Newsbeitrag
news:dmh919$8r1$1...@smc.vnet.net...
Jens-Peer Kuska
Mathematica *and* can find matching brackets and so it is mutch more
helpfull than the FrontEnd.
David Park
Why can't you use line-breaks tabs and spacing in StandardForm expressions
in package notebooks? I do it all the time.
It is the use of comments that is the problem. We don't know their status
and when and how we can or can't use them.
Pratik Desai
>And I forgot to say that my ASCII text editor has syntax coloring for
>Mathematica *and* can find matching brackets and so it is mutch more
>helpfull than the FrontEnd.
>
>
I think you can find matching brackets on the front end using Ctrl+Shift+B
For the syntax coloring free software WinEdt should work fine, it also
has the functionality to delimiter checks and can process Tex files and
such.. Although I admit I have not yet tried to write a package.
Pratik
>Regards
> Jens
>
>"Gerry Flanagan" <flan...@materials-sciences.com>
>schrieb im Newsbeitrag
>news:dmh919$8r1$1...@smc.vnet.net...
>| I'm surprised by the number of people that say
>they develop packages
>| using the notebook interface as an editor. About
>once a year I give that
>| a try and decide its hopeless. I'm a big fan of
>using line-breaks, tabs,
>| and other pretty-print tricks to add some
>clarity to the functions. The
>| automated features in the notebook are clever,
>but not good enough for
>| something I want to release within the company.
>So I end up with
>| developmental notebooks that feed (copy/paste) a
>text .m file over time.
>| BTW, I like a product called UltraEdit for my
>programming. It allows me
>| to set up a file of Mathematica keywords so that
>I can use color syntax
>| highlighting while editing.
>| Gerry F.
>|
--
Pratik Desai
Graduate Student
UMBC
Department of Mechanical Engineering
Phone: 410 455 8134
Trevor Baca
to
AutoIndent -> False
as available in the option inspector.
AutoIndent is set to Automatic by default; set AutoIndent to False and
suddenly you can format your code again, all in the notebook FrontEnd.
(That said, I agree with David that the real problem is the instability
of comments.)
Trevor.