emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Austin Frank <austin.frank@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [babel] re-hash cached blocks on each execution?  or, force re-hash?
Date: Mon, 12 Jul 2010 12:35:27 -0700	[thread overview]
Message-ID: <878w5gbihz.fsf@gmail.com> (raw)
In-Reply-To: m0aapwd90l.fsf@gmail.com

Hi Austin,

You've found an error.  The hash should be updated every time a new
result is inserted into the buffer.  I've just pushed up a fix which I
believe should take care of this error.  Please let me know if any
problems persist, or if some portion of your request remains
unfulfilled.

Thanks -- Eric

Austin Frank <austin.frank@gmail.com> writes:

> 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:
>
> * 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).
>
>
> Thanks,
> /au

  reply	other threads:[~2010-07-12 19:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 15:17 [babel] re-hash cached blocks on each execution? or, force re-hash? Austin Frank
2010-07-12 19:35 ` Eric Schulte [this message]
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

  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=878w5gbihz.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=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 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).