similar to: (PR#7899) seek(con, 0, "end", rw="r") does not always work

ligges@statistik.uni-dortmund.de wrote: > tplate@blackmesacapital.com wrote: > > >>I've noticed that seek(con, 0, "end", rw="r") on a file connection does >>not always work correctly after a write (R 2.1.0 on Windows). >> >>[Is a call to fflush() needed inside file_seek() in main/connections.c?] > > > > If you have an idea

This message relates to handling files > 2Gb under Windows. (I use 2Gb as shorthand for 2^31-1 -- the largest integer representable in a signed 32 bit integer.) First issue: truncate() is not able to successfully truncate files at a position > 2Gb. This appears to be due to the use of the Windows function chsize() in file_truncate() in main/connections.c (chsize() takes a long int

__USE_LARGEFILE is a standard Unix way to allow > 2Gb files on 32-bit OSes by using f{seek,tell}o Take a look at the definition of f_tell: #if defined(HAVE_OFF_T) && defined(__USE_LARGEFILE) #define f_seek fseeko #define f_tell ftello #else #ifdef Win32 #define f_seek fseeko64 #define f_tell ftello64 #else #define f_seek fseek #define f_tell ftell #endif #endif Windows support for

tplate@blackmesacapital.com wrote: > I've noticed that seek(con, 0, "end", rw="r") on a file connection does > not always work correctly after a write (R 2.1.0 on Windows). > > [Is a call to fflush() needed inside file_seek() in main/connections.c?] If you have an idea where to fflush() precisely and your patch works, please tell it! I'll happily run

Full_Name: John Brzustowski Version: R-devel-trunk, R-2.4.0 OS: linux Submission from: (NULL) (206.248.132.197) DESCRIPTION seek() on files larger than 2 gigabytes fails for large values of "where" on i386 linux 2.6.13 (and presumably other 32-bit unix-like platforms). e.g.: > f<-file("3gigabytefile.dat", "rb") > seek(f, 3e9, "start",

I've noticed that seek(con, 0, "end", rw="r") on a file connection does not always work correctly after a write (R 2.1.0 on Windows). [Is a call to fflush() needed inside file_seek() in main/connections.c?] Example (see the lines with the "***WRONG***" comment) > # seek(, rw="r") on a file does not always work correctly after a write > f

Thanks to all who have responded. My concern was to be able to write a csv file that can have line feeds in string columns chr(10). Why? Excel allows line feeds chr(10) within cells and line breaks chr(13)+chr(10) at line ending, but the windows version of R automatically replaces \n by \r\n in writing and \r\n by \n in reading (text mode). The clues for a solution came from Brian Ripley and

Hello, I've noticed a specific type of pipe() usage that works in released R, but not in r-devel. In 4.3.2 on macOS, I can write to a connection returned by pipe(), i.e. "hello, world" prints here: > R.version.string [1] "R version 4.3.2 (2023-10-31)" > con <- pipe("cat") > writeLines("hello, world", con) hello, world But in r-devel on

I've now tested with: > R.version.string [1] "R Under development (unstable) (2024-02-16 r85931)" and all of the previously mentioned examples now work as expected on macOS. Thanks for the quick fix, Jenny On Thu, Feb 15, 2024 at 8:02?AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 2/14/24 23:43, Jennifer Bryan wrote: > > Hello, > > >

Hello, I am trying to write some code in R to communicate over sockets via the STOMP protocol (http://stomp.codehaus.org/Protocol). As you can see, a null byte (ASCII 0) is used as the "over" signal. I'd like to be able to do something like this: write.socket(socket, "CONNECT\nlogin: me\npasscode: pass\n\n\000") However, R does not like it when you put "\000"

Hi, I need to create a text file in the following format, > 1 100.0 0 > 0 0 > 1 1 > 0 0 > 1 1 > # > 1 100.0 0 > 0 0 > 0 1 > 1 0 > 1 1 ... where # is part of the format and not a R comment. Each block (delimited by #) consists of a first line with three values, call it dose, and a list of (x,y) coordinates which are a matrix or data.frame, >

Recent functionality in jsonlite allows for streaming json to a user supplied connection object, such as a file, pipe or socket. RFC7159 prescribes json must be encoded as unicode; ISO-8859 (including latin1) is invalid. Hence I would like R to write strings as utf8, irrespective of the type of connection, platform or locale. Implementing this turns out to be unsurprisingly difficult on windows.

On 23.02.2016 14:06, Mikko Korpela wrote: > On 23.02.2016 11:37, Martin Maechler wrote: >>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: >> >> > Dear R developers >> > I think I have found a bug that can be reproduced with two lines of code >>

I have just committed your first patch (the strlen() replacement) to R-devel, and will soon put it in R-patched as well. I wont have time to look at this again before the 3.2.4 release, so your file.show() patch isn't going to make it unless someone else gets to it. There's still a faint chance that I'll do more in R-devel before 3.3.0, but I think it's best if there were bug

On 23/02/2016 7:06 AM, Mikko Korpela wrote: > On 23.02.2016 11:37, Martin Maechler wrote: >>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: >> >> > Dear R developers >> > I think I have found a bug that can be reproduced with two lines of code

Hi, I am reading a large space-delimited text file into R (41 columns and many rows) and need to do run each row's values through another R object and then write to another text file. So, far using readLines and writeLines seems to be the best bet. I've gotten the data exchange working except each row is read in as one 'chunk', meaning the row has all values between two quotes

Hello, The diffs below are based on revision 37445 and show some typo corrections for writeLines.Rd, readLines.Rd, and data.matrix.Rd that I'd like to bring to the list's attention. Sincerely, Stephen Weigand Rochester, Minnesota, USA --- ./src/library/base/man/writeLines.Rd Sun Feb 26 13:46:06 2006 +++ /tmp/writeLines.Rd Sun Feb 26 20:53:44 2006 @@ -14,8 +14,8 @@ each

>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: > Dear R developers > I think I have found a bug that can be reproduced with two lines of code > and I am very thankful to get your first assessment or feed-back on my > report. > If this is the wrong mailing list or I

On 24/02/2016 9:55 AM, Mikko Korpela wrote: > On 24.02.2016 15:47, Duncan Murdoch wrote: >> On 23/02/2016 7:06 AM, Mikko Korpela wrote: >>> On 23.02.2016 11:37, Martin Maechler wrote: >>>>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: >>>>

There was a discussion on r-help of getting the output from print.packageInfo into a file. Spencer and I have added a file= argument to print.packageInfo for consideration in R. Had this been available it would have simplified the answer to that thread. If the file= argument is used then the packageInfo information is sent to the file specified rather than displayed using file.show .