Hi everyone. I'm working on R sources themselves (look into past
messages if interested), and need to debug/benchmark R itself.
To check R functionality, I'm running the test-suite with 'make
check-devel', but it seems to overwrite the "reference output" at each
invocation. I want to compare the o
On Thu, 13 Aug 2009 13:42:39 -0400
Simon Urbanek wrote:
> I'm not convinced that what you propose is a good idea. First, I
> don't quite understand why you would want to use an existing SEXP -
> if you had a valid SEXP for the current R instance, then there is no
> need for R_RegisterObject. If t
Hi everyone. In response to my previous message (Memory management
issues), I've come up with the following patch against R 2.9.1.
To summarize the situation:
- We're hitting the memory barrier in our lab when running concurrent R
processes due to the large datasets we use.
- We don't want to c
In article
<8ec76080907051259q4744d40bp46b2434b086d5...@mail.gmail.com>,
Whit Armstrong wrote:
> If you are in control of the c++ library (i.e. it is not from a
> vendor), then you can also override the new operator of your object so
> that it allocates an SEXP. if you implement PROTECT/UNPROT
In article <4a5102ff.8040...@stats.uwo.ca>,
Duncan Murdoch wrote:
> > What I'd would like to do is:
> >
> > - "patch" the SEXP returned to R so that DATAPTR() points directly to
> > the required address.
>
> The normal way to do what you want is to use an "external pointer". R
> assumes t
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
