[Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image
Pfaff, Bernhard Dr.
Bernhard_Pfaff at fra.invesco.com
Fri Nov 3 16:55:28 CET 2006
Dear John, Dear Seth,
many (a thousands) thanks for your clarification and highlighting of the
problem.
>It's not a simple serialization issue, but related to the initial
>computations when a saved image is reloaded at the start of a session,
>so the implication is less general than you imply.
Hm, yes, that seems to be true. I do not know what the R-wizard Prof.
Douglas Bates has done, but going through the same exercise with:
library(lme4)
example(lmer)
saving the work space (without moving it to another file), quitting R
and starting such that the previously work space is restored, will yield
the following:
> ls()
[1] "fm1" "fm2"
> showMethods("summary")
Function "summary":
<not a generic function>
> fm1
Loading required package: lme4
Loading required package: Matrix
Loading required package: lattice
## output as expected, but omitted here
Well, John, referring to your question. IMHO it is a question how useRs
work with R. Personnaly, I almost never work with work spaces but rather
scripts: write it - like it or fudge it. Anyway, a useR has pointed me
to this behaviour and I reckon that he uses the 'save work
space'-approach for an E-lab class that he teaches.
Aside, of this issue and something more for R-Core, I am wondering if
some hint/pointer should be placed in the R-ext document (maybe in the
section 'Package name spaces' and/or in the subsection 'The DESCRIPTION
file'). I have re-read it, but could not find a hint with respect to
'methods' and 'S4'.
Let me thank you once more for your time taken, patience devoted and
enlightenment given to this problem. I must confess, that 'serialization
of R objects' is beyond the scope of my computer literacy as an
economist.
Gratefully,
Bernhard
>
>If you move the saved image to another file, say "savedImage", then:
>
> > load("savedImage")
> > library(urca)
> > showMethods("summary")
>Function: summary (package base)
>object="ANY"
>object="ca.jo"
>object="ca.po"
>object="cajo.test"
>object="ur.df"
>object="ur.ers"
>object="ur.kpss"
>object="ur.pp"
>object="ur.sp"
>object="ur.za"
>
>and summary(lc.df) then works as expected.
>
>So the workaround, other than inserting all the import(methods), etc.
>you can think of, seems to be to save/load explicitly.
>
>Seth Falcon wrote:
>> John Chambers <jmc at r-project.org> writes:
>>
>>
>>> I haven't had a chance to verify these exact examples, but
>the likely
>>> explanation is that loading the workspace does not cache the saved
>>> methods. Assuming this is indeed what's happening, the
>workaround is to
>>> cache them "manually" by the call:
>>>
>>> cacheMetaData(.GlobalEnv)
>>>
>>> (after attaching the relevant library)
>>>
>>> It would be nice to have the same effect occur
>automatically, but there
>>> may be issues since the needed class definitions may not be
>available
>>> when the saved workspace is reloaded.
>>>
>>> A natural question to ask is whether there is some
>practical motivation
>>> for this exercise.
>>>
>>
>> The main use case is that since serialization of objects is such an
>> R-ish thing to do, you really want to have deserialized S4 instances
>> "work" properly when loaded.
>>
>> I admit that it is also useful to be able to load an arbitrary object
>> and inspect it even if it will be "broken" (without this, it would be
>> very hard to write any sort of automated class update code).
> It would
>> seem that this behavior could be achieved in a force=TRUE mode and
>> that otherwise, it would be an error to deserialize an S4 instance
>> when the class def is not available.
>>
>> + seth
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
>______________________________________________
>R-devel at r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
*****************************************************************
Confidentiality Note: The information contained in this mess...{{dropped}}
More information about the R-devel
mailing list