From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lawrence Mitchell Subject: Re: [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it Date: Fri, 03 Jun 2011 09:33:57 +0100 Message-ID: References: <1307009045-10010-1-git-send-email-wence@gmx.li> <1307009045-10010-2-git-send-email-wence@gmx.li> <87y61k9jil.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:47851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSPpe-0000AQ-KQ for emacs-orgmode@gnu.org; Fri, 03 Jun 2011 04:34:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSPpd-00042u-Fk for emacs-orgmode@gnu.org; Fri, 03 Jun 2011 04:34:14 -0400 Received: from lo.gmane.org ([80.91.229.12]:48595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSPpd-00042b-Ai for emacs-orgmode@gnu.org; Fri, 03 Jun 2011 04:34:13 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QSPpa-0004He-AT for emacs-orgmode@gnu.org; Fri, 03 Jun 2011 10:34:10 +0200 Received: from e4300lm.epcc.ed.ac.uk ([129.215.63.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 10:34:10 +0200 Received: from wence by e4300lm.epcc.ed.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 10:34:10 +0200 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: emacs-orgmode@gnu.org 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