> Matthew,
>
> I was hoping I misunderstood you first proposal, but I suspect I did not
> ;).
>
> Personally, I find DT[1,V1 <- 3] highly disturbing - I would expect it to
> evaluate to
> { V1 <- 3; DT[1, V1] }
> thus returning the first element of the third column.
Please see FAQ 1.1, since furt
According to the download.file manual the timeout of a connection can be set
using options(timeout=10). This seems to work as expected on windows, but on
linux the connection does not timeout. I reproduced the problem both 0on
R-2.13 on Ubuntu and on R-2.12.1 on CentOS, but not in Windows.
> optio
Thanks for the replies and info. An attempt at fast
assign is now committed to data.table v1.6.3 on
R-Forge. From NEWS :
o Fast update is now implemented, FR#200.
DT[i,j]<-value is now handled by data.table in C rather
than falling through to data.frame methods.
Thanks to Ivo We
Hi,
in "save.image", it would be nice if there was a "compression_level"
argument that is passed along to "save".
Or is there a reason for disabling the "compression_level" option for
saving workspaces, but enabling it for manually saving individual
objects?
Thanks,
Andreas
Simon,
If you didn't install.packages() with method="source" from R-Forge, that
would explain (some of) it. R-Forge builds binaries once each night. This
commit was long after the cutoff.
Matthew
>> Matthew,
>>
>> I was hoping I misunderstood you first proposal, but I suspect I did not
>> ;).
>>
On Jul 12, 2011, at 6:24 AM, Matthew Dowle wrote:
>> Matthew,
>>
>> I was hoping I misunderstood you first proposal, but I suspect I did not
>> ;).
>>
>> Personally, I find DT[1,V1 <- 3] highly disturbing - I would expect it to
>> evaluate to
>> { V1 <- 3; DT[1, V1] }
>> thus returning the firs
?connections tells us:
"Note that this is a timeout for no response, not for the whole operation."
And indeed, it will take roughly 20 seconds rather than 60 - at least on
the Linux machine I tried it on with R-2.13.1.
Best,
Uwe Ligges
On 12.07.2011 14:24, jeroen00ms wrote:
According to
> Can you please verify the behaviour is still the same in a recent R-devel or
> at least R-2.13.1? And that there was no other already answered request on
> R-help or R-devel re. timeouts?
The code below is R 2.13.1. It shows that the timeout time is more
than 3 minutes, although it was set to 5
On Jul 12, 2011, at 4:22 PM, Jeroen Ooms wrote:
>> Can you please verify the behaviour is still the same in a recent R-devel or
>> at least R-2.13.1? And that there was no other already answered request on
>> R-help or R-devel re. timeouts?
>
> The code below is R 2.13.1. It shows that the timeo
Never mind, I found the issue - contrary to the documentation Linux does modify
tv in the call to select() so our measure of elapsed time doesn't increase.
Work-around now present in R-devel.
Cheers,
Simon
On Jul 12, 2011, at 5:23 PM, Simon Urbanek wrote:
>
> On Jul 12, 2011, at 4:22 PM, Jer
10 matches
Mail list logo
