From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: R code block produces only partial output Date: Sat, 16 Aug 2014 11:50:00 -0700 Message-ID: References: <87iom8zd24.fsf@gmail.com> <877g2oz9gv.fsf@gmail.com> <87lhr27oap.fsf@gmail.com> <87r40uwavs.fsf@gmail.com> <8761i5kg8f.fsf@gmail.com> <87ppgcrg8n.fsf@gmail.com> <87lhr0qimr.fsf@gmail.com> <87wqa9owhv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1495617002-1408210432=:605" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIj3R-0002ij-FV for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 14:50:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XIj3K-00013T-Jz for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 14:50:17 -0400 Received: from iport-acv1-out.ucsd.edu ([132.239.0.176]:47713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIj3K-000124-7L for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 14:50:10 -0400 In-Reply-To: <87wqa9owhv.fsf@gmail.com> Content-ID: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Aaron Ecay Cc: emacs-orgmode@gnu.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1495617002-1408210432=:605 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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 --0-1495617002-1408210432=:605--