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

[Aaron Ecay]

Hi Chuck,

Thanks for your feedback.

2014ko abuztuak 16an, "Charles C. Berry"-ek idatzi zuen:
> 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.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That’s ... special.  Do you have experience with such environments?

> 
> So, making it optional might be necessary.

I don’t like this idea; it means that we’d have to support the old,
hacky way of doing things indefinitely.  I’d like to hear more from
people for whom local installation of R packages creates an issue.

> 
> ---
> 
> 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().

I’m not sure I see what you mean.  The tryCatch exists to ensure that
the sentinel file is created, to signal emacs that the R code is done
running.  It might not be strictly necessary, as long as the rest of
babel’s injected code is error-free (evaluate takes care of catching
errors in user code).  But emacs will busy-wait indefinitely if the
creation of that file does not happen, so I have tried to play it safe.

As for capture.output, the knitr function you reference is doing a lot
of heavy lifting; I don’t understand it all.  I just need to get the
result of evaluate() into a file somehow.  There are other ways of doing
this than capture.output + replay, but it seems like they’d be just as
complicated.

> 
> - 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.

I omitted to rm() .org.eval.result for debugging purposes, but in the
final patch I will do so.  I much prefer an explicit variable creation /
rm() to environment-hacking.

> 
> - 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!)

I don’t like this, since it would not carry over to the other 3/4
cases (value results in a session; either type of result outside of a
session).  I’d like to get this patch working first, and then focus on
the others.  It may be that we want to move to using the evaluate
package in all cases, in which case this suggestion would be workable.

-- 
Aaron Ecay