Re: [Rd] Custom per-package options passed down via library() ?
Dear Brian, On 20 February 2007 at 07:46, Prof Brian Ripley wrote: | Some packages have their own option-like mechanism, e.g. sm. | Others use environment variables for this purpose. | And there are userhooks for .First.lib, .onLoad and .onAttach that could | be exploited. Ah, now I see setHook() et al. Interesting, thanks. Won't help in my case -- I need to load a library without triggering some code branches, eg inits of compiled code. I may just have to split my library, or do something else. | In the Hmisc case, you are talking about messages, I believe. You can | handle those via message classes. The latter is not as easy as I would | like (and is currently under discussion), but in this particular case the | message class 'packageStartupMessage' of R >= 2.5.0 seems to be what is | wanted. | | library() does not have a ... argument, so you cannot do what your subject | line suggests. Since library() is scheduled to be replaced by use() | sometime Real Soon Now, it is not being enhanced but I think this is part | of the goals for use(). Interesting too -- that should be Real Useful Real Soon Now. Thanks, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
On Tue, Feb 20, 2007 at 07:35:51AM +, Prof Brian Ripley wrote: > Since you have not told us what 'the documents' are (and only vaguely > named one), do you not think your own documentation is inadequate? I mean the command description produced by ?tryCatch. > > There are documents about the condition system on developer.r-project.org: > please consult them. > OK, though I would hope the user level documentation would suffice. > I quess 'ctl-C' is your private abbreviation for 'control C' (and not a > type of cancer): that generates an interrrupt in most (but not all) R > ports. Where it does, you can set up interrupt handlers (as the help page > said) > My P.S. concerned whether the code that was interrupted could continue from the point of interruption. As far as I can tell from ?tryCatch there is not, > > On Mon, 19 Feb 2007, Ross Boylan wrote: > > >I'm confused by the page documenting tryCatch and friends. > > > >I think it describes 3 separate mechanisms: tryCatch (in which control > >returns to the invoking tryCatch), withCallHandlers (in which control > >goes up to the calling handler/s but then continues from the point at > >which signalCondition() was invoked), and withRestarts (I can't tell > >where control ends up). > > > >For tryCatch the docs say the arguments ... provide handlers, and that > >these are matched to the condition. It appears that matching works by > >providing entries in ... as named arguments, and the handler matches > >if the name is one of the classes of the condition. Is that right? I > >don't see the matching rule explicitly stated. And then the handler > >itself is a single argument function, where the argument is the > >condition? > > > >My reading is that if some code executes signalCondition and it is > >running inside a tryCatch, control will not return to the line after > >the signalCondition. Whereas, if the context is withCallHandlers, > >the call to signalCondition does return (with a NULL) and execution > >continues. That seems odd; do I have it right? > > > >Also, the documents don't explicitly say that the abstract subclasses > >of 'error' and 'warning' are subclasses of 'condition', though that > >seems to be implied and true. > > > >It appears that for tryCatch only the first matching handler is > >executed, while for withCallHandlers all matching handlers are > >executed. > > > >And, finally, with restarts there is again the issue of how the name > >in the name=function form gets matched to the condition, and the more > >basic question of what happens. My guess is that control stays with > >the handler, but then this mechanism seems very similar to tryCatch > >(with the addition of being able to pass extra arguments to the > >handler and maybe a more flexible handler specification). > > > >Can anyone clarify any of this? > > > >P.S. Is there any mechanism that would allow one to trap an interrupt, > >like a ctl-C, so that if the user hit ctl-C some state would be > >changed but execution would then continue where it was? I have in > >mind the ctl-C handler setting a "time to finish up" flag which the > >maini code checks from time to time. > > > >Thanks. > > > >Ross Boylan > > > >__ > >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] RODBC problems with unixodbc
Hi,
I noticed that if a column is named "end" in a data frame (table.df
below), it leads to errors when trying to sqlSave()'it to a postgresql
connection:
---<---cut here---start-->---
con <- odbcConnect("PostgreSQL-DB", uid="user", pwd="password",
case="postgresql")
R> sqlSave(con, table.df)
Error in sqlSave(con, table.df) :
[RODBC] ERROR: Could not SQLExecDirect
42601 7 [unixODBC]Error while executing the query;
ERROR: syntax error at or near "end" at character 140
---<---cut here---end>---
If I rename the column to something else (e.g. "ending"), this proceeds
without problems. What could the problem be here? Thanks.
Cheers,
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RODBC problems with unixodbc
On Tuesday 20 February 2007 13:51, Sebastian P. Luque wrote:
> Hi,
>
> I noticed that if a column is named "end" in a data frame (table.df
> below), it leads to errors when trying to sqlSave()'it to a postgresql
> connection:
>
>
> ---<---cut here---start-->---
> con <- odbcConnect("PostgreSQL-DB", uid="user", pwd="password",
>case="postgresql")
> R> sqlSave(con, table.df)
> Error in sqlSave(con, table.df) :
> [RODBC] ERROR: Could not SQLExecDirect
> 42601 7 [unixODBC]Error while executing the query;
> ERROR: syntax error at or near "end" at character 140
> ---<---cut here---end>---
>
>
> If I rename the column to something else (e.g. "ending"), this proceeds
> without problems. What could the problem be here? Thanks.
"end" is a reserved word in postgresql. See here:
http://www.postgresql.org/docs/8.2/static/sql-keywords-appendix.html
This doesn't have anything to do with RODBC or unixODBC, I don't think.
Sean
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal to allow just transcript files (output only) in the 'tests' directory
Currently, as far as I can see, both input and output fles must be supplied in the 'tests' directory (the input in a '.R' file, and the output in a corresponding '.Rout.save' file.) Often, the '.R' file is redundant, as it could be reconstructed by simply stripping the commands out of the '.Rout.save' file. E.g., the command $ sed -n -e 's/^[>+] //p' ./src/library/stats/tests/nls.Rout.save produces the same R commands as in ./src/library/stats/tests/nls.R If I've missed something, and this is already supported, my apologies, & please let me know. If indeed this facility is not present, would anyone from the R core group consider an addition to allow '.Rt' (or '.Rt.save') files in the 'tests' directory? These would by just like the '.Rout.save' files, except that no corresponding '.R' file would be required -- the R commands would be extracted from them by simple line processing. Of course, '.R' and '.Rout.save' files could still be used where necessary or preferred. The primary advantage of this change would be to make it easier to add and maintain tests -- only one file would need to be created or changed, and no redundant information would be required. My view is that tests should be as easy as possible to create and maintain, and the current system adds a small amount of unnecessary difficulty. If such an addition would be considered, I would be happy to supply patches to implement it (and test them in a build under Windows & Linux). I have tested a prototype, and it seems pretty simple to add this: as far as I can see, small changes are needed in three files: ./share/make/tests.mk ./src/gnuwin32/fixed/share/tests.mk ./bin/check Please respond with comments/suggestions/corrections/pointing-out-of-gotchas/etc! thanks, Tony Plate __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RODBC problems with unixodbc
On Tuesday 20 February 2007 1:51 pm, Sebastian P. Luque wrote:
> Hi,
>
> I noticed that if a column is named "end" in a data frame (table.df
> below), it leads to errors when trying to sqlSave()'it to a postgresql
> connection:
>
>
> ---<---cut here---start-->---
> con <- odbcConnect("PostgreSQL-DB", uid="user", pwd="password",
>case="postgresql")
> R> sqlSave(con, table.df)
> Error in sqlSave(con, table.df) :
> [RODBC] ERROR: Could not SQLExecDirect
> 42601 7 [unixODBC]Error while executing the query;
> ERROR: syntax error at or near "end" at character 140
> ---<---cut here---end>---
>
>
> If I rename the column to something else (e.g. "ending"), this proceeds
> without problems. What could the problem be here? Thanks.
It is likely "end" is a reserved word
best
Vladimir Dergachev
>
>
> Cheers,
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
On Tue, 20 Feb 2007, Ross Boylan wrote: > On Tue, Feb 20, 2007 at 07:35:51AM +, Prof Brian Ripley wrote: >> Since you have not told us what 'the documents' are (and only vaguely >> named one), do you not think your own documentation is inadequate? > I mean the command description produced by ?tryCatch. >> >> There are documents about the condition system on developer.r-project.org: >> please consult them. >> > OK, though I would hope the user level documentation would suffice. >> I quess 'ctl-C' is your private abbreviation for 'control C' (and not a >> type of cancer): that generates an interrrupt in most (but not all) R >> ports. Where it does, you can set up interrupt handlers (as the help page >> said) >> > My P.S. concerned whether the code that was interrupted could continue > from the point of interruption. As far as I can tell from ?tryCatch > there is not, Currently interrupts cannot be handled in a way that allows them to continue at the point of interruption. On some platforms that is not possible in all cases, and coming close to it is very difficult. So for all practical purposes only tryCatch is currently useful for interrupt handling. At some point disabling interrupts will be possible from the R level but currently I believe it is not. Best, luke > >> >> On Mon, 19 Feb 2007, Ross Boylan wrote: >> >>> I'm confused by the page documenting tryCatch and friends. >>> >>> I think it describes 3 separate mechanisms: tryCatch (in which control >>> returns to the invoking tryCatch), withCallHandlers (in which control >>> goes up to the calling handler/s but then continues from the point at >>> which signalCondition() was invoked), and withRestarts (I can't tell >>> where control ends up). >>> >>> For tryCatch the docs say the arguments ... provide handlers, and that >>> these are matched to the condition. It appears that matching works by >>> providing entries in ... as named arguments, and the handler matches >>> if the name is one of the classes of the condition. Is that right? I >>> don't see the matching rule explicitly stated. And then the handler >>> itself is a single argument function, where the argument is the >>> condition? >>> >>> My reading is that if some code executes signalCondition and it is >>> running inside a tryCatch, control will not return to the line after >>> the signalCondition. Whereas, if the context is withCallHandlers, >>> the call to signalCondition does return (with a NULL) and execution >>> continues. That seems odd; do I have it right? >>> >>> Also, the documents don't explicitly say that the abstract subclasses >>> of 'error' and 'warning' are subclasses of 'condition', though that >>> seems to be implied and true. >>> >>> It appears that for tryCatch only the first matching handler is >>> executed, while for withCallHandlers all matching handlers are >>> executed. >>> >>> And, finally, with restarts there is again the issue of how the name >>> in the name=function form gets matched to the condition, and the more >>> basic question of what happens. My guess is that control stays with >>> the handler, but then this mechanism seems very similar to tryCatch >>> (with the addition of being able to pass extra arguments to the >>> handler and maybe a more flexible handler specification). >>> >>> Can anyone clarify any of this? >>> >>> P.S. Is there any mechanism that would allow one to trap an interrupt, >>> like a ctl-C, so that if the user hit ctl-C some state would be >>> changed but execution would then continue where it was? I have in >>> mind the ctl-C handler setting a "time to finish up" flag which the >>> maini code checks from time to time. >>> >>> Thanks. >>> >>> Ross Boylan >>> >>> __ >>> 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 > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
On Mon, 19 Feb 2007, Ross Boylan wrote: > I'm confused by the page documenting tryCatch and friends. > > I think it describes 3 separate mechanisms: tryCatch (in which control > returns to the invoking tryCatch), withCallHandlers (in which control > goes up to the calling handler/s but then continues from the point at > which signalCondition() was invoked), unless a handler does a non-local exit, typically by invoking a restart > and withRestarts (I can't tell > where control ends up). at the withRestarts call > For tryCatch the docs say the arguments ... provide handlers, and that > these are matched to the condition. It appears that matching works by > providing entries in ... as named arguments, and the handler matches > if the name is one of the classes of the condition. Is that right? I > don't see the matching rule explicitly stated. And then the handler > itself is a single argument function, where the argument is the > condition? > > My reading is that if some code executes signalCondition and it is > running inside a tryCatch, control will not return to the line after > the signalCondition. Whereas, if the context is withCallHandlers, > the call to signalCondition does return (with a NULL) and execution > continues. That seems odd; do I have it right? If all the available handlers return normally then signalCondition returns. Not odd at all -- analogous to synchronous posix signals. If you don't want this then write a handler that does a transfer of control or write a signaling function that uses signalCondition and provides a default action, i.e. what it does if signalCondition returns, that does a transfer of control, e.g. by invoking an "abort" restart. This is essentially what stop() does. > > Also, the documents don't explicitly say that the abstract subclasses > of 'error' and 'warning' are subclasses of 'condition', though that > seems to be implied and true. > > It appears that for tryCatch only the first matching handler is > executed, while for withCallHandlers all matching handlers are > executed. All handlers are executed, most recently established first, until there are none left or there is a transfer of control. Conceptually, exiting handlers established with tryCatch execute a transfer of control and then run their code. > And, finally, with restarts there is again the issue of how the name > in the name=function form gets matched to the condition, and the more > basic question of what happens. My guess is that control stays with > the handler, but then this mechanism seems very similar to tryCatch > (with the addition of being able to pass extra arguments to the > handler and maybe a more flexible handler specification). Restart names, in the simple forms of withRestarts, are names for points to transfer control to. They are not conditions. They are used by condition handlers to find appropriate points to jump to. You can look at the code for warning() and suppressWarnings() to see an example of how this is used. The tryCatch mechanism is quite simple and adequate for most purposes. The calling handler plus restarts framweork is itended to be rich enough to allow construction of a variety of frameworks, including tryCatch, but this power comes at the cost of added complexity. Hopefully a more extensive document on this will get written in the next few months; for now the notes available off the developer page may be useful. best, luke > > Can anyone clarify any of this? > > P.S. Is there any mechanism that would allow one to trap an interrupt, > like a ctl-C, so that if the user hit ctl-C some state would be > changed but execution would then continue where it was? I have in > mind the ctl-C handler setting a "time to finish up" flag which the > maini code checks from time to time. > > Thanks. > > Ross Boylan > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
> Since you have not told us what 'the documents' are (and only vaguely > named one), do you not think your own documentation is inadequate? > > There are documents about the condition system on developer.r-project.org: > please consult them. Where exactly? I tried: * reading http://developer.r-project.org/, but couldn't see anything obvious, and there certainly isn't anything in the pointers section * using find on that page to search for "condition", "try" * using the google search with keywords: "condition system", "try catch", "try" Perhaps you could provide a more explicit reference? Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal to allow just transcript files (output only) in the 'tests' directory
On Tue, 20 Feb 2007, Tony Plate wrote: > Currently, as far as I can see, both input and output fles must be > supplied in the 'tests' directory (the input in a '.R' file, and the > output in a corresponding '.Rout.save' file.) Often, the '.R' file is > redundant, as it could be reconstructed by simply stripping the commands > out of the '.Rout.save' file. E.g., the command > $ sed -n -e 's/^[>+] //p' ./src/library/stats/tests/nls.Rout.save > produces the same R commands as in ./src/library/stats/tests/nls.R Some output lines start with "+ ". E.g., in gamlss/tests/manual.Rout.save I see > mod3<-stepAIC(mod1, scope=list(lower=~1,upper=~(x1+x2+x3+x4+x5+x6)^2)) Distribution parameter: mu Start: AIC= 319.16 y ~ x1 + x2 + x3 + x4 + x5 + x6 DfAIC + x4:x5 1 307.07 + x1:x5 1 316.94 - x6 1 317.16 so R would try to parse "x4:x5 1 307.07". You could use awk so the "^+ " lines had to immediately follow "^> " (or a properly preceded "^+ "), but I suspect there will still be problems. I have experimented with similar things to compare Splus and R output for the same commands. Having the original input lines helps there. The hard part is parsing the output so it can be recognized as a matrix, a vector with names, an expression, lm() output, etc. Then I could see that the following outputs are equivalent: R: R: Call: R: lm(formula = log(x) ~ x, data = list(x = 1:10)) R: R: Coefficients: R: (Intercept)x R: 0.2432 0.2304 R: Splus: Call: Splus: lm(formula = log(x) ~ x, data = list(x = 1:10)) Splus: Splus: Coefficients: Splus: (Intercept) x Splus:0.2432038 0.2304068 Splus: Splus: Degrees of freedom: 10 total; 8 residual Splus: Residual standard error: 0.2388027 This would also be handy for comparing results in different versions of R, where low level printing routines may be changed a bit. Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
Look for 'exception' or 'handling': http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html http://www.stat.uiowa.edu/~luke/R/exceptions/simplecond.html On Tue, 20 Feb 2007, hadley wickham wrote: >> Since you have not told us what 'the documents' are (and only vaguely >> named one), do you not think your own documentation is inadequate? >> >> There are documents about the condition system on developer.r-project.org: >> please consult them. > > Where exactly? > > I tried: > > * reading http://developer.r-project.org/, but couldn't see anything > obvious, and there certainly isn't anything in the pointers section > > * using find on that page to search for "condition", "try" > > * using the google search with keywords: "condition system", "try catch", > "try" > > Perhaps you could provide a more explicit reference? > > Hadley > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
Search for 'exception'. THe result points to http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html Best, luke On Tue, 20 Feb 2007, hadley wickham wrote: >> Since you have not told us what 'the documents' are (and only vaguely >> named one), do you not think your own documentation is inadequate? >> >> There are documents about the condition system on developer.r-project.org: >> please consult them. > > Where exactly? > > I tried: > > * reading http://developer.r-project.org/, but couldn't see anything > obvious, and there certainly isn't anything in the pointers section > > * using find on that page to search for "condition", "try" > > * using the google search with keywords: "condition system", "try catch", > "try" > > Perhaps you could provide a more explicit reference? > > Hadley > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] fix for a major format.pval limitation
'format.pval' has a major limitation in its implementation for example
suppose a person had a vector like 'a' and the error being ±0.001.
> a <- c(0.1, 0.3, 0.4, 0.5, 0.3, 0.0001)
> format.pval(a, eps=0.001)
The person wants to have the 'format.pval' output with 2 digits always
showing like this
[1] "0.10" "0.30" "0.40" "0.50" "0.30" "<0.001"
How ever format.pval can only display this
[1] "0.1""0.3""0.4""0.5""0.3""<0.001"
If this was the 'format' function this could be corrected by setting the
'nsmall' argument to 2. But 'format.pval' has no ability to pass
arguments to format.
I think that the best solution would be to give 'format.pval' a '...'
argument that would get passed to all the 'format' function calls in
'format.pval'.
I have attached a patch that does this. This patch is against svn
r-release-branch and will also apply to r-devel.
Charles Dupont
--
Charles Dupont Computer System Analyst School of Medicine
Department of Biostatistics Vanderbilt University
Index: src/library/base/R/format.R
===
--- src/library/base/R/format.R (revision 40768)
+++ src/library/base/R/format.R (working copy)
@@ -43,7 +43,7 @@
}
format.pval <- function(pv, digits = max(1, getOption("digits")-2),
- eps = .Machine$double.eps, na.form = "NA")
+ eps = .Machine$double.eps, na.form = "NA", ...)
{
## Format P values; auxiliary for print.summary.[g]lm(.)
@@ -55,8 +55,8 @@
## be smart -- differ for fixp. and expon. display:
expo <- floor(log10(ifelse(pv > 0, pv, 1e-50)))
fixp <- expo >= -3 | (expo == -4 & digits>1)
- if(any( fixp)) rr[ fixp] <- format(pv[ fixp], dig=digits)
- if(any(!fixp)) rr[!fixp] <- format(pv[!fixp], dig=digits)
+ if(any( fixp)) rr[ fixp] <- format(pv[ fixp], dig=digits, ...)
+ if(any(!fixp)) rr[!fixp] <- format(pv[!fixp], dig=digits, ...)
r[!is0]<- rr
}
if(any(is0)) {
@@ -67,7 +67,7 @@
digits <- max(1, nc - 7)
sep <- if(digits==1 && nc <= 6) "" else " "
} else sep <- if(digits==1) "" else " "
- r[is0] <- paste("<", format(eps, digits=digits), sep = sep)
+ r[is0] <- paste("<", format(eps, digits=digits, ...), sep = sep)
}
if(has.na) { ## rarely
rok <- r
Index: src/library/base/man/format.pval.Rd
===
--- src/library/base/man/format.pval.Rd (revision 40768)
+++ src/library/base/man/format.pval.Rd (working copy)
@@ -6,13 +6,14 @@
\alias{format.pval}
\usage{
format.pval(pv, digits = max(1, getOption("digits") - 2),
-eps = .Machine$double.eps, na.form = "NA")
+eps = .Machine$double.eps, na.form = "NA", \dots)
}
\arguments{
\item{pv}{a numeric vector.}
\item{digits}{how many significant digits are to be used.}
\item{eps}{a numerical tolerance: see Details.}
\item{na.form}{character representation of \code{NA}s.}
+ \item{\dots}{arguments passed to the \code{\link{format}} function.}
}
\value{
A character vector.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
> Search for 'exception'. THe result points to > > http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html Thanks Luke (and Brian). The note is entitled "A Prototype of a Condition System for R" - can we assume the actual implementation is as described? Thanks, Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
Qualitatively I believe so. Names were changed and some details were changed to better integrate with existing paractice and internals, and the hook mechanisms used for experimenting are either no longer available or will be removed before long. Sorting these things out is one of the tastks of writing up a pepr on this, which I hioe to get to within a few months. Best, luke On Tue, 20 Feb 2007, hadley wickham wrote: >> Search for 'exception'. THe result points to >> >> http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html > > Thanks Luke (and Brian). The note is entitled "A Prototype of a > Condition System for R" - can we assume the actual implementation is > as described? > > Thanks, > > Hadley > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling (interrupts)
[resequencing and deleting for clarity]
On Tue, Feb 20, 2007 at 01:15:25PM -0600, Luke Tierney wrote:
> On Tue, 20 Feb 2007, Ross Boylan wrote:
> >>>P.S. Is there any mechanism that would allow one to trap an interrupt,
> >>>like a ctl-C, so that if the user hit ctl-C some state would be
> >>>changed but execution would then continue where it was? I have in
> >>>mind the ctl-C handler setting a "time to finish up" flag which the
> >>>maini code checks from time to time.
>
> >On Tue, Feb 20, 2007 at 07:35:51AM +, Prof Brian Ripley wrote:
...
> >>I quess 'ctl-C' is your private abbreviation for 'control C' (and
> >>not a
[yes, ctl-C = control C, RB]
> >>type of cancer): that generates an interrrupt in most (but not all) R
> >>ports. Where it does, you can set up interrupt handlers (as the help page
> >>said)
> >>
> >My P.S. concerned whether the code that was interrupted could continue
> >from the point of interruption. As far as I can tell from ?tryCatch
> >there is not,
>
> Currently interrupts cannot be handled in a way that allows them to
> continue at the point of interruption. On some platforms that is not
> possible in all cases, and coming close to it is very difficult. So
> for all practical purposes only tryCatch is currently useful for
> interrupt handling. At some point disabling interrupts will be
> possible from the R level but currently I believe it is not.
>
> Best,
>
> luke
I had suspected that, since R is not thread-safe, handling
asynchronous events might be challenging.
I tried the following experiment on Linux:
> h<-function(e) print("Got You!")
> f<-function(n, delay) for (i in seq(n)) {Sys.sleep(delay); print(i)}
> withCallingHandlers(f(7,1), interrupt=h)
[1] 1
[1] "Got You!"
So in this case the withCallingHandlers acts like a tryCatch, in that
control does not return to the point of interruption. However,
sys.calls within h does show where things were just before the
interrupt:
> h<-function(e) {print("Got You!"); print(sys.calls());}
> withCallingHandlers(f(7,1), interrupt=h)
[1] 1
[1] 2
[1] 3
[1] "Got You!"
[[1]]
withCallingHandlers(f(7, 1), interrupt = h)
[[2]]
f(7, 1)
[[3]]
Sys.sleep(delay)
[[4]]
function (e)
{
print("Got You!")
print(sys.calls())
}(list())
Ross
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling (interrupts)
On Tue, 20 Feb 2007, Ross Boylan wrote:
> [resequencing and deleting for clarity]
> On Tue, Feb 20, 2007 at 01:15:25PM -0600, Luke Tierney wrote:
>> On Tue, 20 Feb 2007, Ross Boylan wrote:
> P.S. Is there any mechanism that would allow one to trap an interrupt,
> like a ctl-C, so that if the user hit ctl-C some state would be
> changed but execution would then continue where it was? I have in
> mind the ctl-C handler setting a "time to finish up" flag which the
> maini code checks from time to time.
>>
>>> On Tue, Feb 20, 2007 at 07:35:51AM +, Prof Brian Ripley wrote:
> ...
>
I quess 'ctl-C' is your private abbreviation for 'control C' (and
not a
> [yes, ctl-C = control C, RB]
type of cancer): that generates an interrrupt in most (but not all) R
ports. Where it does, you can set up interrupt handlers (as the help page
said)
>>> My P.S. concerned whether the code that was interrupted could continue
>>> from the point of interruption. As far as I can tell from ?tryCatch
>>> there is not,
>>
>> Currently interrupts cannot be handled in a way that allows them to
>> continue at the point of interruption. On some platforms that is not
>> possible in all cases, and coming close to it is very difficult. So
>> for all practical purposes only tryCatch is currently useful for
>> interrupt handling. At some point disabling interrupts will be
>> possible from the R level but currently I believe it is not.
>>
>> Best,
>>
>> luke
> I had suspected that, since R is not thread-safe, handling
> asynchronous events might be challenging.
This has nothing to do with thread safety. It has everything to do
with what is safe to do within signal handlers on the one hand and OS
specific variations on what happens when signals interrupt a system
call on the other.
>
> I tried the following experiment on Linux:
>
>> h<-function(e) print("Got You!")
>> f<-function(n, delay) for (i in seq(n)) {Sys.sleep(delay); print(i)}
>> withCallingHandlers(f(7,1), interrupt=h)
> [1] 1
> [1] "Got You!"
>
> So in this case the withCallingHandlers acts like a tryCatch, in that
> control does not return to the point of interruption. However,
> sys.calls within h does show where things were just before the
> interrupt:
>> h<-function(e) {print("Got You!"); print(sys.calls());}
>> withCallingHandlers(f(7,1), interrupt=h)
> [1] 1
> [1] 2
> [1] 3
> [1] "Got You!"
> [[1]]
> withCallingHandlers(f(7, 1), interrupt = h)
>
> [[2]]
> f(7, 1)
>
> [[3]]
> Sys.sleep(delay)
>
> [[4]]
> function (e)
> {
>print("Got You!")
>print(sys.calls())
> }(list())
Experiments like this are useful but don't expect results you get to
be reliable in the future. What the call stack as shown by sys.xyz
looks like in particular at handling time may change (probably not
much for calling handlers but most likely for exiting ones).
Best,
luke
>
> Ross
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "try"ing to understand condition handling
Thanks; your response is very helpful. This message has some remarks on my questions relative to the developer docs, one additional question, and some documentation comments. I'm really glad to hear you plan to revise the exception/condition docs. since I found the existing ones a bit murky. Below, [1] means http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html, one of the documents Prof Ripley referred to. That page also has a nice illustration of using the restart facility. On Tue, Feb 20, 2007 at 01:40:11PM -0600, Luke Tierney wrote: > On Mon, 19 Feb 2007, Ross Boylan wrote: > > >I'm confused by the page documenting tryCatch and friends. > > > >I think it describes 3 separate mechanisms: tryCatch (in which control > >returns to the invoking tryCatch), withCallHandlers (in which should have been "withCallingHandlers" > >control > >goes up to the calling handler/s but then continues from the point at > >which signalCondition() was invoked), > > unless a handler does a non-local exit, typically by invoking a restart > > >and withRestarts (I can't tell > >where control ends up). > > at the withRestarts call > > >For tryCatch the docs say the arguments ... provide handlers, and that > >these are matched to the condition. It appears that matching works by > >providing entries in ... as named arguments, and the handler matches > >if the name is one of the classes of the condition. Is that right? I > >don't see the matching rule explicitly stated. And then the handler > >itself is a single argument function, where the argument is the > >condition? >From [1], while discussing tryCatch, Handlers are specified as name = fun where name specifies an exception class and fun is a function of one argument, the condition that is to be handled. ... > > > >Also, the documents don't explicitly say that the abstract subclasses > >of 'error' and 'warning' are subclasses of 'condition', though that > >seems to be implied and true. The class relations are explicit in [1]. > > > >It appears that for tryCatch only the first matching handler is > >executed, while for withCallHandlers all matching handlers are > >executed. > > All handlers are executed, most recently established first, until > there are none left or there is a transfer of control. Conceptually, > exiting handlers established with tryCatch execute a transfer of > control and then run their code. Here's the one point of clarification: does the preceding paragraph about "all handlers are executed" apply only to withCallingHandlers, or does it include tryCatch as well? Rereading ?tryCatch, it still looks as if the first match only will fire. > > Hopefully a more extensive document on this will get written in the > next few months; for now the notes available off the developer page > may be useful. > > best, > > luke Great. FWIW, here are some suggestions about the documentation: I would find a presentation that provided an overall orientation and then worked down easiest to follow. So, goiing from the top down: 1. there are 3 forms of exception handling: try/catch, calling handlers and restarts. 2. the characteristic behavior of each is ... (i.e., what's the flow of control). Maybe give a snippet of typical uses of each. 3. the details (exact calling environment of the handler(s), matching rules, syntax...) 4. try() is basically a convenient form of tryCatch. 5. Other relations between these 3 forms: what happens if they are nested; how restarts alter the "standard" control flow of the other forms. I also found the info that the restart mechanism is the most general and complicated useful for orientation (that might go under point 1). It might be appropriate to document each form on a separate manual page; I'm not sure if they are too linked (particularly by the use of conditions and the control flow of restart) to make that a good idea. I notice that some of the outline above is not the standard R manual format; maybe the big picture should go in the language manual or on a concept page (?Exceptions maybe). Be explicit about the relations between conditions (class inheritance relations). Be explicit about how handlers are chosen and which forms they take. It might be worth mentioning stuff that is a little surprising. The fact that the value of the finally is not the value of the tryCatch was a little surprising, since usually the value of a series of statements or expression is that of the last one. The fact that signalCondition can participate in two different flows of control (discussion snipped above) was also surprising to me. In both cases the current ?tryCatch is pretty explicit already, so that's not the issue. I found the current language (for ?tryCatch) about the calling context of different handlers a bit obscure. For example, discussing tryCatch: " If a handler is found then control is transferred to the 'tryCatch' call that established the handler, the handler found and all more rec
Re: [Rd] "try"ing to understand condition handling
On Tue, 20 Feb 2007, Ross Boylan wrote:
> Thanks; your response is very helpful. This message has some remarks
> on my questions relative to the developer docs, one additional
> question, and some documentation comments.
>
> I'm really glad to hear you plan to revise the exception/condition
> docs. since I found the existing ones a bit murky.
>
> Below, [1] means
> http://www.stat.uiowa.edu/~luke/R/exceptions/simpcond.html,
> one of the documents Prof Ripley referred to.
>
> That page also has a nice illustration of using the restart facility.
>
> On Tue, Feb 20, 2007 at 01:40:11PM -0600, Luke Tierney wrote:
>> On Mon, 19 Feb 2007, Ross Boylan wrote:
>>
>>> I'm confused by the page documenting tryCatch and friends.
>>>
>>> I think it describes 3 separate mechanisms: tryCatch (in which control
>>> returns to the invoking tryCatch), withCallHandlers (in which
> should have been "withCallingHandlers"
>>> control
>>> goes up to the calling handler/s but then continues from the point at
>>> which signalCondition() was invoked),
>>
>> unless a handler does a non-local exit, typically by invoking a restart
>>
>>> and withRestarts (I can't tell
>>> where control ends up).
>>
>> at the withRestarts call
>>
>>> For tryCatch the docs say the arguments ... provide handlers, and that
>>> these are matched to the condition. It appears that matching works by
>>> providing entries in ... as named arguments, and the handler matches
>>> if the name is one of the classes of the condition. Is that right? I
>>> don't see the matching rule explicitly stated. And then the handler
>>> itself is a single argument function, where the argument is the
>>> condition?
> From [1], while discussing tryCatch,
>
> Handlers are specified as
>
> name = fun
>
> where name specifies an exception class and fun is a function of one
> argument, the condition that is to be handled.
>
>
> ...
>>>
>>> Also, the documents don't explicitly say that the abstract subclasses
>>> of 'error' and 'warning' are subclasses of 'condition', though that
>>> seems to be implied and true.
> The class relations are explicit in [1].
>
>>>
>>> It appears that for tryCatch only the first matching handler is
>>> executed, while for withCallHandlers all matching handlers are
>>> executed.
>>
>> All handlers are executed, most recently established first, until
>> there are none left or there is a transfer of control. Conceptually,
>> exiting handlers established with tryCatch execute a transfer of
>> control and then run their code.
>
> Here's the one point of clarification: does the preceding paragraph
> about "all handlers are executed" apply only to withCallingHandlers,
> or does it include tryCatch as well? Rereading ?tryCatch, it still
> looks as if the first match only will fire.
>
Only to calling handlers because exiting ones conceptually execute a
transfer of control out of the loop over the eligible handlers.
[In principle tryCatch can be written in terms of withCallingHandlers
using callCC to transfer control (callCC will be in R-devel shortly
and corresponds to callcc in [1]). The expression
tryCatch(expr, c1 = h1, c2 = h2)
is essentially equivalent to something like (untested but hopefully close)
cond <- NULL
h <- NULL
v <- callCC(function(k)
withCallingHandlers(expr,
c1 = function(c) { cond <<- c; h <<- h1; k(NULL)},
c2 = function(c) { cond <<- c; h <<- h2; k(NULL)}))
if (is.null(h)) value
else h(cond)
Matching calling handlers are applied one at a time, but if one of
these two matches then the call k(NULL) causes an immediate return
from callCC with value NULL. If this doesn't help, ignore it.]
>>
>> Hopefully a more extensive document on this will get written in the
>> next few months; for now the notes available off the developer page
>> may be useful.
>>
>> best,
>>
>> luke
> Great. FWIW, here are some suggestions about the documentation:
>
> I would find a presentation that provided an overall orientation and
> then worked down easiest to follow. So, goiing from the top down:
> 1. there are 3 forms of exception handling: try/catch, calling
> handlers and restarts.
> 2. the characteristic behavior of each is ... (i.e., what's the flow
> of control). Maybe give a snippet of typical uses of each.
> 3. the details (exact calling environment of the handler(s), matching
> rules, syntax...)
> 4. try() is basically a convenient form of tryCatch.
> 5. Other relations between these 3 forms: what happens if they are
> nested; how restarts alter the "standard" control flow of the other
> forms. I also found the info that the restart mechanism is the most
> general and complicated useful for orientation (that might go under
> point 1).
>
> It might be appropriate to document each form on a separate manual
> page; I'm not sure if they are too linked (particularly by the use of
> conditions and the control flow of restart) to make that a good i
