Hello,
Just wanted to start a conversation about distribution of Rcpp. For a long
time, distributing Rcpp has meant distributing a package (Rcpp) that contains
the Rcpp library.
These days, we are able to make the codebase completely header only. For
example, the Rcpp11 package that I’m abou
On Mon, Apr 7, 2014 at 4:12 AM, Romain François wrote:
[...]
> However, in terms of wins:
> - package developers would know for sure which version of the codebase is
> used with their package. Once they have done testing, they don't have to be
> hostage of api breakage and things like << please re
Le 7 avr. 2014 à 15:13, Gábor Csárdi a écrit :
> On Mon, Apr 7, 2014 at 4:12 AM, Romain François
> wrote:
> [...]
> However, in terms of wins:
> - package developers would know for sure which version of the codebase is
> used with their package. Once they have done testing, they don’t have to
Romain, Gabor,
Would you considerr taking this discussion elsewhere? Or at least make it
very clear that you are talking about the Rcpp11, which as AFAICT has not
left Github.
Rcpp was created as a CRAN package. It remains a CRAN package. It fits
squarely into the dependency mechanism of CRAN.
As I understand, it would still be an R package, on CRAN, at least this is
certainly a possibility.
The idea was about putting the headers into *every* package that uses Rcpp,
and then these packages don't have to specify LinkingTo: Rcpp*, and they
would be completely independent of subsequent Rcp
Le 7 avr. 2014 à 15:34, Dirk Eddelbuettel a écrit :
> Romain, Gabor,
>
> Would you considerr taking this discussion elsewhere?
This is a broad discussion that might be relevant to anyone doing R and C++
work. So no.
> Or at least make it
> very clear that you are talking about the Rcpp11, wh
On Mon, Apr 7, 2014 at 9:20 AM, Romain François wrote:
[...]
> The only small downsides I see here is that (1) users potentially have to
> do more work to include Rcpp* in their packages (although you can just
> write an R function to include/update their Rcpp* versions); and that (2)
> source pac
Le 7 avr. 2014 à 19:20, Gábor Csárdi a écrit :
> On Mon, Apr 7, 2014 at 9:20 AM, Romain François
> wrote:
> [...]
>> The only small downsides I see here is that (1) users potentially have to do
>> more work to include Rcpp* in their packages (although you can just write an
>> R function to in
Here's some thoughts, from the perspective of a package developer who
might want to use Rcpp11.
One option is to have the Rcpp11 distribution live as a git repository
within the `inst/include` directory of a developer's package. A
package developer could clone the repository (or have it track the
On Mon, Apr 7, 2014 at 2:19 PM, Romain François wrote:
[...]
> Oh, I see, you mean installing Rcpp* dependent packages from git(hub)
> directly. I imagine some people would want to put the headers into their
> tree, as ordinary files.
>
>
> Having the files into the client package is what I meant.
Thanks to have interest in this discussion.
Le 7 avr. 2014 à 20:30, Kevin Ushey a écrit :
> Here's some thoughts, from the perspective of a package developer who
> might want to use Rcpp11.
>
> One option is to have the Rcpp11 distribution live as a git repository
> within the `inst/include` d
On Mon, Apr 7, 2014 at 2:59 PM, Romain François wrote:
[...]
> > Some R functions, e.g. useRcpp11(), could be written that, when run in
> > the package directory, clones a repository in inst/include/Rcpp, and
> > also updates pertinent licensing information (this package uses
> > Rcpp11, which is
Earlier today, Conrad released a new stable release Armadillo 4.200.
As in the past, I rolled this up for CRAN, and we now have a fresh
RcppArmadillo 0.4.200.0 on CRAN.
This release was preceded by two test release which were on Github only (as
CRAN prefers to have about one release / month).
13 matches
Mail list logo
