similar to: R 3.5.3 and 3.6.0 alpha Windows bug: UTF-8 characters in code are simplified to wrong ones

On 4/10/19 1:14 PM, Jeroen Ooms wrote: > On Wed, Apr 10, 2019 at 12:19 PM Tom?? Bo?il <borilt at gmail.com> wrote: >> Minimalistic example: >> Let's type "?" (LATIN SMALL LETTER R WITH CARON) in RGui console: >>> "?" >> [1] "r" >> >> Although the script is in UTF-8, the characters are replaced by >>

On 10/04/2019 10:29 a.m., Yihui Xie wrote: > Since it is "technically easy" to disable the best fit conversion and > the best fit is rarely good, how about providing an option for > code/package authors to disable it? I'm asking because this is one of > the most painful issues in packages that may need to source() code > containing UTF-8 characters that are not

Yes, again in a script sourced by source(encoding = ...). But also by typing it directly in R console. Most of the time, I use RStudio as a front-end. For this experiment, I also verified it in Rgui. In both front-ends, it behaves completely in the same way. An optional parameter to source() function which would translate all UTF-8 characters in string literals to their "\Uxxxx" codes

Since it is "technically easy" to disable the best fit conversion and the best fit is rarely good, how about providing an option for code/package authors to disable it? I'm asking because this is one of the most painful issues in packages that may need to source() code containing UTF-8 characters that are not representable in the Windows native encoding. Examples include

Or, if this cannot be done easily, please, disable the "utf-8" value in source(..., ) function on Windows R. source(..., encoding = "utf-8") -> error: "utf-8" does not work right on Windows. -> (or, at least) warning: "utf-8" is handled by "best fit" on Windows and some characters in string literals may be automatically changed. Because, at

On 4/10/19 6:32 PM, Jeroen Ooms wrote: > On Wed, Apr 10, 2019 at 5:45 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> On 10/04/2019 10:29 a.m., Yihui Xie wrote: >>> Since it is "technically easy" to disable the best fit conversion and >>> the best fit is rarely good, how about providing an option for >>> code/package authors to disable

On Wed, Apr 10, 2019 at 12:19 PM Tom?? Bo?il <borilt at gmail.com> wrote: > > Minimalistic example: > Let's type "?" (LATIN SMALL LETTER R WITH CARON) in RGui console: > > "?" > [1] "r" > > Although the script is in UTF-8, the characters are replaced by > "simplified" substitutes uncontrollably (depending on OS locale).

On 6/29/20 4:39 PM, Johannes Rauh wrote: > Dear R Developers, > > I noticed that `basename` and `dirname` always return "UTF-8" on Windows (tested with R-4.0.0 and R-3.6.3): > >> p <- "F??/B?r" >> Encoding(p) > [1] "latin1" >> Encoding(dirname(p)) > [1] "UTF-8" >> Encoding(basename(p)) > [1] "UTF-8"

Could you recommend any packages/functions that compute hash such that the source references and sexpinfo_struct are ignored? Basically a version of `serialize` that convert R objects to raw without storing the ancillary source reference and sexpinfo. I think most people would think of `digest` but that package uses `serialize` (see discussion

Hi Tomas, Sorry for the false alarm! I did some further testing, and you were right. There was no regression. I suspected it was a regression because the user who reported the issue said his code worked in R 3.6 but not 4.0. I should have tested it more carefully by myself. After I tested it again with the German locale and Chinese locale, respectively, I found that the code worked for both

Hi everyone, I've noticed new behavior in `regexpr(..., perl = TRUE)` on Windows with R4.0 and above with Unicode characters. Here's a minimal example where I'd expect to see a start value of `5` (as R 3.6.2 and below gives), but R 4.0.0 (and R 4.0.1) now returns: ``` > regexpr("b", "foo\U0001F937bar", perl = TRUE) #> [1] 6 #>

> On 31 Jan 2023, at 12:51 , Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > > On 1/31/23 11:50, Martin Maechler wrote: <snippage> >> hmm.., that's a pity; I had hoped it was a pragmatic and valid strategy, >> but of course you are right that type stability is really a >> valid goal.... >> >> In general, what about behaving close

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

For me, this would be a perfect solution. I.e., do not use the ?best? fit and leave it to user?s competence: a) in some functions, utf-8 works b) in others -> error is thrown (e.g., incomplete string, NA, etc.) => user has to change the code with his/her intentional ?best fit string literal substitute? or use another function that can handle utf-8. Making an R code working right only on

Thanks Tomas, I confirm the R Under development (unstable) (2018-04-26 r74651) version works for Rscript when the file name has a space, and no arguments are specified. C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" "C:\foo bar.R" R Under development (unstable) (2018-04-26 r74651) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601)

On 4/11/19 9:10 AM, Tom?? Bo?il wrote: > Or, if this cannot be done easily, please, disable the "utf-8" value > in source(..., ) function on Windows R. > source(..., encoding = "utf-8") > -> error: "utf-8" does not work right on Windows. > -> (or, at least) warning: "utf-8" is handled by "best fit" on Windows > and some

I think that this is because `[<-` dispatches on S4 methods only if the first argument is S4. ?"[<-" says: "These operators are also implicit S4 generics, but as primitives, S4 methods will be dispatched only on S4 objects ?x?." Georgi Boshnakov -----Original Message----- Message: 19 Date: Tue, 8 Sep 2020 22:04:44 -0400 From: Ben Bolker <bbolker at

Hi Tomas, Thanks for the info about the binary builds; I did install it, however the bug still seems to be there in the current build. The workaround you suggested does work: C:\>"C:\Program Files\R\R-devel\bin\x64\Rscript.exe" "C:\foo bar.R" Fatal error: cannot open file 'C:\foo': No such file or directory C:\>"C:\Program

On 8/22/20 9:33 PM, Jeroen Ooms wrote: > On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: >> On 8/22/20 8:26 PM, Tomas Kalibera wrote: >>> On 8/22/20 7:58 PM, Jeroen Ooms wrote: >>>> On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera >>>> <tomas.kalibera at gmail.com> wrote: >>>>> On 8/21/20 11:45

On 9/9/20 9:30 AM, Hugh Parsonage wrote: > Thank you! > > I get > > Starting program: C:\R\R-devel-20200909\bin\x64\Rgui.exe > [New Thread 19940.0x638c] > [New Thread 19940.0x102c] > [New Thread 19940.0x329c] > [New Thread 19940.0x37dc] > warning: Invalid parameter passed to C runtime function. > > Program received signal SIGSEGV, Segmentation fault. >