From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Schulte <schulte.eric@gmail.com>
Subject: Re: [Babel] [Bug] Cache
Date: Fri, 22 Nov 2013 08:03:16 -0700
Message-ID: <87d2lsihdr.fsf@gmail.com>
References: <86fvqqc8jb.fsf@somewhere.org>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49637)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1VjshT-0005kg-1v
	for emacs-orgmode@gnu.org; Fri, 22 Nov 2013 10:31:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1VjshN-0003Lo-3E
	for emacs-orgmode@gnu.org; Fri, 22 Nov 2013 10:31:19 -0500
Received: from mail-pd0-x230.google.com ([2607:f8b0:400e:c02::230]:41742)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <schulte.eric@gmail.com>) id 1VjshM-0003Lh-TN
	for emacs-orgmode@gnu.org; Fri, 22 Nov 2013 10:31:13 -0500
Received: by mail-pd0-f176.google.com with SMTP id w10so1379506pde.21
	for <emacs-orgmode@gnu.org>; Fri, 22 Nov 2013 07:31:12 -0800 (PST)
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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 <sva-news@mygooglest.com>
Cc: emacs-orgmode@gnu.org

Hi Seb,

Could you git bisect this breakage to isolate the offending commit?

Thanks,

"Sebastien Vauban" <sva-news@mygooglest.com> writes:

> Hello Eric,
>
> 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".
>
> Best regards,
>   Seb

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D