[Rcpp-devel] Rcpp module visible after check but not after install

[Dirk Eddelbuettel]

On 9 November 2017 at 01:54, Christopher Genovese wrote:
| Hello,
| 
|   I have a package under development that uses Rcpp modules to expose
| some C++ classes. I hadn't touched the package for some months (close
| to a year). At that time the package compiled and installed without problem
| and worked well. I could access the classes as expected. Recently, having
| updated Rcpp and R in the meantime, I reinstalled the package with
| the following result:
| 
|     1. If building and loading from within the package directory, all works
| fine.
|     2. When installing the package, either from github, locally, or
| otherwise,
|         the modules are *not* visible.

What exactly do you mean by 1. and 2. ?  Per 'Writing R Extensions' we are
meant to create a tar.gz in either way via 'R CMD BUILD' and then install it
via 'R CMD INSTALL'.

Are you doing that?
 
| The package passes devtools:check() and compiles fine.

Well if it passes check you should be fine.
 
| For instance, for one of those classes, LshParameterSetter, I do
| 
| 
| RCPP_EXPOSED_CLASS(LshParameterSetter)
| 
| RCPP_MODULE(mod_params) {
|     class_<LshParameterSetter>("LshParameterSetter")
| 
|     .constructor<int,int>()
| 
|     .method("withDefaults", &LshParameterSetter::withDefaults,
|             "Fill with defaults")
|     .method("distance", &LshParameterSetter::distance,
|             "Set distance metric")
|     .method("numHashFunctions", &LshParameterSetter::numHashFunctions,
|             "Set numbers of hash functions and tables")
|     .method("numHashTables",   &LshParameterSetter::numHashTables,
|             "Set numbers of hash functions and tables")
|     .method("storage",   &LshParameterSetter::storage,
|             "Set LSH Hash Table Storage type")
|     .method("family",   &LshParameterSetter::family,
|             "Set LSH Family")
|     .method("rotations",   &LshParameterSetter::rotations,
|             "Number of rotations")
|     .method("asList",        &LshParameterSetter::asList,
|             "List of parameter values by name")
|    ;
| }
| 
| and similarly for the other classes. This module is loaded in the R code
| with
|                      Rcpp::loadModule("mod_params", TRUE)
| and similarly for the other modules.
| 
| The installed package has the .rdb, .rdx, and .so file, so it's hard to see
| if something has been lost in the installation.  There's no indication what
| is wrong, but after loading the installed package, a class like
| LshParameterSetter
| is not defined. (Loading from within the package source directory it is,

What do you mean by 'loading from within the package source directory' ?

| showing
| 
| > > LshParameterSetter
| > C++ class 'LshParameterSetter' <0x7fde72fb1940>
| > Constructors:
| >     LshParameterSetter(int, int)
| >
| > Fields: ...
| >
| as it should be.) I've done this with simple skeletons and not had a
| similar problem. But I don't see a qualitative difference between these
| cases.
| 
| The full package code is at  https://github.com/genovese/falconnr
| and the session info is below.

Thanks for posting the link.  Not a small package ...
 
| I'd appreciate any pointers on this, as the problem is unclear to me,
| especially since it worked without problem last year. I'm happy to
| provide any useful information that I might have omitted here.

Not sure what is going on there. Package clearly builds. Testing complains
some but hey, it is not a CRAN package yet...

You have

    falconnr::LshTable

visible, but (what you probably want) only un-exported:

    falconnr:::LshNnTable
    falconnr:::LshParameterSetter

I have been using Modules for about as long as we've had them, but I have
always been a little mystified by the various UPPERCASE_MACROS exporting
things.  Looking at what was probably my first Modules package, RcppBDT, I
seem to "simply" do 

RCPP_MODULE(bdtDdMod) {
    Rcpp::class_<bdtDd>("bdtDd")   
       // ... stuff omitted

and nothing else for the four or so different modules there.  That worked. I
think you may rely on a helper macro which may have gotten stale as the
_underlying R behaviour_ may have changed.  I think I use one or two of the
exporter macros in other places (ie RcppAnnoy) so you could try that.

In general, I always recommend to simplify as much as you can.

Hope this helps,  Dirk

| Thanks for your help, Chris
| 
| > sessionInfo()
| R version 3.3.2 (2016-10-31)
| Platform: x86_64-apple-darwin13.4.0 (64-bit)
| Running under: macOS Sierra 10.12.6
| 
| locale:
| [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
| 
| attached base packages:
| [1] grid      stats     graphics  grDevices utils     datasets  methods
| base
| 
| other attached packages:
| [1] falconnr_0.0.0.9001 MASS_7.3-45         lattice_0.20-34
| 
| loaded via a namespace (and not attached):
| [1] Rcpp_0.12.13     codetools_0.2-15
| _______________________________________________
| 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

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org