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

[Charles C. Berry]

On Thu, 7 Aug 2014, Aaron Ecay wrote:

> Hi Chuck,
>
> Thanks for your feedback.
>
> 2014ko abuztuak 7an, "Charles C. Berry"-ek idatzi zuen:
> > Hi Aaron,
> >
> > I like what you are trying to do, but ...
> >
> > 1) The change has at least one bug: Remote sessions are broken by this
> > change.
> >
> > 2) The behavior of :results output is modified in ways that might not be
> > desired. i.e. warnings and errors will not show up in the output.

[snip issue 1 discussion]

> > Issue 2) ===========
> >
> > ECM:
> >
> > #+NAME: aa
> > #+BEGIN_SRC R :session R2 :results output
> > warning("this is a warning")
> > 1+1
> > #+END_SRC
> >
> > #+RESULTS: aa
> > : [1] 2
> >
> > For some purposes having the warnings in the #+RESULTS: block is helpful.
> >
> > And when revising code, having the errors in the #+RESULTS helps -
> > especially if I have to put aside work in progress.
>
> Hmm.  Certainly, the previous behavior should be retained for now.  In
> the longer term, I’d like to see a system whereby R errors trigger elisp
> errors.  This is so that the execution of a whole document (subtree,
> etc.) will be halted by the first error, rather than continuing what may
> be a long series of commands that will not give valid output.  What do
> you think?

I need a while to sort through this. stop(), warning(), and message() will 
print to the session but not show up in what capture.output retains.

sink() has the ability to capture those things, but there is added 
baggage.

I fear some study of ?conditions is needed. My knowledge of condition 
handling in R is scant.

As for stopping on error, I think that anything that changes current 
behavior at this late date ought to be configurable.

FWIW, when I export documents, I sometimes get innocuous errors that I am 
happy did not stop the run in its tracks - like formatting one table fails 
with an error but all else went through. And sometimes I wish it had 
stopped.

Best,

Chuck