[Rcpp-devel] [ANN] Rcpp 0.9.1

Douglas Bates bates at stat.wisc.edu
Mon Feb 14 21:10:35 CET 2011


On Mon, Feb 14, 2011 at 12:45 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> The new Rcpp 0.9.1 release is now on CRAN.  The NEWS entry is below; more
> details are in the ChangeLog.  But in short, this is a mostly 'internal
> fixes' release which addresses some issues in memory management which, while
> not tripping up our (short ?) unit tests or common usage, caused trouble for
> advanced Rcpp modules use and repeated memory allocation / deallocation.
> Rcpp should now be a tad more robust in general.
>
> The memory bug bit Doug Bates repeatedly, and he put his head down and
> debugged the issue. A number of changes in Rcpp (as well as in R-devel)
> later, this looks much better and we owe a hearfelt Thank You!
>
> A big Thanks! also goes to Luke Tierney who out some new memory debugging
> code into R-devel which the --enable-strict-barrier in R 2.13.0 (due in
> April) will enable.  I am a little unclear at this point which of these
> changes from R-devel will make it into R 2.12.2 due in eleven days (and I
> think the envir.c fix is in but the debugging code is not) but maybe Doug
> will clarify.

Yes, the envir.c fix is in.  As a bit of background, even folks in
R-core didn't all realize that the Rf_eval function doesn't PROTECT
its arguments (because it is called so frequently and often
recursively) so a construction like

Rf_eval(Rf_install("foo"), ...)

can, if it happens to be the first time that the symbol "foo" is
evaluated, cause a garbage collection to occur with unpleasant results
if things in ... are not protected.  Luke has added debugging code to
R-devel (to be R-2.13.0) that, when enabled, looks at every SEXP
before using it to determine if it is unprotected.  Using this he
discovered a couple of problems, one in envir.c, that were tripping us
up when gctorture(1) was active.  The unprotected object situation has
been fixed in R-2.12.2 but the code to detect unprotected objects will
be in R-2.13.0, not R-2.12.2.  It is assumed that anyone who knows
about that particular piece of debugging code is able to compile
R-devel for themselves.

> Cheers, Dirk
>
>
> 0.9.1   2011-02-14
>
>    o   A number of internal changes to the memory allocation / protection of
>        temporary objects were made---with a heartfelt "Thank You!" to both
>        Doug Bates for very persistent debugging of Rcpp modules code, and to
>        Luke Tierney who added additional memory allocation debugging tools
>        to R-devel (which will be in R 2.13.0 and may also be in R 2.12.2)
>
>    o   Removed another GNU Make-specific variable from src/Makevars in order
>        to make the build more portable; this was noticed on FreeBSD
>
>    o   On *BSD, do not try to compute a stack trace but provide file and
>        line number (which is the same behaviour as implemented in Windows)
>
>    o   Fixed an int conversion bug reported by Daniel Sabanes Bove on r-devel,
>        added unit test as well
>
>    o   Added unit tests for complex-typed vectors (thanks to Christian Gunning)
>
>    o   Expanded the Rcpp-quickref vignette (with thanks to Christian Gunning)
>
>    o   Additional examples were added to the Rcpp-FAQ vignette
>
>
>
> --
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>


More information about the Rcpp-devel mailing list