From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Aaron Ecay <aaronecay@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: R code block produces only partial output
Date: Sat, 16 Aug 2014 11:50:00 -0700 [thread overview]
Message-ID: <alpine.OSX.2.00.1408161025380.605@charles-berrys-macbook.local> (raw)
In-Reply-To: <87wqa9owhv.fsf@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2060 bytes --]
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
next prev parent reply other threads:[~2014-08-16 18:50 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
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 [this message]
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.1408161025380.605@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).