[Rd] Suppress specific warnings
Hello, is there a convenient way to suppress only *specific* warnings? (I know about ?suppressWarnings) I depend on another package, from which I want to suppress only some warnings, but not others. Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
On 13-04-18 7:31 AM, Felix Schönbrodt wrote: Hello, is there a convenient way to suppress only *specific* warnings? (I know about ?suppressWarnings) I depend on another package, from which I want to suppress only some warnings, but not others. This is difficult in most cases, because most packages don't give enough information to distinguish among their warnings. You could probably do it based on the message as follows, but the test won't work if someone is running in a locale where the warning message has been translated to a different language: x - 1:10 x + 1:3 # gives the warning: In x + 1:3 : longer object length is not a multiple of shorter object length To suppress just this one, try this: withCallingHandlers(x + 1:3, warning=function(w) { if (grepl(longer object length, w$message)) invokeRestart(muffleWarning) } ) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
On 04/18/2013 05:57 AM, Duncan Murdoch wrote: On 13-04-18 7:31 AM, Felix Schönbrodt wrote: Hello, is there a convenient way to suppress only *specific* warnings? (I know about ?suppressWarnings) I depend on another package, from which I want to suppress only some warnings, but not others. This is difficult in most cases, because most packages don't give enough information to distinguish among their warnings. You could probably do it based maybe useful to make the point that it isn't hard to for the package you depend on to signal different types of warnings w = simpleWarning(curves ahead) class(w) = c(curves, class(w)) warning(w) more below... on the message as follows, but the test won't work if someone is running in a locale where the warning message has been translated to a different language: x - 1:10 x + 1:3 # gives the warning: In x + 1:3 : longer object length is not a multiple of shorter object length To suppress just this one, try this: withCallingHandlers(x + 1:3, warning=function(w) { if (grepl(longer object length, w$message)) invokeRestart(muffleWarning) } ) ...which are then caught as withCallingHandlers({ warning(w) # 'curves'; caught warning(another warning) }, curves=function(w) invokeRestart(muffleWarning)) The tricky part is to come up with an appropriate scheme for classifying warnings. Martin Morgan Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suppress specific warnings
For my logging package (futile.logger) any log statements coming from a package are assigned to a package namespace. This way you have control of log messages at a package level (e.g. I can set the default log threshold to DEBUG, while package 'A' has a log threshold of WARN). I seems a hierarchical namespace facility would work for the below case as well. On Apr 18, 2013, at 9:29 AM, Martin Morgan mtmor...@fhcrc.org wrote: To suppress just this one, try this: withCallingHandlers(x + 1:3, warning=function(w) { if (grepl(longer object length, w$message)) invokeRestart(muffleWarning) } ) ...which are then caught as withCallingHandlers({ warning(w) # 'curves'; caught warning(another warning) }, curves=function(w) invokeRestart(muffleWarning)) The tricky part is to come up with an appropriate scheme for classifying warnings. • Brian Lee Yung Rowe 917 496 4583 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
Duncan Murdoch murdoch.dun...@gmail.com on Thu, 25 Oct 2012 06:51:25 -0400 writes: On 12-10-25 5:28 AM, Martin Maechler wrote: Sorry guys, for coming late, but *please* don't go there. I've been there years ago, and found later why the approach is flawed by design : Internationalization / Localization: - If the warning comes from a standard R function, the warning is almost surely different in a (say) German locale, and your pattern won't be detected. - Ditto if from a recommended package. - If it is a warning that is not translated then it may be that it is just not *YET* translated. I think the other Martin's suggestion addressed this: he matched the translated message, not the English original. Duncan Murdoch Well, I don't think I understand. Of course you can only match the message that warning() or error() {or rather tryCatch() ,...} produces. But you cannot guarantee nor know (for sure) if that message is 'original' or translated. cannot, because AFAIK we cannot guarantee Sys.setlocale() is obeyed platform independently: You would have to query the current and save that, set it to C, get the message, and then reset the locale to the previously saved one. And these do not work reliably, on some platforms, AFAIK and read our documentation. Martin The really dangerous thing about matching error / warning messages -- I had done it in the past with the error message I caught via tryCatch() -- is that - in your tests the code will work perfectly. - on CRAN the code will work perfectly, as they also use the English (or C) locale. So, by doing this you are distributing code that almost always works ... in your environment if you are US, UK or similarly based. Indeed, a *really* dangerous practice. Martin Maechler, ETH Zurich Martin Morgan mtmor...@fhcrc.org on Tue, 23 Oct 2012 05:28:48 -0700 writes: On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote: On Sun, 21 Oct 2012, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling The sources in srs/library/base/conditions.R have suppressWarnings - function(expr) { ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval on.exit(options(ops)) ## calls are removed from methods code withCallingHandlers(expr, warning=function(w) invokeRestart(muffleWarning)) } I uspect we have still not entirely eliminated R_tryEval in this context but I'm not sure. Will check when I get a chance. a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } A problem with using expression matching is of course that this fails with internationalized messages. Ideally warnings should be signaled as warning conditions of a particular class, and that class can be used to discriminate. Unfortunately very few warnings are designed this way. Probably specific messages, rather than patterns, would be handled and then suppressWarnings2 - function(expr, messages = character()) { opts - options(warn = -1) on.exit(options(ops)) withCallingHandlers(expr, warning=function(w) { if (conditionMessage(w) %in% messages) invokeRestart(muffleWarning) }) } gives one the illusion of speaking many
Re: [Rd] suppress *specific* warnings?
On Oct 26, 2012, at 11:17 , Martin Maechler wrote: Duncan Murdoch murdoch.dun...@gmail.com on Thu, 25 Oct 2012 06:51:25 -0400 writes: On 12-10-25 5:28 AM, Martin Maechler wrote: Sorry guys, for coming late, but *please* don't go there. I've been there years ago, and found later why the approach is flawed by design : Internationalization / Localization: - If the warning comes from a standard R function, the warning is almost surely different in a (say) German locale, and your pattern won't be detected. - Ditto if from a recommended package. - If it is a warning that is not translated then it may be that it is just not *YET* translated. I think the other Martin's suggestion addressed this: he matched the translated message, not the English original. Duncan Murdoch Well, I don't think I understand. Of course you can only match the message that warning() or error() {or rather tryCatch() ,...} produces. But you cannot guarantee nor know (for sure) if that message is 'original' or translated. cannot, because AFAIK we cannot guarantee Sys.setlocale() is obeyed platform independently: You would have to query the current and save that, set it to C, get the message, and then reset the locale to the previously saved one. And these do not work reliably, on some platforms, AFAIK and read our documentation. I think the point was to use gettext() on the pattern-to-match. If the warning is translated, so would this be. The main limitations would seem to be that you have to be d*mn sure to get the spelling right and, presumably, it only works with straight string translations, not variant forms like msgid found %d fatal error msgid_plural found %d fatal errors msgstr[0] s'ha trobat %d error fatal msgstr[1] s'han trobat %d errors fatals Martin The really dangerous thing about matching error / warning messages -- I had done it in the past with the error message I caught via tryCatch() -- is that - in your tests the code will work perfectly. - on CRAN the code will work perfectly, as they also use the English (or C) locale. So, by doing this you are distributing code that almost always works ... in your environment if you are US, UK or similarly based. Indeed, a *really* dangerous practice. Martin Maechler, ETH Zurich Martin Morgan mtmor...@fhcrc.org on Tue, 23 Oct 2012 05:28:48 -0700 writes: On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote: On Sun, 21 Oct 2012, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling The sources in srs/library/base/conditions.R have suppressWarnings - function(expr) { ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval on.exit(options(ops)) ## calls are removed from methods code withCallingHandlers(expr, warning=function(w) invokeRestart(muffleWarning)) } I uspect we have still not entirely eliminated R_tryEval in this context but I'm not sure. Will check when I get a chance. a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } A problem with using expression matching is of course that this fails with internationalized messages. Ideally warnings should be signaled as warning conditions of a particular class, and that class can be used to discriminate. Unfortunately very few warnings are designed this way. Probably specific messages, rather than patterns, would be handled and then suppressWarnings2 - function(expr, messages = character()) { opts - options(warn = -1) on.exit(options(ops)) withCallingHandlers(expr, warning=function(w) { if (conditionMessage(w) %in% messages) invokeRestart(muffleWarning) }) } gives one the illusion
Re: [Rd] suppress *specific* warnings?
On 26/10/2012 12:04, peter dalgaard wrote: On Oct 26, 2012, at 11:17 , Martin Maechler wrote: Duncan Murdoch murdoch.dun...@gmail.com on Thu, 25 Oct 2012 06:51:25 -0400 writes: On 12-10-25 5:28 AM, Martin Maechler wrote: Sorry guys, for coming late, but *please* don't go there. I've been there years ago, and found later why the approach is flawed by design : Internationalization / Localization: - If the warning comes from a standard R function, the warning is almost surely different in a (say) German locale, and your pattern won't be detected. - Ditto if from a recommended package. - If it is a warning that is not translated then it may be that it is just not *YET* translated. I think the other Martin's suggestion addressed this: he matched the translated message, not the English original. Duncan Murdoch Well, I don't think I understand. Of course you can only match the message that warning() or error() {or rather tryCatch() ,...} produces. But you cannot guarantee nor know (for sure) if that message is 'original' or translated. cannot, because AFAIK we cannot guarantee Sys.setlocale() is obeyed platform independently: You would have to query the current and save that, set it to C, get the message, and then reset the locale to the previously saved one. And these do not work reliably, on some platforms, AFAIK and read our documentation. I think the point was to use gettext() on the pattern-to-match. If the warning is translated, so would this be. The main limitations would seem to be that you have to be d*mn sure to get the spelling right and, presumably, it only works with straight string translations, not variant forms like msgid found %d fatal error msgid_plural found %d fatal errors msgstr[0] s'ha trobat %d error fatal msgstr[1] s'han trobat %d errors fatals Yes: you also need to get the domain right (and it would be unsafe not to specify it on the gettext() call). And C-level messages do move between domains; for example between R 2.15.x and R-devel most of the graphics ones have moved from 'R' to 'graphics'. -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] suppress *specific* warnings?
Sorry guys, for coming late, but *please* don't go there. I've been there years ago, and found later why the approach is flawed by design : Internationalization / Localization: - If the warning comes from a standard R function, the warning is almost surely different in a (say) German locale, and your pattern won't be detected. - Ditto if from a recommended package. - If it is a warning that is not translated then it may be that it is just not *YET* translated. The really dangerous thing about matching error / warning messages -- I had done it in the past with the error message I caught via tryCatch() -- is that - in your tests the code will work perfectly. - on CRAN the code will work perfectly, as they also use the English (or C) locale. So, by doing this you are distributing code that almost always works ... in your environment if you are US, UK or similarly based. Indeed, a *really* dangerous practice. Martin Maechler, ETH Zurich Martin Morgan mtmor...@fhcrc.org on Tue, 23 Oct 2012 05:28:48 -0700 writes: On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote: On Sun, 21 Oct 2012, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling The sources in srs/library/base/conditions.R have suppressWarnings - function(expr) { ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval on.exit(options(ops)) ## calls are removed from methods code withCallingHandlers(expr, warning=function(w) invokeRestart(muffleWarning)) } I uspect we have still not entirely eliminated R_tryEval in this context but I'm not sure. Will check when I get a chance. a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } A problem with using expression matching is of course that this fails with internationalized messages. Ideally warnings should be signaled as warning conditions of a particular class, and that class can be used to discriminate. Unfortunately very few warnings are designed this way. Probably specific messages, rather than patterns, would be handled and then suppressWarnings2 - function(expr, messages = character()) { opts - options(warn = -1) on.exit(options(ops)) withCallingHandlers(expr, warning=function(w) { if (conditionMessage(w) %in% messages) invokeRestart(muffleWarning) }) } gives one the illusion of speaking many languages suppressWarnings2(log(-1), gettext(NaNs introduced, domain=R)) Martin Best, luke If the restart isn't invoked, then the next handler is called and the warning is handled as normal. So with f - function() { warning(oops) 2 } there is suppressWarnings2(f()) [1] 2 Warning message: In f() : oops suppressWarnings2(f(), oops) [1] 2 For your own code I think a better strategy is to create a sub-class of warnings that can be handled differently mywarn - function(..., call.=TRUE, immediate.=FALSE, domain=NULL) { msg - .makeMessage(..., domain=domain, appendLF=FALSE) call - NULL if (call.) call - sys.call(1L) class - c(silencable, simpleWarning, warning, condition) cond - structure(list(message=msg, call=call), class=class) warning(cond) } suppressWarnings3 - function(expr) { withCallingHandlers(expr, silencable=function(w) {
Re: [Rd] suppress *specific* warnings?
On 12-10-25 5:28 AM, Martin Maechler wrote: Sorry guys, for coming late, but *please* don't go there. I've been there years ago, and found later why the approach is flawed by design : Internationalization / Localization: - If the warning comes from a standard R function, the warning is almost surely different in a (say) German locale, and your pattern won't be detected. - Ditto if from a recommended package. - If it is a warning that is not translated then it may be that it is just not *YET* translated. I think the other Martin's suggestion addressed this: he matched the translated message, not the English original. Duncan Murdoch The really dangerous thing about matching error / warning messages -- I had done it in the past with the error message I caught via tryCatch() -- is that - in your tests the code will work perfectly. - on CRAN the code will work perfectly, as they also use the English (or C) locale. So, by doing this you are distributing code that almost always works ... in your environment if you are US, UK or similarly based. Indeed, a *really* dangerous practice. Martin Maechler, ETH Zurich Martin Morgan mtmor...@fhcrc.org on Tue, 23 Oct 2012 05:28:48 -0700 writes: On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote: On Sun, 21 Oct 2012, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling The sources in srs/library/base/conditions.R have suppressWarnings - function(expr) { ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval on.exit(options(ops)) ## calls are removed from methods code withCallingHandlers(expr, warning=function(w) invokeRestart(muffleWarning)) } I uspect we have still not entirely eliminated R_tryEval in this context but I'm not sure. Will check when I get a chance. a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } A problem with using expression matching is of course that this fails with internationalized messages. Ideally warnings should be signaled as warning conditions of a particular class, and that class can be used to discriminate. Unfortunately very few warnings are designed this way. Probably specific messages, rather than patterns, would be handled and then suppressWarnings2 - function(expr, messages = character()) { opts - options(warn = -1) on.exit(options(ops)) withCallingHandlers(expr, warning=function(w) { if (conditionMessage(w) %in% messages) invokeRestart(muffleWarning) }) } gives one the illusion of speaking many languages suppressWarnings2(log(-1), gettext(NaNs introduced, domain=R)) Martin Best, luke If the restart isn't invoked, then the next handler is called and the warning is handled as normal. So with f - function() { warning(oops) 2 } there is suppressWarnings2(f()) [1] 2 Warning message: In f() : oops suppressWarnings2(f(), oops) [1] 2 For your own code I think a better strategy is to create a sub-class of warnings that can be handled differently mywarn - function(..., call.=TRUE, immediate.=FALSE, domain=NULL) { msg - .makeMessage(..., domain=domain, appendLF=FALSE) call - NULL if (call.) call - sys.call(1L) class -
Re: [Rd] suppress *specific* warnings?
On Sun, 21 Oct 2012, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling The sources in srs/library/base/conditions.R have suppressWarnings - function(expr) { ops - options(warn = -1) ## FIXME: temporary hack until R_tryEval on.exit(options(ops)) ## calls are removed from methods code withCallingHandlers(expr, warning=function(w) invokeRestart(muffleWarning)) } I uspect we have still not entirely eliminated R_tryEval in this context but I'm not sure. Will check when I get a chance. a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } A problem with using expression matching is of course that this fails with internationalized messages. Ideally warnings should be signaled as warning conditions of a particular class, and that class can be used to discriminate. Unfortunately very few warnings are designed this way. Best, luke If the restart isn't invoked, then the next handler is called and the warning is handled as normal. So with f - function() { warning(oops) 2 } there is suppressWarnings2(f()) [1] 2 Warning message: In f() : oops suppressWarnings2(f(), oops) [1] 2 For your own code I think a better strategy is to create a sub-class of warnings that can be handled differently mywarn - function(..., call.=TRUE, immediate.=FALSE, domain=NULL) { msg - .makeMessage(..., domain=domain, appendLF=FALSE) call - NULL if (call.) call - sys.call(1L) class - c(silencable, simpleWarning, warning, condition) cond - structure(list(message=msg, call=call), class=class) warning(cond) } suppressWarnings3 - function(expr) { withCallingHandlers(expr, silencable=function(w) { invokeRestart(muffleWarning) }) } then with g - function() { mywarn(oops) 3 } suppressWarnings3(f()) [1] 2 Warning message: In f() : oops g() [1] 3 Warning message: In g() : oops suppressWarnings3(g()) [1] 3 withCallingHandlers(expr, warning = function(w) { ## browser() if (is.null(regex) || grepl(w[[message]],regex)) { invokeRestart(muffleWarning) } else { ## ? what do I here to get the warning issued? ## browser() ## computeRestarts() shows browser, ##muffleWarning, and abort ... options(opts) warning(w$message) ## how can I get back from here to the calling point ## *without* muffling warnings ... ? } }) } suppressWarnings2(sqrt(-1)) suppressWarnings2(sqrt(-1),abc) It seems to me I'd like to have a restart option that just returns to the point where the warning was caught, *without* muffling warnings ... ? But I don't quite understand how to set one up ... Ben Bolker __ 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: 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] suppress *specific* warnings?
Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) withCallingHandlers(expr, warning = function(w) { ## browser() if (is.null(regex) || grepl(w[[message]],regex)) { invokeRestart(muffleWarning) } else { ## ? what do I here to get the warning issued? ## browser() ## computeRestarts() shows browser, ##muffleWarning, and abort ... options(opts) warning(w$message) ## how can I get back from here to the calling point ## *without* muffling warnings ... ? } }) } suppressWarnings2(sqrt(-1)) suppressWarnings2(sqrt(-1),abc) It seems to me I'd like to have a restart option that just returns to the point where the warning was caught, *without* muffling warnings ... ? But I don't quite understand how to set one up ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling a warning). I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } If the restart isn't invoked, then the next handler is called and the warning is handled as normal. So with f - function() { warning(oops) 2 } there is suppressWarnings2(f()) [1] 2 Warning message: In f() : oops suppressWarnings2(f(), oops) [1] 2 For your own code I think a better strategy is to create a sub-class of warnings that can be handled differently mywarn - function(..., call.=TRUE, immediate.=FALSE, domain=NULL) { msg - .makeMessage(..., domain=domain, appendLF=FALSE) call - NULL if (call.) call - sys.call(1L) class - c(silencable, simpleWarning, warning, condition) cond - structure(list(message=msg, call=call), class=class) warning(cond) } suppressWarnings3 - function(expr) { withCallingHandlers(expr, silencable=function(w) { invokeRestart(muffleWarning) }) } then with g - function() { mywarn(oops) 3 } suppressWarnings3(f()) [1] 2 Warning message: In f() : oops g() [1] 3 Warning message: In g() : oops suppressWarnings3(g()) [1] 3 withCallingHandlers(expr, warning = function(w) { ## browser() if (is.null(regex) || grepl(w[[message]],regex)) { invokeRestart(muffleWarning) } else { ## ? what do I here to get the warning issued? ## browser() ## computeRestarts() shows browser, ##muffleWarning, and abort ... options(opts) warning(w$message) ## how can I get back from here to the calling point ## *without* muffling warnings ... ? } }) } suppressWarnings2(sqrt(-1)) suppressWarnings2(sqrt(-1),abc) It seems to me I'd like to have a restart option that just returns to the point where the warning was caught, *without* muffling warnings ... ? But I don't quite understand how to set one up ... Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 12-10-21 09:08 PM, Martin Morgan wrote: On 10/21/2012 12:28 PM, Ben Bolker wrote: Not desperately important, but nice to have and possibly of use to others, is the ability to suppress specific warnings rather than suppressing warnings indiscriminately. I often know of a specific warning that I want to ignore (because I know that's it's a false positive/ignorable), but the current design of suppressWarnings() forces me to ignore *any* warnings coming from the expression. I started to write a new version that would check and, if supplied with a regular expression, would only block matching warnings and otherwise would produce the warnings as usual, but I don't quite know enough about what I'm doing: see ??? in expression below. Can anyone help, or suggest pointers to relevant examples/documentation (I've looked at demo(error.catching), which isn't helping me ... ?) suppressWarnings2 - function(expr,regex=NULL) { opts - options(warn = -1) on.exit(options(opts)) I'm not really sure what the options(warn=-1) is doing there, maybe its for efficiency to avoid generating a warning message (as distinct from signalling a warning). As may have been obvious, I was copying suppressWarnings() verbatim -- so I guess you'd have to ask R-core for the reasoning there ... I think you're after something like suppressWarnings2 - function(expr, regex=character()) { withCallingHandlers(expr, warning=function(w) { if (length(regex) == 1 length(grep(regex, conditionMessage(w { invokeRestart(muffleWarning) } }) } If the restart isn't invoked, then the next handler is called and the warning is handled as normal. So with f - function() { warning(oops) 2 } there is suppressWarnings2(f()) [1] 2 Warning message: In f() : oops suppressWarnings2(f(), oops) [1] 2 Great, thank you! For your own code I think a better strategy is to create a sub-class of warnings that can be handled differently mywarn - function(..., call.=TRUE, immediate.=FALSE, domain=NULL) { msg - .makeMessage(..., domain=domain, appendLF=FALSE) call - NULL if (call.) call - sys.call(1L) class - c(silencable, simpleWarning, warning, condition) cond - structure(list(message=msg, call=call), class=class) warning(cond) } suppressWarnings3 - function(expr) { withCallingHandlers(expr, silencable=function(w) { invokeRestart(muffleWarning) }) } then with g - function() { mywarn(oops) 3 } suppressWarnings3(f()) [1] 2 Warning message: In f() : oops g() [1] 3 Warning message: In g() : oops suppressWarnings3(g()) [1] 3 withCallingHandlers(expr, warning = function(w) { ## browser() if (is.null(regex) || grepl(w[[message]],regex)) { invokeRestart(muffleWarning) } else { ## ? what do I here to get the warning issued? ## browser() ## computeRestarts() shows browser, ##muffleWarning, and abort ... options(opts) warning(w$message) ## how can I get back from here to the calling point ## *without* muffling warnings ... ? } }) } suppressWarnings2(sqrt(-1)) suppressWarnings2(sqrt(-1),abc) It seems to me I'd like to have a restart option that just returns to the point where the warning was caught, *without* muffling warnings ... ? But I don't quite understand how to set one up ... Ben Bolker __ 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