From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte 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 Message-ID: <87hajor343.fsf@gmail.com> References: <1362542863-25992-1-git-send-email-aaronecay@gmail.com> <87obetsgma.fsf@Rainer.invalid> <877glhsfus.fsf@gmail.com> <87k3phs84b.fsf@Rainer.invalid> <87ip50qv36.fsf@gmail.com> <87li9wcr9e.fsf@gmail.com> <87y5dwpbfi.fsf@gmail.com> <87ppz4ar85.fsf@gmail.com> <87y5drcq8a.fsf@gmail.com> <87mwu0vvs0.fsf@gmail.com> <87ppyppwvx.fsf@gmail.com> <87eheuvnse.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:44522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN9Ui-0005co-NE for emacs-orgmode@gnu.org; Tue, 02 Apr 2013 18:15:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UN9Ub-0000Qs-5L for emacs-orgmode@gnu.org; Tue, 02 Apr 2013 18:15:56 -0400 Received: from mail-da0-x234.google.com ([2607:f8b0:400e:c00::234]:56650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UN9Ua-0000QF-7m for emacs-orgmode@gnu.org; Tue, 02 Apr 2013 18:15:49 -0400 Received: by mail-da0-f52.google.com with SMTP id f10so375018dak.11 for ; Tue, 02 Apr 2013 15:15:47 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Aaron Ecay 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=E2=80=99m uneasy with how magic :var is, in the sense that it does a lo= t of > heavy lifting with interconversion to/from org syntax, table formats, > etc. What if a special convention was introduced, whereby > :var _=3Dwhatever would not result in any variable binding being introduc= ed > 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, _ =3D iOnlyCareAboutTheSecondValue() > #+end_src > > So, this would look like: > #+begin_src R :var a=3D123 :var _=3D(R-pid) :var _=3D(something-else) > # code which can access a, but has no access to (R-pid) or (something-e= lse) > #+end_src > > If this doesn=E2=80=99t resonate with you, I=E2=80=99ll just drop this su= ggestion. 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? >>=20 >> #+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=E2=80=99s end, and fair= ly > 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. T= he >>>> 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 >>>>=20 >>>> #+begin_src R :cache yes >>>> # code to perform side effect >>>> #+end_src >>>>=20 >>>> to >>>>=20=20=20 >>>> #+begin_src R :cache 9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a >>>> # code to perform side effect >>>> #+end_src >>>>=20 >>>> keeping in mind that the actual hash value should be hidden after the >>>> first couple of characters. > > [...] > >>=20 >>>=20 >>> 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!) >>>=20 >>> One question: should we have the cache in the header only for :results >>> none blocks, or for all blocks? >>>=20 >>=20 >> 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 =E2=80=93 = 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)))))=20=20=20=20 > (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=3DR-pid"))) > #+END_SRC > Sounds great. > > I=E2=80=99d prefer to use the proposed _ for the var here, but otherwise = this > seems to work. > > Thanks, --=20 Eric Schulte http://cs.unm.edu/~eschulte