From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Date: Wed, 13 Mar 2013 08:42:45 -0600 Message-ID: <874ngfe4sx.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> <87mwu8aqf2.fsf@gmail.com> 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]:60051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFmwe-0001CL-90 for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFmwU-0006NG-O2 for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:20 -0400 Received: from mail-da0-x22b.google.com ([2607:f8b0:400e:c00::22b]:37576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFmwU-0006N7-EJ for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:10 -0400 Received: by mail-da0-f43.google.com with SMTP id u36so449141dak.30 for ; Wed, 13 Mar 2013 07:46:09 -0700 (PDT) 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 Aaron Ecay writes: > 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. > This is what is already taking place. The :var header arguments are automatically expanded into dependencies between code blocks, and the results of previous code blocks are included in the hash calculation of the current code block. >From re-looking at Achim's previous noweb example, it seems that we currently do *not* include the values of noweb expansions in code block hash calculations, I think this is a bug which should be fixed. > > And when evaluating a block, the dependencies should be (recursively) > evaluated first, in case any of them has changed. > This is exactly what happens currently with previous blocks referenced through :var header arguments. > > Is it clear what I am describing, and do you have thoughts on it? > Very, thank you for spelling it out. I believe that given the bug fix just mentioned, the current model indeed does support automatic inference of dependencies between blocks. > >>=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. To echo Achim's response, you've accidentally uttered Org-mode heresy. A core design principle is that everything be represented as plain text in the buffer. That said, the hashes should be largely hidden by default, and the degree of hiding can be controlled by the `org-babel-hash-show' variable. >=20 > 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. :-) I think Org-mode already provides the bulk of what is desired. If we agree to treat ":cache yes :results none" as obviously taking place for side effects, and then sticking a hash behind the :cache header argument with the code block, then what functionality would be missing? Thanks, --=20 Eric Schulte http://cs.unm.edu/~eschulte