similar to: allocVector reference

For using R's .Call interface to C functions, all the examples I've seen have the C function return type SEXP. Why? What does R actually do with this return type? What happens if I *don't* return a SEXP? Reason I ask, is I've written some R code which allocates two long lists, and then calls a C function with .Call. My C code writes to those two pre-allocated lists, thus, I

Dear R-dev, I would like to accelerate my R computation by using parallel OpenMP compilers (e.g from Pathscale) on a 2-processor AMD server and I would like to know whether R is a tread safe library. The main kernel of the OpenMP parallelization is a C SEXP function that performs the computational routine in parallel with: ******************* SEXP example(SEXP list, SEXP expr, SEXP rho) {

Hi, I am a newbie on C++ Right now I have an array of doubles in C++. Is there a way to "export" that array into R? Of course, I can allocate the memory block first using "allocVector" and copying the array contents one by one. But, what if that array is fairly large? Copying doesn't look that efficient. I was thinking of setting the data pointer(DATAPTR) point to that

R folks, I'm curious about possible support for Lisp-style macros in R. I'm aware of the "defmacro" support for S-Plus and R discussed here: http://www.biostat.wustl.edu/archives/html/s-news/2002-10/msg00064.html but that's really just a syntactic short-cut to the run-time use of substitute() and eval(), which you could manually put into a function yourself if you cared

Hi everybody, I have been interfacing some C++ library code into an R package but ran into optimization issues specific to memory management that require some insight into the GC. One of the C++ libraries returns simple vectors of integers, doubles and complex which are allocated and managed from the library itself. I cannot know the length of the array beforehand, so I cannot pre-allocate that

It would be nifty to incorporate this into R or into an R package: http://sourcefrog.net/projects/natsort/

On 4 February 2016 at 22:56, Sebastian P. Luque wrote: | Hello, | | It has been a while since my last R Devel build, and now I'm running | into an issue I'm not sure how to isolate. After updating to the latest | SVN sources, and using: | | ---<--------------------cut here---------------start------------------->--- | tools/rsync-recommended | R_PAPERSIZE=letter \ |

Rprof seems to ignore all time spent inside system() calls. E.g., this simple example actually takes about 10 seconds, but Rprof thinks the total time is only 0.12 seconds: > Rprof("sleep-system.out") ; system.time(system(command="sleep 10")) ; Rprof(NULL) user system elapsed 0.000 0.004 10.015 > summaryRprof("sleep-system.out")$by.total

Hello, Until last weekend, I used to build R Devel smoothly with this switch (--enable-strict-barrier) on, but now it fails on my Debian system (found the culprit after posting on r-sig-debian). Configuring and building with: ---<--------------------cut here---------------start------------------->--- tools/rsync-recommended R_PAPERSIZE=letter \ R_BATCHSAVE="--no-save

WRE explains that R_alloc() can be used to allocate memory which automatically gets released by R at the end of a .C, .Call or .External, even in the case of an error or interruption. This is a really great feature to prevent memory leaks. I was wondering if there is a way to extend this mechanism to allow for automatically running UNPROTECT and custom finalizers at the end of a .Call as well.

Hello, It has been a while since my last R Devel build, and now I'm running into an issue I'm not sure how to isolate. After updating to the latest SVN sources, and using: ---<--------------------cut here---------------start------------------->--- tools/rsync-recommended R_PAPERSIZE=letter \ R_BATCHSAVE="--no-save --no-restore" \ R_BROWSER=xdg-open \ LIBnn=lib \

For many years, when my R process starts up I've been automatically setting my preferred default plot colors, basically like so: my.colors <- c("black" ,"red" ,"gold" ,"sky blue" ,"green" ,"blue" ,"orange" ,"grey" ,"hot pink" ,"brown" ,"sea green" ,"cyan"

Hi. I have the following question about reading from large data objects from within R functions; I have tried to simplify my problem as much as possible in what follows. Imagine I have various large data objects sitting in my global environment (call them "data1", "data2", ...). I want to write a function "extract" that extracts some of the rows of a particular

I am calling a C (C++ really) function via the .C interface. Sometimes when things go wrong I want to return an error message. 1. R provides C functions error and warning which look about right. But exactly how does this exit, and in particular what happens with cleaning up, calling C++ destructors, and unwinding the stack? Will I get memory leaks? 2. Before I discovered those functions, I

On Fri, 10 May 2019, ??? wrote: > Hi Gabriel, > > Thanks for your explanation, I totally understand that it is almost > impossible to change the data structure of STRSXP. However, what I'm > proposing is not about changing the internal representation, but rather > about how we design and use the ALTREP API. > > I might do not state the workarounds clearly as English is

Hi, I am not sure if this is a bug and I apologize if it is something I didn't read carefully in the R extension manual. My initial search on the R help and R devel list archive didn't find useful information. I am using .Call (as written in the R extension manual) for the C code and have found that the .Call didn't release the memory claimed by allocVector. Even after applying

Hi, I am not sure if this is a bug and I apologize if it is something I didn't read carefully in the R extension manual. My initial search on the R help and R devel list archive didn't find useful information. I am using .Call (as written in the R extension manual) for the C code and have found that the .Call didn't release the memory claimed by allocVector. Even after applying

I recently started using R 2.7.2, and noticed a surprising change in the behavior of var() on NA data: R 2.6.1 (Patched), 2007-11-26, svn.rev 43541, x86_64-unknown-linux-gnu: > stdev(rep(NA,3), na.rm=F) [1] NA > stdev(rep(NA,3), na.rm=T) [1] NA > var(rep(NA,3), na.rm=T, use="complete.obs") [1] NA R 2.7.2 (Patched), 2008-09-02, svn.rev 46491,

I want to create my own "[" function (for use on vectors, matrices, arrays, etc.), which calls the stock R "[", does some additional work, and then finally returns the modified result. But, how do I properly call the stock R "[" function? It takes a varying number of positional arguments, and its R-level closure is just: .Primitive("[") It's

>From copyVector in duplicate.c : void copyVector(SEXP s, SEXP t) { int i, ns, nt; nt = LENGTH(t); ns = LENGTH(s); switch (TYPEOF(s)) { ... case INTSXP: for (i = 0; i < ns; i++) INTEGER(s)[i] = INTEGER(t)[i % nt]; break; ... could that be replaced with : case INTSXP: for (i=0; i<ns/nt; i++) memcpy((char *)DATAPTR(s)+i*nt*sizeof(int),