From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz 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 Message-ID: <87y5dvocw5.fsf@Rainer.invalid> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEbzp-0003fl-CO for emacs-orgmode@gnu.org; Sun, 10 Mar 2013 04:52:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEbzn-0003yz-K7 for emacs-orgmode@gnu.org; Sun, 10 Mar 2013 04:52:45 -0400 Received: from plane.gmane.org ([80.91.229.3]:41843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEbzn-0003yv-9t for emacs-orgmode@gnu.org; Sun, 10 Mar 2013 04:52:43 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UEc06-0004Ur-28 for emacs-orgmode@gnu.org; Sun, 10 Mar 2013 09:53:02 +0100 Received: from pd9eb4c29.dip.t-dialin.net ([217.235.76.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Mar 2013 09:53:02 +0100 Received: from Stromeko by pd9eb4c29.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Mar 2013 09:53:02 +0100 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: emacs-orgmode@gnu.org Eric Schulte writes: > A hash marks a *result* with an indication of what was used to generate > it (code block & parameters). The point of a hash is to allow the > result to be returned without having to re-execute. For this reason, I > think that the hash should live with the result. Here Babel is assuming a very specific execution model, namely a functional one (a function with the same parameters always delivers the same results, so if you see the same function invoked with the same parameters you can just substitute the result from an earlier invocation). Babel isn't a functional language however, so it is both possible and done in practice to use it for side-effects or even side-effects only. 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. --8<---------------cut here---------------start------------->8--- #+name: list #+header: :exports none :results yes :eval query :cache yes #+begin_src emacs-lisp '(a b c d) #+end_src #+RESULTS[6bd0507c2cc972cc7647a9c2c169a1095bab5941]: list | a | b | c | d | #+RESULTS[d8dad02c5c6fd93a991a4bb23471f273cc0b3415]: list-1 | a | b | c | #+name: indirect #+header: :noweb yes #+header: :exports none :results yes :eval query :cache yes #+begin_src emacs-lisp <> #+end_src #+RESULTS[0b6ada101242e80d4d50f4909f33d8819a88ea4e]: indirect | a | b | c | d | #+RESULTS[0b6ada101242e80d4d50f4909f33d8819a88ea4e]: indirect-1 | a | b | c | --8<---------------cut here---------------end--------------->8--- I'm not saying this needs fixing (expanding references could easily be the most costly step in a re-evaluation), but the description in the manual talks about caching in terms of results which is not what is actually implemented, as demonstrated above. > In general a hash without a result doesn't make sense (because then > what is cached?). If the question was meant as "did this code block already run?" and the invocation was for side-effects only, then it does make sense to me. > If one did want to move hashes to code blocks it would be a major > refactoring which would (in my opinion) require significant > justification. 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. > As I understand this particular case, the OP is using a hash not to mark > a result as up to date, but rather to mark a side effect (loading data > into R) as having taken place. I think this is a misuse of a cache. Or you might call it a clever hack. But I think the general problem of needing one-time invocations of source blocks is one that comes up often when programming with side-effects that are not directly observable. This again comes in different shades, I'd often want to run some blocks only when the document is first opened, but then only again if something changes. This would require that the hash value was a property of the buffer text, not actual buffer text, I'd think. Sure, you can use hooks to nuke the caches on load, but that only works when you are using your own Emacs configuration. > What if the R process restarts? The hash would still be valid, but the > side effects have been lost. I think a better approach would be to > implement the logic in R required to check if data is present and > conditionally load it if not. Then simply re-run this conditional > reloading code in full every time. Oh yes, there's a whole set of _other_ problems that are waiting to be solved. :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada