[Rd] debugonce() functions are not considered as debugged
debugonce() sets a different flag (RSTEP), and this is not queried by
isdebugged(), and it is also not unset by undebug().
Is this expected? If yes, is there a way to query and unset the RSTEP flag
from R code?
❯ f <- function() { }
❯ debugonce(f)
❯ isdebugged(f)
[1] FALSE
❯ undebug(f)
Warning message:
In undebug(f) : argument is not being debugged
❯ f()
debugging in: f()
debug at #1: {
}
Browse[2]>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Bug report] Chinese characters are not handled correctly in Rterm for Windows
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, BAC3 in CP936.
>Could you reproduce the problem with printing just one of the characters, say
>print("ABC\u4f60DEF") ?
Yes. The console output is pasted in [ https://paste.ubuntu.com/p/TYgZWhdgXK/ ]
(to avoid gibberish in e-mail).
The Active Code Page is 936 before and after running Rterm.
>As a sanity check - does this display the correct characters in RGui?
Yes.
>If you take the sequence of the "fputc" commands you captured by the debugger,
>and create a trivial console application to just run them - would the
>characters display correctly in the same terminal from which you run R.exe?
Yes. I created an Win32 Console Application in VS [
https://paste.ubuntu.com/p/h3NFV6nQvs/ ], and all the characters were displayed
correctly in two ways. The WriteConsoleA variant uses the current console CP
settings, and it should behave like fputc.
I guess the Rterm uses its own console I/O mechanism so the 2nd parameter of
fputc is not stdout's handle. (I tried to read the source but unable to figure
out how it works). The crash in mbcs_get_next, which is also mentioned in the
previous post, may be related to this mechanism.
If you need further information, please let me know.
Thanks,
i...@azurefx.name
Tomas Kalibera 2018/4/5 22:42
>
>
>Thank you for the report and initial debugging. I am not sure what is going
>wrong, we may have to rely on your help to debug this (I do not have a system
>to reproduce on). A user-targeted advice would be to use RGui (Rgui.exe).
>
>Does the problem also exist in R-devel?
>https://cran.r-project.org/bin/windows/base/rdevel.html
>
>Your example print("ABC\u4f60\u597dDEF") is printing two Chinese characters,
>right? The first one is C4E3 in CP936 (4F60 in Unicode) and the second one is
>BAC3 in CP936 (597D in Unicode)? Could you reproduce the problem with printing
>just one of the characters, say print("ABC\u4f60DEF") ?
>
>As a sanity check - does this display the correct characters in RGui? It
>should, and does on my system, as RGui uses Unicode internally. By correct I
>mean the characters shown e.g. here
>
>https://msdn.microsoft.com/en-us/library/cc194923.aspx
>https://msdn.microsoft.com/en-us/library/cc194920.aspx
>
>What is the output of "chcp" in the terminal, before you run R.exe? It may be
>different from what Sys.getlocale() gives in R.
>
>If you take the sequence of the "fputc" commands you captured by the debugger,
>and create a trivial console application to just run them - would the
>characters display correctly in the same terminal from which you run R.exe?
>
>Thanks
>Tomas
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in RScript.exe for 3.5.0
It seems the fix has not been ported to the patched version of R on
Windows yet. I just tested R version 3.5.0 Patched (2018-04-27
r74667).
IMHO this bug is so bad that it is worth a new release R 3.5.1 before
it starts biting more users like this one
https://stackoverflow.com/q/50077412/559676. BTW, although the bug has
been fixed (https://github.com/wch/r-source/commit/c29f694), I think
it will be even better if a corresponding test is added at the same
time to prevent this from happening again in the future.
Thanks!
Yihui
On Fri, Apr 27, 2018 at 7:03 AM, Kerry Jackson wrote:
>
> 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) Service Pack 1
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0
>
> C:\>
>
> -Original Message-
> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> Sent: Thursday, April 26, 2018 10:22 AM
> To: Kerry Jackson
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
>
> Thanks, actually this is because the snapshot build is still one version
> behind (74642, the fix is in 74643). When I build my own installer and
> install it seems to be working fine. Sorry for the confusion,
>
> Tomas
>
> On 04/26/2018 02:49 PM, Kerry Jackson wrote:
> > 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 Files\R\R-devel\bin\x64\Rscript.exe" --vanilla "C:\foo
> > bar.R"
> > What do you get when you multiply 6 * 9?
> > C:\>
> >
> > -Original Message-
> > From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> > Sent: Thursday, April 26, 2018 8:35 AM
> > To: Kerry Jackson ; r-devel@r-project.org
> > Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
> >
> > On 04/26/2018 02:23 PM, Kerry Jackson wrote:
> >> 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.
> > Thanks, Kerry.
> >
> > There are binary builds for daily snapshots of R-devel
> > (development/unstable version of R) at
> > https://cran.r-project.org/bin/windows/base/rdevel.html
> >
> > At this time the build should already have the fix.
> >
> > Best
> > Tomas
> >
> >> -Original Message-
> >> From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
> >> Sent: Thursday, April 26, 2018 6:34 AM
> >> To: Kerry Jackson ; r-devel@r-project.org
> >> Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
> >>
> >> 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
> >>>
> >>> On 04/25/2018 09:55 PM, Kerry Jackson wrote:
> Hi R Developers,
> I have found what I think is a bug in the RScript.exe in version
> 3.5.0 of R for Windows.
> When I call Rscript.exe for Version 3.5 of R, it is unable to open
> the file if the file name or path has a space in it.
> As an example of what happens, I saved 2 files with the code:
> cat("What do you get when you multiply 6 * 9?") as C:\foo bar.R and
> as C:\foo_bar.R When I in a DOS command window try to run these
> using version 3.4.3 and 3.5:
> C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo bar.R"
> What do you get when you multiply 6 * 9?
> C:\>"C:\Program Files\R\R-3.4.3\bin\x64\Rscript.exe" "C:\foo_bar.R"
> What do you get when you multiply 6 * 9?
> C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo bar.R"
> Fatal error: cannot open file 'C:\foo': No such file or directory
>
>
> C:\>"C:\Program Files\R\R-3.5.0\bin\x64\Rscript.exe" "C:\foo_bar.R"
> What do you get when you multi
Re: [Rd] Bug in RScript.exe for 3.5.0
I don't have an opinion if this requires 3.5.1 to be released soon(er),
but I have ported to R-patched now. The bug existed in R-devel for a
year without being spotted, which is quite a long time - but it may be
these bugs are hard to find before release, because people testing and
using an unreleased version of R would not use space in file names. As
apparently users of released versions do, we should do better about
testing, perhaps test regularly with space in path names on a system
that supports it. I think normal regression tests should not depend on
such support.
In either case, I would recommend users to avoid space in file names to
be safe. One known problem is that some packages will not build when
RHOME has space in its name (on Windows, this is not a problem on drives
with short file names supported, but that is not always the case) - CRAN
is now checking the most common source of this issue, but there may be more.
Tomas
On 04/28/2018 07:23 PM, Yihui Xie wrote:
It seems the fix has not been ported to the patched version of R on
Windows yet. I just tested R version 3.5.0 Patched (2018-04-27
r74667).
IMHO this bug is so bad that it is worth a new release R 3.5.1 before
it starts biting more users like this one
https://stackoverflow.com/q/50077412/559676. BTW, although the bug has
been fixed (https://github.com/wch/r-source/commit/c29f694), I think
it will be even better if a corresponding test is added at the same
time to prevent this from happening again in the future.
Thanks!
Yihui
On Fri, Apr 27, 2018 at 7:03 AM, Kerry Jackson wrote:
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) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.6.0
C:\>
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: Thursday, April 26, 2018 10:22 AM
To: Kerry Jackson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
Thanks, actually this is because the snapshot build is still one version behind
(74642, the fix is in 74643). When I build my own installer and install it
seems to be working fine. Sorry for the confusion,
Tomas
On 04/26/2018 02:49 PM, Kerry Jackson wrote:
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 Files\R\R-devel\bin\x64\Rscript.exe" --vanilla "C:\foo bar.R"
What do you get when you multiply 6 * 9?
C:\>
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: Thursday, April 26, 2018 8:35 AM
To: Kerry Jackson ; r-devel@r-project.org
Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
On 04/26/2018 02:23 PM, Kerry Jackson wrote:
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.
Thanks, Kerry.
There are binary builds for daily snapshots of R-devel
(development/unstable version of R) at
https://cran.r-project.org/bin/windows/base/rdevel.html
At this time the build should already have the fix.
Best
Tomas
-Original Message-
From: Tomas Kalibera [mailto:tomas.kalib...@gmail.com]
Sent: Thursday, April 26, 2018 6:34 AM
To: Kerry Jackson ; r-devel@r-project.org
Subject: Re: [Rd] Bug in RScript.exe for 3.5.0
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
On 04/25/2018 09:55 PM, Kerry Jackson wrote:
Hi R Developers,
I have found what I think is a bug in the RScript.exe in version
3.5.0 of R for Windows.
When I call Rscript.exe for Version 3.5 of R, it is unable to open
the file if the file name or path has a space in it.
As an example of what happens, I saved 2 files with the code:
cat("What do you get when you multiply 6 * 9?") as C:\foo bar.R and
[Rd] Result of 'seq' doesn't use compact internal representation
> .Internal(inspect(1:10)) @300e4e8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) > .Internal(inspect(seq(1,10))) @3b6e1f8 13 INTSXP g0c4 [] (len=10, tl=0) 1,2,3,4,5,... > system.time(1:1e7) user system elapsed 0 0 0 > system.time(seq(1,1e7)) user system elapsed 0.050.000.04 It seems that result of function 'seq' doesn't use compact internal representation. However, looking at the code of function 'seq.default', seq(1,n) produces 1:n. What is going on? > h <- seq.default > environment(h) <- .GlobalEnv > library(compiler) > enableJIT(0) [1] 3 > .Internal(inspect(h(1,10))) @375ade8 13 INTSXP g0c0 [NAM(3)] 1 : 10 (compact) A non-byte-compiled version of function 'seq.default' can produce object that uses compact internal representation. > sessionInfo() R version 3.5.0 (2018-04-23) Platform: i386-w64-mingw32/i386 (32-bit) Running under: Windows XP (build 2600) Service Pack 3 Matrix products: default locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] compiler stats graphics grDevices utils datasets methods [8] base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
