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 <[EMAIL PROTECTED]>
>>>>>>> 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, [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
