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

[Aaron Ecay <aaronecay@gmail.com>]

Hi Eric,

2013ko martxoak 23an, Eric Schulte-ek idatzi zuen:

> Unless you actually try :var and find it lacking in some way, I'd prefer
> to stick with simply using :var to identify dependencies between code
> blocks.  We've seen in other places how providing multiple alias for
> header arguments increases rather than reduces confusion.

I’m uneasy with how magic :var is, in the sense that it does a lot of
heavy lifting with interconversion to/from org syntax, table formats,
etc.  What if a special convention was introduced, whereby
:var _=whatever would not result in any variable binding being introduced
into the code block (but would behave the same wrt. dependencies)?  This
is similar to the syntax for discarding unused values in some
programming languages (python comes to mind):

#+begin_src python
  _, foo, _ = iOnlyCareAboutTheSecondValue()
#+end_src

So, this would look like:
#+begin_src R :var a=123 :var _=(R-pid) :var _=(something-else)
  # code which can access a, but has no access to (R-pid) or (something-else)
#+end_src

If this doesn’t resonate with you, I’ll just drop this suggestion.  I
will of course certainly report any problems I have using :var in
practice as well, with patches to fix them insofar as it is within my
ability to provide them.

> Maybe the documentation of :var should be improved to enhance
> discoverability.  I would be happy to apply a patch to this effect.

Patch is on the way.

> Why not just return a dummy value at the end of the code block?
> 
>     #+begin_src R :cache yes
>       # code to perform side effect
>       "done"
>     #+end_src

This would require the user to add this dummy result redundantly to many
code blocks, for no reason.  That is cognitively burdensome (user must
remember when to add it) and ugly, if the source code is to be exported
in the document (or tangled).

But this case is straightforward to detect on org’s end, and fairly
straightforward to work around (this is in fact what my original patch
was).  So I am still not sure why this burden should to be imposed.

>>> 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.

[...]

> 
>> 
>> If you want the cache in the header, I think I can try to work on a
>> patch, but it does look tricky.  So I am not sure I will have time to
>> work on it until next week.  (If anyone else wants to beat me to the
>> punch, please feel free!)
>> 
>> One question: should we have the cache in the header only for :results
>> none blocks, or for all blocks?
>> 
> 
> I'm just as happy raising an error or warning when the :cache and
> ":results none" options are found together, and doing no caching in that
> case.  Users can always just return a dummy value and remove ":results
> none".

So should I not work on this modified version of my original patch?  I
am genuinely trying to be helpful, so that my own modest contribution
can make even more useful what is already a very useful tool thanks to
the efforts of many people, including you.  Maybe I am barking up the
wrong tree.  I am certainly sorry if you are upset by something I have
said – such was never my intention.

> It sounds like such an (R-pid "foo") function would be easy to
> implement.  I'd vote for that solution (implementing this function in
> your .emacs, and then sharing it if necessary) for now.  If this need to
> associate PIDs with results becomes more wide spread (in a couple of
> years of Org-mode code blocks this is the first time I've seen it
> arise), then a built-in solution becomes more appealing.

This part of the solution I have implemented:

#+name: R-pid
#+BEGIN_SRC emacs-lisp
  (let* ((info (org-babel-get-src-block-info 'light))
         (session-name (cdr (assoc :session (nth 2 info)))))    
    (if (and session-name
             (not (equal session-name "none")))
        (progn
          (org-babel-R-initiate-session session-name (nth 2 info))
          (with-current-buffer (get-buffer session-name)
            (process-id (get-process ess-current-process-name))))
      "none"))
#+END_SRC

And in my init file:

#+BEGIN_SRC emacs-lisp
  (setq org-babel-default-header-args:R '((:var . "R.pid=R-pid")))
#+END_SRC

I’d prefer to use the proposed _ for the var here, but otherwise this
seems to work.

Thanks,

-- 
Aaron Ecay