search for: reprotected

On 06.06.2017 10:07, Martin Maechler 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);

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

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

>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> >>>>> on Thu, 8 Jun 2017 12:55:26 +0200 writes: > On 06.06.2017 22:14, Kirill M?ller wrote: >> >> >> On 06.06.2017 10:07, Martin Maechler wrote: >>>>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> on

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

On 06.06.2017 22:14, Kirill M?ller wrote: > > > On 06.06.2017 10:07, Martin Maechler 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 >>

Hello. I'm trying to read a delimited file. I'm a little new to the R api. In the program, I do something like this... /*****************************/ SEXP retval; PROTECT(retval = allocMatrix(STRSXP,1,names.dim)); int r_eltctr = 0; while(!myfile.eof()) { SET_LENGTH(retval,r_eltctr+num_of_fields); for(int i = 0;numofcolumns; ++i) { INTEGER(retval)[r_eltctr++] = 1;/*some

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

Dear R-devel, A couple of weeks ago I started to use the R C API for package development. Without knowing much about C, I've been able to write some routines sucessfully... until now. My problem consists in dynamically creating a list ("L1") of lists using .Call, the tricky part is that each element of the "mother list" contains two vectors (INTSXP and REALEXP types) with

As I mentioned in my previous message about speeding up evalList, I've been looking at ways to speed up the R interpreter. One sees in the code many, many calls of PROTECT, UNPROTECT, and related functions, so that seems like an obvious target for optimization. Indeed, I've found that one can speed up the interpreter by about 10% by just changing these. The functions are actually macros

Create a new PTE function which combines clearing a kernel PTE with the subsequent flush. This allows the two to be easily combined into a single hypercall or paravirt-op. More subtly, reverse the order of the flush for kmap_atomic. Instead of flushing on establishing a mapping, flush on clearing a mapping. This eliminates the possibility of leaving stale kmap entries which may still have

Can please someone familiar with the R internals enlighten me on the following strange observation: # this is IDENTICAL as expected identical(substitute(substitute()), substitute(substitute())) # but NOT EQUAL !???? substitute(substitute()) == substitute(substitute()) # I originally found it on t2 <- function(e){ substitute(e) } t2(substitute(x==y, list(y=y)))[1] # I would expect all

Hello, This is a question that probably reveals my lack of understanding. In a C function (call it cfunc), i created a SEXP, called S, and then called R_PreserveObject on S. I returned the SEXP to the calling R function (call it rfunc). Note, I didn't call R_ReleaseObject on S. v <- .Call("cfunc") So, are the following statements correct 1. S is 'doubly' protected

[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

Good morning! I recently implemented a KD tree in JAVA for faster kernel density estimation (part of the code follows). It went well. To hook it with R, however, has proved more difficult. My question is: is it possible to implement the algorithm in R? My impression seems to indicate no as the code requires a complete class-object framework that R does not support. But is there an R package or

The build system rolled up R-3.0.0.tar.gz (codename "Masked Marvel") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.0.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter Dalgaard

The build system rolled up R-3.0.0.tar.gz (codename "Masked Marvel") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-3/R-3.0.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter Dalgaard

At OLS I gave a talk on some of the Xen scalability inhibitors, and one of these was writable page tables. We went over why the feature does not scale, but just as important, we found that the uniprocessor case does not provide any advantage either. These tests were done on x86_64, so I wanted to run the 1-way test on 32 bit to show the same problem. So, I have run with writable PTs and