From: Nathaniel Nicandro <nathanielnicandro@gmail.com>
To: David Dynerman <emperordali@block-party.net>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: Feedback on Emacs-Jupyter
Date: Fri, 07 Jan 2022 12:57:59 -0600 [thread overview]
Message-ID: <87h7afl6fc.fsf@gmail.com> (raw)
In-Reply-To: <15302A63-FD67-4754-A32E-46EE40AD4076@block-party.net>
> Let me echo others’ comments by saying how much I appreciate your work
> on emacs-jupyter. I use the package daily in my work and it’s been
> really fantastic. Thank you very, very much for your huge efforts and
> time investment in creating and maintaining this package.
Your welcome, I've enjoyed my time learning about Emacs, Org, and
Jupyter in the process.
> (is there an emacs-jupyter mailing list or preferred venue?)
No mailing list. Currently just using GitHub. A mailing list sounds
interesting though. I wonder if people would be more willing to
contribute pull requests in that case?
> It would be great to be able to re-establish the connection to the
> REPL without discarding the buffer.
I like this idea. When a connection to a kernel is lost for some
reason we can reset the connection. For ZMQ based connections I think
it would be as simple as shutting down and starting up new ZMQ
sockets. For notebook based connections, closing and then re-opening
the WebSocket that represents the connection.
> 2) Getting results from a running block after
> disconnecting/reconnecting. Currently it’s difficult to manage
> long-running code blocks using emacs-jupyter if I disconnect from
> the remote server while the code block is running. The work around
> in #1 above to re-connect to a remote kernel doesn’t work if the
> kernel is still executing a block. If the kernel has completed
> executing the block, then the results are not populated back into
> the notebook (the execution UUID populated when the code block
> began executing remains).
I wonder if the issue has to do with the fact that a new session ID is
created every time you reconnect to the kernel using workaround #1.
The function jupyter-api-get-kernel-ws is responsible for returning a
new WebSocket when connecting to a kernel and using your workaround
would mean the session ID associated with the WebSocket connection
would be different after reconnecting. That may be why the messages
don't get handled. That's just my initial guess though. Could you
open up an issue over at emacs-jupyter about this?
> 3) Similarly, improving feedback from a long-running block would be
> very helpful. Currently you can use print statements in a long
> running block to report progress, but these are lost after
> disconnecting (maybe they are buffered on the jupyter server side
> and could be replayed on reconnect?). Further, I don’t know if
> this is feasible, but it would be amazing to have support for
> progress bars for long-running tasks (e.g., have a tqdm progress
> bar render in the org notebook).
I'll have to investigate the buffering of messages on the Jupyter
server side of things. I do think there is some message buffering
going on and that they get replayed to the client, but I'll have to
double check. I did play play around with tqdm, and it works mostly.
What about the behavior with tqdm do you not see. When I was testing
it, it seemed that the previous progress bars would stack up instead
of being removed from the buffer. But then I M-x eval-defun on
jupyter-org--handle-control-codes and everything worked as it should,
that is only one progress bar gets refreshed on every iteration. Not
sure what is happening there.
Thanks for your feedback,
--
Nathaniel
next prev parent reply other threads:[~2022-01-07 19:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 23:24 Feedback on Emacs-Jupyter Nathaniel Nicandro
2022-01-05 4:37 ` Ken Mankoff
2022-01-06 18:44 ` Nathaniel Nicandro
2022-01-05 7:26 ` Colin Baxter 😺
2022-01-05 17:39 ` David Dynerman
2022-01-07 18:57 ` Nathaniel Nicandro [this message]
2022-01-08 11:27 ` Daniel Fleischer
2022-01-12 13:24 ` Ihor Radchenko
2022-01-13 20:56 ` Nathaniel Nicandro
2022-01-14 14:25 ` Ihor Radchenko
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=87h7afl6fc.fsf@gmail.com \
--to=nathanielnicandro@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=emperordali@block-party.net \
/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).