similar to: corruption of data with serialize(ascii=TRUE)

This Index: src/main/altrep.c =================================================================== --- src/main/altrep.c (revision 79385) +++ src/main/altrep.c (working copy) @@ -275,10 +275,11 @@ SEXP psym = ALTREP_SERIALIZED_CLASS_PKGSYM(info); SEXP class = LookupClass(csym, psym); if (class == NULL) { - SEXP pname = ScalarString(PRINTNAME(psym)); + SEXP pname =

Hi all, I am not able to export an ALTREP object when `gctorture` is on in the worker. The package simplemmap can be used to reproduce the problem. See the example below ``` ## Create a temporary file filePath <- tempfile() con <- file(filePath, "wrb") writeBin(rep(0.0,10),con) close(con) library(simplemmap) library(parallel) cl <- makeCluster(1) x <- mmap(filePath,

I use recordPlot() to save plots to disk that I render later to a variety of formats. This works fine for base R plots and ggplot2 plots, and also used to work for lattice plots. However somewhere in version 2.14 things stopped working for lattice plots. Here is an example: library(lattice); histogram(rnorm(100)); x <- recordPlot(); saveRDS(x, "myplot.rds"); y <-

I ran into an interesting error unserializing a file created with ascii=TRUE: R 3.5.1 (Windows or Linux): > unserialize(serialize(list(raw=as.raw(c(39,41))), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(raw = as.raw(c(39, 41))), NULL, version = 2, : ReadItem: unknown type 29, perhaps written by later version of R The same error happens when the

I noticed today that in R 2.3.1, I get > serialize(list(1,2,3), NULL, ascii = TRUE) [1] "A\n2\n131841\n131840\n19\n3\n14\n1\n1\n14\n1\n2\n14\n1\n3\n" > but in R 2.4.0 alpha I get > serialize(list(1,2,3), NULL, ascii = TRUE) [1] 41 0a 32 0a 31 33 32 30 39 36 0a 31 33 31 38 34 30 0a 31 39 0a 33 0a 31 34 [26] 0a 31 0a 31 0a 31 34 0a 31 0a 32 0a 31 34 0a 31 0a 33 0a >

[I thought I'd submitted this bug report some time ago, but it's never showed up on the bug tracking system, so I'm submitting again.] qr.solve() gives incorrect results when dealing with complex matrices or with qr objects that have been computed with LAPACK=TRUE, whenever the b argument has more than one column. This bug flows from qr.coef(), which has a similar problem. I believe

Dear R-Users, I need a very fast and reliable database solution so I try to serialize a data.frame (to binary data) and to store this data to an SQLite database. This is what I tried to do: library(RSQLite) con <- dbDriver("SQLite") db <- dbConnect(con, "test") dbSendQuery(db, 'CREATE TABLE frames("simID" INT, "data" BLOB)') data.bin <-

Agreed that's it's rounding error, and all.equal would be the way to go. I wouldn't call it a bug, it's simply part of working with floating point numbers, any language has the same issue. And while we're at it, I think the function can be a lot shorter: .is_continous_evenly_spaced <- function(n){ length(n)>1 && isTRUE(all.equal(n[order(n)], seq(from=min(n),

El vie., 31 ago. 2018 a las 16:00, Mark van der Loo (<mark.vanderloo at gmail.com>) escribi?: > > how about > > is_evenly_spaced <- function(x,...) all.equal(diff(sort(x)),...) This doesn't work, because 1. all.equal does *not* return FALSE. Use of isTRUE or identical(., TRUE) is required if you want a boolean. 2. all.equal compares two objects, not elements in a vector.

Hi folks, I've attached a patch to the svn trunk that improves the performance of the serialize/unserialize interface for vector types. The current implementation: a) invokes the R_XDREncode operation for each element of the vector type, and b) uses a switch statement to determine the stream type for each element of the vector type. I've added R_XDREncodeVector/R_XDRDecodeVector functions

Dear all, I a bit unsure, whether this qualifies as a bug, but it is definitly a strange behaviour. That why I wanted to discuss it. With the following function, I want to test for evenly space numbers, starting from anywhere. .is_continous_evenly_spaced <- function(n){ if(length(n) < 2) return(FALSE) n <- n[order(n)] n <- n - min(n) step <- n[2] - n[1] test <-

Hi, While debugging a network server I'm developing I noticed something unusual - call to unserialize() resulted in an error about loading a namespace. I was a bit taken back by this - why should unserializing an object cause a namespace lookup? Are there any other side-effects of unserialize() that I should be cautious about? I've been digging through the R_Unserialize() call, I

I see this on MacOS as well, so likely not platform dependent. A little more diddling to try to narrow it down: > unserialize(serialize(as.raw(1), NULL, version=2, ascii=TRUE)) [1] 30 > unserialize(serialize(list(as.raw(1)), NULL, version=2, ascii=TRUE)) [[1]] [1] 30 > unserialize(serialize(list(raw=as.raw(1)), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(raw =

I stumbled upon the following: f <- parallel::mcparallel(raw(0L)) parallel::mccollect(f) # $`77083` # NULL but f <- parallel::mcparallel(raw(1L)) parallel::mccollect(f) # Error in unserialize(r) : read error traceback() # 2: unserialize(r) # 1: parallel::mccollect(f) (restarting because the above appears to corrupt the R session) f <- parallel::mcparallel(raw(2L))

Someone solved the problem of saving R-objects to a database? These are the two varaints I've tried so far without success: 1) ser = rawToChar(serialize(obj, NULL, ascii=TRUE)) dbSendQuery(link, paste("insert into table values(1, '",ser,"')",sep='')) The field to save the object in the MySQL Database is of type text. unser = dbGetQuery(link,"select

Thanks for the report. Will look into it when I get a chance unless someone else gets there first. A simpler reprex: ## create and serialize a memmory-mapped file object filePath <- "x.dat" con <- file(filePath, "wrb") writeBin(rep(0.0,10),con) close(con) library(simplemmap) x <- mmap(filePath, "double") saveRDS(x, file = "x.Rds") ## in a

I think Robin knows about FAQ 7.31/floating point (author of 'Brobdingnag', among other numerical packages). I agree that this is surprising (to me). To reframe this question: is there way to get an *exact* ASCII representation of a numeric value (i.e., guaranteeing the restored value is identical() to the original) ? .deparseOpts has ?"digits17"?: Real and finite complex

I found that also; fixed in r79386 in the trunk. Will port to R-patched shortly. Best, luke On Thu, 29 Oct 2020, Martin Morgan wrote: > This > > Index: src/main/altrep.c > =================================================================== > --- src/main/altrep.c (revision 79385) > +++ src/main/altrep.c (working copy) > @@ -275,10 +275,11 @@ > SEXP psym =

Daniel, thanks for the test case. I did run it in valgrind but nothing showed up, however ... I'm starting to have a suspicion that this has something to do with identical() - look at this: > identical(M1,M2) [1] FALSE > all(serialize(M1,NULL)==serialize(M2,NULL)) [1] TRUE > identical(unserialize(serialize(M1,NULL)),unserialize(serialize(M2,NULL))) [1] FALSE >

Hello, I have some code which generates lattice objects. The function recieves serialized forms of the lattice objects which it then unserializes and then adds to an ArrayList<REXP>. REXPRaw rser = new REXPRaw( target ); //target contains the raw serialized forms of lattice objects rconn.assign("temp",rser); REXP ret =