Re: [Rd] RInside & child threads
Hi, Thank you for your interest in RInside. We usually engage people to use the Rcpp-devel mailing list for questions about RInside. Could you prepare a small example of what you are trying to achieve and repost there. https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel Romain Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit : Hi Folks, I am creating a multi-threaded C++ application that initializes RInside in one of the child thread. I would also like to access support interfaces like Rcpp::Environment in the remaining child threads, so that I could access any "R" function associated with the environment initialized. When I run my program, I always get "C Stack limit too huge" errors. I looked at the "Writing R Extensions" manual, and it pointed to initializing the R_CStackLimit variable to "-1", and that this initialization need to be made after the RInside constructor is called. I did that, but it still does not work. Can you please let me know how do we accomplish this task? Thanks very much, Jai -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/9aKDM9 : embed images in Rd documents |- http://tr.im/OIXN : raster images and RImageJ |- http://tr.im/OcQe : Rcpp 0.7.7 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RInside & child threads
Hi, Thank you for your interest in RInside. We usually engage people to use the Rcpp-devel mailing list for questions about RInside. Could you prepare a small example of what you are trying to achieve and repost there. https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel Romain Le 30/04/10 19:32, Jaiganesh Balasubramanian a écrit : Hi Folks, I am creating a multi-threaded C++ application that initializes RInside in one of the child thread. I would also like to access support interfaces like Rcpp::Environment in the remaining child threads, so that I could access any "R" function associated with the environment initialized. When I run my program, I always get "C Stack limit too huge" errors. I looked at the "Writing R Extensions" manual, and it pointed to initializing the R_CStackLimit variable to "-1", and that this initialization need to be made after the RInside constructor is called. I did that, but it still does not work. Can you please let me know how do we accomplish this task? Thanks very much, Jai -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://bit.ly/9aKDM9 : embed images in Rd documents |- http://tr.im/OIXN : raster images and RImageJ |- http://tr.im/OcQe : Rcpp 0.7.7 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug in POSIX classes for R 2.11.0?
To the R development team;
I found an unusual behavior in zoo when I upgraded to R 2.11.0 - it abruptly
terminated when I performed certain operations on large zoo objects. I sent an
e-mail to Achim Zeileis and he said this was a potential bug that I should
report to the R development team. The details are given below in the thread
below. Basically, I can crash R with this code:
library(zoo)
x <- runif(14, 2009, 2010)
x <- as.yearmon(x)
table(x)
This will not crash with a vector of size 13.
Achim got it to crash with the following code that did not use zoo:
x <- rep(as.Date("1970-01-01"), 14)
y <- as.POSIXlt(x)
z <- format(y, "%d")
I did find a work around, so this is no longer an immediate problem for me, but
it would be better if the problem didn't exist in the first place. Thank you
for your help.
Lester Wollman
Corporate Statistician
Symmetricom, Inc.
lwoll...@symmetricom.com
-Original Message-
From: Achim Zeileis [mailto:achim.zeil...@uibk.ac.at]
Sent: Thursday, April 29, 2010 1:16 PM
To: Lester Wollman
Subject: Re: Unusual behavior of zoo and R2.11.0 - simple operation on large
zoo object crashes R
Lester,
thanks for the report. The problem does not seem to be in "zoo" but in the
new POSIX classes and/or their their coercion from "Date".
The following should reproduce your crash:
x <- rep(as.Date("1970-01-01"), 14)
y <- as.POSIXlt(x)
z <- format(y, "%d")
The reason is probably that R-core changed the internals of all the POSIX
stuff. Furthermore, this problem appears to be fixed in 2.12.0 (the
current devel version). Maybe you can ask on R-devel whether this is a
know issue (my guess is that it is).
Thanks for the report && best wishes,
Z
On Thu, 29 Apr 2010, Lester Wollman wrote:
>
> Achim,
>
>
>
> I found unusual behavior, or even possibly a bug, in zoo. When I run the
> code below, R crashes. There is no error message, R simply exits with no
> warning.
>
>
>
>
>
> library(zoo)
>
> x <- runif(14, 2009, 2010) # Random days in 2009
>
> x <- as.yearmon(x) # This works
>
> table(x) # This crashes. print(x) also crashes R.
> summary(x) does not
>
>
>
>
>
>
> However, if I change the number of random dates to 13, there is no
> problem.
>
>
>
> I have been using zoo for a few years with no problems, including using
> code similar to the one above. I did just upgrade to R 2.11.0 and this is
> my first use of zoo for a large vector since the upgrade.
>
>
>
> I cannot tell if the problem is with zoo or R or my machine. I tried
> installing zoo from CRAN instead of R-Forge, but that did not help.
> Increasing the memory limit to 3G did not help either.
>
>
>
> I attached relevant (and irrelevant) system information below. I am using R
> with Tinn-R and Tinn-R loads some packages (Hmisc, R2HTML, etc.)
>
>
>
> Thank you for your help.
>
>
>
>
>
> Lester Wollman
>
> Corporate Statistician
>
> Symmetricom, Inc.
>
> lwoll...@symmetricom.com
>
>
>
>
>
>
>
>
>
> > sessionInfo()
>
>
>
> R version 2.11.0 (2010-04-22)
>
> i386-pc-mingw32
>
>
>
> locale:
>
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
> States.1252 LC_MONETARY=English_United States.1252
>
> [4] LC_NUMERIC=C LC_TIME=English_United
> States.1252
>
>
>
> attached base packages:
>
> [1] grDevices datasets splines graphics stats tcltk utils
> methods base
>
>
>
> other attached packages:
>
> [1] svSocket_0.9-48 TinnR_1.0.3 R2HTML_2.0.0 Hmisc_3.7-0
> survival_2.35-8
>
>
>
> loaded via a namespace (and not attached):
>
> [1] cluster_1.12.3 grid_2.11.0 lattice_0.18-5 svMisc_0.9-57
>
>
>
>
>
> System Information:
>
> Windows XP Professional Version 2002 Service Pack 3
>
>
>
> Computer Information:
>
> Dell with Intel CPU
>
> T2600 @ 2.16 GHz, 1G of RAM
>
>
>
>
>
>
>
> zoo information
>
> > packageDescription("zoo")
>
> Package: zoo
>
> Version: 1.6-3
>
> Date: 2010-02-22
>
> Title: Z's ordered observations
>
> Author: Achim Zeileis, Gabor Grothendieck, Felix Andrews
>
> Maintainer: Achim Zeileis
>
> Description: An S3 class with methods for totally ordered indexed
> observations. It is particularly aimed at irregular time series of numeric
> vectors/matrices and factors. zoo's key design goals are independence of a
> particular index/date/time class and consistency with ts and base R by
> providing methods to extend standard generics.
>
> Depends: R (>= 2.10.0), stats
>
> Suggests: coda, chron, DAAG, fCalendar, fSeries, fts, its, lattice,
> strucchange, timeDate, timeSeries, tis, tseries, xts
>
> Imports: stats, utils, graphics, grDevices, lattice (>= 0.18-1)
>
> LazyLoad: yes
>
> License: GPL-2
>
> URL: http://R-Forge.R-project.org/projects/zoo/
>
> Repository: R-Forge
>
> Repository/R-Forge/Project: zoo
>
> Repository/R-Fo
Re: [Rd] Memory allocation in C/C++ vs R?
Simon,
Le 30/04/10 20:12, Simon Urbanek a écrit :
Dominick,
On Apr 30, 2010, at 1:40 PM, Dominick Samperi wrote:
Just to be sure that I understand, are you suggesting that the R-safe way to do
things is to not use STL, and to not use C++ memory management and exception
handling? How can you leave a function in an irregular way without triggering a
seg fault or something like that, in which case there is no chance for recovery
anyway?
In my experience the C++ exception stack seems to unwind properly before
returning to R when there is an exception, and memory that is allocated by C++
functions seems to maintain its integrity and does not interfere with R's
memory management.
It would be helpful if you could specify what kind of interference you are
referring to here between C++ exception handling and R's error handling, and
why STL is dangerous and best avoided in R. I have used STL with R for a long
time and have experienced no problems.
There are essentially two issues here that I had in mind.
1) C++ exception handling and R exceptions handling both use setjmp/longjmp
with the assumption that no one else does the same. That assumption is voided
when both are used so interleaving them will cause problems (you're fine if you
can guarantee that they always stack but that's not always easy to achieve yet
easy to miss).
2) C++ compilers assume that you cannot leave the context of a function in
unusual ways. But you can, namely if an R error is raised. This affects (among
others) locally allocated objects.
Thank you for these nuggets of information. It might be beneficial to
promote them to some notes in the "Interfacing C++ code" section of WRE.
As a side note for users of Rcpp. In recent versions of Rcpp, we take
precautions against the R error/c++ exception problem. We engage users
to always enclose each c++ function in explicit try/catch/forward to R,
and in Rcpp 0.8.0 (about to be released) we have macros BEGIN_RCPP /
END_RCPP.
So foo below would become :
extern "C" SEXP foo() {
BEGIN_RCPP
vector a;
a.resize(-1);
END_RCPP
return R_NilValue;
}
We also have less invasive macros RCPP_FUNCTION_0, ...,
RCPP_FUNCTION_65, and RCPP_FUNCTION_VOID_0, ..., so that one can write
foo as:
RCPP_FUNCTION_VOID_0(foo){
vector a;
a.resize(-1);
}
We also take care of the second problem, so that callbacks to R through
the Rcpp api are enclosed in R tryCatch blocks, through our
Evaluator::run :
SEXP Evaluator::run(SEXP expr, SEXP env) throw(eval_error) {
SEXP call = PROTECT( Rf_lang3( Rf_install("rcpp_tryCatch") , expr, env
) ) ;
Environment RCPP = Environment::Rcpp_namespace();
/* call the tryCatch call */
SEXP res = PROTECT( Rf_eval( call, RCPP ) );
/* was there an error ? */
int error = LOGICAL( Rf_eval( Rf_lang1( Rf_install("errorOccured") ),
RCPP ) )[0];
if( error ){
SEXP err_msg = PROTECT( Rf_eval(
Rf_lang1( Rf_install("getCurrentErrorMessage")),
RCPP ) );
std::string message = CHAR(STRING_ELT(err_msg,0)) ;
UNPROTECT( 3 ) ;
throw eval_error(message) ;
} else {
UNPROTECT(2) ;
return res ;
}
}
So when users of Rcpp do callbacs to R, like this:
Rcpp::Function rnorm( "rnorm" ) ;
rnorm( -10 ) ;
Rcpp catches the R error and c++ify it as a eval_error exception, so
that it can be handled in terms of c++ try/catch.
This is somewhat a hack due to the lack of explicit C level api for R
error handling.
http://www.mail-archive.com/r-devel@r-project.org/msg19300.html
Romain
On 1:
You cannot interleave R error handling and C++ exceptions. For example if there
is a chance of a C++ exception you must guarantee that the exception won't
leave the R context that you are in. This is easily demonstrated because R
check the consistency (see ex.1). Vice versa the consequences are not easily
visible, because C++ provides no tracking, but is equally fatal. If you raise R
exception from C++ it does not clean up whatever C++ exception context you were
it and bypasses it. But there are even more grave consequences:
On 2:
If you any R error from within C++ code you'll break the assumption of C++ that
it has control over the entry/exit point of a function. Take a really trivial
example:
void foo() {
Object o;
// some other code
error("blah")
normally, the life of o is controlled by C++ and it will correctly execute its
destructor when you leave the function. However, the error call in R will cause
it to bypass that, the object won't be destroyed even though it was allocated
on the stack. Although it's obvious in the example above, pretty much all R API
function can raise errors so the same applies to any R API call - direct or
indirect. As a consequence you pretty much cannot call R API func
Re: [Rd] Possible bug in POSIX classes for R 2.11.0?
On 30/04/2010 12:46 PM, Lester Wollman wrote:
To the R development team;
I found an unusual behavior in zoo when I upgraded to R 2.11.0 - it abruptly
terminated when I performed certain operations on large zoo objects. I sent an
e-mail to Achim Zeileis and he said this was a potential bug that I should
report to the R development team. The details are given below in the thread
below. Basically, I can crash R with this code:
library(zoo)
x <- runif(14, 2009, 2010)
x <- as.yearmon(x)
table(x)
This will not crash with a vector of size 13.
Achim got it to crash with the following code that did not use zoo:
x <- rep(as.Date("1970-01-01"), 14)
y <- as.POSIXlt(x)
z <- format(y, "%d")
I did find a work around, so this is no longer an immediate problem for me, but
it would be better if the problem didn't exist in the first place. Thank you
for your help.
Have you tried R-patched? This looks like a bug that was fixed there
recently. See
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14267
for details.
Duncan Murdoch
Lester Wollman
Corporate Statistician
Symmetricom, Inc.
lwoll...@symmetricom.com
-Original Message-
From: Achim Zeileis [mailto:achim.zeil...@uibk.ac.at]
Sent: Thursday, April 29, 2010 1:16 PM
To: Lester Wollman
Subject: Re: Unusual behavior of zoo and R2.11.0 - simple operation on large
zoo object crashes R
Lester,
thanks for the report. The problem does not seem to be in "zoo" but in the
new POSIX classes and/or their their coercion from "Date".
The following should reproduce your crash:
x <- rep(as.Date("1970-01-01"), 14)
y <- as.POSIXlt(x)
z <- format(y, "%d")
The reason is probably that R-core changed the internals of all the POSIX
stuff. Furthermore, this problem appears to be fixed in 2.12.0 (the
current devel version). Maybe you can ask on R-devel whether this is a
know issue (my guess is that it is).
Thanks for the report && best wishes,
Z
On Thu, 29 Apr 2010, Lester Wollman wrote:
Achim,
I found unusual behavior, or even possibly a bug, in zoo. When I run the
code below, R crashes. There is no error message, R simply exits with no
warning.
library(zoo)
x <- runif(14, 2009, 2010) # Random days in 2009
x <- as.yearmon(x) # This works
table(x) # This crashes. print(x) also crashes R.
summary(x) does not
However, if I change the number of random dates to 13, there is no
problem.
I have been using zoo for a few years with no problems, including using
code similar to the one above. I did just upgrade to R 2.11.0 and this is
my first use of zoo for a large vector since the upgrade.
I cannot tell if the problem is with zoo or R or my machine. I tried
installing zoo from CRAN instead of R-Forge, but that did not help.
Increasing the memory limit to 3G did not help either.
I attached relevant (and irrelevant) system information below. I am using R
with Tinn-R and Tinn-R loads some packages (Hmisc, R2HTML, etc.)
Thank you for your help.
Lester Wollman
Corporate Statistician
Symmetricom, Inc.
lwoll...@symmetricom.com
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United
States.1252LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United
States.1252
attached base packages:
[1] grDevices datasets splines graphics stats tcltk utils
methods base
other attached packages:
[1] svSocket_0.9-48 TinnR_1.0.3 R2HTML_2.0.0Hmisc_3.7-0
survival_2.35-8
loaded via a namespace (and not attached):
[1] cluster_1.12.3 grid_2.11.0lattice_0.18-5 svMisc_0.9-57
System Information:
Windows XP Professional Version 2002 Service Pack 3
Computer Information:
Dell with Intel CPU
T2600 @ 2.16 GHz, 1G of RAM
zoo information
packageDescription("zoo")
Package: zoo
Version: 1.6-3
Date: 2010-02-22
Title: Z's ordered observations
Author: Achim Zeileis, Gabor Grothendieck, Felix Andrews
Maintainer: Achim Zeileis
Description: An S3 class with methods for totally ordered indexed
observations. It is particularly aimed at irregular time series of numeric
vectors/matrices and factors. zoo's key design goals are independence of a
particular index/date/time class and consistency with ts and base R by
providing methods to extend standard generics.
Depends: R (>= 2.10.0), stats
Suggests: coda, chron, DAAG, fCalendar, fSeries, fts, its, lattice,
strucchange, timeDate, timeSeries, tis, tseries, xts
Imports: stats, utils, graphics, grDevices, lattice (>= 0.18-1)
LazyLoad: yes
License: GPL-2
URL: http://R-Forge.R-project.org/projects/zoo/
Repository: R-Forge
Repository/R-Forge/Project: zoo
Repository/R-Forge/Revision: 688
Date/Publication: 2010-03-20 02:29:04
Packaged
Re: [Rd] Memory allocation in C/C++ vs R?
On Sat, May 1, 2010 at 5:02 AM, Romain Francois wrote: > > Simon, > > Le 30/04/10 20:12, Simon Urbanek a écrit : > Thank you for these nuggets of information. It might be beneficial to > promote them to some notes in the "Interfacing C++ code" section of WRE. The manual is also missing information on R_PreserveObject() and R_ReleaseObject(), useful but undocumented features that are exploited in Rcpp to elininate the need for the ubiquitous PROTECT/UNPROTECT macros. > As a side note for users of Rcpp. In recent versions of Rcpp, we take > precautions against the R error/c++ exception problem. We engage users to > always enclose each c++ function in explicit try/catch/forward to R, and in > Rcpp 0.8.0 (about to be released) we have macros BEGIN_RCPP / END_RCPP. Good idea. > So when users of Rcpp do callbacs to R, like this: > > Rcpp::Function rnorm( "rnorm" ) ; > rnorm( -10 ) ; > > Rcpp catches the R error and c++ify it as a eval_error exception, so that it > can be handled in terms of c++ try/catch. > > This is somewhat a hack due to the lack of explicit C level api for R error > handling. http://www.mail-archive.com/r-devel@r-project.org/msg19300.html Nice trick. Given the use of undocumented features and the hacks, wouldn't it make more sense to make Rcpp part of the R core, a kind of limited implementation of CXXR? With these hacks, along with a small change in the way R is built, it seems like most of the C++ issues disappear. The change I am referring to is to compile main.c (or a stub part of it) using C++ instead of C. This would take care of the one remaining C++ issue: static initializers not being called. Apparently this issue does not come up in most situations because R links to packages that use C++ via the runtime system / shared library mechanism, and this mechanism takes care of the necessary static initialization. This may not work under all OS's though, and building main.c using C++ would solve this problem. Another advatage of building main.c using C++ is that R becomes a C++ application (that just happens to be largely composed of C modules). This would open more possibilities for R development without requiring a complete refactoring as in the case of CXXR. Dominick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
