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 <x...@unm.edu> wrote:
| > On Tue, Apr 12, 2011 at 11:07 PM, Romain Francois
| > <rom...@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 | e...@debian.org | http://dirk.eddelbuettel.com
On 04/14/2011 04:20 PM, rcpp-devel-requ...@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
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
