search for: protect_with_index

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); but I believe it has to be PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), &ipx); because PROTECT_WITH_INDEX() returns void. Best regards Kirill

...r 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); > > > but I believe it has to be > > > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), &ipx); > > > because PROTECT_WITH_INDEX() returns void. > > Yes indeed, thank you Kirill! > > no...

...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); >>> >>> > but I believe it has to be >>> >>> > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), >>> &ipx); >>> >>> > b...

>>>>> 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); > but I believe it has to be > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), &ipx); > because PROTECT_WITH_INDEX() returns void. Yes indeed, thank you Kirill! note that the same is true for its partner functio...

...;>>> 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); >> >> > but I believe it has to be >> >> > PROTECT_WITH_INDEX(s = eval(OS->R_fcall, OS->R_env), &ipx); >> >> > because PROTECT_WITH_INDEX() returns void. >> >> Yes indeed...

What is the best way to grow an R return object in writing a C function using the Rdefines.h macros. In my application, the final size of the return object is not known during construction. My understanding is that each time I grow an R object I have to use PROTECT() again, probably before UNPROTECTing the smaller version. However, due to the stack character of the PROTECT mechanism, UNPROTECT

...ach element of the mother list: for(i=0;i<n;i++) { SECOND: By reading this post in Stackoverflow http://stackoverflow.com/questions/7458364/growing-an-r-matrix-inside-a-c-loop/7458516#7458516 I understood that it was necesary to (1) create the "child lists" and protecting them with PROTECT_WITH_INDEX, and (2) changing its size using SETLENGTH (Rf_lengthgets) and REPROTECT ing the lists in order to tell the GC that the vectors had change. THIRD: Once my two vectors are done ("id" and "lambda"), assign them to the i-th element of the "mother list" L1 using SET_VEC...

...R_PPStack[R_PPStackTop++] = tmp_prot_sexp; \ else \ Rf_protect(tmp_prot_sexp); \ } while (0) #define UNPROTECT(n) (R_PPStackTop >= (n) ? \ (void) (R_PPStackTop -= (n)) : Rf_unprotect(n)) #define PROTECT_WITH_INDEX(x,i) do { \ PROTECT(x); \ *(i) = R_PPStackTop - 1; \ } while (0) #define REPROTECT(x,i) ( (void) (R_PPStack[i] = x) ) Unfortunately, one can't just change the definitions in Rinternals.h. S...

...sentation(x="numeric", y="numeric")) [1] "track" > o <- new( "track", x = 1, y = 2 ) > for( i in o ){ + cat( "hello\n") + } Error: invalid type/length (S4/1) in vector allocation This happens at those lines of do_for: n = LENGTH(val); PROTECT_WITH_INDEX(v = allocVector(TYPEOF(val), 1), &vpi); because allocVector( S4SXP, 1) does not make sense. What about detecting S4SXP and attempt to call as.list, similarly to what lapply does ? > as.list.track <- function(x, ...){ list( x = x at x, y = x at y ) } > lapply( o, identity ) $x [1...

Hi folks. I posted this question a few days ago, but maybe it got lost because of the code I included with it. I'm having a problem using the SET_LENGTH() macro in an R extension I'm writing in C++. In a function within the extension I use SET_LENGTH() to resize R vectors so as to allow the concatenation of single values onto the vectors -- it's a "push back" function to

I'm preparing some code to compute the optimal geometry of stressed solids. The core of the calculations is the optimization of elastic energy using the simulated annealing method implemented in the R optim() rutine. I've defined a function to compute this "energy" scalar (the fn parameter for optim) and prepared a list with the arrays defining the geometry and the elastic

...or the tarball. * R CMD build now removes src/*.mod files on all platforms. C-LEVEL FACILITIES: * New pointer protection C functions R_PreserveInMSet and R_ReleaseFromMSet have been introduced to replace UNPROTECT_PTR, which is not safe to mix with UNPROTECT (and with PROTECT_WITH_INDEX). Intended for use in parsers only. * NAMEDMAX has been raised to 7 to allow further protection of intermediate results from (usually ill-advised) assignments in arguments to BUILTIN functions. Properly written package code should not be affected. * R_unif_index is now c...

...or the tarball. * R CMD build now removes src/*.mod files on all platforms. C-LEVEL FACILITIES: * New pointer protection C functions R_PreserveInMSet and R_ReleaseFromMSet have been introduced to replace UNPROTECT_PTR, which is not safe to mix with UNPROTECT (and with PROTECT_WITH_INDEX). Intended for use in parsers only. * NAMEDMAX has been raised to 7 to allow further protection of intermediate results from (usually ill-advised) assignments in arguments to BUILTIN functions. Properly written package code should not be affected. * R_unif_index is now c...

...or the tarball. * R CMD build now removes src/*.mod files on all platforms. C-LEVEL FACILITIES: * New pointer protection C functions R_PreserveInMSet and R_ReleaseFromMSet have been introduced to replace UNPROTECT_PTR, which is not safe to mix with UNPROTECT (and with PROTECT_WITH_INDEX). Intended for use in parsers only. * NAMEDMAX has been raised to 7 to allow further protection of intermediate results from (usually ill-advised) assignments in arguments to BUILTIN functions. Properly written package code should not be affected. * R_unif_index is now c...

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