From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Date: Wed, 13 Mar 2013 00:12:49 -0400 Message-ID: <87mwu8aqf2.fsf@gmail.com> References: <1362542863-25992-1-git-send-email-aaronecay@gmail.com> <87obetsgma.fsf@Rainer.invalid> <877glhsfus.fsf@gmail.com> <87k3phs84b.fsf@Rainer.invalid> <87ip50qv36.fsf@gmail.com> <87y5dvocw5.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFd3f-0004a2-M0 for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 00:12:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFd3c-00046S-KQ for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 00:12:55 -0400 Received: from mail-qa0-f44.google.com ([209.85.216.44]:60945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFd3c-00046K-GS for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 00:12:52 -0400 Received: by mail-qa0-f44.google.com with SMTP id bv4so2018349qab.3 for ; Tue, 12 Mar 2013 21:12:52 -0700 (PDT) In-Reply-To: <87y5dvocw5.fsf@Rainer.invalid> 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: Achim Gratz Cc: emacs-orgmode@gnu.org Hi Achim, 2013ko martxoak 10an, Achim Gratz-ek idatzi zuen: > 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. See the > example below where after the first invocation I change the source block > referenced to deliver a different result. That invalidates the cache > for direct invocation of that block, but fails to do so for the indirect > invocation. If you look at the two result blocks, you see that the same > hash is added to two different blocks. I think this points in the direction of having the notion of dependencies among source blocks. This is an idea that knitr (http://yihui.name/knitr/) implements. The idea would be to include in the hash of a source block X (in addition to all the pieces that are already in the hash) the hash of the blocks that X depends on. So in your example, the data that generated the hashes beginning 0bd... would be made distinct, because they would include in one case the hash 6bd... and in the other d8d... . As in knitr, I think that manual dependency specification (e.g. in the header args of the block) should be possible. But it would also be possible to automatically infer that a block depends on any block that it references via a :var header or noweb reference =E2=80=93 which would in= turn automatically fix the case you discussed. And when evaluating a block, the dependencies should be (recursively) evaluated first, in case any of them has changed. Is it clear what I am describing, and do you have thoughts on it? >=20 >> If one did want to move hashes to code blocks it would be a major >> refactoring which would (in my opinion) require significant >> justification. >=20 > I'm not disputing that it requires significant effort. The benefits > would be that we might have a chance to clear up some confusion over the > code execution model of Babel and better support different ones. FWIW, I think that hashes shouldn=E2=80=99t be stored in the buffer text at= all. They=E2=80=99re not really part of the document data or metadata. Rather, = they are information about how the content of the document (code and its results) was instantiated/computed in a particular environment/occasion. I=E2=80=99d rather see them stored in a lisp data structure. They could be written out to an invisible file when the org buffer is saved, and re-read on load. > Oh yes, there's a whole set of _other_ problems that are waiting to be > solved. :-) There always is. :-) --=20 Aaron Ecay