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: Sat, 09 Mar 2013 11:35:28 -0700 Message-ID: <87ip50qv36.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:60937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEOd8-0006Gd-32 for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 13:36:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEOcz-0002T8-VD for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 13:36:26 -0500 Received: from mail-pb0-f50.google.com ([209.85.160.50]:34635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEOcz-0002Sm-Oi for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 13:36:17 -0500 Received: by mail-pb0-f50.google.com with SMTP id up1so2308472pbc.23 for ; Sat, 09 Mar 2013 10:36:17 -0800 (PST) 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 Achim Gratz writes: > Eric Schulte writes: >> I prefer leaving the hash with the results, as it is the results which >> are "hashed". Also, same input does not always guarantee same output, >> e.g., >> >> #+begin_src sh >> date >> #+end_src > > That's not what I'm seeing, but I may be missing something again. The > hash is for the parameters of the call, not the result. If I'm editing > the result, Babel still marks the cache valid and does not re-compute > it. It does re-compute if I change the parameters explicitly or > implicitly, even if the result will not change. > 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. In general a hash without a result doesn't make sense (because then what is cached?). If one did want to move hashes to code blocks it would be a major refactoring which would (in my opinion) require significant justification. 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. 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. It is very possible I've missed something. I hope these comments are helpful. Best, -- Eric Schulte http://cs.unm.edu/~eschulte