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

From: Robert Gentleman <>
Date: Fri 03 Feb 2006 - 16:00:41 GMT

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. 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).

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, 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.

best wishes

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 <>
>>>>>>> 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, 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:
>>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
>>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.
>> 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
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024

______________________________________________ mailing list
Received on Sat Feb 04 03:13:19 2006

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:40 GMT