[Rd] SaveImage, LazyLoad, S4 and all that {was "install.R ... files"}

[Prof Brian Ripley]

On Fri, 3 Feb 2006, Robert Gentleman wrote:

> My understanding, and John or others may correct that, is that you need 
> SaveImage if you want to have the class hierarchy and generic functions, plus 
> associated methods all created and saved at build time.

That meaning the time of using R CMD INSTALL rather than using R CMD 
build, I guess?  (We do have an unfortunate ambiguity.)

> This is basically a sort of compilation step, and IMHO, should always be 
> done since it only needs to be done once, rather than every time a 
> package is loaded. Note that attaching your methods to other people's 
> generics has to happen at load time, since you won't necessarily know 
> where they are or even what they are until then (using an import 
> directive may alleviate some of those issues but I have not tested just 
> what does and does not work currently).

My understanding is that `compilation step' creates objects which are then 
saved in the image.  Such objects would also be saved if the image is 
converted into a lazyload database.

> I hope that LazyLoad does what it says it does, that is dissociates the value 
> from the symbol in such a way that the value lives on disk until it is 
> wanted, but the symbol is available at package load time. I do not see how 
> this relates to precomputing an image,

You obviously have this defined a different way to me: I believe (and so 
does my dictionary) that the image is what I save in my camera, not the 
real world scene.  I understand 'save' to save an image of an environment, 
that is to make a representation on a connection that can be used to 
recreate the environment at a later date.

> and would not be very happy if the two ideas became one, they really are 
> different and can be used to solve very different problems.

To create a lazyload database you first need an environment to save. On 
loading the package it then recreates not the environment but symbols 
linked to promises that will recreate the values at a later date.  So both 
mechanisms create an environment which they `image' in different ways.

The difference here is an inadvertent difference in the Unix INSTALL 
script, which I have now corrected.


> Prof Brian Ripley wrote:
>> The short answer is that there are no known (i.e. documented) differences, 
>> and no examples on CRAN which do not work with lazy-loading (except party, 
>> which loads the saved image in a test).  And that includes examples of 
>> packages which share S4 classes.  But my question was to tease things like 
>> this out.
>> 
>> You do need either SaveImage or LazyLoad in a package that defines S4 
>> classes and methods, since SetClass etc break the `rules' for R files in 
>> packages in `Writing R Extensions'.
>> 
>> When I have time I will take a closer look at this example.
>> 
>> 
>> On Fri, 3 Feb 2006, Martin Maechler wrote:
>> 
>> 
>>>>>>>> "Seth" == Seth Falcon <sfalcon at fhcrc.org>
>>>>>>>>    on Thu, 02 Feb 2006 11:32:42 -0800 writes:
>>> 
>>>   Seth> Thanks for the explaination of LazyLoad, that's very helpful.
>>>   Seth> On  1 Feb 2006, ripley at stats.ox.ac.uk wrote:
>>>   >> There is no intention to withdraw SaveImage: yes.  Rather, if
>>>   >> lazy-loading is not doing a complete job, we could see if it could
>>>   >> be improved.
>>> 
>>>   Seth> It seems to me that LazyLoad does something different with respect 
>>> to
>>>   Seth> packages listed in Depends and/or how it interacts with 
>>> namespaces.
>>> 
>>>   Seth> I'm testing using the Bioconductor package graph and find that if 
>>> I
>>>   Seth> change SaveImage to LazyLoad I get the following:
>>> 
>>> Interesting.
>>> 
>>> I had also the vague feeling that  saveImage  was said to be
>>> important when using  S4 classes and methods; particularly when
>>> some methods are for generics from a different package/Namespace
>>> and other methods for `base' classes (or other classes defined
>>> elsewhere).
>>> This is the case of 'Matrix', my primary experience here.
>>> OTOH, we now only use 'LazyLoad: yes' , not (any more?)
>>> 'SaveImage: yes' -- and honestly I don't know / remember why.
>>> 
>>> Martin
>>> 
>>> 
>>>   Seth> ** preparing package for lazy loading
>>>   Seth> Error in makeClassRepresentation(Class, properties, superClasses, 
>>> prototype,  :
>>>   Seth> couldn't find function "getuuid"
>>> 
>>>   Seth> Looking at the NAMESPACE for the graph package, it looks like it 
>>> is
>>>   Seth> missing some imports.  I added lines:
>>>   Seth> import(Ruuid)
>>>   Seth> exportClasses(Ruuid)
>>> 
>>>   Seth> Aside: am I correct in my reading of the extension manual that if 
>>> one
>>>   Seth> uses S4 classes from another package with a namespace, one
>>>   Seth> must import the classes and *also* export them?
>>> 
>>>   Seth> Now I see this:
>>> 
>>>   Seth> ** preparing package for lazy loading
>>>   Seth> Error in getClass("Ruuid") : "Ruuid" is not a defined class
>>>   Seth> Error: unable to load R code in package 'graph'
>>>   Seth> Execution halted
>>> 
>>>   Seth> But Ruuid _is_ defined and exported in the Ruuid package.
>>> 
>>>   Seth> Is there a known difference in how dependencies and imports are
>>>   Seth> handled with LazyLoad as opposed to SaveImage?
>>> 
>>>   Seth> Thanks,
>>> 
>>>   Seth> + seth

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595