Re: Feedback on Emacs-Jupyter

[Nathaniel Nicandro]

> 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