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: Tue, 19 Mar 2013 00:49:35 -0400 Message-ID: <87mwu0vvs0.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> 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]:54217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHoUW-00066I-9a for emacs-orgmode@gnu.org; Tue, 19 Mar 2013 00:49:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHoUU-0001KQ-BM for emacs-orgmode@gnu.org; Tue, 19 Mar 2013 00:49:40 -0400 Received: from mail-ve0-f171.google.com ([209.85.128.171]:53887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHoUU-0001KK-4C for emacs-orgmode@gnu.org; Tue, 19 Mar 2013 00:49:38 -0400 Received: by mail-ve0-f171.google.com with SMTP id b10so61445vea.2 for ; Mon, 18 Mar 2013 21:49:37 -0700 (PDT) In-Reply-To: <87y5drcq8a.fsf@gmail.com> (Eric Schulte's message of "Wed, 13 Mar 2013 08:45:41 -0600") 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: Achim Gratz , emacs-orgmode@gnu.org Hi Eric, I=E2=80=99m jointly replying to 2 of your emails. 2013ko martxoak 13an, Eric Schulte-ek idatzi zuen: > This is what is already taking place. The :var header arguments are > automatically expanded into dependencies between code blocks, and the > results of previous code blocks are included in the hash calculation of > the current code block. Wow, I did not realize that the :var handling was so sophisticated. Would it be possible to introduce a :depends code-block-name header argument, which recycles the same dependency calculation but does not bind a variable in the code block? Many of the variables that I rely on between blocks are large data frames, and I worry that dumping them into the org buffer and then reloading them into R[fn:1] will result in a slowdown and/or loss of some structure in the data. [fn:1] My understanding of the :var-handling code is that this is how it acquires the values to assign to the variables, as opposed to re-using a variable that is present in a session. But the code is complex, so maybe I=E2=80=99m wrong (again). I also think this would make the feature more discoverable: a :var is just a sub-type of :depends, with extra functionality. Coming from a Sweave/knitr background, I expected something like :depends, and thus didn=E2=80=99t notice :var >=20 > From re-looking at Achim's previous noweb example, it seems that we > currently do *not* include the values of noweb expansions in code block > hash calculations, I think this is a bug which should be fixed. +1 > To echo Achim's response, you've accidentally uttered Org-mode heresy. Oh no. The good news is that thanks to your and Achim=E2=80=99s explanatio= n, I think I now understand this principle better. >>> Oh yes, there's a whole set of _other_ problems that are waiting to be >>> solved. :-) >>=20 >> There always is. :-) >=20 > I think Org-mode already provides the bulk of what is desired. If we > agree to treat ":cache yes :results none" as obviously taking place for > side effects, and then sticking a hash behind the :cache header argument > with the code block, then what functionality would be missing? This was more of a joke on my part: life gets boring when you run out of problems to work on. In this specific case, though: 1) a :depends header argument 2) including the session PID in results hashes by default (because it is the only sensible thing to do) 2013ko martxoak 13an, Eric Schulte-ek idatzi zuen: > 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. If you like this solution, may I try once more to convince you of the empty #+RESULTS solution I originally proposed? I looked at the code for inserting/hiding/finding hash values, and it looks like it would be complicated to change. Empty #+RESULTS is easy, although perhaps less conceptually pure. 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 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. Agreed. But if it is the only =E2=80=9Cright=E2=80=9D thing to do, or one = of a very small set of =E2=80=9Cright=E2=80=9D things, I think it=E2=80=99s a win in = terms of conciseness/ease of use to do it automatically. And I think this is the case here: the presence of :session yes is a clear signal that there is out-of-band (from org=E2=80=99s perspective) communication happening between code blocks, and that the invariance of a result can=E2=80=99t be relied on= in a different session process. So when the session PID changes, the hash value should change as well, to trigger reevaluation. > 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. >=20 > #+begin_src R :cache yes :session foo :var pid=3D(R-pid "foo") > # code to perform side effect > x <- 'side effect' > 'done' > #+end_src >=20 > I don't suppose ESS provides such a function? You can get the value with (process-id (get-process ess-current-process-name)), which you have to evaluate in the current session buffer (the one that C-c C-v C-z takes you to). Generally speaking, I guess each ob-foo should provide a function to retrieve this value, since it will be different for different languages. --=20 Aaron Ecay