Hello,
The compiler tells you that :
Library/Frameworks/R.framework/Versions/3.0/Resources/library/Rcpp/include/Rcpp/internal/export.h:90:
error: no matching function for call to
‘export_range__dispatch(SEXPREC*&, __gnu_cxx::__normal_iteratorstd::vector > >&, Rcpp::traits::r_type_generic_tag)’
Hi Luke,
On 22 August 2013 at 00:30, [email protected] wrote:
| Thanks for your reply Dirk,
|
| >
| > "Should automatically use available" wrappers/bindings.
| >
|
| Okay.. is it more correct to say "Should use available wrapper to
automatically generate bindings"?
|
| > Someone still
Hi Jacob,
On 21 August 2013 at 19:53, [email protected] wrote:
| Thanks for the help! I ended up reading a little more and found that I
| could create a Makefile instead of using Makevars. I took this approach.
Do not do that.
R creates its own Makefile, and it is MUCH easier to
>
> namespace Rcpp {
> template <> B as( SEXP ){
> Rcpp::Reference in_b(b);
> id=in_b.field("id");
> }
> }
>
This should be:
namespace Rcpp {
template <> B as( SEXP );
}
#include
template <> B Rcpp::as( SEXP b ){
Rcpp::Reference in_b(b);
Thanks for your reply Dirk,
>
> "Should automatically use available" wrappers/bindings.
>
Okay.. is it more correct to say "Should use available wrapper to automatically
generate bindings"?
> Someone still has to provide the basic as<>() and wrap() code. For
> common types we have done. For
On 21 August 2013 at 23:21, [email protected] wrote:
| I running into some problems using a combination of Rcpp-attributes and
| Rcpp-modules to expose a C++ class library, and would appreciate your help.
Ahh, that intersection of modules and attributes is still a little rough.
| I am tryi
Hey Dirk,
Thanks for the help! I ended up reading a little more and found that I
could create a Makefile instead of using Makevars. I took this approach.
I am including the Makefile in case anyone else has a similar problem to
what I had but I don't recommend deviating from the Makevars approach
u
On 20 August 2013 at 15:09, [email protected] wrote:
| Hey Dirk,
|
| I know that linking to a shared library is not enough, and that I need
| to runtime load the actual libraries that have their shared code stored
| separately. I wanted to do this in a way that when loaded by someo
On 19 August 2013 at 22:12, Colin Rundel wrote:
| I've run into the same issue and have been using the Rcpp's plugin framework
to
| work around it.
|
| My R file defines a local_include plugin as follows:
|
| registerPlugin("local_include",
| function() {
|
On 20 August 2013 at 11:39, Wush Wu wrote:
| Thanks for you correction, Dirk.
|
| It seems that if I don't care about portability, I could add the absolutely
| path of the .so files into OBJECTS in Makevars.
|
| For example:
|
| ```
| ## Use the R_HOME indirection to support installations of mu
Hi All,
I running into some problems using a combination of Rcpp-attributes and
Rcpp-modules to expose a C++ class library, and would appreciate your help.
I am trying to expose to R the constructor of a C++ class template which
accepts a std vector of the template parameter T as input, as show
11 matches
Mail list logo
