Re: Difficulty with saving Package .m files
- To: mathgroup at smc.vnet.net
- Subject: [mg110444] Re: Difficulty with saving Package .m files
- From: John Fultz <jfultz at wolfram.com>
- Date: Fri, 18 Jun 2010 07:44:01 -0400 (EDT)
- Reply-to: jfultz at wolfram.com
On Fri, 18 Jun 2010 01:24:57 -0400 (EDT), M Kelly wrote: > On Jun 17, 6:11 am, John Fultz <jfu... at 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... at 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 jfultz at wolfram.com User Interface Group Wolfram Research, Inc.