similar to: Speed improvement to PROTECT, UNPROTECT, etc.

Full_Name: John Brzustowski Version: R-devel trunk and R-2.4.0 OS: linux Submission from: (NULL) (76.10.152.79) Here are two minor potential issues in pointer protection stack (PPS) code which could arise in debugging R with valgrind. Only the second could possibly cause a problem in normal use of R, and only under laughably implausible circumstances. (1) valgrind is given a wrong address when

[Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-request at r-project.org wrote: > > Hello, > > We are currently making lots of changes to Rcpp (see the open Rcpp > mailing list if interested [1] in the details). > > We are now using [2] R_PreserveObject and R_ReleaseObject

Hi, As the subject suggests, I am looking for the most robust way to call an (arbitrary) function from the R API from another but the main POSIX thread in a package's code. I know that, "[c]alling any of the R API from threaded code is ?for experts only? and strongly discouraged. Many functions in the R API modify internal R data structures and might corrupt these data structures if

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

Stepan, Andreas gave a lot more thought into what you question in your reply. His question was how you can avoid what you where proposing and have proper threading under safe conditions. Having dealt with this before, I think Andreas' write up is pretty much the most complete analysis I have seen. I'd wait for Luke to chime in as the ultimate authority if he gets to it. The

I've continued to work on speeding up R, and now have a collection of fourteen patches, some of which speed up particular functions, and some of which reduce general interpretive overhead. The total speed improvement from these patches is substantial. It varies a lot from one R program to the next, of course, and probably from one machine to the next, but speedups of 25% can be expected in

Hello all, I am using R 2.4.0 and SJava 0.69-0 on linux. I am not able to install SJava on R. The following errors appear when installing: ... ** R ** inst WARNING: use of install..R is no longer supported ** preparing package for lazy loading Creating a new generic function for "merge" in "SJava" ** help >>> Building/Updating help pages for package

Your analysis looks pretty complete to me and your solutions seems plausible. That said, I don't know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually possible to provide some support for this to be handled via a thread-local variable. Ensuring

Hi Andreas, note that with the introduction of ALTREP, as far as I understand, calls as "simple" as DATAPTR can execute arbitrary code (R or native). Even without ALTREP, if you execute user-provided R code via Rf_eval and such on some custom thread, you may end up executing native code of some package, which may assume it is executed only from the R main thread. Could you (1)

I've continued to work on speeding up R, and now have a collection of fourteen patches, some of which speed up particular functions, and some of which reduce general interpretive overhead. The total speed improvement from these patches is substantial. It varies a lot from one R program to the next, of course, and probably from one machine to the next, but speedups of 25% can be expected in

Hello! I'd like to ask you a question about c (macros): In Rinternals.h are defined: a) SEXP Rf_protect(SEXP); b) #define protect Rf_protect c) #define PROTECT(s) protect(s) As far as I understand the calls Rf_protect( x ), protect( x ) and PROTECT( x ) are all equalent. So whats the reason that there are 2 macros defined? Why 3 times the same when 1 distinct function would be

Hello, I am new to this list. ?I am trying to compile the current svn version of kdeedu on an amd64 linux machine ?which uses R and I get the following compiler output. ------------------------------------------- ?79%] Building CXX object cantor/src/backends/R/rserver/CMakeFiles/cantor_rserver.dir/rserver.o $SOURCES/kdeedu/cantor/src/backends/R/rserver/rserver.cpp: In member function

Le 15/05/2017 ? 15:37, Martin Maechler a ?crit : >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 15 May 2017 13:14:34 +0200 writes: > > I see in the archives that the attachment cannot pass. > > So, here is the code: > > [....... MM: I needed to reformat etc to match closely to > the current

Hello, I'm evaluating this expression expression({ for(x in 1:5){ .Call('rh_status','x') }}) a million times from a program with R embedded in it. I have attached reproducible code that crashes with Program received signal SIGSEGV, Segmentation fault. 0x00002b499ca40a6e in R_gc_internal (size_needed=0) at memory.c:1309 1309 FORWARD_NODE(R_PPStack[i]); Current language:

Hello, (This is follow up from this thread: http://www.nabble.com/execution-time-of-.packages-td22304833.html but with a different focus) I am often confused by the result of the profiler, when a loop is involved. Consider these two scripts: script1: Rprof( ) x <- numeric( ) for( i in 1:10000){ x <- c( x, rnorm(10) ) } Rprof( NULL ) print( summaryRprof( ) ) script2:

This is getting pretty convoluted. The current behavior is consistent with the description at the top of the help page -- it does not promise to stop evaluation once the first non-TRUE is found. That seems OK to me -- if you want sequencing you can use stopifnot(A) stopifnot(B) or stopifnot(A && B) I could see an argument for a change that in the multiple argumetn case reports _all_

Hi gurus, After an unsuccessful scrabble through the documentation and Jon's excellent search facility, I am no wiser as to how R recognizes an incomplete command line and politely raises its hand for more. The help page for parse gives no indication that it does anything more than spit the dummy when fed an incomplete command line, but something in there must recognize such ellipsis.

Hi gurus, After an unsuccessful scrabble through the documentation and Jon's excellent search facility, I am no wiser as to how R recognizes an incomplete command line and politely raises its hand for more. The help page for parse gives no indication that it does anything more than spit the dummy when fed an incomplete command line, but something in there must recognize such ellipsis.

>>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 15 May 2017 16:54:46 -0700 writes: > Hi, > On 05/15/2017 10:41 AM, luke-tierney at uiowa.edu wrote: >> This is getting pretty convoluted. >> >> The current behavior is consistent with the description at the top of >> the help page -- it does not

Hi folks, I apologise if this is in the documentation somewhere, but I can't seem to find it. I also did a search of CRAN without any success. I'm using R-1.8.1 (pre-compiled) on Windows 2000 with Rtools and mingw 2.0.0 (which includes gcc/g++ 3.2). I'm trying to link some C++ code from another application to R using the .Call interface and am experiencing some problems. I was