similar to: redundant "`" symbol in the name of list (R version 3.5.0 & 3.5.1)

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)

Dear all, I would like to have your opinion about an issue I have recently run into while using tcltk in R 3.5.0 under Windows 7 64bit. Here is a reproducible example of the issue, along with information about platform and OS. ############################################################### # R 3.5.0 issue: print does not work properly for data.frames # # when called

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 > Tomas > > On 07/17/2018 05:16 PM, Kevin Ushey wrote:

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

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")

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 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

Fixed in R-devel. I will port to R-patched after more testing. Tomas On 04/26/2018 01:52 AM, Tomas Kalibera wrote: > Thanks for the report. A quick workaround before this gets fixed is to > add an extra first argument that has no space in it, e.g. > > Rscript --vanilla "foo bar.R" > > The problem exists on all systems, not just Windows. > > Best > Tomas >

Thanks Tomas. I confirm the quick workaround works for me in the DOS prompt, and when having a shortcut to RScript in SendTo, and when used in the Task Scheduler. I have not tested the R-devel version, due to my unfamiliarity with installing from source code. -----Original Message----- From: Tomas Kalibera [mailto:tomas.kalibera at gmail.com] Sent: Thursday, April 26, 2018 6:34 AM To: Kerry

On R 3.5.0 (Mac) The issue appears when using the default (libcurl) method and specifying the encoding Note that using method='internal' causes a segfault if used in conjunction with encoding. (and works when encoding is not set) urlR <- "http://home.versanet.de/~s-berman/source2.R" # works url_default <- url(urlR) scan(url_default, "") # Read 7 items # [1]

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. >

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

On Fri, Sep 13, 2019 at 11:53 AM Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > On 9/13/19 11:37 AM, IAGO GIN? V?ZQUEZ wrote: > > But if I type > > >"?" > > the output is > > [1] "?" > > so seemingly it can be represented. Or, am I wrong? > > In RGui you can print the string, because RGui is a Windows Unicode >

On 9/9/20 8:48 AM, Hugh Parsonage wrote: > I am unable to set break or use gdb with any success when I use that version. > > On linux I would do R -d gdb but this gives "unknown option '-d' " > while gdb R.exe (in the same directory as the debug version) gives the > same output as before. > > I'm happy to help but I appreciate this list might not be the

But if I type > "?" the output is [1] "?" so seemingly it can be represented. Or, am I wrong? Best Iago ________________________________ De: Tomas Kalibera <tomas.kalibera at gmail.com> Enviat el: divendres, 13 de setembre de 2019 11:24 Per a: IAGO GIN? V?ZQUEZ <i.gine at pssjd.org>; r-devel at r-project.org <r-devel at r-project.org> Tema: Re: [Rd]

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

Hi Tomas, Sorry for the delayed response. I have tested the problem on the latest R-devel build (2018-04-27 r74651), and it still exists. RGui is always fine with Chinese characters, but some IDEs rely on the CLI version of R (e.g. Visual Studio Code with R plugin). >Your example print("ABC\u4f60\u597dDEF") is printing two Chinese characters, right? Yes. U+4F60, U+597D or C4E3,

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

Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/7/19 10:32 PM, Laurent Gautier wrote: > > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is this > happening during parsing" (that is why

Hello, There is a long-lasting problem with processing UTF-8 source code in R on Windows OS. As Windows do not have "UTF-8" locale and R passes source code through OS before executing it, some characters are "simplified" by the OS before processing, leading to undesirable changes. Minimalistic example: Let's type "?" (LATIN SMALL LETTER R WITH CARON) in RGui