Dear Jean-Luc,
neither write.csv nor save nor save.image nor any other default write
functions in R check for enough space remaining. While this might be indeed
a problem that one should take care of -- sooner or later -- I would
strongly recommend using data.table::fwrite as the working horse for
I tried the newest patch, but it does not seem to work for me (on Linux).
Despite the check in Rconn_printf, the write.csv happily writes to
/dev/full and does not report an error. When I added a printf("%d\n", res);
to the Rconn_printf() definition, I see only positive values returned by
the vfpri
On 05/07/2017 5:26 AM, January W. wrote:
I tried the newest patch, but it does not seem to work for me (on
Linux). Despite the check in Rconn_printf, the write.csv happily writes
to /dev/full and does not report an error. When I added a printf("%d\n",
res); to the Rconn_printf() definition, I see
OK, this does indeed seem to be the case. It is interesting that it works
on MacOS, though. I think that given that errors on flushing the cache
cannot be caught, the behavior is inadvertently unpredictable.
best,
j.
On 5 July 2017 at 13:09, Duncan Murdoch wrote:
> On 05/07/2017 5:26 AM, Jan
Le 05/07/2017 à 13:09, Duncan Murdoch a écrit :
On 05/07/2017 5:26 AM, January W. wrote:
I tried the newest patch, but it does not seem to work for me (on
Linux). Despite the check in Rconn_printf, the write.csv happily writes
to /dev/full and does not report an error. When I added a printf("%d\
Le 05/07/2017 à 14:46, Serguei Sokol a écrit :
Le 05/07/2017 à 13:09, Duncan Murdoch a écrit :
On 05/07/2017 5:26 AM, January W. wrote:
I tried the newest patch, but it does not seem to work for me (on
Linux). Despite the check in Rconn_printf, the write.csv happily writes
to /dev/full and does
Here is what I've learned about OpenMPI and Rmpi during the past 2
weeks. Please tell me if you think I'm incorrect.
I don't understand computer science enough to understand fully the
dangers of forks and data corruption when OpenMPI uses infiniband.
However, perhaps one of you can tell me.
1. Rm
I've found some funny behavior in the dlnorm() function that I believe to be a
bug. For example, the following command:
> dlnorm( c(5e-323, 5e-324, 5e-325), 0, 0.3 )
Produces the output below, including the NaN value that should (ideally would
be) zero.
[1] 0 NaN 0
Warning message:
In dlno
