Re: [Rd] inappropriate warning in latticeExtra

2019-12-06 Thread Deepayan Sarkar
On Fri 6 Dec, 2019, 6:46 PM Richard M. Heiberger,  wrote:

> This problem is still present in
>

Yes, my bad. I'm traveling till Monday, but will get an update out as soon
as possible after I'm back.

-Deepayan


> > version
>_
> platform   x86_64-w64-mingw32
> arch   x86_64
> os mingw32
> system x86_64, mingw32
> status Under development (unstable)
> major  4
> minor  0.0
> year   2019
> month  12
> day03
> svn rev77513
> language   R
> version.string R Under development (unstable) (2019-12-03 r77513)
> nickname   Unsuffered Consequences
>
> Rich
>
>
>
> On Sat, Jun 15, 2019 at 3:13 AM Deepayan Sarkar
>  wrote:
> >
> > On Fri, Jun 14, 2019 at 6:42 PM Richard M. Heiberger 
> wrote:
> > >
> > > This is still not repaired in
> > >  R version 3.6.0 Patched (2019-05-17 r76528)
> > > > library(latticeExtra)
> > > >  a <- xyplot(1 ~ 1)
> > > > c(a,a)
> > > Warning message:
> > > In formals(fun) : argument is not a function
> > >
> > > Can we have it in R-3.6.1 that Peter just announced?
> >
> > Sorry I have been neglecting this (and some lattice bugs as well). I
> > should get time to work on this after mid-July.
> >
> > -Deepayan
> >
> > >
> > > Rich
> > >
> > > On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> > >  wrote:
> > > >
> > > > On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger <
> r...@temple.edu> wrote:
> > > > > The warning message in the last line of this email is incorrect.
> > > > > This is behavior which Duncan Murdoch labeled a bug in
> > > > >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> > > >
> > > > Yes, sorry, this has been fixed in the r-forge sources for a while
> > > > now, but I haven't had the time to finish up some other fixes and
> push
> > > > an update to CRAN.
> > > >
> > > > Hopefully over the summer break.
> > > >
> > > > Regards,
> > > > -Deepayan
> > > >
> > > >
> > > > > This is a fresh install of R-devel (2018-03-21 r74436)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered
> Consequences"
> > > > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > > > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > > > >
> > > > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > > > You are welcome to redistribute it under certain conditions.
> > > > > Type 'license()' or 'licence()' for distribution details.
> > > > >
> > > > >   Natural language support but running in an English locale
> > > > >
> > > > > R is a collaborative project with many contributors.
> > > > > Type 'contributors()' for more information and
> > > > > 'citation()' on how to cite R or R packages in publications.
> > > > >
> > > > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > > > 'help.start()' for an HTML browser interface to help.
> > > > > Type 'q()' to quit R.
> > > > >
> > > > >> library(latticeExtra)
> > > > > Error in library(latticeExtra) :
> > > > >   there is no package called ‘latticeExtra’
> > > > >> install.packages("latticeExtra")
> > > > > Warning in install.packages("latticeExtra") :
> > > > >   'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > > > > --- Please select a CRAN mirror for use in this session ---
> > > > > also installing the dependency ‘RColorBrewer’
> > > > >
> > > > > Warning: unable to access index for repository
> > > > > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> > > > >   cannot open URL
> > > > > '
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > > > > trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > > > > Content type 'application/zip' length 55444 bytes (54 KB)
> > > > > downloaded 54 KB
> > > > >
> > > > > trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > > > > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > > > > downloaded 2.1 MB
> > > > >
> > > > > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > > > > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> > > > >
> > > > > The downloaded binary packages are in
> > > > >
>  
> C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> > > > >> library(latticeExtra)
> > > > > Loading required package: lattice
> > > > > Loading required package: RColorBrewer
> > > > >> a <- xyplot(1 ~ 1)
> > > > >> c(a,a)
> > > > > Warning message:
> > > > > In formals(fun) : argument is not a function
> > > > >>
> > > > >
> > > > > __
> > > > > R-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] long vector support

2019-12-06 Thread Will L
All,


At first glance, a recent commit to R-devel (
https://github.com/wch/r-source/commit/2c182014ecc8c2407a89092c9162d86046bd18da)
appears to be related to long vector support. But as Henrik Bengtsson
points out at
https://github.com/HenrikBengtsson/Wishlist-for-R/issues/97#issuecomment-562659134,
writeBin() still prohibits long vectors. Are there any plans to add long
vector support to R 4.0.0?

x <- raw(2^31)
writeBin(x, con = nullfile())
# Error in writeBin(x, con = nullfile()) :
#  long vectors not supported yet: connections.c:4430

x <- raw(2^31)
con <- rawConnection(raw(0L), "w")
writeBin(raw(2^31), con = con)
# Error in writeBin(raw(2^31), con = con) :
#  long vectors not supported yet: connections.c:4430


Will

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] inappropriate warning in latticeExtra

2019-12-06 Thread Richard M. Heiberger
This problem is still present in

> version
   _
platform   x86_64-w64-mingw32
arch   x86_64
os mingw32
system x86_64, mingw32
status Under development (unstable)
major  4
minor  0.0
year   2019
month  12
day03
svn rev77513
language   R
version.string R Under development (unstable) (2019-12-03 r77513)
nickname   Unsuffered Consequences

Rich



On Sat, Jun 15, 2019 at 3:13 AM Deepayan Sarkar
 wrote:
>
> On Fri, Jun 14, 2019 at 6:42 PM Richard M. Heiberger  wrote:
> >
> > This is still not repaired in
> >  R version 3.6.0 Patched (2019-05-17 r76528)
> > > library(latticeExtra)
> > >  a <- xyplot(1 ~ 1)
> > > c(a,a)
> > Warning message:
> > In formals(fun) : argument is not a function
> >
> > Can we have it in R-3.6.1 that Peter just announced?
>
> Sorry I have been neglecting this (and some lattice bugs as well). I
> should get time to work on this after mid-July.
>
> -Deepayan
>
> >
> > Rich
> >
> > On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> >  wrote:
> > >
> > > On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger  
> > > wrote:
> > > > The warning message in the last line of this email is incorrect.
> > > > This is behavior which Duncan Murdoch labeled a bug in
> > > >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> > >
> > > Yes, sorry, this has been fixed in the r-forge sources for a while
> > > now, but I haven't had the time to finish up some other fixes and push
> > > an update to CRAN.
> > >
> > > Hopefully over the summer break.
> > >
> > > Regards,
> > > -Deepayan
> > >
> > >
> > > > This is a fresh install of R-devel (2018-03-21 r74436)
> > > >
> > > >
> > > >
> > > >
> > > > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered 
> > > > Consequences"
> > > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > > >
> > > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > > You are welcome to redistribute it under certain conditions.
> > > > Type 'license()' or 'licence()' for distribution details.
> > > >
> > > >   Natural language support but running in an English locale
> > > >
> > > > R is a collaborative project with many contributors.
> > > > Type 'contributors()' for more information and
> > > > 'citation()' on how to cite R or R packages in publications.
> > > >
> > > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > > 'help.start()' for an HTML browser interface to help.
> > > > Type 'q()' to quit R.
> > > >
> > > >> library(latticeExtra)
> > > > Error in library(latticeExtra) :
> > > >   there is no package called ‘latticeExtra’
> > > >> install.packages("latticeExtra")
> > > > Warning in install.packages("latticeExtra") :
> > > >   'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > > > --- Please select a CRAN mirror for use in this session ---
> > > > also installing the dependency ‘RColorBrewer’
> > > >
> > > > Warning: unable to access index for repository
> > > > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> > > >   cannot open URL
> > > > 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > > > trying URL 
> > > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > > > Content type 'application/zip' length 55444 bytes (54 KB)
> > > > downloaded 54 KB
> > > >
> > > > trying URL 
> > > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > > > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > > > downloaded 2.1 MB
> > > >
> > > > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > > > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> > > >
> > > > The downloaded binary packages are in
> > > > 
> > > > C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> > > >> library(latticeExtra)
> > > > Loading required package: lattice
> > > > Loading required package: RColorBrewer
> > > >> a <- xyplot(1 ~ 1)
> > > >> c(a,a)
> > > > Warning message:
> > > > In formals(fun) : argument is not a function
> > > >>
> > > >
> > > > __
> > > > 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] Maybe bug? Using non-integer frequencies in stats::ts

2019-12-06 Thread Duncan Murdoch

To R-devel:

I've sent this to Johann privately already; just in case anyone else is 
interested in this issue, here's what I wrote:


Just started looking into it, and discovered this paragraph in ?ts:

"The value of argument frequency is used when the series is sampled an
integral number of times in each unit time interval. For example, one
could use a value of 7 for frequency when the data are sampled daily,
and the natural time period is a week, or 12 when the data are sampled
monthly and the natural time period is a year. Values of 4 and 12 are
assumed in (e.g.) print methods to imply a quarterly and monthly series
respectively."

That says that frequency will be a positive integer, so frequency=0.2
was not intended to be covered, and I'd say it's not exactly a bug that
it doesn't work.  (It might be called a bug that there's no error message.)

On the other hand, it comes close to working, and it seems like allowing
frequency=0.2 would be a useful addition.  I'm going to keep looking,
and see how hard it would be to get this to work properly.  If it 
doesn't break other things, I may submit this as an enhancement.


Duncan Murdoch


On 06/12/2019 10:00 a.m., Johann R. Kleinbub wrote:

Thank you for the quick follow up, Duncan.
Unfortunately extend=TRUE is called internally in various instances such as
when replacing parts of the time-series with  window<-.ts
Consider the following examples of time series with ugly values:
x = 1:22
foo = ts(x, start = 1.5, end = 106.5, frequency = 0.2) # a ts of 525 cycles
bar = ts(x, start = 2.5, end = 107.5, frequency = 0.2) # a ts of 525 cycles
starting 5 cycles later than foo
qux = ts(x, start = 2.5, end = 102.5, frequency = 0.2) # a ts of 500 cycles
starting 5 cycles later than foo

# extraction works fine
window(foo, start = 20, end = 30)  # works fine
window(bar, start = 20, end = 30)  # works fine
window(qux, start = 20, end = 30)  # works fine

# assignment fails in different ways for bar and qux
window(foo, start = 20, end = 30) <- NA  # works fine
window(bar, start = 20, end = 30) <- NA  # ERROR: "invalid time series
parameters specified"
window(qux, start = 20, end = 30) <- NA  # ERROR: "times to be replaced do
not match"

If extraction works fine, there's no reason why replacing the values should
fail.
I don't have an account on bugs.r-project.org yet. I'd be available to do
the report if I'm assigned one.
Best,
Johann

On Thu, 5 Dec 2019 at 17:46, Duncan Murdoch 
wrote:


On 05/12/2019 11:00 a.m., Johann R. Kleinbub wrote:

It's been three months without an answer, is it ok to thread bump?
Would someone provide a pointer?


I agree it's a bug, and agree with your analysis.  You should report it
on bugs.r-project.org.  (If you don't have an account there, let us
know, and either someone will give you one, or someone will report it
for you.)

As a workaround, I don't see it happening with extend=FALSE, but of
course that might not suit your needs in general.

Duncan Murdoch





Thank you for your consideration,
Johann


On Mon, 16 Sep 2019 at 15:53, Johann R. Kleinbub <

johann.klein...@gmail.com>

wrote:


I am developing a package to analyse physiological time-series and I

thought that the most reliable and robust solution was to base it on the
native stats::ts class. In my domain it is common to express series
frequencies as samples-per-second. So ts(..., frequency=10) would mean a
signal sampled 10 times every second, and ts(..., frequency = 1) a signal
sampled every second. Following this logic, a few slower signals are
sampled every 5 seconds (or more), resulting in a frequency of e.g. 0.2

Nowhere in the documentation is stated that the frequency must be an

integer value, but using fractional values gives inconsistent results.

For instance, in this example, foo and bar are identical, just with

start-end values shifted by 1. Yet when extracting an arbitrary window,

the

'bar' series gives error.


x = 1:22
foo = ts(x, start = 1.5, end = 106.5, frequency = 0.2)
bar = ts(x, start = 2.5, end = 107.5, frequency = 0.2)

window(foo, start = 20, end = 30, extend=TRUE)

# Time Series:
# Start = 20
# End = 25
# Frequency = 0.2
# [1] 5 6

window(bar, start = 20, end = 30, extend=TRUE)

# Error in attr(y, "tsp") <- c(ystart, yend, xfreq) :
#   invalid time series parameters specified

The reason is in the rounding procedures for ystart and yend at the end

of the stats::window function. For the 'foo' series the ystart and yend
values are calculated as: c(20, 25), whereas for the 'bar' series, they
become c(20, 30) although the window should be of the very same size in
both cases. (A further discussion on the example is at:
https://stackoverflow.com/questions/57928054 )

Should I report a bug or am I misunderstanding something?

--
Johann R. Kleinbub, PhD
University of Padova
FISPPA Dep. - Section of Applied Psychology
Cell: +39 3495986373




--
Johann R. Kleinbub, PhD
University of Padova
FISPPA Dep. - Section of Applied Psychology
Cell: +39 3495986373

Re: [Rd] Error in close.connection(p) : ignoring SIGPIPE signal

2019-12-06 Thread William Dunlap via R-devel
You may be running out of file descriptors because the pipe objects are not
getting garbage collected often enough.  Adding the line
   if (cnt %% 100 == 0) { cat(cnt, "\n"); gc() }
to your loop  lets it continue indefinitely.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Dec 6, 2019 at 4:29 AM Benjamin Tyner  wrote:

> Andreas,
>
> How right you are! Still, I find it curious that in the context of the
> while(TRUE) loop, I am allowed to do this 653 times, with failure on the
> 654th attempt. Perhaps there is something asynchronous going on? If I
> eliminate the looping, it does indeed fail (as expected) on the first
> attempt to close the pipe.
>
> Regards
>
> Ben
>
> On 12/6/19 2:04 AM, Andreas Kersting wrote:
> > Hi Benjamin,
> >
> > you cannot pipe to echo, since it does not read from stdin.
> >
> > echo just echos is first arg, i.e. echo /dev/stdin > /dev/null will echo
> the string "/dev/stdin"to /dev/stdout, which is redirected to /dev/null.
> >
> > Try
> >
> > p <- pipe("cat > /dev/null", open = "w")
> >
> > instead.
> >
> > Regards,
> > Andreas
> >
> > 2019-12-06 02:46 GMT+01:00 Benjamin Tyner:
> >> Not sure if this is a bug, so posting here first. If I run:
> >> cnt <- 0L
> >> while (TRUE) {
> >> cnt <- cnt + 1L
> >> p <- pipe("echo /dev/stdin > /dev/null", open = "w")
> >> writeLines("foobar", p)
> >> tryCatch(close(p), error = function(e) { print(cnt); stop(e)})
> >> }
> >>
> >> then once cnt gets to around 650, it fails with:
> >>
> >> [1] 654
> >> Error in close.connection(p) : ignoring SIGPIPE signal
> >>
> >> Should I not be using pipe() in this way? Here is my sessionInfo()
> >>
> >> R version 3.6.0 (2019-04-26)
> >> Platform: x86_64-pc-linux-gnu (64-bit)
> >> Running under: Ubuntu 18.04.3 LTS
> >>
> >> Matrix products: default
> >> BLAS:   /home/btyner/R360/lib64/R/lib/libRblas.so
> >> LAPACK: /home/btyner/R360/lib64/R/lib/libRlapack.so
> >>
> >> locale:
> >>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> >>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> >>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> >>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> >>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> >> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >>
> >> attached base packages:
> >> [1] stats graphics  grDevices utils datasets  methods base
> >>
> >> loaded via a namespace (and not attached):
> >> [1] compiler_3.6.0
> >>
> >> Regards,
> >> Ben
> >>
> >> __
> >> 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
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Maybe bug? Using non-integer frequencies in stats::ts

2019-12-06 Thread Johann R. Kleinbub
Thank you for the quick follow up, Duncan.
Unfortunately extend=TRUE is called internally in various instances such as
when replacing parts of the time-series with  window<-.ts
Consider the following examples of time series with ugly values:
x = 1:22
foo = ts(x, start = 1.5, end = 106.5, frequency = 0.2) # a ts of 525 cycles
bar = ts(x, start = 2.5, end = 107.5, frequency = 0.2) # a ts of 525 cycles
starting 5 cycles later than foo
qux = ts(x, start = 2.5, end = 102.5, frequency = 0.2) # a ts of 500 cycles
starting 5 cycles later than foo

# extraction works fine
window(foo, start = 20, end = 30)  # works fine
window(bar, start = 20, end = 30)  # works fine
window(qux, start = 20, end = 30)  # works fine

# assignment fails in different ways for bar and qux
window(foo, start = 20, end = 30) <- NA  # works fine
window(bar, start = 20, end = 30) <- NA  # ERROR: "invalid time series
parameters specified"
window(qux, start = 20, end = 30) <- NA  # ERROR: "times to be replaced do
not match"

If extraction works fine, there's no reason why replacing the values should
fail.
I don't have an account on bugs.r-project.org yet. I'd be available to do
the report if I'm assigned one.
Best,
Johann

On Thu, 5 Dec 2019 at 17:46, Duncan Murdoch 
wrote:

> On 05/12/2019 11:00 a.m., Johann R. Kleinbub wrote:
> > It's been three months without an answer, is it ok to thread bump?
> > Would someone provide a pointer?
>
> I agree it's a bug, and agree with your analysis.  You should report it
> on bugs.r-project.org.  (If you don't have an account there, let us
> know, and either someone will give you one, or someone will report it
> for you.)
>
> As a workaround, I don't see it happening with extend=FALSE, but of
> course that might not suit your needs in general.
>
> Duncan Murdoch
>
>
>
> >
> > Thank you for your consideration,
> > Johann
> >
> >
> > On Mon, 16 Sep 2019 at 15:53, Johann R. Kleinbub <
> johann.klein...@gmail.com>
> > wrote:
> >>
> >> I am developing a package to analyse physiological time-series and I
> > thought that the most reliable and robust solution was to base it on the
> > native stats::ts class. In my domain it is common to express series
> > frequencies as samples-per-second. So ts(..., frequency=10) would mean a
> > signal sampled 10 times every second, and ts(..., frequency = 1) a signal
> > sampled every second. Following this logic, a few slower signals are
> > sampled every 5 seconds (or more), resulting in a frequency of e.g. 0.2
> >> Nowhere in the documentation is stated that the frequency must be an
> > integer value, but using fractional values gives inconsistent results.
> >> For instance, in this example, foo and bar are identical, just with
> > start-end values shifted by 1. Yet when extracting an arbitrary window,
> the
> > 'bar' series gives error.
> >>
> >> x = 1:22
> >> foo = ts(x, start = 1.5, end = 106.5, frequency = 0.2)
> >> bar = ts(x, start = 2.5, end = 107.5, frequency = 0.2)
> >>
> >> window(foo, start = 20, end = 30, extend=TRUE)
> >>
> >> # Time Series:
> >> # Start = 20
> >> # End = 25
> >> # Frequency = 0.2
> >> # [1] 5 6
> >>
> >> window(bar, start = 20, end = 30, extend=TRUE)
> >>
> >> # Error in attr(y, "tsp") <- c(ystart, yend, xfreq) :
> >> #   invalid time series parameters specified
> >>
> >> The reason is in the rounding procedures for ystart and yend at the end
> > of the stats::window function. For the 'foo' series the ystart and yend
> > values are calculated as: c(20, 25), whereas for the 'bar' series, they
> > become c(20, 30) although the window should be of the very same size in
> > both cases. (A further discussion on the example is at:
> > https://stackoverflow.com/questions/57928054 )
> >> Should I report a bug or am I misunderstanding something?
> >>
> >> --
> >> Johann R. Kleinbub, PhD
> >> University of Padova
> >> FISPPA Dep. - Section of Applied Psychology
> >> Cell: +39 3495986373
> >
> >
> >
> > --
> > Johann R. Kleinbub, PhD
> > University of Padova
> > FISPPA Dep. - Section of Applied Psychology
> > Cell: +39 3495986373
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>

-- 
Johann R. Kleinbub, PhD
University of Padova
FISPPA Dep. - Section of Applied Psychology
Cell: +39 3495986373

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Error in close.connection(p) : ignoring SIGPIPE signal

2019-12-06 Thread Benjamin Tyner

Andreas,

How right you are! Still, I find it curious that in the context of the 
while(TRUE) loop, I am allowed to do this 653 times, with failure on the 
654th attempt. Perhaps there is something asynchronous going on? If I 
eliminate the looping, it does indeed fail (as expected) on the first 
attempt to close the pipe.


Regards

Ben

On 12/6/19 2:04 AM, Andreas Kersting wrote:

Hi Benjamin,

you cannot pipe to echo, since it does not read from stdin.

echo just echos is first arg, i.e. echo /dev/stdin > /dev/null will echo the string 
"/dev/stdin"to /dev/stdout, which is redirected to /dev/null.

Try

p <- pipe("cat > /dev/null", open = "w")

instead.

Regards,
Andreas

2019-12-06 02:46 GMT+01:00 Benjamin Tyner:

Not sure if this is a bug, so posting here first. If I run:
    cnt <- 0L
    while (TRUE) {
        cnt <- cnt + 1L
        p <- pipe("echo /dev/stdin > /dev/null", open = "w")
        writeLines("foobar", p)
        tryCatch(close(p), error = function(e) { print(cnt); stop(e)})
    }

then once cnt gets to around 650, it fails with:

    [1] 654
    Error in close.connection(p) : ignoring SIGPIPE signal

Should I not be using pipe() in this way? Here is my sessionInfo()

    R version 3.6.0 (2019-04-26)
    Platform: x86_64-pc-linux-gnu (64-bit)
    Running under: Ubuntu 18.04.3 LTS

    Matrix products: default
    BLAS:   /home/btyner/R360/lib64/R/lib/libRblas.so
    LAPACK: /home/btyner/R360/lib64/R/lib/libRlapack.so

    locale:
     [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
     [3] LC_TIME=en_US.UTF-8    LC_COLLATE=en_US.UTF-8
     [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
     [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
     [9] LC_ADDRESS=C   LC_TELEPHONE=C
    [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

    attached base packages:
    [1] stats graphics  grDevices utils datasets  methods base

    loaded via a namespace (and not attached):
    [1] compiler_3.6.0

Regards,
Ben

__
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