similar to: Use of C++ in Packages

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

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

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 results. Such use-cases are completely fine in C++ as they don't need to trigger the issues

Kevin, > On Mar 29, 2019, at 17:01, Kevin Ushey <kevinushey at gmail.com> 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 necessity of handling lifespan of objects

Dear r-devel folks, [if this is more appropriate 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);

Please patch Mini-OS so that it uses stddef.h to define size_t and NULL. This problem fixes errors that occur when linking Mini-OS with ANSI standard code that uses stddef.h. John diff -ur oxen-3.0-testing/extras/mini-os/include/lib.h nxen-3.0-testing/extras/mini-os/include/lib.h --- oxen-3.0-testing/extras/mini-os/include/lib.h 2006-04-14 22:21:55.000000000 -0400 +++

Thanks, that's really useful. One more question for you, or someone else here: const ArrayXd glmLink::linkFun(const ArrayXd& mu) const { return as<ArrayXd>(::Rf_eval(::Rf_lang2(as<SEXP>(d_linkFun), as<SEXP>(Rcpp::NumericVector(mu.data(), mu.data() + mu.size())) ), d_rho); } I guess I need that to read

On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma > Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am

Hi, I am encountering a problem that I do not know how to debug. I would greatly appreciate any guidance on this issue. On Windows when I run Lua test cases from JITed code I am getting following error: Unhandled exception at 0x00007FFCEEEAC500 (ntdll.dll) in lua.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation. This is happening when the Lua code is

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

On 8/22/20 8:26 PM, Tomas Kalibera wrote: > On 8/22/20 7:58 PM, Jeroen Ooms wrote: >> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera >> <tomas.kalibera at gmail.com> wrote: >>> On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: >>>> Ah yes, this is related. I reported v2010 below, but it looks like >>>> I was updated to this

On 8/22/20 9:33 PM, Jeroen Ooms wrote: > On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: >> On 8/22/20 8:26 PM, Tomas Kalibera wrote: >>> On 8/22/20 7:58 PM, Jeroen Ooms wrote: >>>> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera >>>> <tomas.kalibera at gmail.com> wrote: >>>>> On 8/21/20 11:45

On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote: > > Ah yes, this is related. I reported v2010 below, but it looks like I was updated to this Insider Build overnight without my knowledge, and conflated it with the new installation R v4 this morning. > > > > I will

To reduce difficulties for people relying on automated tests set up to build&"check --as-cran" using R-devel (e.g. travis-ci), the default serialization version has been temporarily switched back to 2. Thank you for your patience - according to svn history, the last change of the serialization format happened 16 years ago, and unsurprisingly some practices that developed since

On Lua: lua_version=5.3.4 On Perl: perl_version=5.28.0 On Python 2: python_version=2.7.15 On Python 3: python_version=3.7.0 python_pep_384_abi_version=3 On Ruby 2.5.1p57: ruby_api_version=2.5.0 On Tcl: tcl_version=8.6 tcl_patch_level=8.6.8 --- plugins/lua/lua.c | 11 +++++++++++ plugins/perl/perl.c | 4 ++++ plugins/python/python.c | 8 ++++++++

This request stems off a bug report I posted https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was determined the current behaviour is as expected. To recap: when given a real file, normalizePath() always* returns the full absolute path. When given a non-existent file, normalizePath() returns a full path on Windows but it returns the input on other systems*. I'd argue that

Are you using split stacks of some kind? Are you sure these actually work as intended on Win64? Based on the source code, it looks like you are allocating stack manually, but I could be wrong. What triple are you using with LLVM to generate code? There isn't much else information here, but you can try to zero in on the problem by checking the stack alignment manually with a helper like: void

#this is my stab at - I am sure that I am missing something. If this doesn't make sense then please ask for more details. #This may show my low level of programing knowledge hester. <- c(1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4) value <- rnorm(16) x <- data.frame(value, hester.) z <- (if(x[,"hester."]==1){ x[,"value"]*6.250} else if(x[,"hester."]==2){

On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 8/25/20 6:14 PM, Tomas Kalibera wrote: > > On 8/22/20 9:33 PM, Jeroen Ooms wrote: > >> On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera > >> <tomas.kalibera at gmail.com> wrote: > >>> On 8/22/20 8:26 PM, Tomas Kalibera wrote: > >>>> On

R does provide the addTaskCallback / taskCallbackManager to run a callback function after every top level command. However there is not an equivalent interface that would be run _before_ each command, which would make it possible to time of top level calls and provide other execution measurements. On Thu, Dec 21, 2017 at 11:31 AM, William Dunlap via R-devel <r-devel at r-project.org> wrote: