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

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Sun 05 Feb 2006 - 15:50:30 GMT

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@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@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@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

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Mon Feb 06 02:57:56 2006

This archive was generated by hypermail 2.1.8 : Sun 05 Feb 2006 - 20:20:52 GMT