From: Austin Frank <austin.frank@gmail.com>
To: emacs-orgmode@gnu.org
Subject: [babel] re-hash cached blocks on each execution? or, force re-hash?
Date: Mon, 12 Jul 2010 10:17:46 -0500 [thread overview]
Message-ID: <m0aapwd90l.fsf@gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3311 bytes --]
Hello!
I would find it extremely useful if the org-babel-execute-* family of
commands re-hashed the executed blocks on each execution, or,
alternatively, accepted a prefix argument that meant "re-execute this
block even if cached, and replace the cache-hash if necessary".
Currently, if a block is cached, when I change something inside the
block and then execute the block again, the hash in the #+results line
doesn't change. In cases where the contents of the block change but the
output of the block does not, this makes it very difficult to tell
whether the block has been re-executed or not.
If there are good reasons not to re-hash the block on each execution and
update the hash in the results line, I would like to be able to force
this behavior. In cases where I know that I want the block to be
re-hashed and re-executed, it seems like C-u C-c C-c or C-u C-u C-c C-c
would be a natural and org-ish way to force this.
Here's a simple test case:
--8<---------------cut here---------------start------------->8---
* elisp example
#+source: elisp-test
#+BEGIN_SRC emacs-lisp :cache yes
(print "hello world")
(print "re-hash and re-execute, please!")
#+END_SRC
#+results[f6dfc164b16889f1569fcd3242ba3de721853bc8]: elisp-test
: hello world
Now I change the above block in place (but reproduce the changes
sequentially here):
#+source: elisp-test
#+BEGIN_SRC emacs-lisp :cache yes
(print "hello world")
(print "re-hash and re-execute, please!")
#+END_SRC
#+results[f6dfc164b16889f1569fcd3242ba3de721853bc8]: elisp-test
: re-hash and re-execute, please!
Note that the block changed, and the results changed, but the hash did
not.
Now we change it again, in a way that doesn't change the output:
#+source: elisp-test
#+BEGIN_SRC emacs-lisp :cache yes
(setq four (+ 2 2))
(print "hello world")
(print "re-hash and re-execute, please!")
#+END_SRC
#+results[f6dfc164b16889f1569fcd3242ba3de721853bc8]: elisp-test
: re-hash and re-execute, please!
Again the block changed, but this time the results did not change and
neither did the hash. This makes it very hard to tell whether the code
has been re-executed or not. If the hash changed when the block
changed, I could tell that the new code had been detected and run.
Finally, we check whether the previous change was actually evaluated:
* elisp test
#+source: elisp-test
#+BEGIN_SRC emacs-lisp :cache yes
(setq four (+ 2 2))
(print "hello world")
(print "re-hash and re-execute, please!")
(print four)
#+END_SRC
#+results[f6dfc164b16889f1569fcd3242ba3de721853bc8]: elisp-test
: 4
So the block is re-evaluated when it's changed, but the hash isn't
updated. The only way we can tell if an altered block is re-run is if
the output changes, but that won't necessarily be the case for every
change in a block. It would be very useful if the block were re-hashed
before each execution, and the cache line updated whenever the hash
changes. One possible solution is to force re-hashing and re-execution
with a prefix argument (or double prefix argument, if preferred).
--8<---------------cut here---------------end--------------->8---
Thanks,
/au
--
Austin Frank
http://aufrank.net
GPG Public Key (D7398C2F): http://aufrank.net/personal.asc
[-- Attachment #1.2: Type: application/pgp-signature, Size: 194 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
next reply other threads:[~2010-07-12 15:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-12 15:17 Austin Frank [this message]
2010-07-12 19:35 ` [babel] re-hash cached blocks on each execution? or, force re-hash? Eric Schulte
2010-07-13 3:52 ` Austin Frank
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m0aapwd90l.fsf@gmail.com \
--to=austin.frank@gmail.com \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.