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