From: Aaron Ecay <aaronecay@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-orgmode@gnu.org
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 [thread overview]
Message-ID: <87mwu0vvs0.fsf@gmail.com> (raw)
In-Reply-To: <87y5drcq8a.fsf@gmail.com> (Eric Schulte's message of "Wed, 13 Mar 2013 08:45:41 -0600")
Hi Eric,
I’m 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’m 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’t notice :var
>
> 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’s explanation, I
think I now understand this principle better.
>>> Oh yes, there's a whole set of _other_ problems that are waiting to be
>>> solved. :-)
>>
>> There always is. :-)
>
> 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
>
> #+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 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 “right” thing to do, or one of a very
small set of “right” things, I think it’s 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’s perspective) communication happening between
code blocks, and that the invariance of a result can’t 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.
>
> #+begin_src R :cache yes :session foo :var pid=(R-pid "foo")
> # code to perform side effect
> x <- 'side effect'
> 'done'
> #+end_src
>
> 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.
--
Aaron Ecay
next prev parent reply other threads:[~2013-03-19 4:49 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 [this message]
2013-03-23 22:34 ` Eric Schulte
2013-04-01 5:10 ` Aaron Ecay
2013-04-02 22:14 ` Eric Schulte
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=87mwu0vvs0.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=Stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/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).