Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: command to save as .m file

  • To: mathgroup at smc.vnet.net
  • Subject: [mg113767] Re: command to save as .m file
  • From: Sebastian <sebhofer at gmail.com>
  • Date: Thu, 11 Nov 2010 06:10:25 -0500 (EST)
  • References: <ibdvkj$8q9$1@smc.vnet.net>

On Nov 10, 12:28 pm, John Fultz <jfu... at wolfram.com> wrote:
> On Mon, 8 Nov 2010 05:40:06 -0500 (EST), Sebastian wrote:
> > On Nov 6, 10:59 am, David Bailey <d... at removedbailey.co.uk> wrote:
> >> On 05/11/10 10:11, David Bailey wrote:
>
> >>> On 04/11/10 09:01, Sebastian wrote:
> >>>> Hi,
> >>>> I've been searching the newsgroup and the web for an answer for
> >>>> this,
> >>>> but all the results were unsatisfactory:
> >>>> Is there a way to save the currently opened .nbfileto a .mfileby
> >>>> using a mathematica command and not the "Save as..." menu command?
> >>>> Please note that I want _all_ the cells to be written to themfile,
> >>>> not only the initialization cells. Even better would be a way to do
> >>>> this on every save of the nb, but I have given up hope that such a
> >>>> thing is possible. All this is part of my effort to find an
> >>>> effective
> >>>> version control solution for my mathematica files.
> >>>> TIA
> >>>> Sebastian
>
> >>> It would definitely help to explain a bit about what you want to
> >>> achiev=
> > e.
>
> >>> However, you could read your notebook with NotebookGet, then write
> >>> that
> >>> messy structure to a .mfilewith Save. It would really help to
> >>> understand how you want to use this.
>
> >>> David Bailey
> >>>http://www.dbaileyconsultancy.co.uk
>
> >> Sorry, I realised after I had written this, that you had explained wha=
t
> >> you are trying to achieve. I have a couple of extra suggestions:
>
> >> 1)   I believe Wolfram Workbench supports version control, but I don=
't
> >> use this because it seems to involve a steep learning curve and is not
> >> particularly well integrated with Mathematica.
>
> >> 2)  Notebooks are actually text files - try opening one with a text
> >> editor. Therefore, it is possible to read a notebook as lines of text
> >> from within Mathematica.
>
> >> David Baileyhttp://www.dbaileyconsultancy.co.uk
>
> > Hi,
> > thanks for your suggestions but they don't really achieve what I'm
> > trying to do. Sorry if it wasn't clear what I was trying to do, so
> > here goes again: By choosing "Save as..." from the file menu and then
> > selecting "Mathematica Package (*.m)" I can save a real "plain text"
> > file as opposed to a notebook (.nb) file, which has all these
> > metainformation and a very "messy structure" as you called it. This I
> > can easily check into a VC system, easily resolve merge conflicts and
> > so on. The problem is, that sometimes I want to edit the notebook
> > files as I want to keep certain output cells and I tend to forget to
> > save it to a package file.
> > Hope that clears things up!
> > Sebastian

Hi John,
thanks for your extensive reply!

> Yes, you can do this, and I'll show you how...but I'm confused about some=
thing.  
> I'm not fully convinced by your revision control strategy.  Either your
> notebooks really are the source document, in which case, you should keep =
them
> under source control regardless of the difficulties.  Or the packages r=
eally are
> the source document, in which case you should be opening/editing/saving t=
hem as
> packages natively (i.e., using Workbench and/or the front end's package
> editor...which play very nicely with each other, I might add), and never =
as
> notebooks.
I'm also not fully convinced by this strategy and I will likely change
it in the future. What I am convinced of is, that putting notebook
files under revision control is a major pain. Either that or I'm just
doing it wrong. I would be grateful for suggestions how to handle
merge conflicts of nb files! Resolving them seems to be a nearly
impossible task and generally not worth the time and hassle! The only
option I see is not to merge nb files at all, which kind of defies the
point of using revision control. So my strategy is twofold:
1) Separate code from output/plots... as much as possible
2) If this is not possible, work on the nb file, save as package and
check that into revision control. If something has to be merged I can
resave to a nb file, which works reasonably well I think... or does it
not?

> Putting generated artifacts under source control...and generating artifac=
ts is
> precisely what Save As->Package from a notebook does...is generally ill-a=
dvised
> and exposes you to either the loss of your source material, or synchroniz=
ation
> problems with that source materia l.
What do you mean by "generated artifacts"? Why does saving to a
package generate artifacts? I am completely lost here, please
elaborate!

> All of those warnings having been stated, here's how you can do what you =
want:
>
> MathLink`CallFrontEnd[
>  FrontEndToken[nb, "Save", {filename, "Package"}]]
>
> where nb is the NotebookObject[] (which you might get from, e.g.,
> InputNotebook[], EvaluationNotebook[], Notebooks[], etc.), and filename i=
s the
> string representing the complete path to the .m file.
>
> Alternatively, you could also set the AutoGeneratedPackage option in the =
Option
> Inspector for the given notebooks, which could force them to always save =
a
> synchronized package file...although this even more greatly magnifies the
> "generated artifact" problem I outlined above.
This is actually what I would like to use, but the auto generated
packages only include initialization cells, which is not enough.

Best regards,
Sebastian


  • Prev by Date: occasional problems with exporting to GIF, Unable to communicate
  • Next by Date: Tensor Contraction
  • Previous by thread: Re: command to save as .m file
  • Next by thread: Re: command to save as .m file