Re: [Rd] error unserializing ascii format (v2 or v3)
Thanks, fixed in R-devel and R-patched. The problem was only in unserializing of raw vectors serialized in ASCII, the format is not affected. Old serialized ASCII files created by R 3.5 or earlier can be read in R-patched and re-saved in binary format, which can in turn be read in R 3.5 and earlier. Serialization/unserialization in binary format is not affected by this problem. Best Tomas On 11/8/18 11:41 AM, peter dalgaard wrote: 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 = as.raw(1)), NULL, version = 2, : 'installTrChar' must be called on a CHARSXP, but got 'pairlist' unserialize(serialize(list(r=as.raw(1)), NULL, version=2, ascii=TRUE)) Error in unserialize(serialize(list(r = as.raw(1)), NULL, version = 2, : 'installTrChar' must be called on a CHARSXP, but got 'pairlist' unserialize(serialize(list(r=1), NULL, version=2, ascii=TRUE)) $r [1] 1 unserialize(serialize(list(as.raw(c(1,2))), NULL, version=2, ascii=TRUE)) [[1]] [1] 30 31 So it looks like there is an issue with reading a named list containing a raw vector. Unnamed lists work and so does non-raw vectors. The length of the vector doesn't seem to matter and neither does the actual name. You can vary the error message by varying the entries in the vector, but the gist of it is that something gets misinterpreted and the rest of the data stop making sense. I also tried going explicitly through a text connection, and that seems exactly equivalent. -pd On 7 Nov 2018, at 23:35 , Michael Sannella via R-devel wrote: 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 serialization is done with version=2 or version=3. It does not happen if the serialization is done with ascii=FALSE. Note that 0x29 == 41. It looks like unserialize is reading the wrong line. I tried this in earlier versions of R on Windows, and the same error happens in every version from R-2.15.3 (the earliest I have) on up. ~~ Michael Sannella [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Better cleanup of example session during check
I have a couple of packages (‘fiery’ and ‘reqres') that uses a mock of a rook
request for their examples. The mock is an R6 object containing a
rawConnection, along with a finalizer that closes this connection when the
object is removed. So far so good. I’ve recently been getting CRAN errors due
to the rawConnection not being closed in examples
> cleanEx()
Error: connections left open:
content (rawConnection)
and the only way to remove this is by removing the objects and calling gc() as
part of the example code. While it is possible to hide all that inside a
\dontshow{} block, it appears to me that it would be better if cleanEx() did a
cleaning of the environment along with a single gc call prior to performing any
checks on the end state. Is this something you would consider?
best
Thomas Lin Pedersen
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Better cleanup of example session during check
On 12/11/2018 8:09 AM, Thomas Lin Pedersen wrote:
I have a couple of packages (‘fiery’ and ‘reqres') that uses a mock of a rook
request for their examples. The mock is an R6 object containing a
rawConnection, along with a finalizer that closes this connection when the
object is removed. So far so good. I’ve recently been getting CRAN errors due
to the rawConnection not being closed in examples
cleanEx()
Error: connections left open:
content (rawConnection)
and the only way to remove this is by removing the objects and calling gc() as
part of the example code. While it is possible to hide all that inside a
\dontshow{} block, it appears to me that it would be better if cleanEx() did a
cleaning of the environment along with a single gc call prior to performing any
checks on the end state. Is this something you would consider?
Wouldn't it be possible for you to add a way to explicitly request the
connection be closed? Then the finalizer would only need to close it if
you forgot.
best
Thomas Lin Pedersen
[[alternative HTML version deleted]]
This message was fine, but sometimes posting in HTML makes your message
unreadable. This list wants plain text.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Better cleanup of example session during check
On 12/11/2018 8:32 AM, Duncan Murdoch wrote:
On 12/11/2018 8:09 AM, Thomas Lin Pedersen wrote:
I have a couple of packages (‘fiery’ and ‘reqres') that uses a mock of a rook
request for their examples. The mock is an R6 object containing a
rawConnection, along with a finalizer that closes this connection when the
object is removed. So far so good. I’ve recently been getting CRAN errors due
to the rawConnection not being closed in examples
cleanEx()
Error: connections left open:
content (rawConnection)
and the only way to remove this is by removing the objects and calling gc() as
part of the example code. While it is possible to hide all that inside a
\dontshow{} block, it appears to me that it would be better if cleanEx() did a
cleaning of the environment along with a single gc call prior to performing any
checks on the end state. Is this something you would consider?
Wouldn't it be possible for you to add a way to explicitly request the
connection be closed? Then the finalizer would only need to close it if
you forgot.
After some private messages, it appears that having the example code
explicitly remove the object is enough to satisfy the check. Presumably
this is because a garbage collection is happening before the error is
issued, and it triggers the finalizer.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
