Hello,
This is explained in Writing R Extensions, Section 6.1 file R-exts.pdf
in your distribution of R, folder doc.
There are two types of functions to allocate memory in C functions
called from R code.
1. R_alloc() - the memory is automatically reclaimed at the end of the
function call.
2.
Hi ,
I am a newbie to R and i am trying to create a R package which is pretty
main memory intensive.
I would like to know what happens to the variables allocated in the C code
while writing R extensions based on C.
Are they preserved until someone de-allocate them or are they taken out by
R's garb
Without the file, we can do nothing with this, so please put it
somewhere accessible. Also, we need exact reproduction instructions:
how did you tell R this was a UTF-8 file? If you copy-pasted it, what
did you copy it from?
The posting guide and FAQ did ask you not to report on obsolete
ve
--=_mixed 00289247C1257634_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear R-Bugs,
thank you for your wonderful software, which we use a lot. We are having a =
bit of difficulty right now because it crashes sometimes with Unicode=20
characters.
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
Yuri,
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 the SEXP is from a different R instance then you
ca
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
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
14 matches
Mail list logo
