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: Wed, 13 Mar 2013 08:45:41 -0600 Message-ID: <87y5drcq8a.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> 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]:60059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFmwf-0001Ca-FM for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFmwY-0006O3-7j for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:21 -0400 Received: from mail-da0-x22b.google.com ([2607:f8b0:400e:c00::22b]:58845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFmwX-0006Nd-Ur for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 10:46:14 -0400 Received: by mail-da0-f43.google.com with SMTP id u36so451518dak.16 for ; Wed, 13 Mar 2013 07:46:13 -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: Achim Gratz Cc: emacs-orgmode@gnu.org Aaron Ecay writes: > Hi Eric, > > 2013ko martxoak 9an, Eric Schulte-ek idatzi zuen: >> Could something like the following work? Removing ":results none" and >> adding something small as the returned result which may easily be parsed >> and placed in the buffer w/o problem. >>=20 >> #+begin_src R :cache yes >> # code to perform side effect >> x <- 'side effect' >> 'done' >> #+end_src >>=20 >> #+RESULTS[9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a]: >> : done > > It works, but it is a kludge. In fact, it is the same kludge that we > used to need before :results none (to avoid emacs choking on reading a > monster data frame). > 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 =20=20 #+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. > > >> This does not need special built in support, e.g., >>=20 >> #+name: R-pid >> #+begin_src sh :var R=3D"/usr/lib64/R/bin/exec/R" >> ps auxwww|grep "$R"|grep -v 'grep'|awk '{print $2}' >> #+end_src >>=20 >> #+begin_src R :cache yes :var pid=3DR-pid >> # code to perform side effect >> x <- 'side effect' >> 'done' >> #+end_src >>=20 >> #+RESULTS[da16f09882a6295815db51247592b77c80ed0056]: >> : done > > Now *this* is a kludge! I was actually very proud of this solution. It is what would be done by the framework if we did implement custom support, but by doing it with code blocks the exact mechanics are visible to the user. > Since babel involves executing arbitrary code, the question to ask is > not =E2=80=9CIs this possible in babel?=E2=80=9D. The answer is always = =E2=80=9Cyes.=E2=80=9D Thank you very much. :) > The right question is instead =E2=80=9CWhat does it make the most sense f= or > babel to do?=E2=80=9D I think Achim=E2=80=99s contributions to this thre= ad pushing us > in the direction of thinking about what the execution model is are > exactly what is needed. > > For cached code running in a session, I think a sensible model is: > - Code should be re-run once after each session startup > - Other than that, code should be re-run only if it changes, or if the > user explicitly requests it to be re-run. > How should session startup be determined if not through inclusion of the session PID in the code block hash? Perhaps the above could be made more elegant through the addition of an elisp function which returns the pid of the current R session, allowing the above to be truncated to something like the following. #+begin_src R :cache yes :session foo :var pid=3D(R-pid "foo") # code to perform side effect x <- 'side effect' 'done' #+end_src I don't suppose ESS provides such a function? > > In order to implement this, it is necessary to figure out how to hash > the contents of :results none blocks, and include the session process id > in the hash. If you have a different model in mind, then you will want > different behavior. But I think (thanks to Achim=E2=80=99s clarifying co= mments) > we can=E2=80=99t really discuss what is the =E2=80=9Cright=E2=80=9D behav= ior without also > discussing which is the =E2=80=9Cright=E2=80=9D model. Perhaps what we want is a ":results hash" header argument, which returns the hash of the code block *as* the code blocks result? I'm not yet convinced that the existing variable/results support with dummy values is insufficient to structure dependencies between blocks. Thanks, --=20 Eric Schulte http://cs.unm.edu/~eschulte