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 <[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
--
Brian D. Ripley, [EMAIL PROTECTED]
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
