On Jul 5, 2009, at 10:54 AM, Yuri D'Elia wrote:
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, d
On 05/07/2009 6:05 PM, Yuri D'Elia wrote:
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 p
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
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/UNPROTECT calls
correctly, then GC will not be a problem.
The approach that I've taken with my time series lib
On 05/07/2009 10:54 AM, Yuri D'Elia wrote:
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
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
On Fri, Jul 03, 2009 at 07:57:49AM -0700, Martin Morgan wrote:
[...]
> sort.list is always called but used only to determine the order of
> levels, so unnecessary when levels are provided.
I think, this is correct. Replacing
ind <- sort.list(x)
by
if (missing(levels))
ind <- sort.list(x
