[Rd] serializing recordedplot object

[Martin Morgan]

On 01/10/2012 02:54 PM, Simon Urbanek wrote:
> On Jan 10, 2012, at 4:12 PM, Jeroen Ooms wrote:
>
>> On Tue, Jan 10, 2012 at 6:17 AM, Simon Urbanek
>> <simon.urbanek at r-project.org>  wrote:
>>> Unfortunately R doesn't provide a way for this. Without changes to unserialization (on the wishlist for a few years now, but not easy to design) the best you can do is to check the native symbols for NULL pointers on usage and then re-fetch - that's something that could be done reasonably easily, although it's still a hack ...
>>
>> Hmm that concerns me a bit. I make heavy use of saveRDS and readRDS in
>> my framework and have assumed that for all practical purposes most
>> objects can be saved to disk and loaded later on without problems. Are
>> there any other types of objects that are not being
>> serialized-unserialized to a state where they are functional again?
>>
>
> No, AFAIR just external pointers (and weak references I presume).
> There is simply no way to serialize them, because by definition such
> objects are transient and only present in the running process. They
> lose meaning the moment the process is terminated.

Maybe obvious so I won't waste public bandwidth, but opened connections 
of all sorts (e.g., to data bases) and [to be explicit] references to c 
/ c++ (probably many packages using Rcpp produce these) objects. Martin

>
>
>> In the case of the NativeSymbolInfo object, it should not be too hard
>> to add an optional feature to unserialize which reloads the package
>> and NativeSymbolInfo when it runs into nullpointers during
>> unserialization? I am currently doing this manually after the
>> unserialization, but that introduces quite some overhead.
>>
>
> You could hard-code a special case of NativeSymbolInfo into R itself, but there are many other uses of external pointers in packages. The practical problem is that by definition you have no way of knowing which code will be able to unserialize a given external pointer. The fact that it is wrapped in a class is quite irrelevant to the pointer itself which doesn't know that. And conversely the class itself doesn't know that it may contain an external pointer - it's just a vanilla structure and you can't feasibly run a method on every single object you unserialize just to find out. Also you would need a special way of creating some raw byte stream that represents the state of the external pointer - apart from the regular serialization. That's why the current "solution" is that code using external pointers checks for NULL pointers and attempts to deal with that by inferring whether it can restore it or not from the information available (which is not always possible).
>
> Cheers,
> Simon
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793