[Rcpp-devel] package .onLoad multiple modules

baptiste auguie baptiste.auguie at googlemail.com
Mon May 30 23:04:22 CEST 2011


Hi,

On 31 May 2011 07:55, Romain Francois <romain at r-enthusiasts.com> wrote:
> 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.

I'd prefer not having to change names, so I'll probably stick to the
old lockBinding() approach for now, if that's not deprecated.

Best,

baptiste



>
>> Best regards,
>>
>> baptiste
>>
>>
>> On 30 May 2011 11:11, Dirk Eddelbuettel<edd at debian.org>  wrote:
>>>
>>> On 30 May 2011 at 10:29, baptiste auguie wrote:
>>> | Hi,
>>> |
>>> | On 30 May 2011 04:28, Dirk Eddelbuettel<edd at debian.org>  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
>> Rcpp-devel at lists.r-forge.r-project.org
>> 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
>
>
>


More information about the Rcpp-devel mailing list