emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] ob-R, problem with try/catch


From: Aaron Ecay
Subject: Re: [O] ob-R, problem with try/catch
Date: Thu, 23 Apr 2015 17:42:19 +0100
User-agent: Notmuch/0.19+52~g1722ea2 (http://notmuchmail.org) Emacs/25.0.50.4 (x86_64-unknown-linux-gnu)

Hello all,

2015ko apirilak 23an, Rainer M Krug-ek idatzi zuen:
>> I'm picking up a project that I last worked on in 2013.  I was under the
>> impression that the source code blocks were working at that time, but I
>> guess it is possible that I added the rm() statements after the code
>> blocks were working and didn't realize that the addition broke them.
> 
> The rm() did not break anything. The behavior that if you want to have
> a ggplot (and e.g. Lattice as well) in a pdf/png/... You have to use
> print() is standard R behavior and was the same before. This question
> question comes up from time to time on the R list as well. And I don't
> think this can be easily be dealt with in org, as it is standard R.

Before this change, the code was fed line-by-line to the R interpreter,
and thus each line was auto printed.  (Technically, the result of each
expresion, whcih could span multiple lines.)  After this change, the
code is one expression, and only the result of the whole block is
printed.  Thus the different behavior.

The previous behavior was not unproblematic.  If a code block contained
more than one plot, the results would have been odd: for a pdf device a
multi-page pdf is generated.  For jpg/png, several files are generated
with a sequence number appended to each.

The principled approach is to use the evaluate package for this.  I had
worked on a patch to move towards this approach, but the effort stalled
when Charles Berry reported some regressions with remote sessions, which
I was never able to reproduce (and thus fix) satisfactorily.  The patch
is here: <http://mid.gmane.org/address@hidden>.

In any case, it is clear that one of the workarounds discussed in
this thread should be used.  Perhaps we should generate a warning for
“:results output graphics” R code blocks, since they could produce
this strange situation.  A priori, I expect that “:results value
graphics” should be free from this problem.

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]