SaveImage, LazyLoad, S4 and all that {was "install.R ... files"}
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 Robert
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
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 206-667-7700 rgentlem at fhcrc.org