On 6/27/12 7:07 AM, Douglas Bates wrote:
On Tue, Jun 26, 2012 at 7:04 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
On 26 June 2012 at 17:21, Jiqiang Guo wrote:
| Dear List,
|
| I am wondering if there is a way to check whether an object created from
Rcpp's
| module is valid or not especially for objects loaded in another session.
|
| In detail, we know that we could not save and load objects created from Rcpp's
| module [section 5 of http://cran.r-project.org/web/packages/Rcpp/vignettes/
| Rcpp-modules.pdf]. But that does not prevent users doing that. So if an
| object created from Rcpp's module is loaded in another session, we would end
up
| with errors or even segfault. It would be nice we have a method to check if
| it is valid or not so that when we are writing a package, we could do a check
| before calling those methods of that object.
It's a very good idea. I don't have a good idea as to how we'd do this though.
There has to be one or more external pointers in the R object
somewhere (although I spent some time looking at the Rcpp-modules code
and came away very confused so I can't tell you exactly where.) That
pointer will become a NULL pointer after a serialize/unserialize
sequence so you need to check for its being NULL. This is why the
reference classes in the development version of lme4 have a field
named ptr and a method named Ptr. The Ptr method first checks if ptr
is a null pointer and, if so, regenerates the object then returns ptr.
I can say from experience that this all gets rather complicated.
However I haven't looked at John Chambers' new code for Rcpp classes
in R and he might have addressed the issue.
Well, no, and it doesn't seem particularly a modules issue, but rather a
general point in using C++ data in R. Since C++ deals with run-time
object pointers, there is always the likelihood that an arbitrary
reference to such objects will fail to serialize.
What one could easily write is a recursive check on an object that looks
for any elements, attributes or objects in environments that are
external pointer types with NULL values. That would be a good thing to
have--maybe someone did this as part of general QC software?
Given that, we could perhaps embed this in code that unserializes class
"C++Object". Of course, one can check but clearly there is no universal
repair method.
John
Dirk
| An illustrative example:
|
| require("Rcpp")
| require("inline")
|
| inc <- '
| class Foo {
| private:
| int x_;
| public:
| Foo(int x) : x_(x) { }
| int getx() const { return x_;}
| };
|
| RCPP_MODULE(foo) {
| class_<Foo>("Foo")
| .constructor<int>()
| .method("getx", &Foo::getx)
| ;
| }
|
| fx <- cxxfunction(signature(), "", include = inc, plugin = "Rcpp", verbose =
| FALSE)
| m <- Module("foo", getDynLib(fx))
| cppo = new(m$Foo, 5)
|
| print(cppo$getx())
| save("cppo", file = 'cppo.RData')
|
| rm(list = ls())
| load("cppo.RData")
| print(cppo$getx())
|
| For the above code, we know the last line would not work. If we have a
| function to test the validity of cppo,then if not valid, we would not call
| cppo's function and are able to tell users that cppo is not valid any more.
|
| Best,
| Jiqiang
|
| ----------------------------------------------------------------------
| _______________________________________________
| 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
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
