From: David Park on
You are absolutely right! WRI is delinquent in showing how to do packages.
In the first place, they don't seem to be certain themselves what is a
preferred method. Nowhere do that take you through the steps that would work
for a typical user. I didn't really learn about Code cells until I started
using Workbench and also read some posts on MathGroup.

There might be one method for simple undocumented packages (basically using
notebooks and Initialization cells) and another method for more extensive
applications with documentation done in Workbench, where you might work with
the package.m files and Code cells.

WRI should really get this down because it is very important for serious
users who are trying to build up a body of knowledge and not just using
Mathematica as a calculator.


David Park
djmpark(a)comcast.net
http://home.comcast.net/~djmpark/



From: M Kelly [mailto:michaelkelly1444(a)gmail.com]


On Jun 17, 6:11 am, John Fultz <jfu...(a)wolfram.com> wrote:
> On Thu, 17 Jun 2010 02:04:10 -0400 (EDT), M Kelly wrote:
> > I am having difficulties in saving or editing the Package .m files.
> > If I open a .m file and attempt to make any changes to it and then
> > Save the file or even use Save As, then it always wraps every line
> > with (* *) annotation brackets, making the file unusable when I
> > attempt to load in the definitions with Get[].
>
> > Does anyone have a solution to this problem, or is it the case that
> > Mathematica is just forcing me to use the IDE Wolfram Workbench to
> > make any changes?
>
> > Any help would be appreciated.
>
> By default, cells created using the Code style will be saved as executable
code,
> while those created using the Input style will be saved as commented code.
The
> two styles are useful so that you can maintain code which you can execute
inside
> the front end for testing or bootstrapping purposes, but which doesn't get
> deployed for runtime use.
>
> If you open a .m file, you should be in an environment where all new cells
> created by default are Code cells. If you're working with a .nb file,
then you
> will have to make sure to manually change the style to Code (Alt+8 or
Cmd+8, or
> Code under the Format->Style menu) before choosing the Save As command and
> creating a package file.
>
> Sincerely,
>
> John Fultz
> jfu...(a)wolfram.com
> User Interface Group
> Wolfram Research, Inc.

Hi again John

I have just gone through the documentation in version 7 and nowhere
can I find a reference to the Code style for cells. It is not
mentioned in the documentation for Cell, Style, Package (.m). And when
you go to the Front End and use the Menu Format->Style there is no
Code style explicitly mentioned.
You have to actually open a package, choose a cell and then go to
Format->Style->Other before it tells you that these are cells with the
style "Code".
Why the secrecy?
Especially since this is a very important aspect of the Mathematica
program: being able to store executable code!
Can this please be resolved with some documentation or others will
have the same unnecessary problems that I experienced.

Regards
Michael



From: telefunkenvf14 on
On Jun 19, 6:48 am, "David Park" <djmp...(a)comcast.net> wrote:
> You are absolutely right! WRI is delinquent in showing how to do packages.
> In the first place, they don't seem to be certain themselves what is a
> preferred method. Nowhere do that take you through the steps that would work
> for a typical user. I didn't really learn about Code cells until I started
> using Workbench and also read some posts on MathGroup.
>
> There might be one method for simple undocumented packages (basically using
> notebooks and Initialization cells) and another method for more extensive
> applications with documentation done in Workbench, where you might work with
> the package.m files and Code cells.
>
> WRI should really get this down because it is very important for serious
> users who are trying to build up a body of knowledge and not just using
> Mathematica as a calculator.

1. I'd add that it would be super-awesome if WRI could also provide
some guidance on how to conduct 'unit-testing' properly in Mathematica. (I've
watched a recent screencast that demonstrates some tests in
Workbench---but doesn't go into detail on how/why to construct such
tests, with non-professional programmers in mind.)

2. A question related to the original question posed by M Kelly:
http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_thread/thread/5e7f4b6288fa8e80?hl=en#

3. Here's a great demonstration by Mike Honeychurch (of WRI) for
building up a complicated function to grab economic data from FRED.
This enables you to follow along with a simple development process and
shows how to turn the end product into a package. Even though some of
the final details on package construction could be fleshed out a bit
more, this remains a gem in the Wolfram Library, IMO.

-RG

>
> David Park
> djmp...(a)comcast.nethttp://home.comcast.net/~djmpark/
>
> From: M Kelly [mailto:michaelkelly1...(a)gmail.com]
>
> On Jun 17, 6:11 am, John Fultz <jfu...(a)wolfram.com> wrote:
>
>
>
> > On Thu, 17 Jun 2010 02:04:10 -0400 (EDT), M Kelly wrote:
> > > I am having difficulties in saving or editing the Package .m files.
> > > If I open a .m file and attempt to make any changes to it and then
> > > Save the file or even use Save As, then it always wraps every line
> > > with (* *) annotation brackets, making the file unusable when I
> > > attempt to load in the definitions with Get[].
>
> > > Does anyone have a solution to this problem, or is it the case that
> > > Mathematica is just forcing me to use the IDE Wolfram Workbench to
> > > make any changes?
>
> > > Any help would be appreciated.
>
> > By default, cells created using the Code style will be saved as executable
> code,
> > while those created using the Input style will be saved as commented code.
> The
> > two styles are useful so that you can maintain code which you can execute
> inside
> > the front end for testing or bootstrapping purposes, but which doesn't get
> > deployed for runtime use.
>
> > If you open a .m file, you should be in an environment where all new cells
> > created by default are Code cells. If you're working with a .nb file,
> then you
> > will have to make sure to manually change the style to Code (Alt+8 or
> Cmd+8, or
> > Code under the Format->Style menu) before choosing the Save As command and
> > creating a package file.
>
> > Sincerely,
>
> > John Fultz
> > jfu...(a)wolfram.com
> > User Interface Group
> > Wolfram Research, Inc.
>
> Hi again John
>
> I have just gone through the documentation in version 7 and nowhere
> can I find a reference to the Code style for cells. It is not
> mentioned in the documentation for Cell, Style, Package (.m). And when
> you go to the Front End and use the Menu Format->Style there is no
> Code style explicitly mentioned.
> You have to actually open a package, choose a cell and then go to
> Format->Style->Other before it tells you that these are cells with the
> style "Code".
> Why the secrecy?
> Especially since this is a very important aspect of the Mathematica
> program: being able to store executable code!
> Can this please be resolved with some documentation or others will
> have the same unnecessary problems that I experienced.
>
> Regards
> Michael


From: telefunkenvf14 on
On Jun 21, 1:16 am, telefunkenvf14 <rgo...(a)gmail.com> wrote:
> On Jun 19, 6:48 am, "David Park" <djmp...(a)comcast.net> wrote:
>
> > You are absolutely right! WRI is delinquent in showing how to do packages.
> > In the first place, they don't seem to be certain themselves what is a
> > preferred method. Nowhere do that take you through the steps that would work
> > for a typical user. I didn't really learn about Code cells until I started
> > using Workbench and also read some posts on MathGroup.
>
> > There might be one method for simple undocumented packages (basically using
> > notebooks and Initialization cells) and another method for more extensive
> > applications with documentation done in Workbench, where you might work with
> > the package.m files and Code cells.
>
> > WRI should really get this down because it is very important for serious
> > users who are trying to build up a body of knowledge and not just using
> > Mathematica as a calculator.
>
> 1. I'd add that it would be super-awesome if WRI could also provide
> some guidance on how to conduct 'unit-testing' properly in Mathematica. (I've
> watched a recent screencast that demonstrates some tests in
> Workbench---but doesn't go into detail on how/why to construct such
> tests, with non-professional programmers in mind.)
>
> 2. A question related to the original question posed by M Kelly:http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_...
>
> 3. Here's a great demonstration by Mike Honeychurch (of WRI) for
> building up a complicated function to grab economic data from FRED.
> This enables you to follow along with a simple development process and
> shows how to turn the end product into a package. Even though some of
> the final details on package construction could be fleshed out a bit
> more, this remains a gem in the Wolfram Library, IMO.

Below is the link to Mike's FRED package. Man, I hate it when I do
that. :)

http://library.wolfram.com/infocenter/MathSource/7583/

From: M Kelly on
On Jun 18, 6:44 am, John Fultz <jfu...(a)wolfram.com> wrote:
> On Fri, 18 Jun 2010 01:24:57 -0400 (EDT), M Kelly wrote:
> > On Jun 17, 6:11 am, John Fultz <jfu...(a)wolfram.com> wrote:
> >> On Thu, 17 Jun 2010 02:04:10 -0400 (EDT), M Kelly wrote:
> >>> I am having difficulties in saving or editing the Package .m files.
> >>> If I open a .m file and attempt to make any changes to it and then
> >>> Save the file or even use Save As, then it always wraps every line
> >>> with (* *) annotation brackets, making the file unusable when I
> >>> attempt to load in the definitions with Get[].
>
> >>> Does anyone have a solution to this problem, or is it the case that
> >>> Mathematica is just forcing me to use the IDE Wolfram Workbench to
> >>> make any changes?
>
> >>> Any help would be appreciated.
>
> >> By default, cells created using the Code style will be saved as
> >> executable code,
> >> while those created using the Input style will be saved as commented
> >> code. The
> >> two styles are useful so that you can maintain code which you can
> >> execute inside
> >> the front end for testing or bootstrapping purposes, but which doesn't
> >> get
> >> deployed for runtime use.
>
> >> If you open a .m file, you should be in an environment where all new
> >> cells
> >> created by default are Code cells. If you're working with a .nb file,
> >> then you
> >> will have to make sure to manually change the style to Code (Alt+8 or
> >> Cmd+8, or
> >> Code under the Format->Style menu) before choosing the Save As command
> >> and
> >> creating a package file.
>
> >> Sincerely,
>
> >> John Fultz
> >> jfu...(a)wolfram.com
> >> User Interface Group
> >> Wolfram Research, Inc.
>
> > Thanks John
>
> > I appreciate your quick response.
> > But why didn't WRI just stick with the old system of using
> > Initialization cells?
> > This worked in both environments.
>
> I don't know what you mean by "both environments". The Code style was
> introduced simultaneously with the package editor, if that's the environment you
> mean. And the Code style sets the InitializationCell option.
>
> > Also I was unable to find anywhere
> > in the documentation that
> > mentions Code cells. Shouldn't the tutorial and Guide on Packages at
> > least make some reference to this important difference for .m files?
>
> I don't disagree that this could be better documented.
>
> > Regards
> > Michael
> > Hi again John
>
> > I have just gone through the documentation in version 7 and nowhere
> > can I find a reference to the Code style for cells. It is not
> > mentioned in the documentation for Cell, Style, Package (.m). And when
> > you go to the Front End and use the Menu Format->Style there is no
> > Code style explicitly mentioned.
>
> Unless you're using a legacy notebook with an embedded legacy stylesheet, or
> unless you have a stylesheet sitting in $UserBaseDirectory or $BaseDirectory
> that's overriding the default behavior, then you've just overlooked it. It's
> sitting right between Text and Input in that menu.
>
> > You have to actually open a package, choose a cell and then go to
> > Format->Style->Other before it tells you that these are cells with the
> > style "Code".
> > Why the secrecy?
>
> There is no secrecy. The behavior you describe is neither the designed behavior
> nor the behavior which has been observed by many people on this forum (where the
> package editor and the Code style have been occasionally discussed in the past
> few years).
>
> Additionally, the Code style is the default cell style in the package editor.
> The default behavior is to create package code...you actually have to do
> something different if you want to create Input cells which are not part of the
> package code.
>
> > Especially since this is a very important aspect of the Mathematica
> > program: being able to store executable code!
> > Can this please be resolved with some documentation or others will
> > have the same unnecessary problems that I experienced.
>
> > Regards
> > Michael
>
> Sincerely,
>
> John Fultz
> jfu...(a)wolfram.com
> User Interface Group
> Wolfram Research, Inc.- Hide quoted text -
>
> - Show quoted text -

Thanks John for the update.

However there must be some problem either with my installation or the
existence of some legacy style sheet which is confusing the program
because the only Style between Text and Input in my Format menu is
SmallText. There are no legacy Stylesheets in the $UserBaseDirectory.
However I do have old style sheets in SystemFiles > FrontEnd >
StyleSheets.
Do you think that these might be causing the problem?
Having old (legacy) notebooks and Stylesheets is a concomitant side
effect of being a long term devoted Mathematica user.
If old Stylesheets and any other old System files are a source of
problems, how can we replace them without going through all the bother
of reinstallation?

From: M Kelly on
On Jun 21, 4:00 am, telefunkenvf14 <rgo...(a)gmail.com> wrote:
> On Jun 21, 1:16 am, telefunkenvf14 <rgo...(a)gmail.com> wrote:
>
>
>
>
>
> > On Jun 19, 6:48 am, "David Park" <djmp...(a)comcast.net> wrote:
>
> > > You are absolutely right! WRI is delinquent in showing how to do packages.
> > > In the first place, they don't seem to be certain themselves what is a
> > > preferred method. Nowhere do that take you through the steps that would work
> > > for a typical user. I didn't really learn about Code cells until I started
> > > using Workbench and also read some posts on MathGroup.
>
> > > There might be one method for simple undocumented packages (basically using
> > > notebooks and Initialization cells) and another method for more extensive
> > > applications with documentation done in Workbench, where you might work with
> > > the package.m files and Code cells.
>
> > > WRI should really get this down because it is very important for serious
> > > users who are trying to build up a body of knowledge and not just using
> > > Mathematica as a calculator.
>
> > 1. I'd add that it would be super-awesome if WRI could also provide
> > some guidance on how to conduct 'unit-testing' properly in Mathematica. (I've
> > watched a recent screencast that demonstrates some tests in
> > Workbench---but doesn't go into detail on how/why to construct such
> > tests, with non-professional programmers in mind.)
>
> > 2. A question related to the original question posed by M Kelly:http://groups.google.com/group/comp.soft-sys.math.mathematica/browse_...
>
> > 3. Here's a great demonstration by Mike Honeychurch (of WRI) for
> > building up a complicated function to grab economic data from FRED.
> > This enables you to follow along with a simple development process and
> > shows how to turn the end product into a package. Even though some of
> > the final details on package construction could be fleshed out a bit
> > more, this remains a gem in the Wolfram Library, IMO.
>
> Below is the link to Mike's FRED package. Man, I hate it when I do
> that. :)
>
> http://library.wolfram.com/infocenter/MathSource/7583/- Hide quoted text -
>
> - Show quoted text -

Thanks RG for this reference

Regards
M Kelly