From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Subject: Re: long running processes Date: Wed, 18 Nov 2015 15:31:17 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141b2c4276bbe0524d90b25 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzCCR-0006W9-0x for emacs-orgmode@gnu.org; Wed, 18 Nov 2015 18:31:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzCCP-0008OZ-Oh for emacs-orgmode@gnu.org; Wed, 18 Nov 2015 18:31:38 -0500 Received: from mail-io0-x229.google.com ([2607:f8b0:4001:c06::229]:36106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzCCP-0008OK-JA for emacs-orgmode@gnu.org; Wed, 18 Nov 2015 18:31:37 -0500 Received: by iofh3 with SMTP id h3so71608021iof.3 for ; Wed, 18 Nov 2015 15:31:37 -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: emacs-orgmode@gnu.org --001a1141b2c4276bbe0524d90b25 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 18, 2015 at 2:55 PM, John Kitchin wrote: > I am pretty sure this is not directly possible right now. > > Some approaches that resemble it could be: > 1. write a src block that will be tangled to a script. > 2. tangle the block > 3. Run the script in a shell src block with an & so it runs > non-blocking. > > or, use an elisp block like: > > (org-babel-tangle) > (async-shell-command "your script" some-output-buffer) > > I don't know a way to get continuous updated output in an org-buffer > though. > Thanks for the response. I didn't necessarily expect continuous output into the org-buffer itself to work, but I don't see why the Python subprocess can't display output as it occurs. After all, it uses comint, and comint certainly has facilities for collecting output incrementally while still displaying it (cf comint-output-filter-functions). It looks to me like the problem is that org-babel-comint-with-output uses a "while" loop to collect process output (ob-comint.el:92). At least, it could insert the output into the subprocess buffer and make redisplay happen. But I'm not sure why the code is written that way anyway. Long running "while" loops in Emacs code don't seem like a good idea to begin with. Wouldn't the more natural way for this code to be written in Emacs be the following? - an output filter gets added to the subprocess that collects output - the code is sent to the subprocess for execution - the command returns - the output filter inserts any data it gets into the subprocess buffer, into its "results" data structure, perhaps even into the org-buffer - when the output filter gets the eoe-indicator, it removes itself from the output filter list and sends a notification that execution has completed If the user schedules a second block for execution, the simplest thing to do is return an error if there is already a block executing for that subprocess; alternatively, it could be queued somewhere. Thanks, Tom --001a1141b2c4276bbe0524d90b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 18, 2015 at 2:55 PM, John Kitchin <jkitchin@andrew.cmu.e= du> wrote:
I am pretty sure this is not directly possible right now.
Some approaches that resemble it could be:
1. write a src block that will be tangled to a script.
2. tangle the block
3. Run the script in a shell src block with an & so it runs
non-blocking.

or, use an elisp block like:

(org-babel-tangle)
(async-shell-command "your script" some-output-buffer)

I don't know a way to get continuous updated output in an org-buffer though.

Thanks for the response. I didn't n= ecessarily expect continuous output into the org-buffer itself to work, but= I don't see why the Python subprocess can't display output as it o= ccurs. After all, it uses comint, and comint certainly has facilities for c= ollecting output incrementally while still displaying it (cf comint-output-= filter-functions).

It looks to me like the problem is that org-babel= -comint-with-output uses a "while" loop to collect process output= (ob-comint.el:92). At least, it could insert the output into the subproces= s buffer and make redisplay happen.

But I'm not sure why the cod= e is written that way anyway. Long running "while" loops in Emacs= code don't seem like a good idea to begin with. Wouldn't the more = natural way for this code to be written in Emacs be the following?

-= an output filter gets added to the subprocess that collects output
- th= e code is sent to the subprocess for execution
- the command returns
= - the output filter inserts any data it gets into the subprocess buffer, in= to its "results" data structure, perhaps even into the org-buffer=
- when the output filter gets the eoe-indicator, it removes itself from= the output filter list and sends a notification that execution has complet= ed

If the user schedules a second block for execution, the simplest = thing to do is return an error if there is already a block executing for th= at subprocess; alternatively, it could be queued somewhere.

Thanks,<= br>Tom


--001a1141b2c4276bbe0524d90b25--