Thank you for the quick fix! I could've sworn the 'save()' dance was a
necessary part of the reproducible example, but evidently not ...
On Wed, Jul 18, 2018 at 6:38 AM Tomas Kalibera wrote:
>
> Fixed in R-devel and R-patched,
> Tomas
>
> On 07/18/2018 12:03 PM, Tomas Kalibera wrote:
>
> Thanks, I
Fixed in R-devel and R-patched,
Tomas
On 07/18/2018 12:03 PM, Tomas Kalibera wrote:
> Thanks, I can now reproduce and it is a bug that is easy to fix, I
> will do so shortly.
>
> Fyi it can be reproduced simply by running these two lines in Rgui:
>
> list()
> encodeString("apple")
>
> Best
> Toma
Thanks, I can now reproduce and it is a bug that is easy to fix, I will
do so shortly.
Fyi it can be reproduced simply by running these two lines in Rgui:
list()
encodeString("apple")
Best
Tomas
On 07/17/2018 05:16 PM, Kevin Ushey wrote:
> Sorry, I should have been more clear -- if I write the
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()
Hi Kevin,
the extra bytes you are seeing are escapes for UTF-8 strings used in
input to RGui console. Recently ascii strings are converted to UTF-8 so
you would get these escapes for ascii strings now as well. RGui
understands these escapes and converts from UTF-8 to wide characters
before pr
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