emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <schulte.eric@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Date: Tue, 02 Apr 2013 16:14:08 -0600	[thread overview]
Message-ID: <87hajor343.fsf@gmail.com> (raw)
In-Reply-To: 87eheuvnse.fsf@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

  reply	other threads:[~2013-04-02 22:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06  4:07 [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Aaron Ecay
2013-03-08 21:25 ` Aaron Ecay
2013-03-08 22:07   ` Eric Schulte
2013-03-08 21:53 ` Achim Gratz
2013-03-08 22:09   ` Eric Schulte
2013-03-08 22:24     ` aaronecay
2013-03-09 17:45       ` Eric Schulte
2013-03-09 18:56         ` Aaron Ecay
2013-03-09 20:03         ` Achim Gratz
2013-03-09  0:57     ` Achim Gratz
2013-03-09 18:35       ` Eric Schulte
2013-03-09 19:22         ` Aaron Ecay
2013-03-09 20:26           ` Eric Schulte
2013-03-13  3:55             ` Aaron Ecay
2013-03-13 14:45               ` Eric Schulte
2013-03-19  4:49                 ` Aaron Ecay
2013-03-23 22:34                   ` Eric Schulte
2013-04-01  5:10                     ` Aaron Ecay
2013-04-02 22:14                       ` Eric Schulte [this message]
2013-03-10  8:52         ` Achim Gratz
2013-03-10 20:14           ` Sebastien Vauban
2013-03-10 21:06             ` Achim Gratz
2013-03-13  4:12           ` Aaron Ecay
2013-03-13  7:50             ` Achim Gratz
2013-03-13 14:42             ` Eric Schulte
2013-03-13 18:25               ` Achim Gratz
2013-03-14 19:52                 ` Eric Schulte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hajor343.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).