On Fri, 15 Aug 2014, Aaron Ecay wrote: > Hi Chuck, hi all, > > Attached to this message is a draft patch to complete this idea. It > should address the issue of including warnings, errors, and messages in > output. > > It uses the “evaluate” R package, originally created for the knitr > literate programming system, to do most of the heavy lifting, and > includes a new mechanism to load this package into babel sessions (and > to prompt the user to install it from CRAN, if not already installed). > > It does not yet address Chuck’s first issue of remote sessions, just > because I haven’t had time to look at it in detail (but I still think it > should be easy, based on the code sample/hint that Chuck gave). > > What do you think of the approach broadly? > Aaron, I think doing something along these lines makes sense. evaluate() obviates the need for tryCatch() and capture.output(), and it makes customizing error/warning/message stuff clean. Its use might also lead to cleaner code for R graphics handling. But adding a dependency on the evaluate package is a significant step. This could be a nuisance for users whose code runs just fine right now. It would need to be installed anywhere R is executed, e.g. in remote sessions. The user would need to install it in her private directory if it is not on the system; some shops actually discourage this. So, making it optional might be necessary. --- I looked at the patch briefly. Some comments: - You can ditch tryCatch and capture.output. You might browse knitr:::block_exec to see how it uses evaluate(). - Wrap the code in local() to keep objects you create from persisting where they might not be wanted. I think using local({ res <- evaluate(input, envir=parent.frame(2),...); <...>}) will get assignments from `input' properly placed. - let stop_on_error, keep_warning, and keep_message args be customizable or depend on a header arg. (Then I can stop wrapping require() in suppressPackageStartupMessages() which I always misspell. Argh!) HTH, Chuck