astahlman / ob-async

Asynchronous src_block execution for org-babel
343 stars 32 forks source link

Support running blocks sequentially with org-babel-execute-subtree #64

Open skangas opened 4 years ago

skangas commented 4 years ago

With the following org-mode file:

* test
** foo
#+begin_src shell :async t
sleep 3
echo foo
#+end_src
** bar
#+begin_src shell :async t
echo bar
#+end_src

With point at beginning of buffer, type M-x org-babel-execute-subtree RET. Source code blocks are now evaluated in parallel, such that the result below the second header (bar) shows up before the first (foo).

Please consider adding support for sequential evaluation of source code blocks with org-babel-execute-subtree.

astahlman commented 3 years ago

Off the top of my head, we might be able to add a new function like ob-async-execute-subtree which adds a function to org-babel-after-execute-hook and kicks off the first src-block. The hook function would then jump to the next src-block and execute it.

Open to ideas or pull requests, here.

hraban commented 2 years ago

Without async mode, you could achieve something like this by defining blocks as inputs of other blocks, e.g.:

* Test

#+begin_src emacs-lisp :results none
(setq-local org-confirm-babel-evaluate nil)
#+end_src

#+name: test1
#+begin_src sh :results verbatim :cache yes
sleep 3
echo test 1
date -u
#+end_src

#+begin_src sh :results verbatim :var ignore=test1 :cache yes
date -u
echo test 2
#+end_src

The second block will wait for the first block to complete, perhaps implicitly because evaluation is blocking (I don't know) but the effect is the same: this works.

With ob-async, it seems like a block is immediately considered "done" from babel's pov, so the next block will start immediately, with the first (place-holder) result as input. An error is thrown and the second block never completes:

error in process sentinel: if: Invalid read syntax: "#<"
error in process sentinel: Invalid read syntax: "#<"

If ob-async could somehow detect that an input block is, itself, a pending ob-async operation, and block evaluation until that dependent block is done, you could fix both the expected behaviour, and this github issue could be solved by using the same technique.

What do you think?

hraban commented 2 years ago

Related to #60