From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results Date: Mon, 01 Apr 2013 01:10:41 -0400 Message-ID: <87eheuvnse.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> 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]:33210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMX14-0004K1-DM for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:10:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMX11-0000lR-0s for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:10:46 -0400 Received: from mail-qe0-f48.google.com ([209.85.128.48]:51655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMX10-0000lJ-ST for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:10:42 -0400 Received: by mail-qe0-f48.google.com with SMTP id 2so1039822qea.7 for ; Sun, 31 Mar 2013 22:10:42 -0700 (PDT) In-Reply-To: <87ppyppwvx.fsf@gmail.com> 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: Eric Schulte Cc: emacs-orgmode@gnu.org 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 lot = 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 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, _ =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-els= e) #+end_src If this doesn=E2=80=99t resonate with you, I=E2=80=99ll just drop this sugg= estion. 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? >=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 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 >>>=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. I am certainly sorry if you are upset by something I have said =E2=80=93 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)))))=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 I=E2=80=99d prefer to use the proposed _ for the var here, but otherwise th= is seems to work. Thanks, --=20 Aaron Ecay