similar to: Linking to native routines in other packages

Hi, During my recent r2sundials development, I've came across a strange test failing during 'R CMD check' exclusively on win R-devel which I could reproduce with a minimal example that I present here. The toy packages testarma1 [1] and testarma2 [2] are minimal modifications of a skeleton package produced by RcppArmadillo.package.skeleton(). They are almost identical. The first

Hi I'd like to suggest to make R more informative when a user updates a package A where there's at least one package B that has "LinkingTo: A" in its description. To illustrate the problem, assume package A is updated so that its C/C++ header interface (in inst/include) is changed. For package B to pick up these changes, we need to reinstall package A. In extreme cases, if

Hello, I've been trying to make LinkingTo work when the package linked to has c++ code. I've put dumb packages to illustrate this emails here ; http://addictedtor.free.fr/misc/linkingto Package A defines this C++ class: class A { public: A() ; ~A() ; SEXP hello() ; } ; Package B has this function : SEXP say_hello(){ A a ; return a.hello() ; } headers of package A are copied

On 16 December 2016 at 08:20, Duncan Murdoch wrote: | Perhaps the solution is to recommend that packages which export their | C-level entry points either guarantee them not to change or offer | (require?) version checks by user code. So dplyr should start out by | saying "I'm using Rcpp interface 0.12.8". If Rcpp has a new version | with a compatible interface, it replies

The Rcpp package and some related packages such as RcppArmadillo make use of (local) wrappers around the utils::package.skeleton() function for creating (basic yet functional) packages using Rcpp or RcppArmadillo. RStudio also exposes this under the graphical menu as a nice way to construct a package. But it seems that something changed quite recently in R. I looked into this a little yesterday

On 16 December 2016 at 11:00, Duncan Murdoch wrote: | On 16/12/2016 10:40 AM, Dirk Eddelbuettel wrote: | > On 16 December 2016 at 10:14, Duncan Murdoch wrote: | > | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | > | Perhaps the solution is to recommend that packages which export their | > | > |

Make a reproducible example [1][2][3], because it doesn't happen for me. Then post your example at [4] or [5], because this is the wrong list for this question. You may find that the act of browsing the directory using a GUI is what creates that file rather than the compilation itself. [1] http://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example [2]

Hi, I am trying to make a package B that extends another package A. Package A uses Rcpp, and I want to extend a class X used there. So package A has src/X.h and inst/include/X.h class X { ... } src/X.cpp X::X( arguments ) { ... } My package B wants to do this: DESCRIPTION [...] LinkingTo: Rcpp, RcppArmadillo, A Imports: Rcpp, RcppArmadillo, A src/Y.h class Y: public X { ... } src/Y.cpp

I have two questions about the CRAN machines that build binary packages for Mac. When a new version of a package is released, (A) Do the downstream dependencies get re-checked? (B) Do the downstream dependencies get re-built? I have heard (but do not know for sure) that the answer to (A) is no, the downstream dependencies do not get rechecked. >From publicly available information on the

On 16 December 2016 at 10:14, Duncan Murdoch wrote: | On 16/12/2016 8:37 AM, Dirk Eddelbuettel wrote: | > | > On 16 December 2016 at 08:20, Duncan Murdoch wrote: | > | Perhaps the solution is to recommend that packages which export their | > | C-level entry points either guarantee them not to change or offer | > | (require?) version checks by user code. So dplyr should start out by

I just (apparently) figured out how to do the stuff described in Section 5.4.2 of Writing R Extensions. I put my test toy packages on github <https://github.com/cjgeyer/linkingTo> for anyone to copy. If anyone cares to read the README and the bits of code it links to and tell me anywhere I am wrong, I would be grateful. But the main point of this e-mail is a complaint about that section

Hi Serguei, Nice analysis! On 14 January 2020 at 11:00, Serguei Sokol wrote: | During my recent r2sundials development, I've came across a strange test | failing during 'R CMD check' exclusively on win R-devel which I could | reproduce with a minimal example that I present here. | The toy packages testarma1 [1] and testarma2 [2] are minimal | modifications of a skeleton package

Hi, everyone, I am just trying to use Rcpp in my computer, and I would like to try a simple example from website, but R keeps reporting me error. I am using Windows XP, and has installed Rtools and GSI. Here is the response: > src = ' + Rcpp::NumericVector xa(a); + Rcpp::NumericVector xb(b); + int n_xa = xa.size(); + int n_xb = xb.size(); + + Rcpp::NumericVector xab(n_xa + n_xb - 1);

I am running into a wall getting my system to work with rcpp and inline. Following Dirk's advice on stackoverflow, I hope someone is able to help me. My steps were to install MinGW 32 bit first, then installing Rtools, I disabled MinGW's entry in the PATH. I am trying to get the following code to work: library(Rcpp) library(inline) body <- ' NumericVector xx(x); return wrap(

Hello,?I?am experiencing some difficult time with my R package. Every time I compilei it a hidden file, desktop.ini, is?being created. I am using C++ behind, linkking to Rcpp. The file is generated even when I compile it with?Linux, and in many different computers. Does anybody have any advice or ideas? [[alternative HTML version deleted]]

> Shield<SEXP> res(Rcpp_fast_eval(Rf_lang2(asEnvironmentSym, x), R_GlobalEnv)); The call should be protected before evaluation though. So more like: Shield<SEXP> call(Rf_lang2(asEnvironmentSym, x)); return Rcpp_fast_eval(call, R_GlobalEnv); Best, Lionel On 3/23/20, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 23 March 2020 at 17:07, Ben Bolker wrote: >

Hello My colleagues asked me to install "R" with module "shiny". R version 3.0.1 compiled fine on Solaris 10 and is running well. I tried to install "shiny". With the dependencies "Rcpp" should be installed before. But the compile step did fail. See below. The initial error message is "Error in dyn.load(file, DLLpath = DLLpath, ...) :" Before

Hello My colleagues asked me to install "R" with module "shiny". R version 3.0.1 compiled fine on Solaris 10 and is running well. I tried to install "shiny". With the dependencies "Rcpp" should be installed before. But the compile step did fail. See below. The initial error message is "Error in dyn.load(file, DLLpath = DLLpath, ...) :"

On 16/12/2016 12:35 PM, Karl Millar wrote: > A couple of points: > - rebuilding dependent packages is needed if there is an ABI change, > not just an API change. For packages like Rcpp which export inline > functions or macros that might have changed, this is potentially any > change to existing functions, but for packages like Matrix, it isn't > really an issue at all

I think there's one typo in your post which may confuse some readers; I've edited it inline below. My comments on the suggestion are at the bottom of the message. On 16/12/2016 5:35 AM, Kirill M?ller wrote: > Hi > > > I'd like to suggest to make R more informative when a user updates a > package A where there's at least one package B that has "LinkingTo: