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
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
__
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
>
> (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
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
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 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
We have a small regression in Rcpp 0.12.8: On old compilers such as the
g++-4.*, Rcpp::stop(txt) no longer returns the proper error messages. It
works with g++-5.* or later, and 'throw std::range_error(txt)' works too.
For those who would rather not alter their error code, or are eg using Travis
