Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files that registerFunctions registers #8

Open
ggrothendieck opened this issue Sep 10, 2014 · 6 comments
Open

Files that registerFunctions registers #8

ggrothendieck opened this issue Sep 10, 2014 · 6 comments

Comments

@ggrothendieck
Copy link

It would be nice if one could tell registerFunctions which functions to register since you might want to keep some of them private while having others public, i.e. you might not wish to register all of them. Perhaps it could input a pattern and only filenames matching that pattern would be scanned for functions to register. For example, we might only want those filenames of the form "^extern_.*\\.cpp$" to be scanned.

@kevinushey
Copy link
Owner

I am not sure if I understand -- registerFunctions expects the user to have explicitly adorned functions with // [[register]] attributes, so only functions with that attribute on top get registered*.

*also, functions within RcppExports.cpp are registered since I figured that is usually what is desired.

@ggrothendieck
Copy link
Author

Sorry. I didn't understand that. If there is a package that uses this can you point it out - an actual example of it in action would be helpful.

@kevinushey
Copy link
Owner

I use it in Kmisc itself :) But the process isn't completely automated. The basic idea is, when I want to build the package, I do:

Rcpp::compileAttributes()
Kmisc::registerFunctions()

and then do the regular R CMD build, R CMD INSTALL. This process auto-generates the RcppExports.cpp file (as per Rcpp::compileAttributes()) and also Kmisc_init.c (giving the call method defs). Presumedly this could be easily automated using configure and cleanup, although I have not done so.

Note that this only works for functions using the .Call interface, though.

@rdiaz02
Copy link

rdiaz02 commented Jun 4, 2015

But I think the above only works as explained if you do
Kmisc::registerFunctions(prefix = "")
as otherwise what gets registered is C_packagename_functionname , but the RcppExports.cpp file has definitions for packagename_functionname and RcppExports.R has .Call('packagename_functionname', blablabla).

Alternatively, if I simply use
Kmisc::registerFunctions()
then I need to edit the RcppExports.R file to have .Call('C_packagename_functionname', blablabla).

I wonder if I am doing something silly.

@kevinushey
Copy link
Owner

The registration work disables dynamic symbol lookup. Unfortunately this means that the R wrappers generated by compileAttributes() will no longer work and so you need to generate your own.

Perhaps this script could be 'nice' and fix up an associated RcppExports.R file when run?

@rdiaz02
Copy link

rdiaz02 commented Jun 4, 2015

"so you need to generate your own." Always? Maybe I am not following here, but in some very limited testing I did, just doing Kmisc::registerFunctions(prefix = "") and not touching anything seemed to work.

As for having a nicer script: that would be nice. But in the meantime maybe adding a paragraph to the documentation of registerFunctions would be enough. For instance, something like "If you want to combine the usage of registerFunctions with Rcpp's compileAttributes, run compileAttributes first. Then, run registerFunctions (all functions within RcppExports.cpp are automatically registered, so you do not need to add //[[register]] to those). Finally, edit the RcppExports.R file; locate each of the usese of .Call, and prefix the name of the .Call'ed function(s) with "C_", or with whatever else you used as the prefix argument to registerFunctions".

But then, couldn't compileAttributes do all of the work and by default also register? I guess I am missing something here, but registration I think is highly recommended for BioC packages and also welcome in CRAN packages so I am not sure about the downsides of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants