[Rd] Saving nothing with save()

Martin Maechler maechler at stat.math.ethz.ch
Tue Dec 20 19:40:15 CET 2011


>>>>> Simon Urbanek <simon.urbanek at r-project.org>
>>>>>     on Mon, 19 Dec 2011 10:38:34 -0500 writes:

    > Martin, On Dec 19, 2011, at 6:39 AM, Martin Maechler
    > wrote:

    >>>>>>> Barry Rowlingson <b.rowlingson at lancaster.ac.uk> on
    >>>>>>> Sun, 18 Dec 2011 01:32:52 +0000 writes:
    >> 
    >>> Scenario: Here I am working away in R. I've got results
    >>> that prove global warming is anthropogenic and also the
    >>> solution for producing limitless carbon-neutral energy
    >>> from nuclear fusion. Its been a good day.
    >> 
    >>> So, I want to save my work. I don't want to overwrite my
    >>> current .RData, so I save it to another file:
    >> 
    >>> save(file="prize.RData") # just need to email this to
    >>> the Nobel committee q() Save workspace image? [y/n/c]: -
    >>> "no" I don't want to save the workspace image, I just
    >>> saved everything to "prize.RData". But gee, it did seem
    >>> to do that quite quickly considering the volume of
    >>> evidential data in my work. My unix shell prompt
    >>> returns.
    >> 
    >>> Uh oh. See what I did there? I typed 'save' when I meant
    >>> 'save.image'.  What does that give me?
    >> 
    >>> A 42 byte, empty, latest.RData, and because there was no
    >>> warning or error I quit without saving it
    >>> again. Oops. Massive Data Loss.
    >> 
    >>> Is there any reason why save(file="file.RData") couldn't
    >>> warn or error if you try and save nothing? There's no
    >>> obvious check in the R code for save.
    >> 
    >>> Barry
    >> 
    >>> PS the above scenario is fictional.
    >> really?  ;-)
    >> 
    >> well, after *not* save()ing all your findings, it
    >> wouldn't have been such a good day, would it?
    >> 
    >> well, in spite of that.  I agree that save() should warn
    >> or stop in that case.  I have now committed a version --
    >> to R-devel only -- which stop()s if 'pretest=TRUE' and
    >> uses warning() otherwise,

    > I don't think I like that - why should it warn/stop in any
    > case even when the use is absolutely legal?

    > I think this is the wrong approach - the whole idea was to
    > warn on unintended *interactive* use - breaking existing
    > code in the process is IMHO not necessary. I don't think
    > save(list=x, file=y) should fail even if x is empty - that
    > makes it fail for completely legal code. What Barry was
    > worried about was the interactive case of save(file=x)
    > which should IMHO warn (there is a precedent for stopping
    > as well - see tar - so I won't object).

    > I really see no reason for adding the pretest flag - it
    > makes no sense since is warns anyway so it doesn't help at
    > all. I would propose changing *only* the behavior of
    > save(file=x) (to warn or stop - personally I prefer
    > former) and not anything else.

hmm


    >> e.g., in the case of save.image() when there's nothing to
    >> save.
    >> 

    > Why should save.image() warn? Again, it causes unnecessary
    > trouble for automated saving... empty workspace is
    > probably even more common that using save(file=foo) ... If
    > save() was fixed as above, that would be a non-issue.

warning in that case actually *was* a bit intentional:
I think too many people work with '.Rdata' etc ... and I always
use --no-save --no-restore.

But then, you are right.  If we'd want to change that behavior
that should be tried differently...

I've now changed the patch to only warn and only in the case
when the 'list' argument is missing(.).

Martin

    >> Thank you, Barry. for the suggestion!

    > Well, you did not follow his suggestion, though ;)

    > Cheers, Simon


    >> Martin
    >> 
    >>> When did I last have a good day?
    >> 
    >> (I wish you more of those..)
    >> 
    >> ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 
    >>



More information about the R-devel mailing list