Aaron Ecay <aarone...@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
