Re: command to save as .m file
- To: mathgroup at smc.vnet.net
- Subject: [mg113860] Re: command to save as .m file
- From: Sebastian <sebhofer at gmail.com>
- Date: Tue, 16 Nov 2010 05:05:05 -0500 (EST)
- References: <ibj4p0$fi7$1@smc.vnet.net>
On Nov 12, 11:26 am, John Fultz <jfu... at wolfram.com> wrote:
> On Thu, 11 Nov 2010 06:10:25 -0500 (EST), Sebastian wrote:
> > On Nov 10, 12:28 pm, John Fultz <jfu... at wolfram.com> wrote:
> > Hi John,
> > thanks for your extensive reply!
>
> >> Yes, you can do this, and I'll show you how...but I'm confused about
> >> something. 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 really are the source document, in which case you should
> >> be opening/editing/saving them 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?
>
> Merge conflicts are not easy to deal with for notebooks. They can be minimized
> by working with notebooks without file outline caches. If you set the
> PrivateNotebookOptions->{"FileOutlineCache"->False} option on an individual
> notebook, then the file outline cache drops away. Which means that it loads
> more slowly, but also gets rid of the guaranteed source of merge conflicts.
>
> What remains does, sometimes, merge successfully. When it fails, things are
> still going to be very bad, but it does at least succeed sometimes. And
> possibly quite often, depending upon the kinds of changes being made to the
> notebook.
>
> >> Putting generated artifacts under source control...and generating
> >> artifacts is precisely what Save As->Package from a notebook does...is
> >> generally ill- advised and exposes you to either the loss of your source
> >> material, or synchronization problems with that source material.
> > What do you mean by "generated artifacts"? Why does saving to a
> > package generate artifacts? I am completely lost here, please
> > elaborate!
>
> Let me start with a simple explanation which you may already understand, but
> just to make sure we're on the same page. There's a general principle in
> version control that you try to put only sources, not built objects or, as I'm
> calling them, generated artifacts. If you were working with Java, you would put
> .java files under source control, but not .class or .jar files. If you were
> working with C/C++, you'd put .c/.cpp/.h/.hpp files under source control, but
> not .obj/.a/.exe/.lib/.so/.dll files.
>
> When you're working with notebooks as the source medium, and you do File->Save
> As->Package, you are generating that package file from something which is *not*
> the source. It may not be compiled, but it's generated all the same. And
> you're losing information, and risking the possibility of things getting out of
> sync.
This makes perfect sense of course, although I would say that the
situation is a bit different with .nb <> .m files, as they carry
equivalent information - at least for the purposes I am concerned
with. So I agree that this creates the risk of the documents getting
out of sync, but more for practical reasons (me not working thoroughly
enough) than for fundamental reasons.
> The Mathematica front end has a quite nice package editor. Perhaps you're not
> aware of this, but the front end's package editor can preserve quite a lot of
> style and cell group structure with simple comments which are not cumbersome
> when you see them in Workbench or a text editor (in fact, they can be
> enlightening!). At Wolfram, some people prefer working in the package edit or
> and use it in preference to working in other environments because it maintains a
> very notebook-like environment while working much closer to the plain text model
> of package files. In their case, the package file is the *primary* source file,
> not a secondary file generated by a conversion step. But it doesn't preserve
> outputs, which you seem to be suggesting you're looking for.
I would really prefer to work with .m files, as I like their clean,
slim, plain text structure, compared to the - excuse me - bloated nb
files (of course I have no evidence to back this up, this is just my
impression).
Anyway, the longer you keep talking about switching to package files
altogether, the more seriously I consider to try doing that. Let me
just give you an explanation why I started this discussion in the
first place (also as an reply to Albert's post): I am a physicist and
as such I create plots in various forms and sizes. Some of them take a
(long) while to create, some of them are quick but nice to have
"inline" as a documentation of what the code really does. If you
haven't looked at your code for some months and then come back to
calculate something, it's just easier to look at your plots in order
to figure out what parts of the code you have to execute - especially
if it is more a series of small consecutive steps (as you would do it
with pen and paper) rather than a large routine. Still, I want to be
able to put this kind of files under VC. So if you have any thoughts
on that, please let me know.
Best regards,
Sebastian