similar to: readLines on open connection reads only first write on MacOS

As s work-around I suggest readr::read_file. --Ista On Sep 2, 2017 2:58 PM, "Jennifer Lyon" <jennifer.s.lyon at gmail.com> wrote: > Hi: > > I have a 2.1GB JSON file. Typically I use readLines() and > jsonlite:fromJSON() to extract data from a JSON file. > > When I try and read in this file using readLines() R segfaults. > > I believe the two salient

Although the problem can apparently be avoided in this case. readLines causing a segfault still seems unwanted behaviour to me. I can replicate this with the example below (sessionInfo is further down): # Generate an example file l <- paste0(sample(c(letters, LETTERS), 1E6, replace = TRUE), collapse="") con <- file("test.txt", "wt") for (i in

Thank you for your suggestion. Unfortunately, while R doesn't segfault calling readr::read_file() on the test file I described, I get the error message: Error in read_file_(ds, locale) : negative length vectors are not allowed Jen On Sat, Sep 2, 2017 at 1:38 PM, Ista Zahn <istazahn at gmail.com> wrote: > As s work-around I suggest readr::read_file. > > --Ista > > >

Hi: I have a 2.1GB JSON file. Typically I use readLines() and jsonlite:fromJSON() to extract data from a JSON file. When I try and read in this file using readLines() R segfaults. I believe the two salient issues with this file are 1). Its size 2). It is a single line (no line breaks) I can reproduce this issue as follows #Generate a big file with no line breaks # In R >

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

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

I think the problem in R-devel happens when there are non-ASCII characters in any of the strings passed to gsub. txt <- vapply(list(as.raw(c(0x41, 0x6d, 0xc3, 0xa9, 0x6c, 0x69, 0x65)), as.raw(c(0x41, 0x6d, 0x65, 0x6c, 0x69, 0x61))), rawToChar, "") txt #[1] "Am?lie" "Amelia" Encoding(txt) #[1] "unknown" "unknown" gsub(perl=TRUE,

Hi list, When using R CMD Rd2pdf, it is possible to set environment variable RD2PDF_INPUTENC to value "inputenx" and enjoy better support for UTF-8 characters (see ?Rd2pdf). This enables LaTeX package "inputenx" instead of "inputenc". Even better support for UTF-8 encoded characters can be had by better using the facilities provided by inputenx and making R CMD

| Confirmed for R-devel (current) on Ubuntu 17.10. But ... isn't the regexp | you use wrong, ie isn't R-devel giving the correct answer? No, I don't think R-devel is correct (or at least consistent with the documentation). My interpretation of gsub("(\\w)", "\\U\\1", entry, perl = TRUE) is "Take every word character and replace it with itself, converted to

I was told to re-raise this issue with R-dev: In the documentation of R-dev and R-3.4.3, under ?gsub > replacement > ... For perl = TRUE only, it can also contain "\U" or "\L" to convert the rest of the replacement to upper or lower case and "\E" to end case conversion. However, the following code runs differently: tempf <- tempfile()

Working on Windows I have had to deal with CSV files that, unfortunately, contain embedded Control-Zs, i.e. ASCII character 26 in decimal, and the readLines() function in R on Windows (2.15.2 and 3.0.0) appears to truncate at the control-Z. There is no problem at all on Ubuntu Linux with R 3.0.0. Am I mistaken or is this genuine? # Create a small file with embedded Control-Z h3 <-

Dear R developers, I am developing an R package which returns strings with new line codes. I am not sure if I should use "\r\n" or "\n" in my returned strings on Windows platforms. What is the recommended best practice for package developers (and code in base R) for coding new lines in strings? And just out of curiosity: What is the reason (or history) for preferring

Jeroen: Thank you for pointing me to ndjson, which I had not heard of and is exactly my case. My experience: jsonlite::stream_in - segfaults ndjson::stream_in - my fault, I am running Ubuntu 14.04 and it is too old so it won't compile the package corpus::read_ndjson - works!!! Of course it does a different simplification than jsonlite::fromJSON, so I have to change some code, but

On 25/07/2020 4:48 p.m., nospam at altfeld-im.de wrote: > Dear R developers, > > I am developing an R package which returns strings with new line codes. > I am not sure if I should use "\r\n" or "\n" in my returned strings on Windows platforms. > > What is the recommended best practice for package developers (and code in base R) for coding new lines in

On 25.02.2016 11:31, Mikko Korpela wrote: > 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

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.

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

Tony Plate wrote: > 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

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

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