Code auto-completion trouble with Rcpp and Netbeans/Eclipse - r

I'm trying to write some Rcpp code using Netbeans, primarily using the IDE for the method look-up / code completion. I've set up the project to include the R/include and R/library/Rcpp/include folders, and it seems this -almost- works. For example, if I write
#include <Rcpp.h>
Rcpp::CharacterVector x;
x. // hit CTRL+SPACE to pop-up methods available to x, no hits
However, if we look at what a CharacterVector is, we see:
typedef Vector<STRSXP> CharacterVector
which is defined in Rcpp/include/vector/instanstiation.h, so it should (?) just be inheriting all the methods available to the Rcpp::Vector class. Equivalently, if I write
Rcpp::Vector<STRSXP> x;
x. // hit CTRL+SPACE, and I do see a bunch of methods available
it does work. Furthermore, if I just copy the typedef declaration into my current source file, then the auto-completion does work.
So, I guess my question is - why does Netbeans struggle in finding the methods available to Rcpp::CharacterVector but not Rcpp::Vector?
Ultimately, it's not a big problem, but I am curious...

Related

Nesting Rcpp functions

Is it possible to nest Rcpp functions in each other?
I have a dummy example right here:
cppFunction(
'int add3(int x) {
return x+3;
}')
cppFunction(
'int add4(int x) {
return add3(x)+1;
}')
add3(2)
This does not work. How can I make this work?
Edit: Okay, so I followed Dirk's advice and now I have a test.cpp file:
#include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp::export]]
int add3(int x) {
return x + 3;
}
// [[Rcpp::export]]
int add4(int x) {
return add3(x)+1;
}
Which I load in R with sourceCpp("test.cpp"). Now I can use both functions in R and they work although one function calls the other function.
The answers to your question get a little technical quickly, but are all provided in the Rcpp Attributes vignette, and have been for a long time.
First off, you are more-or-less misusing cppFunction(). It is made for quick and simple one-off function tests. Not for writing "infrastructure" or more complex code. For which you should use sourceCpp(), or better still, use a package.
If you switch you code to sourceCpp() and the [[Rcpp::export]] tag you will notice (in verbose=TRUE mode, or in package building) that the exported functions get 'transliterated' into other functions that R calls.
So yes you can nest functions, as you can in C / C++. Nothing is taken from you. But you cannot call the inner, nested function from R but that is possible with the API offered to us by R and which we use (and free you from interfacing directly). It only has SEXP .Call(functionanme, SEXP a, SEXP b,...) as an interface. I.e. a different signature.
But on the C / C++ you can nest, provided you compile your code differently.

Assigning Rcpp::XPtr on the R side

I'm learning about external pointers, XPtr, in Rcpp. I made the following test functions:
// [[Rcpp::export]]
Rcpp::XPtr<arma::Mat<int>> create_xptr(int i, int j) {
arma::Mat<int>* ptr(new arma::Mat<int>(i, j));
Rcpp::XPtr<arma::Mat<int>> p(ptr, true);
return p;
}
// [[Rcpp::export]]
void fill_xptr(Rcpp::XPtr<arma::Mat<int>>& xptr, int k) {
(*xptr).fill(k);
}
// [[Rcpp::export]]
arma::Mat<int> return_val(Rcpp::XPtr<arma::Mat<int>>& xptr) {
return *xptr;
}
Now on the R side I can of-course create an instance and work with it:
x <- create_xptr(1000, 1000) # (1)
Say, for some reason I accidentally called create_xptr again and assigned the result to x, i.e
x <- create_xptr(1000, 1000) # (2)
Then, I have no longer access to the pointer i created in (1) which makes sense and hence, I cannot free the memory. What I would like is, that the second time (2) it just overwrite the first one (1). And secondly, if I create an external pointer in some local scope (say a simple for loop), should the memory used then be freed automatically when it goes out of scope? I've tried the following:
for (i in 1:3) {
a <- create_xptr(1000, 100000)
fill_xptr(a, 1)
}
But it just adds to the memory usage for each i.
I have tried reading some code on different git-repos, old posts here on stack read a little about finalizers and garbage collection in R. I can't seem to put together the puzzle.
We use external pointers for things that do not have already existing interfaces such as database connections or objects from other new libraries. You may be better off looking at some existing uses of XPtr (or the other external pointer variants in some other packages, there are two small ones on CRAN).
And I don't think I can think of an example directly referencing this in R. It is mostly for "wrapping" external objects to hold on to them and to pass them around for further use elsewhere. And you are correct that you need to read up a little on finalizers. I find reading Writing R Extensions, as dense as it is, to be the best source because you need to get the initial "basics" in C right first.

Rcpp::compileAttributes() not updating .R file

I am trying to build a package in R involving the Rcpp package. When I generated the package using the command Rcpp.package.skeleton("pck338").
By default, the files rcpp_hello_world.cpp is included, and the RcppExports.cpp file is included as well.
To my understanding, the compileAttributes() function needs to be run every time a new .cpp function is added to the src directory.
To that end, I wrote a simple function in the rcpp_dance.cpp file that goes like this:
# include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp:export]]
int rcpp_dance(int x) {
int val = x + 5;
return val;
}
However, when I run the compileAttributes(), the RcppExports.cpp stays the same, so the dance function is not converted to an R function. Why is this happening? Any specific and general feedback would be appreciated.
In a case like this where it smells like a possible error, check for a possible error. I learned (the hard way) to first assume I goofed...
In your case: :: != :.
You wanted Rcpp::export with two colons. Try that, rinse, repeat...
(And for the other conjecture: you need to re-run compileAttributes() each time an interface changes: adding or removing or renaming or retyping an argument in the signature, and of course adding or removing whole functions. But thankfully the function is so fast that you may as well get in the habit of running it often. If in doubt, run it.)

RcppEigen: there are no arguments to 'assert' that depend on a template parameter

In trying to run one of the rcppeigen examples from the rcpp Gallery on Windows 10 I got the following error message:
/R/winlibrary/3.5/RcppEigen/include/unsupported/Eigen/src/MatrixFunctions/MatrixLogarithm.h:137:60:
error: there are no arguments to 'assert' that depend on a template
parameter, so a declaration of 'assert' must be available
[-fpermissive] assert(degree >= minPadeDegree && degree <=
maxPadeDegree);
I'm not sure what this means (I am very new to the Eigen library). The code was taken from the Rcpp Gallery:
#include <RcppEigen.h>
// [[Rcpp::depends(RcppEigen)]]
using Eigen::Map;
using Eigen::MatrixXd;
using Eigen::VectorXd;
using Eigen::SelfAdjointEigenSolver;
// [[Rcpp::export]]
VectorXd getEigenValues(Map<MatrixXd> M) {
SelfAdjointEigenSolver<MatrixXd> es(M);
return es.eigenvalues();
}
I used sourceCpp() to compile a file saved as TestEigen.cpp. I'd appreciate any information on what the issue may be. I looked for similar questions here but did not find a clear answer.
Please feel free to delete my post if this question is a duplicate.
Kind regards

What is the IAR equivalent of __attribute__(section)

Can I directly use the __attribute__((section)) directly as I did in arm gcc or is there any equivalent for the same.. My code has functions utilizing the above construct (which is defined through macro)..
#define PLACE_IN_REGION1 __attribute((section(".section1")))
void function( int ) PLACE_IN_REGION1;
If a similar equivalent is present, I could replace the same without any hassle..
You can use location pragma, in preprocessor macro form:
#define PLACE_IN_REGION1 _Pragma("location=\"section1\"") // section1 is region you have defined in the linker file
PLACE_IN_REGION1 void function(int);
Only difference is that it needs to be at the beginning of the declaration, so you'll need to edit your code a bit.

Resources