Re: [O] R code block produces only partial output

[Charles C. Berry]

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