[Rd] typo in R-lang.texi
Hi, R-lang.texi line 2020/1 currently says: This allows, e.g., a local variable in a function to have the same name AS a global object. The word "AS" is missing in that sentence. (Line number according to https://svn.r-project.org/R/trunk/doc/manual/R-lang.texi) Stephen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] slow graphics on MAC OS X R-2.4.1 (PR#9530)
We use R a lot for graphics and noticed very slow graphics in Quartz mode where X11 is much faster. Our hardware: intel mac pro and intel macbook pro, both are affected. os versions: OS X Tiger 10.4.8 R version: R version 2.4.1 (2006-12-18) We tried the following simple thing. - Open the R program from the dock (not from the command line) - run the following two lines: d = matrix(runif(300*2000),300,2000) image(d) image(d) #again a second time and see how long it takes to appear on screen the first time, and again the second time. Then close R and open an X11 terminal and start R from the command line. try the same commands d = matrix(runif(300*2000),300,2000) image(d) image(d) #again a second time We found huge differences in speed, perhaps we are doing something wrong? As a result we exclusively use R in X11 mode which works fine for us. Felix Naef [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depending on many packages: another best practice question
On 2/24/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Sat, 24 Feb 2007, hadley wickham wrote: > > >> > ggplot currently requires 13 packages (grid, reshape, RColorBrewer, > >> > proto, splines, MASS, Hmisc, boot, butler, hexbin, mapproj, quantreg, > >> > sm). Some of these are absolutely necessary (eg. proto), but most are > >> > used for one or two specific tasks (eg. boot is only used to get > >> > plogis, used for logit scales). > >> > >> Hmm, there is no plogis in boot, but there is in stats. > > > > Oops, I had originally included it to use logit and inv.logit, but > > then realised I could use plogis etc instead. That's one dependency > > down. > > > >> > >> > Do you think I should make them all "depends" packages, or "suggests" > >> > packages, and then manually test for package presence before using a > >> > certain function? What is easier for users? > >> > >> The second, especially as from 2.5.0 the 'Depends' and 'Imports' are > >> installed by default. > > > > Ok, that makes sense then. > > > >> What you have not mentioned is that those packages also have dependencies. > >> > >> Using 'Depends' on a non-CRAN package (e.g. hexbin) is definitely awkward > >> for the user/sysadmin and I would try to avoid it. > > > > It's frustrating enough for the windows user, as suggests packages > > seem to get installed by default as well. > > Prior to 2.5.0, yes, but not in future. Great. One more question: do you have any suggstion for you I should deal with examples? Do I have to wrap those in conditional require statements as well? That seems to be the way to get R CMD check to pass, but adds (unnecessary?) repitition. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depending on many packages: another best practice question
You can use
if(require(myPackage)) { ... }
or
\dontrun{ ... }
or
make them demos in the myPackage/demo directory since demos
are not checked.
On 2/25/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 2/24/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> > On Sat, 24 Feb 2007, hadley wickham wrote:
> >
> > >> > ggplot currently requires 13 packages (grid, reshape, RColorBrewer,
> > >> > proto, splines, MASS, Hmisc, boot, butler, hexbin, mapproj, quantreg,
> > >> > sm). Some of these are absolutely necessary (eg. proto), but most are
> > >> > used for one or two specific tasks (eg. boot is only used to get
> > >> > plogis, used for logit scales).
> > >>
> > >> Hmm, there is no plogis in boot, but there is in stats.
> > >
> > > Oops, I had originally included it to use logit and inv.logit, but
> > > then realised I could use plogis etc instead. That's one dependency
> > > down.
> > >
> > >>
> > >> > Do you think I should make them all "depends" packages, or "suggests"
> > >> > packages, and then manually test for package presence before using a
> > >> > certain function? What is easier for users?
> > >>
> > >> The second, especially as from 2.5.0 the 'Depends' and 'Imports' are
> > >> installed by default.
> > >
> > > Ok, that makes sense then.
> > >
> > >> What you have not mentioned is that those packages also have
> > >> dependencies.
> > >>
> > >> Using 'Depends' on a non-CRAN package (e.g. hexbin) is definitely awkward
> > >> for the user/sysadmin and I would try to avoid it.
> > >
> > > It's frustrating enough for the windows user, as suggests packages
> > > seem to get installed by default as well.
> >
> > Prior to 2.5.0, yes, but not in future.
>
> Great. One more question: do you have any suggstion for you I should
> deal with examples? Do I have to wrap those in conditional require
> statements as well? That seems to be the way to get R CMD check to
> pass, but adds (unnecessary?) repitition.
>
> Hadley
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R/C++/memory leaks
Dear all, I have wrapped a C++ function in an R package. I allocate/deallocate memory using C++ 'new' and 'delete'. In order to allow user interrupts without memory leaks I've moved all the delete statements required after an interrupt to a separate C++ function freeMemory(), which is called using on.exit() just before the .C() call. I am concerned about the following. In square brackets you see R's total virtual memory use (VIRT in `top`): 1) Load library and data [178MB] (if I run gc(), then [122MB]) 2) Just before .C [223MB] 3) Just before freeing memory [325MB] 4) Just after freeing memory [288MB] 5) After running gc() [230MB] So although the freeMemory function works (frees 37MB), R ends up using 100MB more after the function call than before it. ls() only returns the data object so no new objects have been added to the workspace. Do any of you have any idea what could be eating this memory? Many thanks, Ernest PS: it is not practical to use R_alloc et al because C++ allocation/ deallocation involves constructors/destructors and because the C++ code is also compiled into a standalone binary (I would rather avoid maintaining two separate versions). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depending on many packages: another best practice question
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> You can use
>
> if(require(myPackage)) { ... }
Probably you will want:
if (suppressWarnings(require("somePkg"))) { ... }
This way, you won't get a lot of noise when somePkg isn't installed.
Running the examples at least some of the time seems like a nice idea
to assure basic functionality...
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
On Sun, Feb 25, 2007 at 05:37:24PM +, Ernest Turro wrote:
> Dear all,
>
> I have wrapped a C++ function in an R package. I allocate/deallocate
> memory using C++ 'new' and 'delete'. In order to allow user
> interrupts without memory leaks I've moved all the delete statements
> required after an interrupt to a separate C++ function freeMemory(),
> which is called using on.exit() just before the .C() call.
Do you mean that you call on.exit() before the .C, and the call to
on.exit() sets up the handler? Your last sentence sounds as if you
invoke freeMemory() before the .C call.
Another approach is to associate your C objects with an R object, and
have them cleaned up when the R object gets garbage collected.
However, this requires switching to a .Call interface from the more
straightforward .C interface.
The finalizer call I used doesn't assure cleanup on exit. The optional
argument to R_RegisterCFinalizerEx might provide such assurance, but I
couldn't tell what it really does. Since all memory should
be released by the OS, when the process ends, I wasn't so worried
about that.
Here's the pattern:
// I needed R_NO_REMAP to avoid name collisions. You may not.
#define R_NO_REMAP 1
#include
#include
extern "C" {
// returns an |ExternalPtr|
SEXP makeManager(
@);
// user should not need to call
// cleanup
void finalizeManager(SEXP ptr);
}
SEXP makeManager(
@){
// stuff
Manager* pmanager = new Manager(pd, pm.release(),
*INTEGER(stepNumerator), *INTEGER(stepDenominator),
(*INTEGER(isexact)) != 0);
// one example didn't use |PROTECT()|
SEXP ptr;
Rf_protect(ptr = R_MakeExternalPtr(pmanager, R_NilValue, R_NilValue));
R_RegisterCFinalizer(ptr, (R_CFinalizer_t) finalizeManager);
Rf_unprotect(1);
return ptr;
}
void finalizeManager(SEXP ptr){
Manager *pmanager = static_cast(R_ExternalPtrAddr(ptr));
delete pmanager;
R_ClearExternalPtr(ptr);
}
I'd love to hear from those more knowledgeable about whether I did
that right, and whether the FinalizerEx call can assure cleanup on
exit.
Make manager needes to be called from R like this
mgr <- .Call("makeManager", args)
>
> I am concerned about the following. In square brackets you see R's
> total virtual memory use (VIRT in `top`):
>
> 1) Load library and data [178MB] (if I run gc(), then [122MB])
> 2) Just before .C [223MB]
> 3) Just before freeing memory [325MB]
So you explicitly call your freeMemory() function?
> 4) Just after freeing memory [288MB]
There are at least 3 possibilities:
* your C++ code is leaking
* C++ memory is never really returned (Commonly, at least in C, the
amount of memory allocated to the process never goes down, even if
you do a free. This may depend on the OS and the specific calls the
program makes.
* You did other stuff in R that's still around. After all you went
up +45MB between 1 and 2; maybe it's not so odd you went up +65MB
between 2 and 4.
> 5) After running gc() [230MB]
>
> So although the freeMemory function works (frees 37MB), R ends up
> using 100MB more after the function call than before it. ls() only
> returns the data object so no new objects have been added to the
> workspace.
>
> Do any of you have any idea what could be eating this memory?
>
> Many thanks,
>
> Ernest
>
> PS: it is not practical to use R_alloc et al because C++ allocation/
> deallocation involves constructors/destructors and because the C++
> code is also compiled into a standalone binary (I would rather avoid
> maintaining two separate versions).
I use regular C++ new's too (except for the external pointer that's
returned). However, you can override the operator new in C++ so that
it uses your own allocator, e.g., R_alloc. I'm not sure about all the
implications that might make that dangerous (e.g., can the memory be
garbage collected? can it be moved?). Overriding new is a bit tricky
since there are several variants. In particular, there is one with
and one without an exception. Also, invdividual classes can define
their own new operators; if you have any, you'd need to change those
too.
Ross Boylan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R/C++/memory leaks
On 25 Feb 2007, at 22:21, Ross Boylan wrote:
> On Sun, Feb 25, 2007 at 05:37:24PM +, Ernest Turro wrote:
>> Dear all,
>>
>> I have wrapped a C++ function in an R package. I allocate/deallocate
>> memory using C++ 'new' and 'delete'. In order to allow user
>> interrupts without memory leaks I've moved all the delete statements
>> required after an interrupt to a separate C++ function freeMemory(),
>> which is called using on.exit() just before the .C() call.
>
> Do you mean that you call on.exit() before the .C, and the call to
> on.exit() sets up the handler? Your last sentence sounds as if you
> invoke freeMemory() before the .C call.
>
" 'on.exit' records the expression given as its argument as needing
to be executed when the current function exits (either naturally
or as the result of an error)."
This means you call on.exit() somewhere at the top of the function.
You are guaranteed the expression you pass to on.exit() will be
executed before the function returns. So, even though you call on.exit
() before .C(), the expression you pass it will actually be called
after .C().
This means you can be sure that freeMemory() is called even if an
interrupt or other error occurs.
> Another approach is to associate your C objects with an R object, and
> have them cleaned up when the R object gets garbage collected.
> However, this requires switching to a .Call interface from the more
> straightforward .C interface.
>
> The finalizer call I used doesn't assure cleanup on exit. The optional
> argument to R_RegisterCFinalizerEx might provide such assurance, but I
> couldn't tell what it really does. Since all memory should
> be released by the OS, when the process ends, I wasn't so worried
> about that.
>
>
> Here's the pattern:
> // I needed R_NO_REMAP to avoid name collisions. You may not.
> #define R_NO_REMAP 1
> #include
> #include
>
> extern "C" {
> // returns an |ExternalPtr|
> SEXP makeManager(
> @);
>
>
> // user should not need to call
> // cleanup
> void finalizeManager(SEXP ptr);
>
> }
>
> SEXP makeManager(
> @){
> // stuff
>
> Manager* pmanager = new Manager(pd, pm.release(),
> *INTEGER(stepNumerator), *INTEGER(stepDenominator),
> (*INTEGER(isexact)) != 0);
>
> // one example didn't use |PROTECT()|
> SEXP ptr;
> Rf_protect(ptr = R_MakeExternalPtr(pmanager, R_NilValue,
> R_NilValue));
> R_RegisterCFinalizer(ptr, (R_CFinalizer_t) finalizeManager);
> Rf_unprotect(1);
> return ptr;
>
> }
>
> void finalizeManager(SEXP ptr){
> Manager *pmanager = static_cast(R_ExternalPtrAddr(ptr));
> delete pmanager;
> R_ClearExternalPtr(ptr);
> }
>
> I'd love to hear from those more knowledgeable about whether I did
> that right, and whether the FinalizerEx call can assure cleanup on
> exit.
>
> Make manager needes to be called from R like this
> mgr <- .Call("makeManager", args)
>
Since this is a standalone C++ program too, I'd rather use the R API
as little as possible... But I will look at your solution if I find
it is really necessary.. Thanks
>>
>> I am concerned about the following. In square brackets you see R's
>> total virtual memory use (VIRT in `top`):
>>
>> 1) Load library and data [178MB] (if I run gc(), then [122MB])
>> 2) Just before .C [223MB]
>> 3) Just before freeing memory [325MB]
> So you explicitly call your freeMemory() function?
This is called thanks to on.exit()
>> 4) Just after freeing memory [288MB]
> There are at least 3 possibilities:
> * your C++ code is leaking
The number of news and deletes are the same, and so is their
branching... I don't think it is this.
> * C++ memory is never really returned (Commonly, at least in C, the
> amount of memory allocated to the process never goes down, even if
> you do a free. This may depend on the OS and the specific calls the
> program makes.
OK, but the memory should be freed after the process completes, surely?
> * You did other stuff in R that's still around. After all you went
> up +45MB between 1 and 2; maybe it's not so odd you went up +65MB
> between 2 and 4.
Yep, I do stuff before .C and that accounts for the increase
before .C. But all the objects created before .C go out of scope by
4) and so, after gc(), we should be back to 122MB. As I mentioned, ls
() after 5) returns only the data loaded in 1).
>> 5) After running gc() [230MB]
>>
>> So although the freeMemory function works (frees 37MB), R ends up
>> using 100MB more after the function call than before it. ls() only
>> returns the data object so no new objects have been added to the
>> workspace.
>>
>> Do any of you have any idea what could be eating this memory?
>>
>> Many thanks,
>>
>> Ernest
>>
>> PS: it is not practical to use R_alloc et al because C++ allocation/
>> deallocation involves constructors/destructors and because the C++
>> code is also compiled into a standalone binary (I would rather avoid
>> maintaining two separate versions)
[Rd] Edits of R-exts.texi
I have attached a patch (svn diff) containing some edits of
R-exts.texi to fix minor grammatical errors (I changed a lot of
"which"s to "that"s) and to improve readability (I hope). When
unsure, I have tried to avoid making changes that might affect
meaning, so I hope that this patch will not be controversial.
I have a few other comments, concerning points where I did not make
any changes, but where I think some further (minor) editing is needed.
These are listed below, with approximated line numbers from
R-exts.texi in the current development trunk (revision 40804). I
could come up with my own edits for at least the first and third of
these comments/questions, but I was less sure that such edits would be
welcome.
Line 453:
The statement
Non-ASCII characters in object names will normally fail when the
package is installed.
needs to be more precise. Does the installation fail, or is the
object left undefined, or what? "Non-ASCII characters" will "fail"
doesn't make much sense to me.
Line 793:
What does this comment mean?
(and hence e.g.@: removed from @code{ACX_BLAS})
Lines 1182, 1787, and elsewhere:
This is picky, but shouldn't "DLL" be "shared library/DLL" or "shared
object/DLL" (as at line 811), or even ".so/DLL". Alternatively, maybe
it should be stated somewhere early in the document that DLL may be
used to refer to both Windows DLLs and Unix shared object libraries.
Of course, some of us might prefer to have things the other way
around: isn't "shared library" more generic than "DLL"?
---
Brett Presnell
Department of Statistics
University of Florida
http://www.stat.ufl.edu/~presnell/
"We don't think that the popularity of an error makes it the truth."
-- Richard Stallman
() ascii ribbon campaign - against html mail
/\- against microsoft attachments
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 40804)
+++ doc/manual/R-exts.texi (working copy)
@@ -158,7 +158,7 @@
@cindex cleanup file
The optional files @file{configure} and @file{cleanup} are (Bourne
-shell) script files which are executed before and (provided that option
+shell) script files that are executed before and (provided that option
@option{--clean} was given) after installation on Unix-alikes, see
@ref{Configure and cleanup}.
@@ -276,17 +276,17 @@
etc.). It should not end in a period or comma.
The optional @samp{Date} field gives the release date of the current
-version of the package. It is strongly recommended to use the -mm-dd
-format conforming to the ISO standard.
+version of the package. Use of the -mm-dd format, conforming to the
+ISO standard, is strongly recommended.
The optional @samp{Depends} field gives a comma-separated list of
-package names which this package depends on. The package name may be
+packages that this package depends on. The package name may be
optionally followed by a comparison operator (currently only @samp{>=}
and @samp{<=} are supported), whitespace and a valid version number in
parentheses. (List package names even if they are part of a bundle.)
You can also use the special package name @samp{R} if your package
-depends on a certain version of @R{}. E.g., if the package works only with
[EMAIL PROTECTED] version 2.4.0 or newer, include @samp{R (>= 2.4.0)} in the
+depends on a certain version of @R{}. E.g., if the package works only
+with @R{} version 2.4.0 or newer, include @samp{R (>= 2.4.0)} in the
@samp{Depends} field. Both @code{library} and the @R{} package checking
facilities use this field, hence it is an error to use improper syntax
or misuse the @samp{Depends} field for comments on other software that
@@ -294,8 +294,8 @@
should be listed in the @samp{SystemRequirements} field or a separate
@file{README} file. The @R{} @command{INSTALL} facilities check if the
version of @R{} used is recent enough for the package being installed,
-and the list of packages which is specified will be attached (after
-checking version dependencies) before the current package, both when
+and the list of packages specified will be attached (after checking
+version dependencies) before the current package, both when
@code{library} is called and when saving an image of the package's code
or preparing for lazy-loading.
@@ -329,13 +329,13 @@
@code{library(@var{pkgname})} must be listed in the @samp{Imports}
field.
@item
-Packages that need to be attached to successfully load the package using
+Packages that need to be attached to load the package using
@code{library(@var{pkgname})} must be listed in the @samp{Depends}
field.
@item
-All packages that are needed to successfully run @code{R CMD check} on
-the package must be listed in one of @samp{Depends} or @samp{Suggests}
-or @samp{Imports}.
+All packages that are needed to run @code{R CMD check} on the package
+must be listed in one of @samp{Depends} or @samp{Sugges
Re: [Rd] Edits of R-exts.texi
Somehow I managed to copy an older version of my edits before running "svn diff", so please ignore my last message. I will fix this and resubmit. Sorry for the bother. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Edits of R-exts.texi (2nd try)
I believe that I have this straight now.
I have attached a patch (svn diff) containing some edits of
R-exts.texi to fix minor grammatical errors (I changed a lot of
"which"s to "that"s) and to improve readability (I hope). There's
nothing technical in these changes, and when unsure, I have tried to
avoid making changes that might affect meaning, so I don't think that
there's anything controversial here.
I have three more comments, concerning points where I did not make any
changes, but where I think some further (minor) editing is needed.
These are listed below, with approximate line numbers from R-exts.texi
in the current development trunk (revision 40804). I could come up
with my own edits for at least the first and third of these
comments/questions, but here I was less confident that such edits
would be welcomed.
Line 453:
The statement
Non-ASCII characters in object names will normally fail when the
package is installed.
needs to be more precise. Does the installation fail, or is the
object left undefined, or what? "Non-ASCII characters" will "fail"
doesn't make much sense to me.
Line 793:
What does this comment mean?
(and hence e.g.@: removed from @code{ACX_BLAS})
Lines 1182, 1787, and elsewhere:
This is picky, but shouldn't "DLL" be "shared library/DLL" or "shared
object/DLL" (as at line 811), or even ".so/DLL". Alternatively, maybe
it should be stated somewhere early in the document that DLL may be
used to refer to both Windows DLLs and Unix shared object libraries.
Of course, some might prefer to have things the other way around:
isn't "shared library" more generic than "DLL"?
--
Brett Presnell
Department of Statistics
University of Florida
http://www.stat.ufl.edu/~presnell/
"We don't think that the popularity of an error makes it the truth."
-- Richard Stallman
() ascii ribbon campaign - against html mail
/\- against microsoft attachments
Index: doc/manual/R-exts.texi
===
--- doc/manual/R-exts.texi (revision 40804)
+++ doc/manual/R-exts.texi (working copy)
@@ -158,7 +158,7 @@
@cindex cleanup file
The optional files @file{configure} and @file{cleanup} are (Bourne
-shell) script files which are executed before and (provided that option
+shell) script files that are executed before and (provided that option
@option{--clean} was given) after installation on Unix-alikes, see
@ref{Configure and cleanup}.
@@ -276,12 +276,12 @@
etc.). It should not end in a period or comma.
The optional @samp{Date} field gives the release date of the current
-version of the package. It is strongly recommended to use the -mm-dd
-format conforming to the ISO standard.
+version of the package. Use of the -mm-dd format, conforming to the
+ISO standard, is strongly recommended.
The optional @samp{Depends} field gives a comma-separated list of
-package names which this package depends on. The package name may be
-optionally followed by a comparison operator (currently only @samp{>=}
+package names that this package depends on. Each package name in the list may
+optionally be followed by a comparison operator (currently only @samp{>=}
and @samp{<=} are supported), whitespace and a valid version number in
parentheses. (List package names even if they are part of a bundle.)
You can also use the special package name @samp{R} if your package
@@ -294,7 +294,7 @@
should be listed in the @samp{SystemRequirements} field or a separate
@file{README} file. The @R{} @command{INSTALL} facilities check if the
version of @R{} used is recent enough for the package being installed,
-and the list of packages which is specified will be attached (after
+and the packages listed will be attached (after
checking version dependencies) before the current package, both when
@code{library} is called and when saving an image of the package's code
or preparing for lazy-loading.
@@ -329,11 +329,11 @@
@code{library(@var{pkgname})} must be listed in the @samp{Imports}
field.
@item
-Packages that need to be attached to successfully load the package using
+Packages that must be attached in order to load the package using
@code{library(@var{pkgname})} must be listed in the @samp{Depends}
field.
@item
-All packages that are needed to successfully run @code{R CMD check} on
+All packages that are needed to run @code{R CMD check} successfully on
the package must be listed in one of @samp{Depends} or @samp{Suggests}
or @samp{Imports}.
@end itemize
@@ -350,8 +350,8 @@
@acronym{CRAN}.
Base and recommended packages (i.e., packages contained in the @R{}
-source distribution or available from @acronym{CRAN} and recommended to
-be included in every binary distribution of @R{}) have a @samp{Priority}
+source distribution or available from @acronym{CRAN} and recommended for
+inclusion in every binary distribution of @R{}) have a @samp{Priority}
field with value @samp{base} or @samp{reco
Re: [Rd] R/C++/memory leaks
Here are a few small follow-up comments: On Sun, Feb 25, 2007 at 11:18:56PM +, Ernest Turro wrote: > > On 25 Feb 2007, at 22:21, Ross Boylan wrote: > > >On Sun, Feb 25, 2007 at 05:37:24PM +, Ernest Turro wrote: > >>Dear all, > >> > >>I have wrapped a C++ function in an R package. I allocate/deallocate > >>memory using C++ 'new' and 'delete'. In order to allow user > >>interrupts without memory leaks I've moved all the delete statements > >>required after an interrupt to a separate C++ function freeMemory(), > >>which is called using on.exit() just before the .C() call. > > > >Do you mean that you call on.exit() before the .C, and the call to > >on.exit() sets up the handler? Your last sentence sounds as if you > >invoke freeMemory() before the .C call. > > > > " 'on.exit' records the expression given as its argument as needing > to be executed when the current function exits (either naturally > or as the result of an error)." > > > This means you call on.exit() somewhere at the top of the function. > You are guaranteed the expression you pass to on.exit() will be > executed before the function returns. So, even though you call on.exit > () before .C(), the expression you pass it will actually be called > after .C(). > > This means you can be sure that freeMemory() is called even if an > interrupt or other error occurs. > > > >Another approach is to associate your C objects with an R object, and > >have them cleaned up when the R object gets garbage collected. > >However, this requires switching to a .Call interface from the more > >straightforward .C interface. [details snipped] > > Since this is a standalone C++ program too, I'd rather use the R API > as little as possible... But I will look at your solution if I find > it is really necessary.. Thanks The use of the R api can be confined to a wrapper function. But I can think of no reason that a change to the alternate approach I outlined would solve the apparent leaking you describe. > > >> > >>I am concerned about the following. In square brackets you see R's > >>total virtual memory use (VIRT in `top`): > >> > >>1) Load library and data [178MB] (if I run gc(), then [122MB]) > >>2) Just before .C [223MB] > >>3) Just before freeing memory [325MB] > >So you explicitly call your freeMemory() function? > > This is called thanks to on.exit() > > >>4) Just after freeing memory [288MB] > >There are at least 3 possibilities: > > * your C++ code is leaking > > The number of news and deletes are the same, and so is their > branching... I don't think it is this. > > > * C++ memory is never really returned (Commonly, at least in C, the > > amount of memory allocated to the process never goes down, even if > > you do a free. This may depend on the OS and the specific calls the > > program makes. > > OK, but the memory should be freed after the process completes, > surely? Most OS's I know will free memory when a process finishes, except for shared memory. But is that relevant? I assume the process doesn't complete until you exit R. Your puzzle seems to involve different stages within the life of a single process. > > > * You did other stuff in R that's still around. After all you went > > up +45MB between 1 and 2; maybe it's not so odd you went up +65MB > > between 2 and 4. > > Yep, I do stuff before .C and that accounts for the increase > before .C. But all the objects created before .C go out of scope by > 4) and so, after gc(), we should be back to 122MB. As I mentioned, ls > () after 5) returns only the data loaded in 1). In principle (and according to ?on.exit) the expression registered by on.exit is evaluated when the relevant function is exited. In principle garbage collection reclaims all unused space (though with no guarantee of when). It may be that the practice is looser than the principle. For example, Python always nominally managed memory for you, but I think for quite awhile it didn't really reclaim the memory (because garbage collection didn't exist or had been turned off). > > >>5) After running gc() [230MB] > >> > >>So although the freeMemory function works (frees 37MB), R ends up > >>using 100MB more after the function call than before it. ls() only > >>returns the data object so no new objects have been added to the > >>workspace. > >> > >>Do any of you have any idea what could be eating this memory? > >> > >>Many thanks, > >> > >>Ernest > >> > >>PS: it is not practical to use R_alloc et al because C++ allocation/ > >>deallocation involves constructors/destructors and because the C++ > >>code is also compiled into a standalone binary (I would rather avoid > >>maintaining two separate versions). > > > >I use regular C++ new's too (except for the external pointer that's > >returned). However, you can override the operator new in C++ so that > >it uses your own allocator, e.g., R_alloc. I'm not sure about all the > >implications that might make that dangerous (e.g.,
