[Rd] Using IDs to suppress specific messages and warnings
The suppressMessages and suppressWarnings functions currently suppress
all the message or warnings that are generated by the input
expression.
The ability to suppress only specific messages or warnings is
sometimes useful, particularly for cases like file import where there
are lots of things that can go wrong.
Suppressing only messages that match a regular expression has rightly
been rejected as problematic due to non-portability across locales.
See, for example,
https://stat.ethz.ch/pipermail/r-devel/2012-October/065089.html
A better way of suppressing certain conditions would be to allow them
to have an identifier. (This is how MATLAB allows control over
individual conditions.)
The implementation ought to be fairly simple.
simpleMessage, simpleWarning, and simpleError gain an id arg, which is
stored in their structure.
simpleMessage <- function (message, call = NULL, id = NULL)
{
structure(
list(message = message, call = call, id = id),
class = c("simpleMessage", "message", "condition")
)
}
I envisage IDs being strings, for example, the "NaN produced" warning
when you ask call, e.g., sqrt(-1) could have an ID of
"base:sqrt:nan_produced".
suppressMessage and suppressWarnings gain an ids arg, defaulting to
NULL, which preserves existing behaviour. If it takes a character
vector, messages with the IDs provided get muffled. Something like:
suppressMessages <- function (expr, ids = NULL)
{
withCallingHandlers(
expr,
message = function(c)
{
if(is.null(ids) || (inherits(c, "simpleMessage") && c$id %in%
as.character(ids)))
{
invokeRestart("muffleMessage")
}
}
)
}
The hard part is providing IDs for all the existing messages in R and
its packages. It's certainly do-able, but I imagine would take quite
a lot of time.
Is there any enthusiasm for implementing this feature, or something like it?
--
Regards,
Richie
Learning R
4dpiecharts.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Proposed change in file.exists() to tolerate Windows
Two solutions:
1. Use the wrapper function is_existing_file in assertive.
2. Use standardize_path in pathological before you call file.exists.
On 27 August 2015 at 17:02, Paul Johnson wrote:
> I'm writing to ask if R Core would make file.exists more Windows
> tolerant when the argument has a trailing slash. This has been
> discussed by users a few times here, I know it is not a new topic. But
> it is not a solved problem, yet. I acknowledge that CRAN packages
> exist which fix this by replacing file.exists(), but it seems more
> elegant to me to fix the problem in R itself.
>
> R Core goes to great extremes to accommodate Windows users and the
> refusal to make file.exists() work in a cross-platform way is
> incongruous.
>
> I often do have slashes on the end of directory names being tested.
> Now that I understand the meaning of ?file.exists, I need to wrap the
> name being checked in a slash-deleter
>
> ## delete trailing slashes
> dts <- function(name) gsub("/$", "", name)
> if(!file.exists(dts(any_name))) { ...
>
> Can't you make file.exists do this invisibly? Maybe the argument could
> be filtered through normalizePath() instead.
>
> If not, would you please consider putting a workaround like mine into
> the file.exists documentation so Windows users can see how easy this
> is to avoid?
>
> Respectfully yours,
>
> pj
>
> --
> Paul E. Johnson
> Professor, Political ScienceDirector
> 1541 Lilac Lane, Room 504 Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org http://crmda.ku.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Regards,
Richie
Learning R
4dpiecharts.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using IDs to suppress specific messages and warnings
Conditions have classes and the condition system is designed around
the idea that classes would be used for this sort of thing. That is
already how tryCatch and withCallingHandlers discriminate the
conditions to handle.
Designing and implementing a condition class hierarchy to support this
is indeed the hard/tedious part.
Best,
luke
On Thu, 10 Sep 2015, Richard Cotton wrote:
The suppressMessages and suppressWarnings functions currently suppress
all the message or warnings that are generated by the input
expression.
The ability to suppress only specific messages or warnings is
sometimes useful, particularly for cases like file import where there
are lots of things that can go wrong.
Suppressing only messages that match a regular expression has rightly
been rejected as problematic due to non-portability across locales.
See, for example,
https://stat.ethz.ch/pipermail/r-devel/2012-October/065089.html
A better way of suppressing certain conditions would be to allow them
to have an identifier. (This is how MATLAB allows control over
individual conditions.)
The implementation ought to be fairly simple.
simpleMessage, simpleWarning, and simpleError gain an id arg, which is
stored in their structure.
simpleMessage <- function (message, call = NULL, id = NULL)
{
structure(
list(message = message, call = call, id = id),
class = c("simpleMessage", "message", "condition")
)
}
I envisage IDs being strings, for example, the "NaN produced" warning
when you ask call, e.g., sqrt(-1) could have an ID of
"base:sqrt:nan_produced".
suppressMessage and suppressWarnings gain an ids arg, defaulting to
NULL, which preserves existing behaviour. If it takes a character
vector, messages with the IDs provided get muffled. Something like:
suppressMessages <- function (expr, ids = NULL)
{
withCallingHandlers(
expr,
message = function(c)
{
if(is.null(ids) || (inherits(c, "simpleMessage") && c$id %in%
as.character(ids)))
{
invokeRestart("muffleMessage")
}
}
)
}
The hard part is providing IDs for all the existing messages in R and
its packages. It's certainly do-able, but I imagine would take quite
a lot of time.
Is there any enthusiasm for implementing this feature, or something like it?
--
Luke Tierney
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: luke-tier...@uiowa.edu
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] Using IDs to suppress specific messages and warnings
Thanks Luke, On 10 September 2015 at 14:47, wrote: > Conditions have classes and the condition system is designed around > the idea that classes would be used for this sort of thing. That is > already how tryCatch and withCallingHandlers discriminate the > conditions to handle. That makes sense. Though with my sqrt example, it's just a plain simpleWarning, which doesn't give you the opportunity to do special handling. tryCatch(sqrt(-1), warning = function(w) class(w)) ## [1] "simpleWarning" "warning" "condition" > Designing and implementing a condition class hierarchy to support this > is indeed the hard/tedious part. There are precedents from other languages that could be used as a template. For example, .NET and Java both have very well defined exception hierarchies that could serve as a starting point. https://msdn.microsoft.com/en-us/library/z4c5tckx%28v=vs.110%29.aspx https://docs.oracle.com/javase/7/docs/api/java/lang/package-tree.html Who is the best person to ask/cajole to start getting this implemented? -- Regards, Richie Learning R 4dpiecharts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using IDs to suppress specific messages and warnings
On 10/09/2015 9:03 AM, Richard Cotton wrote: > Thanks Luke, > > On 10 September 2015 at 14:47, wrote: >> Conditions have classes and the condition system is designed around >> the idea that classes would be used for this sort of thing. That is >> already how tryCatch and withCallingHandlers discriminate the >> conditions to handle. > > That makes sense. Though with my sqrt example, it's just a plain > simpleWarning, which doesn't give you the opportunity to do special > handling. > > tryCatch(sqrt(-1), warning = function(w) class(w)) > ## [1] "simpleWarning" "warning" "condition" > > >> Designing and implementing a condition class hierarchy to support this >> is indeed the hard/tedious part. > > There are precedents from other languages that could be used as a > template. For example, .NET and Java both have very well defined > exception hierarchies that could serve as a starting point. > > https://msdn.microsoft.com/en-us/library/z4c5tckx%28v=vs.110%29.aspx > https://docs.oracle.com/javase/7/docs/api/java/lang/package-tree.html > > Who is the best person to ask/cajole to start getting this implemented? I think that if you put together a proposal that looks easy to implement and maintain, and volunteered (or recruited volunteers) to do most of the work, then it would get done. I don't think either of the posted hierarchies would be acceptable, though, because they'd require anyone who was writing new code to learn them. Currently if I want to put in a warning, it's easy: I just call warning(). If you make it take an extra 5 seconds to add something that makes the warning more useful, I'd do it. If it takes 10 minutes of reading through voluminous documentation, I wouldn't. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using IDs to suppress specific messages and warnings
On Thu, 10 Sep 2015, Richard Cotton wrote: Thanks Luke, On 10 September 2015 at 14:47, wrote: Conditions have classes and the condition system is designed around the idea that classes would be used for this sort of thing. That is already how tryCatch and withCallingHandlers discriminate the conditions to handle. That makes sense. Though with my sqrt example, it's just a plain simpleWarning, which doesn't give you the opportunity to do special handling. tryCatch(sqrt(-1), warning = function(w) class(w)) ## [1] "simpleWarning" "warning" "condition" Obviously, that is what happens now since e don't yet have a developed hierarchy of classes. This, and most other internally generated warnings/errors, would need to change to more specific classes of warnings/errors once the hierarchy is developed. Designing and implementing a condition class hierarchy to support this is indeed the hard/tedious part. There are precedents from other languages that could be used as a template. For example, .NET and Java both have very well defined exception hierarchies that could serve as a starting point. https://msdn.microsoft.com/en-us/library/z4c5tckx%28v=vs.110%29.aspx https://docs.oracle.com/javase/7/docs/api/java/lang/package-tree.html The R condition system is based on the one in common lisp, which is quite bit richer than Java's mechanism. Common Lisp's hierarchy would be the best starting point, though ideas from the hierarchy in Java could be useful as well. Who is the best person to ask/cajole to start getting this implemented? I't been on my long todo list for a long time, but I don't expect to have the time to do it myself anytime soon. If someone else want to put in the work I am willing to work with them. Best, luke -- Luke Tierney 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: luke-tier...@uiowa.edu 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] Printing buglet for latin1 encoded strings
x <- c("août", "élève", "ça va")
y <- iconv(x, "UTF-8", "latin1")
x
#> [1] "août" "élève" "ça va"
y
#> [1] "août""élève" "ça va"
(note the difference in spacing)
On both R-release (mac) and R-devel (linux). nchar() and format() both look ok.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
