Re: Difficulty with saving Package .m files
- To: mathgroup at smc.vnet.net
- Subject: [mg110522] Re: Difficulty with saving Package .m files
- From: John Fultz <jfultz at wolfram.com>
- Date: Wed, 23 Jun 2010 01:52:23 -0400 (EDT)
On Tue, 22 Jun 2010 07:01:07 -0400 (EDT), M Kelly wrote: > On Jun 18, 6:44 am, John Fultz <jfu... at 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... 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 >> jfu... at 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? In any of the following directories... $UserBaseDirectory\SystemFiles\FrontEnd\StyleSheets $UserBaseDirectory\Autoload\*\SystemFiles\FrontEnd\StyleSheets $UserBaseDirectory\Applications\*\SystemFiles\FrontEnd\StyleSheets (* and ditto all of the above for $BaseDirectory *) Look for any of the following files: Default.nb Core.nb Package.nb My guess is that you might have a copy of an old Default.nb lying around. It's a very bad idea to have a complete replacement for Default.nb from an older version here, and you'll definitely want to remove it. If you think there's any possibility you may have overwritten the files in the installation directory, then you'll just have to do a reinstall. But this is not the kind of thing that one would generally do accidentally or unknowingly. Sincerely, John Fultz jfultz at wolfram.com User Interface Group Wolfram Research, Inc.