[Rcpp-devel] R.e. loadRcppModules

Christian Gunning xian at unm.edu
Tue Apr 12 04:15:25 CEST 2011


On Mon, Apr 11, 2011 at 3:00 AM,
<rcpp-devel-request at r-forge.wu-wien.ac.at> wrote:
>
>
> This will load the declared modules, and populate them into your
> package's namespace.
>
> I will update the Rcpp-modules vignette accordingly.
>
> Suggestions, comments, improvements, "what are you  ? nuts !", ... are
> always welcome.

Works great for me -- very cool.

One question that's been bothering me -- how are module-based objects
*supposed* to behave across an R session quit/save/restart cycle? I'm
seeing no persistence, and a consistent segfault.  Am I missing
something here (perhaps wrt finalizer)?  If not, I'd like to add a
note to the vignette...

Using the supplied example, I get:

Rcpp.package.skeleton('testpkg1', module=T)
require(testpkg1)
modtest <- new(World)
## everything works
show(modtest)
modtest$set('hello')
modtest$greet()
q()
## Save workspace image? [y/n/c]: y
## exit, save, restart -- nothing works

# [Previously saved workspace restored]
#
# During startup - Warning message:
# Class "C++Object" is defined (with package slot ‘Rcpp’) but no
metadata object found to revise subclass information---not exported?
Making a copy in package ‘.GlobalEnv’

require(testpkg1)
modtest$greet()
#Error in .External(list(name = "CppMethod__invoke_notvoid", address =
<pointer: (nil)>,  :
#  NULL value passed as symbol address

show(modtest)

 *** caught segfault ***
address 0x8, cause 'memory not mapped'

Traceback:
 1: .Call(Class__name, cppclass)
 2: sprintf("C++ object <%s> of class '%s' <%s>",
externalptr_address(pointer),     .Call(Class__name, cppclass),
externalptr_address(cppclass))
 3: show(modtest)
 4: show(modtest)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault


best,
Christian


-- 
A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!


More information about the Rcpp-devel mailing list