similar to: memDecompress and zlib compressed base64 encoded string

Hello, I would like to compress a long string (character vector), store the compressed string in the text field of a SQLite database (using RSQLite), and then load the text back into memory and decompress it back into the the original string. My character vector can be compressed considerably using standard gzip/bzip2 compression. In theory it should be much faster for me to compress/decompress

Hi all, I'm struggling to decompress a gzip'd raw vector in memory: content <- readBin("http://httpbin.org/gzip", "raw", 1000) memDecompress(content, type = "gzip") # Error in memDecompress(content, type = "gzip") : # internal error -3 in memDecompress(2) I'm reasonably certain that the file is correctly compressed, because if I save it

Dear R experts, It seems that Rprintf has to be used to print from a C routine to guarantee to write to R?s output according to https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Printing. However if a string is UTF-8 encoded, non-ASCII characters (e.g., the infinity symbol http://www.fileformat.info/info/unicode/char/221e/index.htm) are misprinted. Is this an unsupported feature or is

On Thu, Feb 15, 2018 at 11:19 AM, Kevin Ushey <kevinushey at gmail.com> wrote: > I suspect your UTF-8 string is being stripped of its encoding before > write, and so assumed to be in the system native encoding, and then > re-encoded as UTF-8 when written to the file. You can see something > similar with: > > > tmp <- '?' > > tmp <- iconv(tmp,

Hi, right now we have (on R v2.7.0 patched (2008-04-23 r45466)) that: > rawToChar(raw(0)) [1] "" > rawToChar(raw(0), multiple=TRUE) character(0) Is this intended or should both return character(0)? Personally, I would prefer that an empty input vector returns an empty output vector. Same should then apply to charToRaw(), but right now we get: > x <- character(0) >

Given the following R script: x <- 1 print(list()) save(x, file = tempfile()) output <- encodeString("apple") print(output) If I source this script from RGui on Windows, I see the output: > source("encoding.R") list() [1] "\002??apple\003??" That is, it's as though R has injected what looks like byte order marks around the

Hi, A piece of my code that uses readBin() to read a certain file type is behaving strangely with R 2.7.0. This seems to be because of a failure to match() strings after using rawToChar() when the original was terminated with a "\0" character. Direct equality testing with == still works as expected. I can reproduce this as follows: > x <- "foo" > y <-

I can confirm that it doesn't happen on Ubuntu 18.04.1 so Peter is most likely correct; it looks like its Windows specific. On Thu, 7 Feb 2019 at 12:55, peter dalgaard <pdalgd at gmail.com> wrote: > > This doesn't seem to be happening on MacOS, neither in Terminal nor RStudio, (R 3.5.1, R-devel, R-patched). So probably Windows specific. > > -pd > > > On 7 Feb

Of course, right after writing this e-mail I tested on my Windows machine and did not see what I expected: > charToRaw(before) [1] c3 a9 > charToRaw(after) [1] e9 so obviously I'm misunderstanding something as well. Best, Kevin On Sat, Feb 17, 2018 at 2:19 PM, Kevin Ushey <kevinushey at gmail.com> wrote: > From my understanding, translation is implied in this line of ?file

Hello, All: Do you know of any capability to substitute more then one byte in an object of class Raw? Consider the following: > let4 <- paste(letters[1:4], collapse='') > (let4Raw <- charToRaw(let4)) [1] 61 62 63 64 > (let. <- sub('bc', '--', let4Raw)) [1] "61" "62" "63" "64" > # no

Dear all, I have 100 files which are used as input.and I have to input the name of my files again and again.the name of the files are 1.out, 2.out......100.out. I want to know if there is anything like perl so that i can use something like this- for($f = 1; $f <= 100; $f++) { $file = $f.".out"; I have tried this thing in R but it does not work.Can somebody please help me.

Hello, Suppose in the following code, PROTECT(sr = R_tryEval( .... )) sr is a RAWSXP vector. I wish to return another RAWSXP starting at position 13 onwards (base=0). I could create another RAWSXP of the correct length and then memcpy the required bytes and length to this new one. However is there a more efficient method? Regards Saptarshi Guha

I think this behavior is inconsistent with the documentation: tmp <- '?' tmp <- iconv(tmp, to = 'UTF-8') print(Encoding(tmp)) print(charToRaw(tmp)) tmpfilepath <- tempfile() writeLines(tmp, con = file(tmpfilepath, encoding = 'UTF-8'), useBytes = TRUE) [1] "UTF-8" [1] c3 a9 Raw text as hex: c3 83 c2 a9 If I switch to useBytes = FALSE, then

Hi R Developers, Greg is helping me with debugging R on Solaris 10 x64. Please let us know if you have any thoughts or tips that can help us debug this. Thanks, David ************ Using default transfer plist in vector_io: permuting About to write *** caught segfault *** address e8554000, cause 'memory not mapped' Traceback: 1: .External("do_hdf5save", call,

I've rolled up R-2.11.1.tar.gz a short while ago. This is an update release, which fixes a number of mostly minor issues. The most annoying one was probably the problem with format.POSIXlt causing C stack overflow on long date vectors. See the full list of changes below. You can get it from http://cran.r-project.org/src/base/R-2/R-2.11.1.tar.gz or wait for it to be mirrored at a CRAN site

I've rolled up R-2.11.1.tar.gz a short while ago. This is an update release, which fixes a number of mostly minor issues. The most annoying one was probably the problem with format.POSIXlt causing C stack overflow on long date vectors. See the full list of changes below. You can get it from http://cran.r-project.org/src/base/R-2/R-2.11.1.tar.gz or wait for it to be mirrored at a CRAN site

Hello, How do I change this: > cnt_str [1] "\002" "\001" "\102" ...to this: > cnt_str [1] "2" "1" "102" Having trouble because of this: > nchar(cnt_str[1]) [1] 1 Thanks! Ben [[alternative HTML version deleted]]

I have a need to find the order of number to get a scaling parameter as a power of 10. I have a function that works *so far*, but it is ugly and probably buggy. In the interest of avoiding code-based outliers in my data, I thought I would ask if anyone here has a better way. > scl <- function(x){ + length(charToRaw(format(trunc(x), scientific = F)))-1} > a <- 123456789 > b <-

Sorry, I should have been more clear -- if I write the contents of that script to a file called 'encoding.R' and source that, then I see the reported behavior. Here's something standalone that you should hopefully be able to copy + paste into RGui to reproduce: code <- ' x <- 1 print(list()) save(x, file = tempfile()) output <- encodeString("apple")

I can reproduce this behavior on my Windows 10 system in RGui (cp1252): when I paste the Unicode infinity symbol into the console, it is treated as number 8. This is caused by Windows "best fit" default behavior in conversion of unicode characters to characters in the current native encoding: at some point in the past, 8 has been chosen as a good fit for infinity in Windows. In my