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?
Thanks!
baptiste
[*]: https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics
https://r-forge.r-project.org/scm/viewvc.php/pkg/planar/?root=photonics
[Rcpp-devel] package .onLoad multiple modules
8 messages · Dirk Eddelbuettel, Baptiste Auguie, Romain Francois
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.
The question Laurent raised the other day about spurious warnings from 'R CMD
check' around this still stands though. Not yet sure what to do there...
Cheers, Dirk
Gauss once played himself in a zero-sum game and won $50.
-- #11 at http://www.gaussfacts.com
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?
Best regards,
baptiste
The question Laurent raised the other day about spurious warnings from 'R CMD check' around this still stands though. ?Not yet sure what to do there... Cheers, Dirk -- Gauss once played himself in a zero-sum game and won $50. ? ? ? ? ? ? ? ? ? ? ?-- #11 at http://www.gaussfacts.com
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
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?
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
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<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
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
Hello, I just added (rev 3043) a "direct" argument to loadRcppModules. When TRUE (the default) it exposes the contents of the module When FALSE it does what you want. Romain Le 29/05/11 08:56, baptiste auguie a ?crit :
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?
Thanks!
baptiste
[*]: https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics
https://r-forge.r-project.org/scm/viewvc.php/pkg/planar/?root=photonics
_______________________________________________ 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