From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: R code block produces only partial output Date: Sat, 16 Aug 2014 16:58:25 -0400 Message-ID: <87oavkp2xa.fsf@gmail.com> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIl3d-0004II-R5 for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 16:58:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XIl3U-0007mC-K0 for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 16:58:37 -0400 Received: from mail-qa0-x235.google.com ([2607:f8b0:400d:c00::235]:51947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIl3U-0007m7-EH for emacs-orgmode@gnu.org; Sat, 16 Aug 2014 16:58:28 -0400 Received: by mail-qa0-f53.google.com with SMTP id v10so3141570qac.26 for ; Sat, 16 Aug 2014 13:58:27 -0700 (PDT) In-Reply-To: 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: "Charles C. Berry" Cc: emacs-orgmode@gnu.org Hi Chuck, Thanks for your feedback. 2014ko abuztuak 16an, "Charles C. Berry"-ek idatzi zuen: > Aaron, >=20 > I think doing something along these lines makes sense. evaluate() obviate= s=20 > the need for tryCatch() and capture.output(), and it makes customizing=20 > error/warning/message stuff clean. Its use might also lead to cleaner cod= e=20 > for R graphics handling. >=20 > But adding a dependency on the evaluate package is a significant step.=20 > This could be a nuisance for users whose code runs just fine right now. I= t=20 > would need to be installed anywhere R is executed, e.g. in remote=20 > sessions. The user would need to install it in her private directory if i= t=20 > is not on the system; some shops actually discourage this. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That=E2=80=99s ... special. Do you have experience with such environments? >=20 > So, making it optional might be necessary. I don=E2=80=99t like this idea; it means that we=E2=80=99d have to support = the old, hacky way of doing things indefinitely. I=E2=80=99d like to hear more from people for whom local installation of R packages creates an issue. >=20 > --- >=20 > I looked at the patch briefly. Some comments: >=20 > - You can ditch tryCatch and capture.output. You might browse > knitr:::block_exec to see how it uses evaluate(). I=E2=80=99m not sure I see what you mean. The tryCatch exists to ensure th= at 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=E2=80=99s 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=E2=80=99t 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=E2=80=99d be just= as complicated. >=20 > - 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=3Dparent.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. >=20 > - 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=E2=80=99t 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=E2=80=99d 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. --=20 Aaron Ecay