I have been developing a package with Rcpp for C++ integration. I used RcppExport to make the functions return SEXP objects.
The issue is travis-ci seems to give warnings telling that there are undocumented code objects. (These are cpp functions). However I do not want users to directly access those functions as well.
How can I resolve this issue? How can I document these functions as well?
You seem to have an elementary misunderstanding here.
If your NAMESPACE contains a wildcard 'export all' a la exportPattern("^[[:alpha:]]+") then each global symbol is exported and per R standards that are clearly documented needs a help entry.
One easy fix is NOT to export everything and just write documentation for what you want exported. We sometimes do that and call the Rcpp function something like foo_impl and then have R functions foo (with documentation) call foo_impl. In that case you would just export foo and all is good.
In short, you are confused about R packages and not so much Rcpp. I would recommend downloading the sources of a few (small) Rcpp packages to get a feel for what they do.
Related
When I do a package including some C code or using Rcpp, I type the roxygen code:
#' #useDynLib TheDLL, .registration=true
I did a package in which I included some DLLs created with Haskell, that I put in the inst/libs folder. I didn't type .registration=true in the roxygen code and the package works fine. Should I type it nevertheless? If so, what is the role of .registration=true?
I think you almost certainly shouldn't use it in a general-purpose DLL, but if the DLL was written specifically for R, maybe you should. It indicates that the dll calls R_registerRoutines from its R_init_DLLNAME function, so entry points can be saved into variables. For example, you might have a function named "foo". You can call it using
.Call("foo", ...)
without registering it, and R will need to search symbol tables for it at run time. Or you can register it and call it as
.Call(foo, ...)
and the search is unnecessary. This is discussed mainly in section 5.4.2 of "Writing R Extensions". I believe that if you specify .registration=true then R will use the registration information to find entry points, otherwise it needs to search through all the exports of the DLL, which is probably slower.
I am writing an R package that should be able to compile C++ code on the fly. In practice, users can define, at run-time, operators based on C++ code that is compiled and then used in computation (for efficiency purpose, like PyTorch or TensorFlow models in Python). Ideally, the code compiled at run-time should use Rcpp features to be exported to R.
Example:
In my R package, I have a function def_operator that can parse some mathematical formula defining an operator.
my_custom_op <- def_operator("x+y", args = c("x", "y"))
My Cpp API knows how to generate the Cpp code associated to this formula. This code should be compiled on the fly (just once, not at each call).
The user can use this new function to do some computations.
res <- my_custom_op(1, 3) # should give 4
Note: this is an example, the operators defined by the user aim at doing more some adding scalar numbers, and the interest is clearly to let the user defines its operators and not to pre-define some generic operators compiled at installation.
I know two things for the moment:
the Cpp code required to generate the operators (which is not compiled at installation) should be put in the inst package directory, it will be copied at installation and I can find where with the R function find.package.
I can use the function sourceCpp to compile code on the fly. Thus I can define some functions in Cpp that will be automatically exported to R and be callable there. It is even possible to keep the shared library to avoid multiple compilations (see Rcpp: how to keep files generated by sourceCpp?)
Here are my questions:
Do you know some alternative to sourceCpp from the Rcpp package to compile C++ code on the fly and export it to R?
Is there some way to manage compilation option for sourceCpp other than using the file ~/.R/Makevars (I need to link the code in the inst directory and I don't want to edit this file on the user system)?
Eventually, do you know some R packages implementing compilation on the fly that I could take as examples?
Do you know some alternative to sourceCpp from the Rcpp package to compile C++ code on the fly and export it to R?
Using sourceCpp() is the best approach. Alternatively, you can use its predecessor from the inline R package. Otherwise, you will need to build your own file via R CMD SHLIB, load the library, and create a wrapper yourself. (Not fun.)
Is there some way to manage compilation option for sourceCpp other than using the file ~/.R/Makevars (I need to link the code in the inst directory and I don't want to edit this file on the user system)?
Yes, there are many Makevars variables that can be set per R session via Sys.setenv("PKG_LIBS" = ...).
Now, to retrieve a file location dynamically, consider RcppMLPACK1's flag function approach.
Eventually, do you know some R packages implementing compilation on the fly that I could take as examples?
There are a couple entrants in this market:
armacmp package by Dirk Schumacher that translates R code to C++ under the armadillo library.
nCompiler package by Perry de Valpine et al. for code-generating C++ and easily interfacing between R and C++.
I created a package with some functions which are helpful at my company. Recently, I restructered the package such that there are helper functions which need not to be accessible for everyone, but are called internally from other (exported) functions of the package. These helper functions are not exported to the namespace (no #' #export in the respective .R files).
Now, when I call one of the "major" (exported) functions, I get the error message (no real function names):
Error in major_function() : could not find function "helper_function"
Im fairly new in building packages, but from what I understood so far (from https://cran.r-project.org/web/packages/roxygen2/vignettes/namespace.html), it should neither be necessary to export the helper functions, nor to add #' importFrom my_package helper_function to the .R file of the major function.
When I tried this, it actually produced errors when checking the package. I also tried to call the helper functions with my_package:::helper_function, but this lead to the note that it should almost never be necessary to call functions from the same package like this.
Maybe useful information:
The error occurs only when I call a major_function_1 which internally calls major_function_2 which calls a helper_function.
I think there is more to your problem than what you state. As long as all your functions are defined in the same namespace (this also means that all your functions need to live in .R files in the same folder), the calling function should find the helper-functions accordingly.
I suspect you have your helper functions nested in some way, and that is causing the problem.
I recommend to recheck your namespace structure, or post a simplistic outline of your package here.
Another reason that could come to mind, is that you do not export your 'mayor_function2' in your NAMESPACE-file in your package root (maybe you have not recompiled the Roxygen documentation generating this file), and additionally have a local shadow of the the calling function 'mayor_function1'. Try to check this and rerun from a clean compile.
Forgive my ignorance. I need to do calculate backward slices for a project. After some searching, I came across frama-c. I downloaded the package on my ubuntu system which got me Frama-c Version: Fluorine-20130601. I am trying to use it for the first time. When finding out the undefined functions in my project almost all library functions are undefined, even printf, scanf etc(Neither code nor specification for function printf). According to the tutorial, I have to add stubs for all the undefined functions. Do I really have to add code for every library function that I am using even printf? Please guide.
You should update to Frama-C Phosphorus, which brings tons of improvements regarding Variadic functions. In particular, specifications are automatically generated for printf/scanf-like functions when they are called on a constant format string. For non-variadic functions, some basic implementations are available in the directory $FRAMA_C_INSTALL/share/libc/*.c (in recent releases of Frama-C).
I made a function with cppFunction which works as expected and now I'd like for my co-workers to be able to use it. Is it possible to make a package that compiles my cpp code so that other users of the package don't need Rcpp? It seems like the guide here http://adv-r.had.co.nz/Rcpp.html#using-rcpp-in-a-package and here http://cran.r-project.org/web/packages/Rcpp/vignettes/Rcpp-package.pdf create packages that have Rcpp as a dependency. Am I reading those guides correctly that what I want to do can't easily be done?
No, you are overlooking the fact that code from Rcpp, just like code from R itself, is loaded via a so-called shared library.
So in order to run code using Rcpp, you need Rcpp installed.
Which is why packages win (again). Wrap your code in a package, have your package depend on Rcpp, and you're (essentially) done.