This turned out to be nastier than expected, so it's good you pointed it
out.
The problem is not the serialized objects themselves, but the
restoration of the namespace, for package urca in your example.
Because the methods package had not been attached when the user data was
restored, the methods for the urca namespace silently failed to be
cached. So as you noted, no methods for summary(). And since the
namespace was now loaded, library(urca) did not fix the problem. The
silent failure is particularly nasty, since the missing methods may not
show up until much later.
The fix is to modify the startup so that, if the methods package is
included in the list of default packages, it is attached before
restoring user data. That seems to fix the bug, in the examples I tested.
Committed to r-devel only, so far, to allow some more testing before
adding it to 2.4patched.
Pfaff, Bernhard Dr. wrote:
> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> *****************************************************************
> Confidentiality Note: The information contained in this mess...{{dropped}}
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
