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

[Eric Schulte]

Achim Gratz <address@hidden> 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