Certainly realize that it's possible to make a more inline form of code
generation work with sourceCpp (and it would overcome the #ifdef issue you
encountered). One additional fly in ointment is that for package
development we _must_ use an external file for code generation (otherwise
we'd need to
J J,
thanks. actually, if you track the source file line number, and inject
"#line" directives around your injections, you don't need to rewrite
error messages.
e.g., let's say we're at line number 77 of file cluster.cc, and we see:
// [[Rcpp::export]]
int int_lots_in_one_out(std::list il)
> would it be possible to output the added code fragments, e.g.,
>
> RcppExport SEXP sourceCpp_7387_none_in_lots_out() {
> BEGIN_RCPP
> Rcpp::RNGScope __rngScope;
> point_l __result = none_in_lots_out();
> return Rcpp::wrap(__result);
> END_RCPP
> }
>
> immediately following t
Dirk,
thanks for being tolerant of newbie confusion.
i *am* looking at some other issue, though as it's in template-land, and
i've lived a temperate template-free life heretofore, i may have to
declare defeat. stay tuned.
>| 2. alternatively, could you parse the output of "g++ -E" (rather
>| t
Greg,
Thanks for your continued interest in Rcpp. It is always interesting to get
feedback from someone who has a fresh look at things.
On 24 February 2013 at 13:27, Greg Minshall wrote:
| 1. could you, on seeing the [[Rcpp::export]], parse the succeeding
| function, then output your conversion
JJ,
thanks for the reply. i'm very sympathetic to not wanting to bundle a
full-on C++ parser. two things i wonder:
1. could you, on seeing the [[Rcpp::export]], parse the succeeding
function, then output your conversion code block, then output the lines
(that you've already partially parsed) f
Hi Greg,
While sourceCpp does parsing of the translation unit to discover exported
functions, it's not a full-on C++ parser (that would require a huge effort
and/or taking on a large dependency like libclang or gccxml). In any case,
in our parser we try to be as semantically sophisticated as we ca
hi. first, i should mention that i think Rcpp is amazing! i'm enjoying
the learning process, and it speeds up my formerly-R code greatly.
(some trivial image processing thing that i was only doing in R in order
to combine two learning activities into one.)
but... ;-)
if i sourceCpp() the follow
>
> experimenting, i ran into this problem that i haven't seen documented:
> if a formal argument to an [[Rcpp::export]] function *begins* with an
> underscore. sourceCpp() ends in failure. with the example below,
> replacing "_parms" with "parms" makes sourceCpp() happy. in the error
> case, the
> I presume that the Rcpp-attributes vignette never ever shows RcppExport,
> and
> JJ probably did not assume it could be used.
>
> And it "really" is just an alias for the uglier-looking 'extern "C"'. And
> of
> course added by the very layers that sourceCpp() puts around the code you
> give it..
On 24 February 2013 at 09:56, Greg Minshall wrote:
| hi. another "find" in experimenting is that [[Rcpp::export]] and the
| RcppExport (in, e.g.,
|
| // [[Rcpp::export]]
| RcppExport SEXP pass1(Rcpp::IntegerVector rgbtotype,
| Rcpp::IntegerMatrix pixmap,
|
Hi Greg,
On 24 February 2013 at 09:55, Greg Minshall wrote:
| hi. i'm trying to understand the difference between using sourceCpp()
| and using R CMD compile/shlib. (i seem to get different results using
| the different methods.) if that's an FAQ, apologies, but any
| enlightenment would be ap
hi. another "find" in experimenting is that [[Rcpp::export]] and the
RcppExport (in, e.g.,
// [[Rcpp::export]]
RcppExport SEXP pass1(Rcpp::IntegerVector rgbtotype,
Rcpp::IntegerMatrix pixmap,
int toosmall) {...}
are mutually exclusive. that's
hi. i'm trying to understand the difference between using sourceCpp()
and using R CMD compile/shlib. (i seem to get different results using
the different methods.) if that's an FAQ, apologies, but any
enlightenment would be appreciated!
experimenting, i ran into this problem that i haven't seen
> Unfortunately, at the moment modules and attributes don't play together.
> The attributes feature used to be built on top of modules, but this caused
> issues on windows.
>
> One thing we could perhaps negociate with JJ is recognition of the export
> attribute on module. Something like :
>
> // [
15 matches
Mail list logo
