emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert


From: Aaron Ecay
Subject: Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Date: Sat, 09 Mar 2013 14:22:37 -0500
User-agent: Notmuch/0.15.2+43~ge848af8 (http://notmuchmail.org) Emacs/24.3.50.1 (x86_64-unknown-linux-gnu)

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 “I do not want to recalculate
this value unless the code changes.”  Caching a null result, by analogy,
says “I do not want these side effects again, unless the code changes”.

> 
> 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 “a place to store results”
or “a way to conditionally rerun code blocks only when they change”, 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 “caching” code
with side-effects using clever means.  I don’t 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.

> 
> 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 “variable not found”
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.)

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]