emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Aaron Ecay <aaronecay@gmail.com>
Cc: emacs-orgmode@gnu.org, Eric Schulte <schulte.eric@gmail.com>
Subject: Re: R code block produces only partial output
Date: Thu, 7 Aug 2014 11:42:29 -0700	[thread overview]
Message-ID: <alpine.OSX.2.00.1408071111430.348@charles-berrys-macbook.local> (raw)
In-Reply-To: <87lhr0qimr.fsf@gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1934 bytes --]

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

  reply	other threads:[~2014-08-07 18:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04 11:18 R code block produces only partial output Andreas Kiermeier
2014-08-04 11:53 ` Eric Schulte
2014-08-04 12:23   ` Andreas Kiermeier
2014-08-04 13:10     ` Eric Schulte
2014-08-05  0:46       ` Andreas Kiermeier
2014-08-05  4:00         ` John Hendy
2014-08-05  4:31           ` Andreas Kiermeier
2014-08-05 18:05       ` Charles Berry
2014-08-05 19:02         ` Eric Schulte
2014-08-05 19:11           ` John Hendy
2014-08-05 19:57             ` Nick Dokos
2014-08-05 20:10               ` Nick Dokos
2014-08-05 22:21             ` Charles C. Berry
2014-08-06  3:32           ` Aaron Ecay
2014-08-06 11:30             ` Eric Schulte
2014-08-07  6:00               ` Aaron Ecay
2014-08-07 17:42                 ` Charles C. Berry
2014-08-07 18:06                   ` Aaron Ecay
2014-08-07 18:42                     ` Charles C. Berry [this message]
2014-08-07 19:06                       ` Thomas S. Dye
2014-08-09  8:54                       ` Rainer M Krug
2014-08-16  5:05                     ` Aaron Ecay
2014-08-16 18:50                       ` Charles C. Berry
2014-08-16 20:58                         ` Aaron Ecay
2014-08-17  6:03                           ` Achim Gratz
2014-08-19  0:13                             ` Aaron Ecay
2014-08-19  5:36                               ` Achim Gratz
2014-08-23  8:32                                 ` Aaron Ecay
2014-08-23  9:24                                   ` Andreas Kiermeier
2014-08-23 17:10                                   ` Aaron Ecay
2014-08-23 18:35                                   ` Thomas S. Dye
2014-08-23 19:37                                     ` Ista Zahn
2014-08-24  0:10                           ` Charles C. Berry
2014-08-28  5:24                             ` Aaron Ecay
2014-09-01  5:00                               ` Aaron Ecay
2014-09-01 16:08                                 ` Charles C. Berry
2014-08-09  8:48                   ` Rainer M Krug
2014-08-06  1:11         ` Andreas Kiermeier
2014-08-06  2:21           ` Charles C. Berry
2014-08-06  3:24             ` Aaron Ecay
2014-08-06 15:59               ` Charles C. Berry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.OSX.2.00.1408071111430.348@charles-berrys-macbook.local \
    --to=ccberry@ucsd.edu \
    --cc=aaronecay@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=schulte.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).