similar to: Upgrading a package to which other packages are LinkingTo

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:

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

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

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 | > | > |

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 > | saying "I'm using Rcpp interface 0.12.8".

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 > | > | C-level entry points either guarantee them not to change or offer

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 IIUC. - If we're looking into a way to check if package APIs are

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 can't seem to reliably obtain parse data via getParseData() for functions from installed packages. The parse data seems to be available only for the *last* file in the package. See [1] for a small example package with just two functions f and g in two files a.R and b.R. See [2] for a documented test run on installed package (Ubuntu 15.10, UTF-8 locale, R 3.2.3). Same behavior with

On 06.06.2017 10:07, Martin Maechler wrote: >>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> >>>>>> on Mon, 5 Jun 2017 17:30:20 +0200 writes: > > Hi I've noted a minor inconsistency in the documentation: > > Current R-exts reads > > > s = PROTECT_WITH_INDEX(eval(OS->R_fcall, OS->R_env), &ipx);

I think that this problem is actually more general than just ABI versioning. The common definition of ABI refers to compiled code, but with R packages similar problems might happen (and they to happen) without any compiled code. I think the key issue is the concept of build-time dependencies. While R packages usually does not distinguish between build-time and run-time dependencies, they still do

Hi everyone, Some of you probably received the following thread from the Rcpp-devel mailing list: http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2018-August/010072.html Summing up, the issue described is the following: pkg1 provides type1 in pkg1.so building on some headers. pkg2 links to pkg1 (BTW, LinkingTo is actually misleading, because it doesn't really link to it), i.e.,

Dear List, R packages may specify a "LinkingTo" attribute to specify dependencies to the source code (mainly the header files) of other packages. Unfortunately, it is not possible to also have a reference to the generated library (.dll on Windows) of the other package. So including a header file from another package to call an (exported) function will just not help. I've tried

Hello, One of our packages contains C++ code that needs to be compiled against 2 other packages. So the LinkingTo field in DESCRIPTION looks like this LinkingTo: FLCore,FLash Both packages are also in the Depends field. In R 2.6.2, first thing we noticed was that both names could not have any space between them, althoguh the example in the html version of "Writing R Extensions" does

Hello, In Sections 5.8.1 and 5.8.2 of Writing R Extensions the following pattern is suggested for getting the path to a file in another package: PKGB_PATH=‘echo ’library(packB); cat(system.file("libs", package="packB"))’ \ | ${R_HOME}/bin/R --vanilla --slave‘ Is the library(packB) really needed here? It is not needed on two systems that I have tested: Windows and Linux. What

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

Dear list For my work, it would be helpful if rpart worked seamlessly with an empty model: library(rpart); rpart(formula=y~0, data=data.frame(y=factor(1:10))) Currently, an unrelated error (originating from na.rpart) is thrown. At some point in the near future, I'd like to release a package to CRAN which uses rpart and relies on that functionality. I have prepared a patch (minor

I am experimenting with exporting pointers to some of the functions in deSolve so that other packages may import them, using the 'R_RegisterCCallable' mechanism. I have added a header file and some other C code in inst/include of the deSolve source package that need to be accessible to other packages. I have a site-library set up in Rprofile.site where all installed packages go, and as

Hi Accesses the $new method for a class defined in a package fails if the methods package is not loaded. I have created a test package with the following single code file: newTest <- function() { cl <- get("someClass") cl$new } someClass <- setRefClass("someClass") (This is similar to code actually used in the testthat package.) If methods is not loaded,

>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> >>>>> on Thu, 8 Jun 2017 12:55:26 +0200 writes: > On 06.06.2017 22:14, Kirill M?ller wrote: >> >> >> On 06.06.2017 10:07, Martin Maechler wrote: >>>>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> on