emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it


From: Lawrence Mitchell
Subject: Re: [O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it
Date: Fri, 03 Jun 2011 09:33:57 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

Eric Schulte wrote:
> Hi Lawrence,

> Is there a reason to make this copy?  Given that params is used like a
> hash/dictionary the order of it's elements should not matter.  Is there
> a case where this patch is necessary to avoid buggy behavior?

Ah, but the sorting is happening so that the hashing function is
stable to changes in the order of the arguments, no?  So I think
sorting is necessary.  At least, the sort was already there, I've
just added the copy-sequence.

> If so then I'm happy to apply the patch, but if there is no need then
> I'd rather avoid the (admittedly small) overhead of making a copy of the
> params list.

[...]

It seems to be necessary to correctly link to the produced
graphics output from (say) R plotting if :cache yes is specified.
Try this without the patch:

* header
#+begin_src R :cache yes :exports results :file plot.png :results graphics
  curve(1*x, from=1, to=10, lwd=2)
#+end_src

#+results:

and evaluate the code block, we get:

#+results[4d3e7ef5e40f7b608d400c310401c15e913a22c0]:
: plot.png

Rather than the (correct):
#+results[4d3e7ef5e40f7b608d400c310401c15e913a22c0]:
[[file:plot.png]]

The problem is that (sort v 'string<) destructively modifies v,
and in this case, that means that the "file" argument to
:result-params in thrown away.

Lawrence
-- 
Lawrence Mitchell <address@hidden>




reply via email to

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