search for: rconn_printf

...=============================================================== --- src/library/utils/src/io.c (r?vision 72357) +++ src/library/utils/src/io.c (copie de travail) @@ -1120,12 +1120,23 @@ for(int i = 0; i < nr; i++) { if(i % 1000 == 999) R_CheckUserInterrupt(); if(!isNull(rnames)) - Rconn_printf(con, "%s%s", - EncodeElement2(rnames, i, quote_rn, qmethod, - &strBuf, sdec), csep); + + if(Rconn_printf(con, "%s%s", EncodeElement2(rnames, i, quote_rn, qmethod, &strBuf, sdec), csep) < 0) { + error(_("IO error, cannot write table.&quo...

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 vfprintf call. Cheers, j. On 4 July 2017 at 21:37, Duncan Murdoch <murdoch.duncan at gmail.com&g...

...?crit : > 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 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 vfprintf call. >>>> >>> >&gt...

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\n", >> res); to the Rconn_printf() definition, I see only positive values >> returned by the vfprintf call. >> > > That's likely because you aren't w...

...se = sep), file, sep = eol) : >> system call failure on writing >> > close(fc) >> >> Serguei. > > I suspect that flushing on every write will slow things down too much. That's quite plausible. > > I think a better approach is to catch the error in the Rconn_printf > calls (as R-devel currently does), and also catch errors on > con->close(con). This one requires more changes to the source, so it > may be a day or two before I commit. I have testes it on file_close() and it works (cf. attached patch): > fc=file("/dev/full", "...

Hello, You can find here a patch to fix disk corruption. When your disk is full, the write function exit without error but the file is truncated. https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17243 Sincerely, Jean-S?bastien Bevilacqua [[alternative HTML version deleted]]

...uot;, file=fc) > Error in writeLines(paste(col.names, collapse = sep), file, sep = eol) : > system call failure on writing > > close(fc) > > Serguei. I suspect that flushing on every write will slow things down too much. I think a better approach is to catch the error in the Rconn_printf calls (as R-devel currently does), and also catch errors on con->close(con). This one requires more changes to the source, so it may be a day or two before I commit. One thing I have to look into: is anyone making use of the fact that the R-level close.connection() function can return -1...

...; system call failure on writing >>> > close(fc) >>> >>> Serguei. >> >> I suspect that flushing on every write will slow things down too much. > That's quite plausible. > >> >> I think a better approach is to catch the error in the Rconn_printf >> calls (as R-devel currently does), and also catch errors on >> con->close(con). This one requires more changes to the source, so it >> may be a day or two before I commit. > I have testes it on file_close() and it works (cf. attached patch): >> fc=file("/dev/f...

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 only positive values > returned by the vfprintf call. > That's likely because you aren't writing enough to actually...

...>>>> > close(fc) >>>> >>>> Serguei. >>> >>> I suspect that flushing on every write will slow things down too much. >> That's quite plausible. >> >>> >>> I think a better approach is to catch the error in the Rconn_printf >>> calls (as R-devel currently does), and also catch errors on >>> con->close(con). This one requires more changes to the source, so it >>> may be a day or two before I commit. >> I have testes it on file_close() and it works (cf. attached patch): >>>...

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 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 vfprintf call. >>> >> >> That's likely...

...>>>>> >>>>> Serguei. >>>> >>>> I suspect that flushing on every write will slow things down too much. >>> That's quite plausible. >>> >>>> >>>> I think a better approach is to catch the error in the Rconn_printf >>>> calls (as R-devel currently does), and also catch errors on >>>> con->close(con). This one requires more changes to the source, so it >>>> may be a day or two before I commit. >>> I have testes it on file_close() and it works (cf. attached patch...

Full_Name: Juan Gea Version: R version 2.6.2 OS: Fedora Core 6 Submission from: (NULL) (79.153.48.49) Abort: objeS <- matrix("AAA",1000000) class(objeS) outTxt <- textConnection("vaClob", open = "w", local = FALSE) dput(objeS,outTxt) close(outTxt) R version 2.6.2 (2008-02-08) Copyright (C) 2008 The R Foundation for Statistical Computing ISBN

Curious to know if this warning is expected behavior, and if so, what is the recommended way instead: > dput(letters, file = stderr()) c("a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p",

...t;>>>> Serguei. >>>>> >>>>> I suspect that flushing on every write will slow things down too much. >>>> That's quite plausible. >>>> >>>>> >>>>> I think a better approach is to catch the error in the Rconn_printf >>>>> calls (as R-devel currently does), and also catch errors on >>>>> con->close(con). This one requires more changes to the source, so it >>>>> may be a day or two before I commit. >>>> I have testes it on file_close() and it works (cf...