On Wed, Nov 30, 2016 at 8:23 AM, Whit Armstrong
wrote:
> My point regarding the clang parser is that one really shouldn't have to
> write any R or Rcpp wrappers at all.
>
I realize this is a bit academic, but I suppose my position reduces to
"RefClass + Rcpp = no wrappers at all".
For many (mos
On 30 November 2016 at 10:23, Whit Armstrong wrote:
| My point regarding the clang parser is that one really shouldn't have to write
| any R or Rcpp wrappers at all.
Did anybody keep tabs on the related projects by Duncan Temple Lang?
https://github.com/omegahat/RClangSimple
https://github.c
My point regarding the clang parser is that one really shouldn't have to
write any R or Rcpp wrappers at all.
If one directly parses the c++ class then both the R6/RefClass/List (or
whatever implementation one chooses to use) and the C wrappers (which we
will still need as we can't expose the c++
On Mon, Nov 28, 2016 at 9:40 PM, Christian Gunning wrote:
>
> B) Are there any *gotchas* with using Rcpp "modify-in-place" functions
> inside RefClass methods?
>
After some reading, I'm going to answer my own question and point to one
possible *gotcha* that wasn't clear to me at first.
* From h
Whit,
I see that this could be useful in similar situations where Rcpp modules
excels (generating R bindings to existing C++ classes). Language preference
aside, it's less clear to me what advantage this approach (or Rcpp modules)
offers average users over RefClasses + Rcpp functions, where the Re
On 29 November 2016 at 21:02, Christian Gunning wrote:
| [...] It can be challenging for end-users to distinguish between projects /
| code that is "fully functional but no longer under active development" (ok)
| from directions that code that is "unofficially deprecated".
Point taken. But it is
All,
Thanks for the comments, much appreciated.
To summarize what I'm hearing:
A) No major problems with the described approach
B) Not much evidence for previous use of this approach
On Tue, Nov 29, 2016 at 12:02 PM, Kevin Ushey wrote:
> To be brief -- Rcpp modules are effectively in maintenanc
On 29 November 2016 at 11:12, Hao Ye wrote:
| (I guess one downside of Rcpp modules is the use of external pointers,
| which implies they do not serialize / deserialize well?)
|
|
| I think not at all, unless you can force the same memory location for a new R
| session and everything it
>
> (I guess one downside of Rcpp modules is the use of external pointers,
> which implies they do not serialize / deserialize well?)
I think not at all, unless you can force the same memory location for a new
R session and everything it loads. This is documented in the Rcpp-modules
vignette -- I
To be brief -- Rcpp modules are effectively in maintenance mode at this
point; we don't plan to extend / improve modules beyond resolving issues if
and when they come up. We did get to the bottom of the posted issue -- R
packages that use modules need to import the whole Rcpp namespace.
I'm not qu
On 29 November 2016 at 07:33, Whit Armstrong wrote:
| Have a look at this project:
| https://github.com/richfitz/RcppR6
Yes, intriguing, even promising, and beyond that, used -- but sadly not on CRAN.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
Have a look at this project:
https://github.com/richfitz/RcppR6
On Mon, Nov 28, 2016 at 11:40 PM, Christian Gunning wrote:
> Dear List,
>
> The following is a general request for advice / comment on modern Rcpp
> development best-practices for package & class development. I looked over
> the Rc
Dear List,
The following is a general request for advice / comment on modern Rcpp
development best-practices for package & class development. I looked over
the Rcpp gallery, and didn't see anything obvious that answers my
questions - perhaps this discussion could serve as a prototype for a new
po
13 matches
Mail list logo
