Thanks, Dirk.
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?
>
Yes. I usually use devtools, but I've done it directly as well.
In #1, for instance: I go to the package source directory, start R,
do devtools::build and devtools::check. This builds and compiles
the package. After library() at this point, the module components
are visible, e.g., LshParameterSetter.
In #2, for instance, I do devtools::install() or devtools::install_github()
or similar.
Quit R, go to some other directory, restart R, and call library(). The R
entry
points are visible, but none of the module classes.
I'm unclear as to what in the installation/export process can explain the
difference
between #1 and #2.
Before emailing yesterday, I had tried removing the RCPP_EXPOSED_CLASS()'s,
but then the code does not compile. There is a static_assert error in
wrap_dispatch_unknown_iterable in Rcpp's wrap.h (line 520). I did not see an
easy way to fix that. (I vaguely recall that I only included them
originally because
I had to.)
I will look RcppAnnoy and see if I can find a way around using these
macros.
Thanks again, Chris
On Thu, Nov 9, 2017 at 7:55 AM, Dirk Eddelbuettel <e...@debian.org> wrote:
>
> 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@lists.r-forge.r-project.org
> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
