From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Subject: Re: asynchronous python code blocks in org-mode Date: Tue, 1 Dec 2015 12:19:31 -0800 Message-ID: References: <2015-11-30T12-27-30@devnull.Karl-Voit.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1136b38c42e3410525dbe18b Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3rOy-00024v-V7 for emacs-orgmode@gnu.org; Tue, 01 Dec 2015 15:19:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3rOx-0004Jp-Kd for emacs-orgmode@gnu.org; Tue, 01 Dec 2015 15:19:52 -0500 Received: from mail-ig0-x233.google.com ([2607:f8b0:4001:c05::233]:34644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3rOx-0004JH-G5 for emacs-orgmode@gnu.org; Tue, 01 Dec 2015 15:19:51 -0500 Received: by igvg19 with SMTP id g19so102860011igv.1 for ; Tue, 01 Dec 2015 12:19:50 -0800 (PST) In-Reply-To: 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: John Kitchin Cc: Karl Voit , emacs-orgmode@gnu.org --001a1136b38c42e3410525dbe18b Content-Type: text/plain; charset=UTF-8 On Mon, Nov 30, 2015 at 1:06 PM, John Kitchin wrote: > I have not thought about sessions and asynchronous execution. It would > mean a queue and a different way to pass code to the process, which I > have not thought through yet. What to do when there are dependencies for > example,... > A good way of converting synchronous into asynchronous code is to use futures/promises. Usually, that's done via data structures, but within Emacs buffers, it could be done via text strings. How might that work? org-babel-execute:python could wait for, say, 0.1 sec for an immediate result. If the computation doesn't finish within that time, it returns a "future", a magic string like "org_mode_future_result(1234) ###MAGIC###". This would then get inserted as output into the org-mode buffer. Later, when the actual result becomes available from the subprocess, that invokes a callback on the org-python mode buffer and replaces tihs magic string with the actual result, and dequeues and executes the next command if necessary. (Picking a Python-parseable expression would even allow futures to be used in some other Python computations as if it were an actual value.) I think that would allow much of the current API to remain in place. Obviously, some things simply can't work. For example, org-babel-reassemble-table expects an actual result, not a future; such post-processing would have to move to a hook function, which probably would be cleaner anyway. Tom --001a1136b38c42e3410525dbe18b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 30, 2015 at 1:06 PM, John Kitchin <jkitchin@andrew.cmu.e= du> wrote:
I have not thought about sessions and asynchronous execution= . It would
mean a queue and a different way to pass code to the process, which I
have not thought through yet. What to do when there are dependencies for example,...

A = good way of converting synchronous into asynchronous code is to use futures= /promises. Usually, that's done via data structures, but within Emacs b= uffers, it could be done via text strings.

How might that work? org-babel-execute:python could wait for, say, = 0.1 sec for an immediate result. If the computation doesn't finish with= in that time, it returns a "future", a magic string like "or= g_mode_future_result(1234) ###MAGIC###". This would then get inserted = as output into the org-mode buffer. Later, when the actual result becomes a= vailable from the subprocess, that invokes a callback on the org-python mod= e buffer and replaces tihs magic string with the actual result, and dequeue= s and executes the next command if necessary.

(Picking a Python-parseable expression would even allow futures = to be used in some other Python computations as if it were an actual value.= )

I think that would allow much of = the current API to remain in place. Obviously, some things simply can't= work. For example, org-babel-reassemble-table expects an actual result, no= t a future; such post-processing would have to move to a hook function, whi= ch probably would be cleaner anyway.

Tom

--001a1136b38c42e3410525dbe18b--