Achim Gratz <strom...@nexgo.de> 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
