Le 30/05/11 01:56, baptiste auguie a écrit :
Thanks, that is helpful. I think I have nailed down the problem.

I defined a wrapper at R level that used a C++ function from a module
named "cd",

circular_dichroism_spectrum<- function( ... ){

  [...] # some argument processing

   res<- cd$circular_dichroism_spectrum(...) # calling the C++ function

  return(res)
}

Now, with loadRcppModules(), no "cd" module is created, as far as I
can tell, and invoking circular_dichroism_spectrum() is calling the
C++ function directly; a segfault results because some of the
arguments differ between the C++ function and its R wrapper.

I see two options:

- choose a different name for the R and C++ functions

- manage some kind of namespace masking the C++ function from the
top-level, like cd$ did before. Is there a way to do this in the
loadRcppModules() approach?

Not currently. functions and classes are directly exposed in the namespace. I guess we could add an argument to control that.

In the meantime, I'd use your first option.

Best regards,

baptiste


On 30 May 2011 11:11, Dirk Eddelbuettel<[email protected]>  wrote:

On 30 May 2011 at 10:29, baptiste auguie wrote:
| Hi,
|
| On 30 May 2011 04:28, Dirk Eddelbuettel<[email protected]>  wrote:
|>
|>  On 29 May 2011 at 18:56, baptiste auguie wrote:
|>  | Dear list,
|>  |
|>  | [Disclaimer: I am not very familiar with Rcpp/C++, and probably
|>  | haven't followed all the relevant discussions on this list.]
|>  |
|>  | I'm trying to tidy up two packages on r-forge [*] before submitting
|>  | them to CRAN. In "cda/zzz.r", I have the following code,
|>  |
|>  | NAMESPACE<- environment()
|>  | cda<- new( "Module" )
|>  | cdatests<- new( "Module" )
|>  | cd<- new( "Module" )
|>  | linear<- new( "Module" )
|>  | array<- new( "Module" )
|>  |
|>  | .onLoad<- function(libname, pkgname){
|>  |   unlockBinding( "cda" , NAMESPACE )
|>  |   unlockBinding( "cdatests" , NAMESPACE )
|>  |   unlockBinding( "cd" , NAMESPACE )
|>  |   unlockBinding( "linear" , NAMESPACE )
|>  |   assign( "cda", Module( "cda" ), NAMESPACE )
|>  |   assign( "cdatests", Module( "cdatests" ), NAMESPACE )
|>  |   assign( "cd", Module( "cd" ), NAMESPACE )
|>  |   assign( "linear", Module( "linear" ), NAMESPACE )
|>  |   lockBinding( "cda", NAMESPACE )
|>  |   lockBinding( "cdatests", NAMESPACE )
|>  |   lockBinding( "cd", NAMESPACE )
|>  |   lockBinding( "linear", NAMESPACE )
|>  |
|>  |   unlockBinding( "array" , NAMESPACE )
|>  |   assign( "array", Module( "array" ), NAMESPACE )
|>  |   lockBinding( "array", NAMESPACE )
|>  |
|>  | }
|>  |
|>  | It seems to work, but is there something I can/should do to make this
|>  | a wee cleaner?
|>
|>  Have another look at the Rcpp-modules vignette, and/or the third set of
|>  slides ("Advanced Rcpp") from our class in April -- you no longer need the
|>  unlockBinding / lockBinding business as Romain internalized that. The
|>  skeleton-generated packages now just do this in zzz.R:
|>
|>    .onLoad<- function(pkgname, libname){
|>        loadRcppModules()
|>    }
|>
|>  using a 'RcppModules: cda, cdatests, cd, linear, array' declaration in
|>  DESCRIPTION.
|
| Strange, this does not seem to work for me.
|
| If I use the following zzz.r, (with RcppModules listed in DESCRIPTION)
|
| .onLoad<- function(libname, pkgname){
|    loadRcppModules()
| }
|
| I get a segfault whenever I use a c++ function,
|
|  *** caught segfault ***
| address 0x0, cause 'memory not mapped'
|
| Traceback:
|  1: .External(list(name = "InternalFunction_invoke", address =
|<pointer: 0x101407f30>,     dll = list(name = "Rcpp", path =
| 
"/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/libs/x86_64/Rcpp.so",
|         dynamicLookup = TRUE, handle =<pointer: 0x101441030>,
| info =<pointer: 0x1002b3ed0>), numParameters = -1L),<pointer:
| 0x103011050>, ...)
|  2: circular_dichroism_spectrum(clust, gold, n = 1.33, N = 36, progress = 
FALSE)
|  3: onecluster()
|
| Is there another step I'm missing?

My first instinct is to check the unitTest, so look at what is different in
test run from

   inst/unitTests/runit.Module.client.package.R

using

   inst/unitTests/testRcppModule/

That should still work on your platform and you should be able to go from there.

Dirk

--
Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com

_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel



--
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
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Reply via email to