Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" <sva-n...@mygooglest.com> 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 >> <<common-code>> >> >> print(s) >> #+end_src >> >> #+results[f472c44e64e310a6d06544dbdfba558a709873a7]: >> : Hello >> --8<---------------cut here---------------end--------------->8--- >> >> Change the "common code" block: edit "Hello", for example, and you'll see >> 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 to 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: ╭──── │ From: Achim Gratz <strom...@nexgo.de> │ Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): │ insert hash for silent results │ Date: Sun, 10 Mar 2013 09:52:10 +0100 (38 weeks, 1 day, 6 hours ago) │ │ [...] │ │ But back to my earlier remark about the hash value actually being a │ signature of the source block and not the result. If I use noweb │ references, the reference text is cached, not its expansion. ╰──── Best regards, Seb -- Sebastien Vauban
