search for: rchk

...ropriate for r-pkg-devel please let me know and I'll repost it over there ...] I'm writing to ask for help with some R/C++ integration idioms that are used in a package I'm maintaining, that are unfamilar to me, and that are now being flagged as problematic by Tomas Kalibera's 'rchk' machinery (https://github.com/kalibera/rchk); results are here https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out The problem is with constructions like ::Rf_eval(::Rf_lang2(fun, arg), d_rho) I *think* this means "construct a two-element pairlist from f...

...please let me know and > I'll repost it over there ...] > > I'm writing to ask for help with some R/C++ integration idioms that are > used in a package I'm maintaining, that are unfamilar to me, and that > are now being flagged as problematic by Tomas Kalibera's 'rchk' > machinery (https://github.com/kalibera/rchk); results are here > https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out > > The problem is with constructions like > > ::Rf_eval(::Rf_lang2(fun, arg), d_rho) > > I *think* this means "co...

...and >> I'll repost it over there ...] >> >> I'm writing to ask for help with some R/C++ integration idioms that are >> used in a package I'm maintaining, that are unfamilar to me, and that >> are now being flagged as problematic by Tomas Kalibera's 'rchk' >> machinery (https://github.com/kalibera/rchk); results are here >> https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/lme4.out >> >> >> The problem is with constructions like >> >> ::Rf_eval(::Rf_lang2(fun, arg), d_rho) >&g...

On 24 March 2020 at 11:39, Lionel Henry wrote: | > 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); Good catch. And recursive grep for Rf_lang2 in the Rcpp sources tree suggests

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

...there? Regards Hugh On Mon, Apr 1, 2019 at 6:23 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > On 3/30/19 8:59 AM, Romain Francois wrote: > > tl;dr: we need better C++ tools and documentation. > > > > We collectively know more now with the rise of tools like rchk and > improved documentation such as Tomas?s post. That?s a start, but it appears > that there still is a lot of knowledge that would deserve to be promoted to > actual documentation of best practices. > Well there is quite a bit of knowledge in Writing R Extensions and many > proble...

On 3/30/19 8:59 AM, Romain Francois wrote: > tl;dr: we need better C++ tools and documentation. > > We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas?s post. That?s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. Well there is quite a bit of knowledge in Writing R Extensions and many problems could have been preve...

...s been my stumbling block. At least last time I tried I got stuck at the? Fortran step. It doesn't help I have very limited experience compiling? software of the complexity of R.? Really, I've only done it within the warm welcoming confines of the vagrant image Tomas Kalibera set up for `rchk`. I also use r-devel on docker, but that isn't very practical for day-to-day usage, which is what I think we need. What would it take to generate pre-release binaries for OS X (and Windows)?? I imagine if such were available the volume of testers would increase dramatically (at least, I haven...

tl;dr: we need better C++ tools and documentation. We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas?s post. That?s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not just RAII. RA...

...g block. > At least last time I tried I got stuck at the Fortran step. It doesn't > help I have very limited experience compiling software of the complexity > of R. Really, I've only done it within the warm welcoming confines of the > vagrant image Tomas Kalibera set up for `rchk`. > > I also use r-devel on docker, but that isn't very practical for > day-to-day usage, which is what I think we need. > > What would it take to generate pre-release binaries for OS X (and Windows)? I > imagine if such were available the volume of testers would increase &...

>>>>> Sebastian Meyer >>>>> on Fri, 15 May 2020 10:47:55 +0200 writes: > I can confirm this changed behaviour. I just compared R-3.6.3 with > yesterday's R-devel. Using R-devel, the tempfile opened by the editor > (Emacs for me, but shouldn't matter) contains doubled backslashes. > This could be related to >

I think there is a memory bug in `substr` that is triggered by a UTF-8 corner case: an incomplete UTF-8 byte sequence at the end of a string.? With a valgrind level 2 instrumented build of R-devel I get: > string <- "abc\xEE"??? # \xEE indicates the start of a 3 byte UTF-8 sequence > Encoding(string) <- "UTF-8" > substr(string, 1, 10) ==15375== Invalid read of

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 be cognizant of the fact that most R APIs can longjmp, and what that implies for cleanup of