From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Date: Sat, 09 Mar 2013 14:22:37 -0500 Message-ID: <87li9wcr9e.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> <87ip50qv36.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEPLy-000604-KX for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 14:22:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEPLr-0007k7-FM for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 14:22:46 -0500 Received: from mail-qe0-f46.google.com ([209.85.128.46]:51644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEPLr-0007jz-Al for emacs-orgmode@gnu.org; Sat, 09 Mar 2013 14:22:39 -0500 Received: by mail-qe0-f46.google.com with SMTP id a11so1657918qen.33 for ; Sat, 09 Mar 2013 11:22:38 -0800 (PST) In-Reply-To: <87ip50qv36.fsf@gmail.com> 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: Eric Schulte Cc: Achim Gratz , emacs-orgmode@gnu.org 2013ko martxoak 9an, Eric Schulte-ek idatzi zuen: > 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?). A :results none code block is run for its side effects (by definition). Caching a code block with results says =E2=80=9CI do not want to recalculate this value unless the code changes.=E2=80=9D Caching a null result, by ana= logy, says =E2=80=9CI do not want these side effects again, unless the code chang= es=E2=80=9D. >=20 > 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. It depends on whether one looks at a cache as =E2=80=9Ca place to store res= ults=E2=80=9D or =E2=80=9Ca way to conditionally rerun code blocks only when they change= =E2=80=9D, I suppose. I guess you hold with the former; I think the latter is a useful conceptual extension. Knitr (http://yihui.name/knitr/) is a very useful literate programming tool for R, and it supports =E2=80=9Ccaching=E2= =80=9D code with side-effects using clever means. I don=E2=80=99t think org should do = all the tricks knitr does, but it would be useful to be able to conditionally reexecute code with no results/with side effects. >=20 > What if the R process restarts? The hash would still be valid, but the > side effects have been lost. This is also an issue if the external data files have changed, the RNG seed is no longer the same, etc. In such cases, the user has to be clever. But the same is true of any cached code that is not a pure function. In practice, if the R process is restarted the =E2=80=9Cvariable not found= =E2=80=9D errors quickly become apparent, and reloading the data is a simple C-u C-c C-c away. (That being said, including the PID of the R process in the results hash, to the effect that the code would be rerun in the case you mention, might not be a bad idea. But that is a separate discussion.) --=20 Aaron Ecay