emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
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	[thread overview]
Message-ID: <87y5dvocw5.fsf@Rainer.invalid> (raw)
In-Reply-To: 87ip50qv36.fsf@gmail.com

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
<<list>>
#+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

  parent reply	other threads:[~2013-03-10  8:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06  4:07 [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Aaron Ecay
2013-03-08 21:25 ` Aaron Ecay
2013-03-08 22:07   ` Eric Schulte
2013-03-08 21:53 ` Achim Gratz
2013-03-08 22:09   ` Eric Schulte
2013-03-08 22:24     ` aaronecay
2013-03-09 17:45       ` Eric Schulte
2013-03-09 18:56         ` Aaron Ecay
2013-03-09 20:03         ` Achim Gratz
2013-03-09  0:57     ` Achim Gratz
2013-03-09 18:35       ` Eric Schulte
2013-03-09 19:22         ` Aaron Ecay
2013-03-09 20:26           ` Eric Schulte
2013-03-13  3:55             ` Aaron Ecay
2013-03-13 14:45               ` Eric Schulte
2013-03-19  4:49                 ` Aaron Ecay
2013-03-23 22:34                   ` Eric Schulte
2013-04-01  5:10                     ` Aaron Ecay
2013-04-02 22:14                       ` Eric Schulte
2013-03-10  8:52         ` Achim Gratz [this message]
2013-03-10 20:14           ` Sebastien Vauban
2013-03-10 21:06             ` Achim Gratz
2013-03-13  4:12           ` Aaron Ecay
2013-03-13  7:50             ` Achim Gratz
2013-03-13 14:42             ` Eric Schulte
2013-03-13 18:25               ` Achim Gratz
2013-03-14 19:52                 ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y5dvocw5.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).