From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [Babel] [Bug] Cache Date: Fri, 06 Dec 2013 12:15:14 -0700 Message-ID: <87d2l96b2y.fsf@gmail.com> References: <86fvqqc8jb.fsf@somewhere.org> <87d2lsihdr.fsf@gmail.com> <86k3fnw905.fsf@somewhere.org> 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]:50601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vp0xO-00059G-BI for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 14:21:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vp0xJ-0007mK-I8 for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 14:20:58 -0500 Received: from mail-pb0-x235.google.com ([2607:f8b0:400e:c01::235]:45301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vp0xJ-0007mG-9s for emacs-orgmode@gnu.org; Fri, 06 Dec 2013 14:20:53 -0500 Received: by mail-pb0-f53.google.com with SMTP id ma3so1597466pbc.26 for ; Fri, 06 Dec 2013 11:20:52 -0800 (PST) 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: Sebastien Vauban Cc: emacs-orgmode@gnu.org "Sebastien Vauban" writes: > Hi Eric, > > Eric Schulte wrote: >> "Sebastien Vauban" writes: >>> >>> IIRC, some time ago, a bug involving the computation of the hash (when >>> option cache is enabled) and NoWeb code blocks. I remember that it had = been >>> fixed. >>> >>> However, the following example shows it's not (true anymore): >>> >>> --8<---------------cut here---------------start------------->8--- >>> #+PROPERTY: cache yes >>> >>> #+name: common-code >>> #+begin_src R :eval no >>> s <- "Hello" >>> #+end_src >>> >>> #+begin_src R :noweb yes >>> <> >>> >>> print(s) >>> #+end_src >>> >>> #+results[f472c44e64e310a6d06544dbdfba558a709873a7]: >>> : Hello >>> --8<---------------cut here---------------end--------------->8--- >>> >>> Change the "common code" block: edit "Hello", for example, and you'll s= ee >>> that the evaluation of the other code block is not redone (like if the = NoWeb >>> code was not expanded for computing the hash). It stays printing "Hello= ". >> >> Could you git bisect this breakage to isolate the offending commit? > > I couldn't find any version where my ECM would work. Though, I was sure t= o have > read comments about that problem -- I never used that situation myself in= the > past, so I just assumed it had been fixed in the meanwhile. It seems not. > > And here the post of Achim where he explains that problem: > > =E2=95=AD=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > =E2=94=82 From: Achim Gratz > =E2=94=82 Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src= -block): > =E2=94=82 insert hash for silent results > =E2=94=82 Date: Sun, 10 Mar 2013 09:52:10 +0100 (38 weeks, 1 day, 6 hou= rs ago) > =E2=94=82 > =E2=94=82 [...] > =E2=94=82 > =E2=94=82 But back to my earlier remark about the hash value actually b= eing a > =E2=94=82 signature of the source block and not the result. If I use n= oweb > =E2=94=82 references, the reference text is cached, not its expansion. > =E2=95=B0=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > In that thread we agreed that the expansion of no-web references *should* be included in code blocks for hashing, but no-one has had the time to implement this. I believe this is still the case. --=20 Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D