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