Re: [Rd] Use of C++ in Packages

2019-03-29 Thread Simon Urbanek
Kevin, > On Mar 29, 2019, at 17:01, Kevin Ushey wrote: > > I think it's also worth saying that some of these issues affect C code > as well; e.g. this is not safe: > >FILE* f = fopen(...); >Rf_eval(...); >fclose(f); > I fully agree, but developers using C are well aware of the

Re: [Rd] Use of C++ in Packages

2019-03-29 Thread Gabriel Becker
Hi Jim (et al.), Comments inline (and assume any offense was unintended, these kinds of things can be tricky to talk about). On Fri, Mar 29, 2019 at 8:19 AM Jim Hester wrote: > First, thank you to Tomas for writing his recent post[0] on the R > developer blog. It raised important issues in

Re: [Rd] default for 'signif.stars'

2019-03-29 Thread Abs Spurdle
> If we were to invent lm() now, how would we solve the problem of big P? > I don't think we would use stars. Assuming that this is a good idea in the first place, here's a simple solution, in the context of backward selection. One could sort the terms, from lowest p-value to highest p-value. If

Re: [Rd] Use of C++ in Packages

2019-03-29 Thread Kevin Ushey
I think it's also worth saying that some of these issues affect C code as well; e.g. this is not safe: FILE* f = fopen(...); Rf_eval(...); fclose(f); whereas the C++ equivalent would likely handle closing of the file in the destructor. In other words, I think many users just may not

[Bioc-devel] Significant User Interface Change to AnnotationHub and ExperimentHub

2019-03-29 Thread Shepherd, Lori
It has been a concern for awhile to have file level checks for when a remote data resource has been updated. While we implemented the option to be able to force download (hub[[force=TRUE]]) we still felt like this should be improved upon. With the creation of BiocFileCache, we decided it was

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread Ralf Stubner
On 29.03.19 17:05, William Dunlap wrote: > It looks like it is not boost but RcppEigen that has the call to > std::rand() that volesti/src/rotating.cpp contains. > > RcppEigen/include/Eigen/src/Core/MathFunctions.h: > static inline Scalar run(const Scalar& x, const Scalar& y) > { > return

Re: [Rd] Use of C++ in Packages

2019-03-29 Thread Simon Urbanek
Jim, I think the main point of Tomas' post was to alert R users to the fact that there are very serious issues that you have to understand when interfacing R from C++. Using C++ code from R is fine, in many cases you only want to access R data, use some library or compute in C++ and return

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread William Dunlap
One can use 'g++ -E' to find the which include file is the culprit. E.g., % g++ -c -E -I`R RHOME`/include -I`R RHOME`/site-library/Rcpp/include -I`R RHOME`/site-library/RcppEigen/include -Iexternal/LPsolve_src/run_headers -Iexternal/minimum_ellipsoid -Iinclude -Iinclude/volume

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread William Dunlap
The check only looks at compiled code. BH contains only headers, no compiled code. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Mar 29, 2019 at 9:27 AM Maxime Turgeon < maxime.turg...@mail.mcgill.ca> wrote: > Hi Bill, > > Maybe I'm missing something, but if RcppEigen were the cause of

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread Ralf Stubner
On 29.03.19 17:27, Maxime Turgeon wrote: > Maybe I'm missing something, but if RcppEigen were the cause of the NOTE, > wouldn't RcppEigen also get the same NOTE? However, it does not: > https://cran.r-project.org/web/checks/check_results_RcppEigen.html > > And for what it's worth, neither does

Re: [Rd] Bug in the "reformulate" function in stats package

2019-03-29 Thread Ben Bolker
I suspect that the issue is addressed (obliquely) in the examples, which shows that variables with spaces in them (or otherwise 'non-syntactic', i.e. not satisfying the constraints of legal R symbols) can be handled by protecting them with backticks (``) ## using non-syntactic names:

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread Maxime Turgeon
Hi Bill, Maybe I'm missing something, but if RcppEigen were the cause of the NOTE, wouldn't RcppEigen also get the same NOTE? However, it does not: https://cran.r-project.org/web/checks/check_results_RcppEigen.html And for what it's worth, neither does BH:

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread William Dunlap
It looks like it is not boost but RcppEigen that has the call to std::rand() that volesti/src/rotating.cpp contains. RcppEigen/include/Eigen/src/Core/MathFunctions.h: static inline Scalar run(const Scalar& x, const Scalar& y) { return x + (y-x) * Scalar(std::rand()) / Scalar(RAND_MAX);

Re: [Rd] Bug in the "reformulate" function in stats package

2019-03-29 Thread J C Nash
The main thing is to post the "small reproducible example". My (rather long term experience) can be written if (exists("reproducible example") ) { DeveloperFixHappens() } else { NULL } JN On 2019-03-29 11:38 a.m., Saren Tasciyan wrote: > Well, first I can't sign in bugzilla

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread William Dunlap
> Library lpSolveAPI uses rand() and srand() in lp_utils.c. We replace > both functions with GetRNGstate(); PutRNGstate(); unif_rand(); from > R’s internal random number generation routines as it is proposed in > `Writing R Extensions`. Moreover if you run in folder `/src`: > $ grep -r 'rand()' >

Re: [Rd] Bug in the "reformulate" function in stats package

2019-03-29 Thread Saren Tasciyan
Well, first I can't sign in bugzilla myself, that is why I wrote here first. Also, I don't know if I have the time at the moment to provide tests, multiple examples or more. If that is not ok or welcomed, that is fine, I can come back, whenever I have more time to properly report the bug. I

[Rd] Use of C++ in Packages

2019-03-29 Thread Jim Hester
First, thank you to Tomas for writing his recent post[0] on the R developer blog. It raised important issues in interfacing R's C API and C++ code. However I do _not_ think the conclusion reached in the post is helpful > don’t use C++ to interface with R There are now more than 1,600 packages

Re: [Bioc-devel] update maintainer or nucleR package

2019-03-29 Thread Turaga, Nitesh
Hi, If you want to change the maintainer on your package, please make the change in the DESCRIPTION file. This is something you need to do. I can make the change on the Bioconductor end, and change the access rights to your package with the new email address. It looks like Diego needs a

Re: [Bioc-devel] failing package seq2pathway

2019-03-29 Thread Turaga, Nitesh
Hi Jennifer, It seems that you are not following the instructions accurately as given on the link you sent. You notice that you are only interacting with your Github repository and not the git.bioconductor.org private git server. You have to add both the "remote"

Re: [R-pkg-devel] CRAN review

2019-03-29 Thread Vissarion Fisikopoulos
Dear all, @Henrik: thanks a lot for your reply. I did one more submission (the third) and I am posting below my answer to the automatic cran email with 2 NOTES. Looking forward to your feedback. Best regards, Vissarion. On Fri, 29 Mar 2019 at 11:04, Vissarion Fisikopoulos wrote: > > Dear

Re: [Rd] Bug in the "reformulate" function in stats package

2019-03-29 Thread Martin Maechler
> Saren Tasciyan > on Thu, 28 Mar 2019 17:02:10 +0100 writes: > Hi, > I have found a bug in reformulate function and have a solution for it. I > was wondering, where I can submit it? > Best, > Saren Well, you could have given a small reproducible example

[Rd] Bug in the "reformulate" function in stats package

2019-03-29 Thread Saren Tasciyan
Hi, I have found a bug in reformulate function and have a solution for it. I was wondering, where I can submit it? Best, Saren -- Saren Tasciyan /PhD Student / Sixt Group/ Institute of Science and Technology Austria Am Campus 1 3400 Klosterneuburg, Austria

Re: [Rd] default for 'signif.stars'

2019-03-29 Thread Andrew Robinson
Hi Martin, I take your point - but I'd argue that significance stars are a clumsy solution to the very real problem that you outline, and their inclusion as a default sends a signal about their appropriateness that I would prefer R not to endorse. My preference (to the extent that it matters)