emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Tom <tmbdev@gmail.com>
To: John Kitchin <jkitchin@andrew.cmu.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: long running processes
Date: Wed, 18 Nov 2015 15:31:17 -0800	[thread overview]
Message-ID: <CABdbsnANqToHjxse5fzRpGAC9M+myr_RpcePhCNyNQFTnUj34A@mail.gmail.com> (raw)
In-Reply-To: <m2lh9uyl2g.fsf@andrew.cmu.edu>

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

On Wed, Nov 18, 2015 at 2:55 PM, John Kitchin <jkitchin@andrew.cmu.edu>
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

[-- Attachment #2: Type: text/html, Size: 2492 bytes --]

next prev parent reply	other threads:[~2015-11-18 23:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 20:04 long running processes Tom
2015-11-18 22:55 ` John Kitchin
2015-11-18 23:31   ` Tom [this message]
2015-11-19 13:38     ` John Kitchin
2015-11-19 17:10       ` Tom

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=CABdbsnANqToHjxse5fzRpGAC9M+myr_RpcePhCNyNQFTnUj34A@mail.gmail.com \
    --to=tmbdev@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jkitchin@andrew.cmu.edu \
    /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

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).