[Rcpp-devel] R.e. loadRcppModules

[Romain Francois]

Hi,

This is something I/we need to concentrate on, so that we find the right 
way to deal with it.

I'm not sure at the moment how much work this will be.

I think R-ints has the answers to the questions I'm not asking myself yet.

Romain

Le 25/05/11 18:29, Christoph Bergmeir a écrit :
> Hi list,
>
> I remembered that this discussion was going on here about 6 weeks back,
> and now I have nearly the same problem. Maybe somebody has made any
> progress:
>
> Luckily, I have for some of my C++ objects a serialization function
> ready. So I'd like to make them survive the save/restart/load cycle. The
> pointer to the C++ object is inside of an S3 object. So the general idea
> as I understood it so far is:
>
> - serialize the C++ object, store it in the S3 object
> - do save/restart/load
> - build a new C++ object out of the serialization.
>
> Some questions arise:
>
> - How will the S3 class notify that it is going to be saved? I heard
> about finalizers, but aren't they called also if I just delete the
> object? And arent they called *after* save?
> - Same for load...This is somewhat more easy because if I get a
> NULL-pointer I can just try to load the serialization. But still: Can
> the object be notified that it just was loaded?
>
> Regards,
> Christoph
>
> PD: I know that this is more of a general R question, and maybe the
> solution is somewhere hidden in the R-exts or R-ints documents..however,
> I didn't find nothing there, and as I stated, I think its exactly the
> same problem that was discussed here earlier, so I'll ask the question
> here...
>
> On 14 April 2011 at 07:49, Douglas Bates wrote:
> | On Thu, Apr 14, 2011 at 12:43 AM, Christian Gunning <xian at unm.edu> wrote:
> | > On Tue, Apr 12, 2011 at 11:07 PM, Romain Francois
> | > <romain at r-enthusiasts.com> wrote:
> | >>>
> | >>> Just to clarify -- ?does your plan include storing user-modified
> | >>> fields and properties in objects? ?E.g. below, modtest with the msg
> | >>> set?
> | >>
> | >> yes. Although the way I see it, this will require more work for the
> | >> developper, who would have to provide a
> serialization/deserialization couple
> | >> for his/her classes.
> | >>
> | >> This is a nice goal for a future version.
> | >
> | > Am I naive to think that a 1-to-1 mapping between C++ object fields &
> | > properties and an S4 object might make sense? ?This reduces the module
> | > developer's problem of serial/deserialization to 1) writing a
> | > constructor (and perhaps with validator) that takes an S4 object, and
> | > 2) writing a finalizer that populates a specified S4 object in the
> | > user's environment, tears down the C++ object (as per R Exts manual),
> | > and let's save() do the rest?
> | >
> | > It seems that, in theory, there's a canonical mapping between the
> | > names/types of fields/properties exposed in the RCPP_MODULE call and
> | > the proposed S4 object. ?The main gotcha I see here is that any
> | > variable within a C++ object *not* exposed as a field/property must be
> | > viewed as a const to ensure consistency of the C++ object between
> | > write and re-construct...
> | >
> | > If this is off-base, feel free to ignore or point out good reading
> material :)
> |
> | I don't think it is off-base. I was planning something very similar
> | to that except that not every field/property would be saved. I have
> | classes in which many of the properties are calculated on the fly and
> | I don't need to save those. I just need to save enough information to
> | create the object again.
> |
> | This approach would run into trouble if there were data fields in the
> | C++ object that could not be expressed as R objects. However, it
> | seems to me that if the C++ object can be generated from R objects in
> | the first place you should be able to serialize enough information to
> | reconstruct it.
>
> This really is darn close to what RProtoBuf does to fit into (Google's)
> Protocol Buffers "everything to everyone" scheme reportedly used for all
> intermachine (and interlanguage) communication. But that would of course
> introduce a new non-R dependency so you probably do not want that here.
>
> So we'd have to reinvent a suitable subset, leaning on R's serialization.
>
> Too bad we didn't have that insight four weeks ago. This would have made a
> swell project for Google Summer of Code. I blame Christian ;-)
>
> Dirk
>
> -- Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>
> On 04/14/2011 04:20 PM, rcpp-devel-request at r-forge.wu-wien.ac.at wrote:
>> Re: R.e. loadRcppModules
>
>


-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/hdKhCy : Rcpp article in JSS
|- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
`- http://bit.ly/fhqbRC : Rcpp workshop in Chicago on April 28th