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

[Eric Schulte <schulte.eric@gmail.com>]

Aaron Ecay <aaronecay@gmail.com> writes:

> Hi Eric,
>
> 2013ko martxoak 9an, Eric Schulte-ek idatzi zuen:
>> Could something like the following work?  Removing ":results none" and
>> adding something small as the returned result which may easily be parsed
>> and placed in the buffer w/o problem.
>> 
>>     #+begin_src R :cache yes
>>       # code to perform side effect
>>       x <- 'side effect'
>>       'done'
>>     #+end_src
>> 
>>     #+RESULTS[9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a]:
>>     : done
>
> It works, but it is a kludge.  In fact, it is the same kludge that we
> used to need before :results none (to avoid emacs choking on reading a
> monster data frame).
>

Well, I suppose one man's dirty kludge is another's beautiful hack.  The
question here is whether the complexity lies in the implementation (and
thus the interface) or in the code block itself.  While I generally
prefer the later, in this case of ":results none :cache yes" I would be
open to placing some custom logic in the backend, which stores the hash
value with the code block, possibly changing

     #+begin_src R :cache yes
       # code to perform side effect
     #+end_src

to
  
     #+begin_src R :cache 9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a
       # code to perform side effect
     #+end_src

keeping in mind that the actual hash value should be hidden after the
first couple of characters.

>
>
>> This does not need special built in support, e.g.,
>> 
>>     #+name: R-pid
>>     #+begin_src sh :var R="/usr/lib64/R/bin/exec/R"
>>       ps auxwww|grep "$R"|grep -v 'grep'|awk '{print $2}'
>>     #+end_src
>> 
>>     #+begin_src R :cache yes :var pid=R-pid
>>       # code to perform side effect
>>       x <- 'side effect'
>>       'done'
>>     #+end_src
>> 
>>     #+RESULTS[da16f09882a6295815db51247592b77c80ed0056]:
>>     : done
>
> Now *this* is a kludge!

I was actually very proud of this solution.  It is what would be done by
the framework if we did implement custom support, but by doing it with
code blocks the exact mechanics are visible to the user.

> Since babel involves executing arbitrary code, the question to ask is
> not “Is this possible in babel?”.  The answer is always “yes.”

Thank you very much. :)

> The right question is instead “What does it make the most sense for
> babel to do?”  I think Achim’s contributions to this thread pushing us
> in the direction of thinking about what the execution model is are
> exactly what is needed.
>
> For cached code running in a session, I think a sensible model is:
> - Code should be re-run once after each session startup
> - Other than that, code should be re-run only if it changes, or if the
>   user explicitly requests it to be re-run.
>

How should session startup be determined if not through inclusion of the
session PID in the code block hash?  Perhaps the above could be made
more elegant through the addition of an elisp function which returns the
pid of the current R session, allowing the above to be truncated to
something like the following.

     #+begin_src R :cache yes :session foo :var pid=(R-pid "foo")
       # code to perform side effect
       x <- 'side effect'
       'done'
     #+end_src

I don't suppose ESS provides such a function?

>
> In order to implement this, it is necessary to figure out how to hash
> the contents of :results none blocks, and include the session process id
> in the hash.  If you have a different model in mind, then you will want
> different behavior.  But I think (thanks to Achim’s clarifying comments)
> we can’t really discuss what is the “right” behavior without also
> discussing which is the “right” model.

Perhaps what we want is a ":results hash" header argument, which returns
the hash of the code block *as* the code blocks result?  I'm not yet
convinced that the existing variable/results support with dummy values
is insufficient to structure dependencies between blocks.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte