Re: [Rd] extendrange(): suggested improvement
> Marius Hofert
> on Wed, 25 Apr 2018 17:31:01 -0400 writes:
> Hi,
> I often need to extend the plot range to the right, but not to the
> left (for example: not below 0 so that log = "x" still works...). This
> could be a handy improvement of extendrange():
> --- utils.R 2015-08-25 18:18:20.0 -0400
> +++ utils.R 2018-04-25 17:21:25.0 -0400
> @@ -30,6 +30,6 @@
>## Purpose: extend a range by a factor 'f' - on each side
>if(!missing(r) && length(r) != 2)
>stop("'r' must be a \"range\", hence of length 2")
> -r + c(-f,f) * diff(r)
> -
> +if(length(f) == 1) f <- rep(f, 2)
> +r + c(-f[1], f[2]) * diff(r)
> }
Yes, you are right and it's not the first time I've heard/seen
this wish.
Thank you for the suggestion!
I'd go for the more elegant (faster, at least in default case?)
version
extendrange <- function(x, r = range(x, na.rm = TRUE), f = 0.05)
{
## Purpose: extend a range by a factor 'f' - on each side
if(!missing(r) && length(r) != 2)
stop("'r' must be a \"range\", hence of length 2")
f <- if(length(f) == 1L) c(-f,f) else c(-f[1L], f[2L])
r + f * diff(r)
}
PS:
/* I hope the tidy faction will at some time be convinced that
using if() as a *function* in R is elegant and *the* R-way:
R is as functional a language as possible and hereby differs
from C and similar languages !
*/
Martin Maechler
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] mean(x) for ALTREP
Hi, By looking at a doc about ALTREP https://svn.r-project.org/R/branches/ALTREP/ALTREP.html (by the way congratulations for that and for R-3.5.0 in general), I was a little bit surprised by the following example: > x <- 1:1e10 > system.time(print(mean(x))) [1] 5e+09 user system elapsed 38.520 0.008 38.531 Taking 38.520 s to calculate a mean value of an arithmetic sequence seemed a lot to me. It probably means that calculations are made by running into a for loop while in the case of arithmetic sequence a mean value can simply be calculated as (b+e)/2 where b and e are the begin and end value respectively. Is it planned to take benefit of ALTREP for functions like mean(), sum(), min(), max() and some others to avoid running a for loop wherever possible? It seems so natural to me but after all some implementation details preventing this can escape to me. Best, Serguei. __ 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
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 multiply 6 * 9?
C:\>
When I try to run the file with a space in the name in version 3.5.0
of R, there is a fatal error saying there is no such file.
Kerry Jackson
Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
Phone: (203) 840-3443
[[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
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 multiply 6 * 9?
C:\>
When I try to run the file with a space in the name in version 3.5.0
of R, there is a fatal error saying there is no such file.
Kerry Jackson
Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
Phone: (203) 840-3443
[[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
Re: [Rd] Bug in RScript.exe for 3.5.0
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.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 multiply 6 * 9?
>> C:\>
>> When I try to run the file with a space in the name in version 3.5.0
>> of R, there is a fatal error saying there is no such file.
>>
>>
>> Kerry Jackson
>> Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
>> Phone: (203) 840-3443
>>
>>
>> [[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
Re: [Rd] Bug in RScript.exe for 3.5.0
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 multiply 6 * 9?
>>> C:\>
>>> When I try to run the file with a space in the name in version 3.5.0
>>> of R, there is a fatal error saying there is no such file.
>>>
>>>
>>> Kerry Jackson
>>> Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
>>> Phone: (203) 840-3443
>>>
>>>
>>> [[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
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 multiply 6 * 9?
C:\>
When I try to run the file with a space in the name in version 3.5.0
of R, there is a fatal error saying there is no such file.
Kerry Jackson
Job title: Senior Account Manager, Ipsos Connect US RA Testing GMU
Phone: (203) 840-3443
[[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
Re: [Rd] mean(x) for ALTREP
Serguei, The R 3.5.0 release includes the fundamental ALTREP framework but does not include many 'hooks' within R's source code to make use of methods on the ALTREP custom vector classes. I have implemented a fair number, including for mean() to use the custom Sum method when available, in the ALTREP branch but unfortunately we did not have time to test and port them to the trunk in time for this release. The current plan, as I understand it, is that we will continue to develop and test these, and other hooks, and then when ready they will be ported into trunk/R-devel over the course this current development cycle for inclusion in the next release of R. My hope is that the end-user benefits of ALTREP will really show through much more in future releases, but for now, things like mean will will behave as they always have from a user perspective. Best, ~G On Thu, Apr 26, 2018 at 2:31 AM, Serguei Sokol wrote: > Hi, > > By looking at a doc about ALTREP https://svn.r-project.org/R/br > anches/ALTREP/ALTREP.html (by the way congratulations for that and for > R-3.5.0 in general), I was a little bit surprised by the following example: > > > x <- 1:1e10 > > system.time(print(mean(x))) > [1] 5e+09 >user system elapsed > 38.520 0.008 38.531 > > Taking 38.520 s to calculate a mean value of an arithmetic sequence seemed > a lot to me. It probably means that calculations are made by running into a > for loop while in the case of arithmetic sequence a mean value can simply > be calculated as (b+e)/2 where b and e are the begin and end value > respectively. Is it planned to take benefit of ALTREP for functions like > mean(), sum(), min(), max() and some others to avoid running a for loop > wherever possible? It seems so natural to me but after all some > implementation details preventing this can escape to me. > > Best, > Serguei. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Gabriel Becker, Ph.D Scientist Bioinformatics and Computational Biology Genentech Research [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() for non-blocking pipeline behaves differently in R 3.5
The issue is that readLines() tries to seek (for reasons I don't
understand) in the non-blocking case, but silently fails for "stdin"
since it's a stream. This confused the buffering logic. The fix is to
mark "stdin" as unable to seek, but I do wonder why readLines() is
seeking in the first place.
Anyway, I'll get this into patched ASAP. Thanks for the report.
Michael
On Wed, Apr 25, 2018 at 5:13 PM, Michael Lawrence wrote:
> Probably related to the switch to buffered connections. I will look
> into this soon.
>
> On Wed, Apr 25, 2018 at 2:34 PM, Randy Lai wrote:
>> It seems that the behavior of readLines() in R 3.5 has changed for
>> non-blocking pipeline.
>>
>>
>> Consider the following R script, which reads from STDIN line by line.
>> ```
>> con <- file("stdin")
>> open(con, blocking = FALSE)
>>
>> while (TRUE) {
>> txt <- readLines(con, 1)
>> if (length(txt) > 0) {
>> cat(txt, "\n", file = stdout())
>> }
>> Sys.sleep(0.1)
>> }
>> close(con)
>>
>> ```
>>
>> In R 3.4.4, it works as expected.
>>
>> ```
>> (randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
>> abc
>> foo
>> ```
>>
>> In R 3.5, only the first line is printed
>> ```
>> (randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
>> abc
>> ```
>>
>> Is this change expected? If I change `blocking` to `TRUE` above, the above
>> code would
>> work. But I need non-blocking connection in my use case of piping buffer from
>> another program.
>>
>> Best,
>>
>> R 3.5 @ macOS 10.13
>>
>>
>> Randy
>>
>>
>> [[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
Re: [Rd] readLines() for non-blocking pipeline behaves differently in R 3.5
I suspect the reason for the seek is this:
cat("1\n", file = "foobar")
f <- file("foobar", blocking = FALSE, open = "r")
readLines(f)
#> [1] "1"
cat("2\n", file = "foobar", append = TRUE)
readLines(f)
#> [1] "2"
cat("3\n", file = "foobar", append = TRUE)
readLines(f)
#> [1] "3"
I.e. R can emulate a file connection with non-blocking reads.
AFAICT there is no such thing, in Unix at least.
For this emulation, it needs to seek to the "current" position.
Gabor
On Thu, Apr 26, 2018 at 7:21 PM, Michael Lawrence
wrote:
> The issue is that readLines() tries to seek (for reasons I don't
> understand) in the non-blocking case, but silently fails for "stdin"
> since it's a stream. This confused the buffering logic. The fix is to
> mark "stdin" as unable to seek, but I do wonder why readLines() is
> seeking in the first place.
>
> Anyway, I'll get this into patched ASAP. Thanks for the report.
>
> Michael
>
>
> On Wed, Apr 25, 2018 at 5:13 PM, Michael Lawrence wrote:
>> Probably related to the switch to buffered connections. I will look
>> into this soon.
>>
>> On Wed, Apr 25, 2018 at 2:34 PM, Randy Lai wrote:
>>> It seems that the behavior of readLines() in R 3.5 has changed for
>>> non-blocking pipeline.
>>>
>>>
>>> Consider the following R script, which reads from STDIN line by line.
>>> ```
>>> con <- file("stdin")
>>> open(con, blocking = FALSE)
>>>
>>> while (TRUE) {
>>> txt <- readLines(con, 1)
>>> if (length(txt) > 0) {
>>> cat(txt, "\n", file = stdout())
>>> }
>>> Sys.sleep(0.1)
>>> }
>>> close(con)
>>>
>>> ```
>>>
>>> In R 3.4.4, it works as expected.
>>>
>>> ```
>>> (randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
>>> abc
>>> foo
>>> ```
>>>
>>> In R 3.5, only the first line is printed
>>> ```
>>> (randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
>>> abc
>>> ```
>>>
>>> Is this change expected? If I change `blocking` to `TRUE` above, the above
>>> code would
>>> work. But I need non-blocking connection in my use case of piping buffer
>>> from
>>> another program.
>>>
>>> Best,
>>>
>>> R 3.5 @ macOS 10.13
>>>
>>>
>>> Randy
>>>
>>>
>>> [[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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() for non-blocking pipeline behaves differently in R 3.5
Thanks for the clear explanation. At first glance seeking to the
current position seemed like it would be a no-op, but obviously things
are more complicated under the hood.
On Thu, Apr 26, 2018 at 11:35 AM, Gábor Csárdi wrote:
> I suspect the reason for the seek is this:
>
> cat("1\n", file = "foobar")
> f <- file("foobar", blocking = FALSE, open = "r")
> readLines(f)
> #> [1] "1"
>
> cat("2\n", file = "foobar", append = TRUE)
> readLines(f)
> #> [1] "2"
>
> cat("3\n", file = "foobar", append = TRUE)
> readLines(f)
> #> [1] "3"
>
> I.e. R can emulate a file connection with non-blocking reads.
> AFAICT there is no such thing, in Unix at least.
> For this emulation, it needs to seek to the "current" position.
>
> Gabor
>
> On Thu, Apr 26, 2018 at 7:21 PM, Michael Lawrence
> wrote:
>> The issue is that readLines() tries to seek (for reasons I don't
>> understand) in the non-blocking case, but silently fails for "stdin"
>> since it's a stream. This confused the buffering logic. The fix is to
>> mark "stdin" as unable to seek, but I do wonder why readLines() is
>> seeking in the first place.
>>
>> Anyway, I'll get this into patched ASAP. Thanks for the report.
>>
>> Michael
>>
>>
>> On Wed, Apr 25, 2018 at 5:13 PM, Michael Lawrence wrote:
>>> Probably related to the switch to buffered connections. I will look
>>> into this soon.
>>>
>>> On Wed, Apr 25, 2018 at 2:34 PM, Randy Lai wrote:
It seems that the behavior of readLines() in R 3.5 has changed for
non-blocking pipeline.
Consider the following R script, which reads from STDIN line by line.
```
con <- file("stdin")
open(con, blocking = FALSE)
while (TRUE) {
txt <- readLines(con, 1)
if (length(txt) > 0) {
cat(txt, "\n", file = stdout())
}
Sys.sleep(0.1)
}
close(con)
```
In R 3.4.4, it works as expected.
```
(randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
abc
foo
```
In R 3.5, only the first line is printed
```
(randymbpro)-Desktop$ echo "abc\nfoo" | R --slave -f test.R
abc
```
Is this change expected? If I change `blocking` to `TRUE` above, the
above code would
work. But I need non-blocking connection in my use case of piping buffer
from
another program.
Best,
R 3.5 @ macOS 10.13
Randy
[[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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] embeded R application on Windows prints broken character.
The issue was reported to me for https://github.com/randy3k/rtichoke/issues/50 which is a python program which embeds R and provides a interface to R. With R 3.5, for reason which i don't understand, when I typed `"a"` in the console STDOUT got `"\x02\xff\xfea\x03\xff\xfe"` with the extra escaped characters. I notice that `\x02\xff\xfe` and `\x03\xff\xfe` are encoding related byte marks. A clear solution is to filter the escaped characters, but I want to understand what changes are causing it happens. It didn’t happen for R 3.4. Randy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embeded R application on Windows prints broken character.
> On Apr 26, 2018, at 4:25 PM, Randy Lai wrote: > > The issue was reported to me for https://github.com/randy3k/rtichoke/issues/50 > which is a python program which embeds R and provides a interface to R. > > With R 3.5, for reason which i don't understand, when I typed `"a"` in the > console > STDOUT got `"\x02\xff\xfea\x03\xff\xfe"` with the extra escaped characters. > > I notice that `\x02\xff\xfe` and `\x03\xff\xfe` are encoding related byte > marks. > A clear solution is to filter the escaped characters, but I want to > understand what > changes are causing it happens. It didn’t happen for R 3.4. The maintainer (randy3k, oh that's you) of that python package has apparently fixed it: https://github.com/randy3k/rtichoke/commit/4e29747c47f03381b319665943e290f17fd7914f > Randy > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius Alameda, CA, USA 'Any technology distinguishable from magic is insufficiently advanced.' -Gehm's Corollary to Clarke's Third Law __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
