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 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):
>

I think the following is the simplest and clearest solution in these
cases (certainly more straightforward than the syntax below).

    #+begin_src R
      x<-"make something big"
      "done"
    #+end_src

    #+RESULTS:
    : done

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

To me this sounds like a solution in search of a problem.  If you
actually run into a problem in real life then we can consider if an
Org-mode solution is necessary.

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

Great, thanks.

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

Again, I think you're anticipating problems which don't crop up in
actuality (e.g., in the many years of Org-mode code block usage by me
and many others).  Please just get to using Org-mode code blocks to do
something, and then much more attention will be paid to *experienced*
rather than *anticipated* problems.

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

Correct, lets not work on implementing this cache in the header idea.

> I am certainly sorry if you are upset by something I have said – such
> was never my intention.
>

You misread my tone, I'm not upset.

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

Sounds great.

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

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