[Rd] Problem building rmarkdown vignettes with child
Dear Community,
I have an Rmarkdown vignette with optional child documents.
Since all markdown files in the vingette folder are build when
executing R CMD build
I did place the child documents in
/inst/ParametrizedReportChid/
so they are excluded from the build.
I do reference them from the markdown file in the vignette folder by:
```{r referencingChildDocument}
child_docs <- "Grp2Analysis_MissingInOneCondtion.Rmd"
if(!sum(NAinfo$nrProteins > 0) > 0){
child_docs <- "Grp2Analysis_Empty.Rmd"
}
child_docs <- system.file("ParametrizedReportsChild",child_docs,package
= "SRMService")
```
```{r includeMissingInOne, child = child_docs}
```
When running
devtools::clean_vignettes()
devtools::build_vingettes()
devtools::build() # or R CMD build PACKAGE
all works fine. However,
devtools::clean_vignettes()
devtools::build() # or R CMD build PACKAGE
Fails with the diagnostic:
** building package indices
** installing vignettes
‘Grp2Analysis.Rmd’ using ‘UTF-8’
Error in eval(x, envir = envir) : object 'child_docs' not found
Warning in readLines(if (is.character(input2)) { :
cannot open file './child_docs': No such file or directory
Quitting from lines 387-388 (./child_docs)
Error in readLines(if (is.character(input2)) { :
cannot open the connection
ERROR: installing vignettes failed
I did try to use the base::system.file and devtools::system.file
function but both generate the same error.
The package and vignette can be found here:
https://github.com/protviz/SRMService
Have a great day
Best regards
Witek
--
Witold Eryk Wolski
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Poor documentation for "adj" and text()
>
> on Thu, 13 Sep 2018 23:33:41 -0700 writes:
> Hello Core Team, I sent this patch over a year ago. It
> looks like it was sent in response to another user's
> complaint which echoed some of my own observations about
> problems in the documentation for 'text'. Did anyone have
> a chance to look it over?
I see it marked in my box as some (of too many !) thing I had
wanted to look at.
OTOH, R core may not be terribly motivated by e-mail threads
starting with "Poor " notably when that thing has
been in R (and S before that) for decades.
OTOH^2, improving documentation is often a good and helpful
thing and I will look at it now.
Thank you, Frederick, for trying to help making R better!
Martin
> I'd like to get it out of my queue.
> Thanks,
> Frederick
> On Tue, Apr 11, 2017 at 12:01:05PM -0700, frede...@ofb.net
> wrote:
>> Thanks Ulrich for sharing your experience.
>>
>> I'm attaching a patch which tries to address the issues
>> you raised.
>>
>> I agree with you in principle, but I think it makes sense
>> to leave some details under "Details". However, the
>> descriptions in "Arguments" should give enough
>> information that a user can get the function to do
>> something predictable in at least one situation, and I
>> feel this is not the case at present.
>>
>> I tried to fix the wording so that 'adj' and 'offset' are
>> no longer confusing to new users (or to me, every time I
>> forget what they mean).
>>
>> I also fixed the paragraph on rotated text; it is more
>> correct now, at least for X11-cairo.
>>
>> I hope that someone in the Core Team can look this over
>> and apply it.
>>
>> Thank you,
>>
>> Frederick
>>
>> On Tue, Apr 11, 2017 at 09:23:50AM +0200, Ulrich Windl
>> wrote: > Hi!
>> >
>> > (I'd like to be able to access your bugzilla, BTW) >
>> The documentation for parameter "adj" of text() in R
>> 3.3.3 is hard to understand (unless you know what it does
>> already):
>> >
>> > "adj > one or two values in [0, 1] which specify the x
>> (and optionally y) adjustment of the labels. On most
>> devices values outside that interval will also work."
>> >
>> > What is the meaning of the values? I think the
>> description ("adj allows adjustment of the text with
>> respect to (x, y). Values of 0, 0.5, and 1 specify
>> left/bottom, middle and right/top alignment,
>> respectively. The default is for centered text, i.e., adj
>> = c(0.5, NA). Accurate vertical centering needs character
>> metric information on individual characters which is only
>> available on some devices. Vertical alignment is done
>> slightly differently for character strings and for
>> expressions: adj = c(0,0) means to left-justify and to
>> align on the baseline for strings but on the bottom of
>> the bounding box for expressions. This also affects
>> vertical centering: for strings the centering excludes
>> any descenders whereas for expressions it includes
>> them. Using NA for strings centers them, including
>> descenders.") should be moved to the parameter.
>> >
>> > In general I'd suggest to describe the range, meaning
>> and default of every parameter where the parameter is
>> listed. "Details" should only give an overview of the
>> functions.
>> >
>> > Likewise "offset": Will the direction be influenced by
>> "pos"? The description is quite silent on that.
>> >
>> > Documentation should be structured to help the user to
>> find the facts easily without having to read the whole
>> page.
>> >
>> > Regards, > Ulrich Windl
>> >
>> > __ >
>> R-devel@r-project.org mailing list >
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>> --- text.Rd 2016-11-27 18:33:26.541516325 -0800 +++
>> new-text.Rd 2017-04-11 11:48:32.668926075 -0700 @@ -26,16
>> +26,18 @@ If \code{labels} is longer than \code{x} and
>> \code{y}, the coordinates are recycled to the length of
>> \code{labels}.} \item{adj}{one or two values in \eqn{[0,
>> 1]} which specify the x - (and optionally y) adjustment
>> of the labels. On most devices values - outside that
>> interval will also work.} + (and optionally y)
>> justification of the labels, with 0 for + left/bottom, 1
>> for right/top, and 0.5 for centered. + On most devices
>> values + outside \eqn{[0, 1]} will also work. See below.}
>> \item{pos}{a position specifier for the text. If
>> specified this overrides any \code{adj} value given.
>> Values of \code{1}, \code{2}, \code{3} and \code{4},
>> respectively indicate positions below, to the left of,
>> above and to the right of - the specified coordinates.}
>> - \item{offs
Re: [Rd] Problem building rmarkdown vignettes with child
On 14/09/2018 3:22 AM, Witold E Wolski wrote:
Dear Community,
I have an Rmarkdown vignette with optional child documents.
Since all markdown files in the vingette folder are build when
executing R CMD build
I did place the child documents in
/inst/ParametrizedReportChid/
so they are excluded from the build.
I do reference them from the markdown file in the vignette folder by:
```{r referencingChildDocument}
child_docs <- "Grp2Analysis_MissingInOneCondtion.Rmd"
if(!sum(NAinfo$nrProteins > 0) > 0){
child_docs <- "Grp2Analysis_Empty.Rmd"
}
child_docs <- system.file("ParametrizedReportsChild",child_docs,package
= "SRMService")
```
```{r includeMissingInOne, child = child_docs}
```
When running
devtools::clean_vignettes()
devtools::build_vingettes()
devtools::build() # or R CMD build PACKAGE
all works fine. However,
devtools::clean_vignettes()
devtools::build() # or R CMD build PACKAGE
Fails with the diagnostic:
** building package indices
** installing vignettes
‘Grp2Analysis.Rmd’ using ‘UTF-8’
Error in eval(x, envir = envir) : object 'child_docs' not found
This message makes it look as though it is looking for an R object named
child_docs and not finding it.
Warning in readLines(if (is.character(input2)) { :
cannot open file './child_docs': No such file or directory
This message makes it look as though it thinks "child_docs" is the
filename, not a variable holding the filename.
Quitting from lines 387-388 (./child_docs)
This one looks like it's a filename again.
It's a long vignette, and not easy to spot where things are going wrong.
I'd recommend backing up the original, and just cutting things out
until the only thing left is the error. Hopefully then it will be clear
what's wrong.
Duncan Murdoch
Error in readLines(if (is.character(input2)) { :
cannot open the connection
ERROR: installing vignettes failed
I did try to use the base::system.file and devtools::system.file
function but both generate the same error.
The package and vignette can be found here:
https://github.com/protviz/SRMService
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion: use mustWork = TRUE as the default for system.file
Hello all, Currently, the default behavior for system.file() is to return "" for faulty paths. I've found this behavior to be difficult when debugging, since it passes the empty path onto other functions. I initially wrote in errors myself (with code like `if(path == "") stop(“Path not found”)`), but I now use mustWork=TRUE or fs::path_package(), which errors by default. What are the general thoughts on this issue? I would love to see mustWork=TRUE become the default in future versions of R, but I would be happy to hear any counterarguments (or support!) for this suggestion. Cheers, Irene Steves [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug when calling system/system2 (and request for Bugzilla account)
Hi all,
I found some strange behaviour, which I think is a bug. Could someone make an
account for me on Bugzilla or pass on my report?
The problem:
When pressing Ctrl-C when a file is sourced in R, run from Terminal (macOS),
sometimes the entire session is ended right away, while I just want to stop the
script. This is the case when I press Ctrl-C while some functions are running
that don’t catch the interrupt. However, the behaviour is different whether I’m
in a clean session (in which case some time is allowed to pass, so that when
the function returns the script can be interrupted), or whether I have called
base::system() or system2() with timeout other than 0.
Reproducible example:
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)
Observed behaviour:
In a clean session, when I hit Ctrl-C during the execution of match, there is a
delay, and as soon as Sys.sleep() is invoked, the script is interrupted, I get
back my R “>”-prompt (unless options(error=…) is set)
But If I add the line system2("ls", timeout = 5), or something similar, when I
try to break during the first part of the script, my Rsession ends, I get
thrown back to my terminal-prompt.
Desired behaviour:
The best setup would probably be if Ctrl-C would always try to break from the
sourced file, and only if that doesn’t success in n seconds, break the rsession
altogether, ideally with a customizable option. But maybe that’s too hard, so
maybe the most pragmatic would be to have 2 hotkeys: one to break from a
hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
Expected behaviour:
Consistent behaviour for Ctrl-C: either trying to break the script, or end the
session altogether.
Some observations:
* I can still break cleanly during the Sys.sleep(). But for larger scripts,
it is largely a matter of luck if I hit Ctrl-C during the right moment.
* I don’t notice any difference between using system or system2, or any of
the arguments other than timeout provided
* I don’t notice any difference whether the timeout is actually exhausted
or not.
* Later calls to system/system2 don’t change anything (i.e. later calling
system(…, timeout=0) does not revert back to the old situation)
My setup:
R 3.5.1 (Feather Spray), run with –vanilla option
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
macOS High Sierra 10.13.6
Best regards,
Emil Bode
Data-analyst
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
i...@dans.knaw.nl |
dans.knaw.nl
DANS is an institute of the Dutch Academy KNAW and funding
organisation NWO
Re: [Rd] Bug when calling system/system2 (and request for Bugzilla account)
I can't reproduce this. Can you be more precise: exactly where are you
putting the system2 call and exactly where are you sending the
interrupt signal with ^C?
Best,
luke
On Fri, 14 Sep 2018, Emil Bode wrote:
Hi all,
I found some strange behaviour, which I think is a bug. Could someone make an
account for me on Bugzilla or pass on my report?
The problem:
When pressing Ctrl-C when a file is sourced in R, run from Terminal (macOS),
sometimes the entire session is ended right away, while I just want to stop the
script. This is the case when I press Ctrl-C while some functions are running
that don’t catch the interrupt. However, the behaviour is different whether I’m
in a clean session (in which case some time is allowed to pass, so that when
the function returns the script can be interrupted), or whether I have called
base::system() or system2() with timeout other than 0.
Reproducible example:
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)
Observed behaviour:
In a clean session, when I hit Ctrl-C during the execution of match, there is a
delay, and as soon as Sys.sleep() is invoked, the script is interrupted, I get
back my R “>”-prompt (unless options(error=…) is set)
But If I add the line system2("ls", timeout = 5), or something similar, when I
try to break during the first part of the script, my Rsession ends, I get thrown back to
my terminal-prompt.
Desired behaviour:
The best setup would probably be if Ctrl-C would always try to break from the
sourced file, and only if that doesn’t success in n seconds, break the rsession
altogether, ideally with a customizable option. But maybe that’s too hard, so
maybe the most pragmatic would be to have 2 hotkeys: one to break from a
hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
Expected behaviour:
Consistent behaviour for Ctrl-C: either trying to break the script, or end the
session altogether.
Some observations:
* I can still break cleanly during the Sys.sleep(). But for larger scripts,
it is largely a matter of luck if I hit Ctrl-C during the right moment.
* I don’t notice any difference between using system or system2, or any of
the arguments other than timeout provided
* I don’t notice any difference whether the timeout is actually exhausted or
not.
* Later calls to system/system2 don’t change anything (i.e. later calling
system(…, timeout=0) does not revert back to the old situation)
My setup:
R 3.5.1 (Feather Spray), run with –vanilla option
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
macOS High Sierra 10.13.6
Best regards,
Emil Bode
Data-analyst
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
i...@dans.knaw.nl |
dans.knaw.nl
DANS is an institute of the Dutch Academy KNAW and funding
organisation NWO
Re: [Rd] Bug 17432 in readLines with R >= 3.5.0 still a problem
Michael:
I don't see any comments on Bug 17432 (
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) later than June
1, 2018. Would you please supply a link pointing to the followup to this
discussion on bugzilla?
Thanks.
Jen.
> On Thu Sep 13 14:14:46 CEST 2018 Michael Lawrence wrote:
>
> Thanks, I responded to this on bugzilla.
> On Wed, Sep 12, 2018 at 9:04 AM Chris Culnane
> wrote:
> >
> > Bug 17432 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432)
is still a problem when using pipes for IPC.
> >
> > The bug is evident when calling R from another process and trying to
communicate via StdIn. R will buffer the input and not read lines until the
buffer is exceeded or StdIn is closed by the sending process. This prevents
interactive communication between a calling process and a child R process.
> >
> > From a quick look at the source code, it looks like the bug is caused
by only disabling buffering when isatty() returns true for a file
descriptor (connections.c). This fixes the original bug when the script is
run in a terminal, but doesn't help for pipes, which will return false for
isatty().
> >
> > An example R script and python script are provided to demonstrate the
problem:
> >
> > R script (example.r):
> >
> > f <- file("stdin")
> > open(f)
> > while(length(line <- readLines(f,n=1)) > 0) {
> > write(line, stderr())
> > }
> >
> > Python3 script:
> >
> > import sys, os, subprocess
> > process = subprocess.Popen(['Rscript', 'example.r'],
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
> > for line in sys.stdin:
> > process.stdin.write((line + '\n').encode('utf-8'))
> > process.stdin.flush()
> >
> >
> > Expected Behaviour:
> > Run python script, each line entered is echoed back immediately by the
R script - which is what happens on 3.4.4
> >
> > Observed Behaviiour on >=3.5.0 (include devel):
> > The R script does not process lines as they are sent, it only receives
them when StdIn is closed.
> >
> >
> > Best Regards
> >
> > Chris
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug 17432 in readLines with R >= 3.5.0 still a problem
The actual bug corresponding to this thread is:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17470
On Fri, Sep 14, 2018 at 9:22 AM Jennifer Lyon wrote:
>
> Michael:
>
> I don't see any comments on Bug 17432
> (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) later than June
> 1, 2018. Would you please supply a link pointing to the followup to this
> discussion on bugzilla?
>
> Thanks.
>
> Jen.
>
> > On Thu Sep 13 14:14:46 CEST 2018 Michael Lawrence wrote:
> >
> > Thanks, I responded to this on bugzilla.
> > On Wed, Sep 12, 2018 at 9:04 AM Chris Culnane
> > wrote:
> > >
> > > Bug 17432 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) is
> > > still a problem when using pipes for IPC.
> > >
> > > The bug is evident when calling R from another process and trying to
> > > communicate via StdIn. R will buffer the input and not read lines until
> > > the buffer is exceeded or StdIn is closed by the sending process. This
> > > prevents interactive communication between a calling process and a child
> > > R process.
> > >
> > > From a quick look at the source code, it looks like the bug is caused by
> > > only disabling buffering when isatty() returns true for a file descriptor
> > > (connections.c). This fixes the original bug when the script is run in a
> > > terminal, but doesn't help for pipes, which will return false for
> > > isatty().
> > >
> > > An example R script and python script are provided to demonstrate the
> > > problem:
> > >
> > > R script (example.r):
> > >
> > > f <- file("stdin")
> > > open(f)
> > > while(length(line <- readLines(f,n=1)) > 0) {
> > > write(line, stderr())
> > > }
> > >
> > > Python3 script:
> > >
> > > import sys, os, subprocess
> > > process = subprocess.Popen(['Rscript', 'example.r'],
> > > stdin=subprocess.PIPE, stdout=subprocess.PIPE)
> > > for line in sys.stdin:
> > > process.stdin.write((line + '\n').encode('utf-8'))
> > > process.stdin.flush()
> > >
> > >
> > > Expected Behaviour:
> > > Run python script, each line entered is echoed back immediately by the R
> > > script - which is what happens on 3.4.4
> > >
> > > Observed Behaviiour on >=3.5.0 (include devel):
> > > The R script does not process lines as they are sent, it only receives
> > > them when StdIn is closed.
> > >
> > >
> > > Best Regards
> > >
> > > Chris
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug when calling system/system2 (and request for Bugzilla account)
I hope it's not too specific in my setup...
I've tried with system2 added on the first line, so:
Example.R:
system2('ls', timeout=5)
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)
And in terminal/bash:
R --vanilla
source('Example.R')
Send ^C between the messages (Start... until Finished)
Or if you have a more powerful CPU you can increase the samples, the exact code
doesn't matter very much.
As soon as you restart and source again with the system2 call outcommented, the
behaviour is different, there is a pause, and your return to the R-prompt.
Best, Emil
On 14/09/2018, 17:39, "luke-tier...@uiowa.edu" wrote:
I can't reproduce this. Can you be more precise: exactly where are you
putting the system2 call and exactly where are you sending the
interrupt signal with ^C?
Best,
luke
On Fri, 14 Sep 2018, Emil Bode wrote:
> Hi all,
>
> I found some strange behaviour, which I think is a bug. Could someone
make an account for me on Bugzilla or pass on my report?
>
> The problem:
> When pressing Ctrl-C when a file is sourced in R, run from Terminal
(macOS), sometimes the entire session is ended right away, while I just want to
stop the script. This is the case when I press Ctrl-C while some functions are
running that don’t catch the interrupt. However, the behaviour is different
whether I’m in a clean session (in which case some time is allowed to pass, so
that when the function returns the script can be interrupted), or whether I
have called base::system() or system2() with timeout other than 0.
>
> Reproducible example:
> cat('Start non-interruptable functions\n')
> sample_a <- sample(1:1e7)
> sample_b <- sample(1:2e7)
> matching <- match(sample_a, sample_b)
> cat('Finished\n')
> Sys.sleep(10)
>
> Observed behaviour:
> In a clean session, when I hit Ctrl-C during the execution of match,
there is a delay, and as soon as Sys.sleep() is invoked, the script is
interrupted, I get back my R “>”-prompt (unless options(error=…) is set)
> But If I add the line system2("ls", timeout = 5), or something similar,
when I try to break during the first part of the script, my Rsession ends, I
get thrown back to my terminal-prompt.
>
> Desired behaviour:
> The best setup would probably be if Ctrl-C would always try to break from
the sourced file, and only if that doesn’t success in n seconds, break the
rsession altogether, ideally with a customizable option. But maybe that’s too
hard, so maybe the most pragmatic would be to have 2 hotkeys: one to break from
a hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
>
> Expected behaviour:
> Consistent behaviour for Ctrl-C: either trying to break the script, or
end the session altogether.
>
> Some observations:
>
> * I can still break cleanly during the Sys.sleep(). But for larger
scripts, it is largely a matter of luck if I hit Ctrl-C during the right moment.
> * I don’t notice any difference between using system or system2, or
any of the arguments other than timeout provided
> * I don’t notice any difference whether the timeout is actually
exhausted or not.
> * Later calls to system/system2 don’t change anything (i.e. later
calling system(…, timeout=0) does not revert back to the old situation)
>
> My setup:
> R 3.5.1 (Feather Spray), run with –vanilla option
> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
> macOS High Sierra 10.13.6
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.b...@dans.knaw.nl
>
> DANS: Netherlands Institute for Permanent Access to Digital Research
Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
i...@dans.knaw.nl |
dans.knaw.nl
> DANS is an institute of the Dutch Academy KNAW and
funding organisation NWO
Re: [Rd] Bug when calling system/system2 (and request for Bugzilla account)
FWIW I can reproduce on macOS with R 3.5.1. A smaller example:
system2("ls", timeout = 5); x <- sample(1:1E8)
If I try to interrupt R while that sample call is running, R itself is closed.
Best,
Kevin
On Fri, Sep 14, 2018 at 10:53 AM Emil Bode wrote:
>
> I hope it's not too specific in my setup...
> I've tried with system2 added on the first line, so:
>
> Example.R:
> system2('ls', timeout=5)
> cat('Start non-interruptable functions\n')
> sample_a <- sample(1:1e7)
> sample_b <- sample(1:2e7)
> matching <- match(sample_a, sample_b)
> cat('Finished\n')
> Sys.sleep(10)
>
> And in terminal/bash:
> R --vanilla
> source('Example.R')
> Send ^C between the messages (Start... until Finished)
>
> Or if you have a more powerful CPU you can increase the samples, the exact
> code doesn't matter very much.
> As soon as you restart and source again with the system2 call outcommented,
> the behaviour is different, there is a pause, and your return to the R-prompt.
>
> Best, Emil
>
>
>
> On 14/09/2018, 17:39, "luke-tier...@uiowa.edu"
> wrote:
>
> I can't reproduce this. Can you be more precise: exactly where are you
> putting the system2 call and exactly where are you sending the
> interrupt signal with ^C?
>
> Best,
>
> luke
>
> On Fri, 14 Sep 2018, Emil Bode wrote:
>
> > Hi all,
> >
> > I found some strange behaviour, which I think is a bug. Could someone
> make an account for me on Bugzilla or pass on my report?
> >
> > The problem:
> > When pressing Ctrl-C when a file is sourced in R, run from Terminal
> (macOS), sometimes the entire session is ended right away, while I just want
> to stop the script. This is the case when I press Ctrl-C while some functions
> are running that don’t catch the interrupt. However, the behaviour is
> different whether I’m in a clean session (in which case some time is allowed
> to pass, so that when the function returns the script can be interrupted), or
> whether I have called base::system() or system2() with timeout other than 0.
> >
> > Reproducible example:
> > cat('Start non-interruptable functions\n')
> > sample_a <- sample(1:1e7)
> > sample_b <- sample(1:2e7)
> > matching <- match(sample_a, sample_b)
> > cat('Finished\n')
> > Sys.sleep(10)
> >
> > Observed behaviour:
> > In a clean session, when I hit Ctrl-C during the execution of match,
> there is a delay, and as soon as Sys.sleep() is invoked, the script is
> interrupted, I get back my R “>”-prompt (unless options(error=…) is set)
> > But If I add the line system2("ls", timeout = 5), or something similar,
> when I try to break during the first part of the script, my Rsession ends, I
> get thrown back to my terminal-prompt.
> >
> > Desired behaviour:
> > The best setup would probably be if Ctrl-C would always try to break
> from the sourced file, and only if that doesn’t success in n seconds, break
> the rsession altogether, ideally with a customizable option. But maybe that’s
> too hard, so maybe the most pragmatic would be to have 2 hotkeys: one to
> break from a hanging/broken rsession, and one to gently try to break from a
> script. But at least I think it should be:
> >
> > Expected behaviour:
> > Consistent behaviour for Ctrl-C: either trying to break the script, or
> end the session altogether.
> >
> > Some observations:
> >
> > * I can still break cleanly during the Sys.sleep(). But for larger
> scripts, it is largely a matter of luck if I hit Ctrl-C during the right
> moment.
> > * I don’t notice any difference between using system or system2, or
> any of the arguments other than timeout provided
> > * I don’t notice any difference whether the timeout is actually
> exhausted or not.
> > * Later calls to system/system2 don’t change anything (i.e. later
> calling system(…, timeout=0) does not revert back to the old situation)
> >
> > My setup:
> > R 3.5.1 (Feather Spray), run with –vanilla option
> > GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
> > macOS High Sierra 10.13.6
> >
> > Best regards,
> > Emil Bode
> >
> > Data-analyst
> >
> > +31 6 43 83 89 33
> > emil.b...@dans.knaw.nl
> >
> > DANS: Netherlands Institute for Permanent Access to Digital Research
> Resources
> > Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
> i...@dans.knaw.nl |
> dans.knaw.nl
> > DANS is an institute of the Dutch Academy KNAW and
> funding organisation NWO
Re: [Rd] Bug when calling system/system2 (and request for Bugzilla account)
Thanks to you both -- I see it now on Ubuntu. A typo in the code for
restoring the SIGINT handler in the timeout cleanup was installing the
wrong handler. Fixed in R-devel and R-patched.
Best,
luke
On Fri, 14 Sep 2018, Kevin Ushey wrote:
FWIW I can reproduce on macOS with R 3.5.1. A smaller example:
system2("ls", timeout = 5); x <- sample(1:1E8)
If I try to interrupt R while that sample call is running, R itself is closed.
Best,
Kevin
On Fri, Sep 14, 2018 at 10:53 AM Emil Bode wrote:
I hope it's not too specific in my setup...
I've tried with system2 added on the first line, so:
Example.R:
system2('ls', timeout=5)
cat('Start non-interruptable functions\n')
sample_a <- sample(1:1e7)
sample_b <- sample(1:2e7)
matching <- match(sample_a, sample_b)
cat('Finished\n')
Sys.sleep(10)
And in terminal/bash:
R --vanilla
source('Example.R')
Send ^C between the messages (Start... until Finished)
Or if you have a more powerful CPU you can increase the samples, the exact code
doesn't matter very much.
As soon as you restart and source again with the system2 call outcommented, the
behaviour is different, there is a pause, and your return to the R-prompt.
Best, Emil
On 14/09/2018, 17:39, "luke-tier...@uiowa.edu" wrote:
I can't reproduce this. Can you be more precise: exactly where are you
putting the system2 call and exactly where are you sending the
interrupt signal with ^C?
Best,
luke
On Fri, 14 Sep 2018, Emil Bode wrote:
> Hi all,
>
> I found some strange behaviour, which I think is a bug. Could someone make
an account for me on Bugzilla or pass on my report?
>
> The problem:
> When pressing Ctrl-C when a file is sourced in R, run from Terminal
(macOS), sometimes the entire session is ended right away, while I just want to
stop the script. This is the case when I press Ctrl-C while some functions are
running that don’t catch the interrupt. However, the behaviour is different
whether I’m in a clean session (in which case some time is allowed to pass, so
that when the function returns the script can be interrupted), or whether I have
called base::system() or system2() with timeout other than 0.
>
> Reproducible example:
> cat('Start non-interruptable functions\n')
> sample_a <- sample(1:1e7)
> sample_b <- sample(1:2e7)
> matching <- match(sample_a, sample_b)
> cat('Finished\n')
> Sys.sleep(10)
>
> Observed behaviour:
> In a clean session, when I hit Ctrl-C during the execution of match, there is
a delay, and as soon as Sys.sleep() is invoked, the script is interrupted, I get back
my R “>”-prompt (unless options(error=…) is set)
> But If I add the line system2("ls", timeout = 5), or something similar,
when I try to break during the first part of the script, my Rsession ends, I get thrown back
to my terminal-prompt.
>
> Desired behaviour:
> The best setup would probably be if Ctrl-C would always try to break from
the sourced file, and only if that doesn’t success in n seconds, break the
rsession altogether, ideally with a customizable option. But maybe that’s too
hard, so maybe the most pragmatic would be to have 2 hotkeys: one to break from a
hanging/broken rsession, and one to gently try to break from a script. But at
least I think it should be:
>
> Expected behaviour:
> Consistent behaviour for Ctrl-C: either trying to break the script, or end
the session altogether.
>
> Some observations:
>
> * I can still break cleanly during the Sys.sleep(). But for larger
scripts, it is largely a matter of luck if I hit Ctrl-C during the right moment.
> * I don’t notice any difference between using system or system2, or any
of the arguments other than timeout provided
> * I don’t notice any difference whether the timeout is actually
exhausted or not.
> * Later calls to system/system2 don’t change anything (i.e. later
calling system(…, timeout=0) does not revert back to the old situation)
>
> My setup:
> R 3.5.1 (Feather Spray), run with –vanilla option
> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
> macOS High Sierra 10.13.6
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.b...@dans.knaw.nl
>
> DANS: Netherlands Institute for Permanent Access to Digital Research
Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 |
i...@dans.knaw.nl |
dans.knaw.nl
> DANS is an institute of the Dutch Academy KNAW and funding
organisation NWO
