The fixes are committed as 53967.
luke
On Wed, 12 Jan 2011, luke-tier...@uiowa.edu wrote:
On Tue, 11 Jan 2011, Simon Urbanek wrote:
On Jan 11, 2011, at 6:55 PM,
wrote:
No. Lots of internal functions expect their callers to protect their
arguments, for efficiency reasons. eval is calle
On Wed, 12 Jan 2011, peter dalgaard wrote:
On Jan 12, 2011, at 14:18 ,
wrote:
I did do a quick scan of R-devel for this issue with eval and found these:
./unix/aqua.c:
eval(LCONS(install("library"),CONS(install("grDevices"),R_NilValue)),R_GlobalEnv);
./unix/sys-std.c:
On Jan 12, 2011, at 14:18 ,
wrote:
>
> I did do a quick scan of R-devel for this issue with eval and found these:
>
>./unix/aqua.c:
> eval(LCONS(install("library"),CONS(install("grDevices"),R_NilValue)),R_GlobalEnv);
>./unix/sys-std.c:infile = PROTECT(eval(lang1(RComp_ge
On Tue, 11 Jan 2011, Simon Urbanek wrote:
On Jan 11, 2011, at 6:55 PM,
wrote:
No. Lots of internal functions expect their callers to protect their arguments,
for efficiency reasons. eval is called very often and almost always with
argument that are protected because they are in the evalu
On 11-01-11 6:55 PM, luke-tier...@uiowa.edu wrote:
No. Lots of internal functions expect their callers to protect their
arguments, for efficiency reasons. eval is called very often and
almost always with argument that are protected because they are in the
evaluation engine, so it would be wastefu
On Jan 11, 2011, at 6:55 PM,
wrote:
> No. Lots of internal functions expect their callers to protect their
> arguments, for efficiency reasons. eval is called very often and almost
> always with argument that are protected because they are in the evaluation
> engine, so it would be wasteful
No. Lots of internal functions expect their callers to protect their
arguments, for efficiency reasons. eval is called very often and
almost always with argument that are protected because they are in the
evaluation engine, so it would be wasteful and potentially very costly
if eval protected its
Interesting, I'd argue that the bug is in eval() not protecting its arguments
since the usual convention is for functions to protect its arguments...
On Jan 11, 2011, at 2:33 PM, Romain Francois wrote:
> Hello,
>
> Using R-devel (rev 53950), I get inconsistent results with as.environment(
> VE
Hello,
Using R-devel (rev 53950), I get inconsistent results with
as.environment( VECSXP ) when gctorture is on.
Consider:
a <- list( aa = rnorm, bb = runif )
gctorture(TRUE)
as.environment( a )
The last line sometimes produces the correct environment, but sometimes
I get errors. Here are t
