Feedback on Emacs-Jupyter

Feedback on Emacs-Jupyter

[Nathaniel Nicandro]

Hello all,

I'm the maintainer of the emacs-jupyter project
(https://github.com/nnicandro/emacs-jupyter) which essentially
integrates Jupyter kernels (https://jupyter.org) with Org mode source
blocks.

I wanted to make an introduction to the Org community.  So...hello!  And
thanks for promoting the project on https://orgmode.org/features.html.

I believe a lot of users of the project use it mainly for the Org
integration.  I thought it would be a good idea to get some feedback
from the community on how their experience using emacs-jupyter has been.
I'm getting back into active maintenance of the project and am looking
for feedback to get a better idea of what the future of the project
could look like.  What features of standard Org source blocks do you
find Jupyter source blocks are lacking?  What potential features do you
think would be useful for Jupyter source blocks to support, given the
capabilities of Jupyter?  What would it mean to see Emacs-Jupyter and
Org more integrated?  Of course, any other thoughts are welcome.

-- 
Nathaniel

Re: Feedback on Emacs-Jupyter

[Ken Mankoff]

Hi Nathaniel,

First, thank you (many times) for maintaining emacs-jupyter. It is one of the most-used tools on my computer. I've been using your software daily for the past few years to develop code and write papers.

I may think of more things as others reply, but the one thing I can think of now is that I sometimes have issues inputting tables into Python code blocks. We discussed this back in 2020/2021 here: https://github.com/nnicandro/emacs-jupyter/issues/267 It is not emacs-jupyter according to you, but I mention it here anyway.


Another feature that could be nice - Org has the ability to embed/encode images into the document (see https://emacs.stackexchange.com/questions/27060/embed-image-as-base64-on-html-export-from-orgmode and  http://mbork.pl/2017-12-04_Embedding_files_in_Org-mode ). I do not suggest doing this for large graphics, but for small graphics, it could be interesting to have a "* Graphics" section at the bottom where the encoded graphics are stored, and then display those encoded graphics at the normal location (#+RESULTS: blocks below the code or elsewhere if #+NAME'd).

Implementing this feature would mean you could have self-contained / single-file / standalone Org files with graphics, similar to how .ipynb files contain graphics within. I'm not sure how useful this would be, but I throw it out there as a concept/idea.

Thanks again for the excellent software,

  -k.


On 2022-01-04 at 15:24 -08, Nathaniel Nicandro <nathanielnicandro@gmail.com> wrote:
> Hello all,
>
> I'm the maintainer of the emacs-jupyter project
> (https://github.com/nnicandro/emacs-jupyter) which essentially
> integrates Jupyter kernels (https://jupyter.org) with Org mode source
> blocks.
>
> I wanted to make an introduction to the Org community. So...hello! And
> thanks for promoting the project on https://orgmode.org/features.html.
>
> I believe a lot of users of the project use it mainly for the Org
> integration. I thought it would be a good idea to get some feedback
> from the community on how their experience using emacs-jupyter has
> been. I'm getting back into active maintenance of the project and am
> looking for feedback to get a better idea of what the future of the
> project could look like. What features of standard Org source blocks
> do you find Jupyter source blocks are lacking? What potential features
> do you think would be useful for Jupyter source blocks to support,
> given the capabilities of Jupyter? What would it mean to see
> Emacs-Jupyter and Org more integrated? Of course, any other thoughts
> are welcome.

Re: Feedback on Emacs-Jupyter

[Colin Baxter 😺]

>>>>> Nathaniel Nicandro <nathanielnicandro@gmail.com> writes:

    > Hello all,

    > I'm the maintainer of the emacs-jupyter project
    > (https://github.com/nnicandro/emacs-jupyter) which essentially
    > integrates Jupyter kernels (https://jupyter.org) with Org mode
    > source blocks.

jupyter.org in using cloudflare uses non-free js. For me, this is a
significant barrier. 

Re: Feedback on Emacs-Jupyter

[David Dynerman]

Dear Nathaniel,

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.

emacs-jupyter has proved so useful that I’ve been collecting a list of suggested improvements - I was actually intending on trying to contribute some of these myself, but I think it would be good to discuss first with you and other users of emacs-jupyter (is there an emacs-jupyter mailing list or preferred venue?). For now I’ll just share what I think would be the biggest improvement for my use case.

I use emacs-jupyter to connect from my laptop to remote jupyter kernels and notebook servers running on powerful machines provided by my employer. I work in a notebook locally on my laptop, but execute code blocks remotely. I specify a single remote jupyter notebook server+kernel to connect to in a #+PROPERTY line at the top of my org file which globally sets header-args for jupyter-python to include the correct :session argument.

For me, the biggest improvements would be addressing some pain points with disconnecting/reconnecting to the jupyter notebook server or kernel. I don’t have technical suggestions yet on how these could be addressed, so I’ll just describe the user experience side of things.

1) Reconnecting to the notebook server after disconnecting. Commonly I’ll work in my notebook, then take a break and close my laptop or disconnect from my work VPN. When I re-open my laptop/reconnect to VPN it seems like the connections to the remote notebook server are in a bad state (this may be a tramp thing, also). Currently my work around is to kill the associated emacs jupyter REPL buffer, then navigate to one of the source blocks in the notebook and run org-babel-pop-to-session which has the side-effect of re-connecting to the jupyter notebook server and recreating the jupyter REPL buffer. 

The main downside to this workaround is that the scroll back history of the REPL buffer is lost, since the buffer was killed. It would be great to be able to re-establish the connection to the REPL without discarding the buffer.

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 don’t know much about jupyter, but I saw some jupyter logs about buffered messages. Perhaps jupyter buffers output when a remote client disconnects? If so, maybe this buffered output could be replayed in a notebook when the emacs jupyter REPL connection is re-established?

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

Thanks again for the wonderful package - I hope we can talk a bit more about some of these friction points. I’d be happy to give a crack at contributing a PR, if that would be welcome.

Thank you,
David

> On Jan 4, 2022, at 15:24, Nathaniel Nicandro <nathanielnicandro@gmail.com> wrote:
> 
> 
> Hello all,
> 
> I'm the maintainer of the emacs-jupyter project
> (https://github.com/nnicandro/emacs-jupyter) which essentially
> integrates Jupyter kernels (https://jupyter.org) with Org mode source
> blocks.
> 
> I wanted to make an introduction to the Org community.  So...hello!  And
> thanks for promoting the project on https://orgmode.org/features.html.
> 
> I believe a lot of users of the project use it mainly for the Org
> integration.  I thought it would be a good idea to get some feedback
> from the community on how their experience using emacs-jupyter has been.
> I'm getting back into active maintenance of the project and am looking
> for feedback to get a better idea of what the future of the project
> could look like.  What features of standard Org source blocks do you
> find Jupyter source blocks are lacking?  What potential features do you
> think would be useful for Jupyter source blocks to support, given the
> capabilities of Jupyter?  What would it mean to see Emacs-Jupyter and
> Org more integrated?  Of course, any other thoughts are welcome.
> 
> -- 
> Nathaniel
> 

Re: Feedback on Emacs-Jupyter

[Nathaniel Nicandro]

Ken,

> First, thank you (many times) for maintaining emacs-jupyter. It is one of the most-used tools on my computer. I've been using your software daily for the past few years to develop code and write papers.

Your welcome, I'm glad that my efforts on the project mean that there are people who have integrated it into their daily workflow!

> issues inputting tables into Python code blocks

The issue that I found was related to how, with a cached result, the
result is eventually read by org-babel-read-result, which in turn
calls org-babel-read-element.  And org-babel-read-element returns nil
for results in a drawer.  I'm assuming because there is not a standard
way to interpret drawer results as Lisp.  Perhaps interpreting the
drawer as a list of results?  So that in the particular case mentioned
in https://github.com/nnicandro/emacs-jupyter/issues/267,
org-babel-read-result would return a list of one element containing
the corresponding table.

> I throw it out there as a concept/idea

I do like the idea of a standalone document that contains everything
without the need of external resources.  So there would be a "*
Graphics" section containing base64 encoded images and then maybe on
opening the document, those get translated to image links under their
respective locations. Maybe by default we treat the "* Graphics"
section similar to a section tagged as ARCHIVE so that a user doesn't
have to weary themselves with all those encoded images.  I would
suggest opening up a new issue requesting the feature so we can talk
more about it.

> Thanks again for the excellent software,

Your welcome,
-- 
Nathaniel

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

Re: Feedback on Emacs-Jupyter

[Daniel Fleischer]

Hi, 

I submitted an issue regarding connection file format incompatibility.
Other than that I'm looking forward trying your package!

-- 

Daniel Fleischer

Re: Feedback on Emacs-Jupyter

[Ihor Radchenko]

Nathaniel Nicandro <nathanielnicandro@gmail.com> writes:

> I'm the maintainer of the emacs-jupyter project
> (https://github.com/nnicandro/emacs-jupyter) which essentially
> integrates Jupyter kernels (https://jupyter.org) with Org mode source
> blocks.
>
> I wanted to make an introduction to the Org community.  So...hello!  And
> thanks for promoting the project on https://orgmode.org/features.html.
>
> I believe a lot of users of the project use it mainly for the Org
> integration.  I thought it would be a good idea to get some feedback
> from the community on how their experience using emacs-jupyter has been.
> I'm getting back into active maintenance of the project and am looking
> for feedback to get a better idea of what the future of the project
> could look like.  What features of standard Org source blocks do you
> find Jupyter source blocks are lacking?  What potential features do you
> think would be useful for Jupyter source blocks to support, given the
> capabilities of Jupyter?  What would it mean to see Emacs-Jupyter and
> Org more integrated?  Of course, any other thoughts are welcome.

Thanks a lot for your work!

I am not an active user of your package, but I recall a detailed video
by Prof. Kitchin where he discussed some of the use cases, improvements,
and "wishes" about emacs-jupyter:
https://www.youtube.com/watch?v=RD0o2pkJBaI

Hope it helps.

Also, it appears that Jupyter is getting a lot of traction in research
community and it is distributed via GPL-compatible license (modified BSD
license). I believe that we should consider including the Org-related
part to Org core if the rest can be distributed via ELPA. WDYT?

Best,
Ihor

Re: Feedback on Emacs-Jupyter

[Nathaniel Nicandro]

> Thanks a lot for your work!

Thanks a lot for maintaining the wonderful Org package!

> Hope it helps.

Thanks, I've previously seen the video and it does help with figuring
out the issues with emacs-jupyter as it currently stands.

> Also, it appears that Jupyter is getting a lot of traction in research
> community and it is distributed via GPL-compatible license (modified BSD
> license). I believe that we should consider including the Org-related
> part to Org core if the rest can be distributed via ELPA. WDYT?

I would be happy to contribute the Org related parts of emacs-jupyter to
Org core.  I think that would mainly mean the ob-jupyter.el file that is
similar to the other ob-*.el files.  How would I go about contributing
ob-jupyter.el in this specific situation?

With regards to distributing the rest via ELPA, I would like to get the
code base into a more stable state as I am planning to integrate changes
that I've been working on this past year which may cause some breaking
changes in people's configs. Once I've shaken out the bugs after I merge
those changes, I'll be more than willing to submit emacs-jupyter as an
ELPA package, if they would have it.

Regards,
-- 
Nathaniel

Re: Feedback on Emacs-Jupyter

[Ihor Radchenko]

Nathaniel Nicandro <nathanielnicandro@gmail.com> writes:

> I would be happy to contribute the Org related parts of emacs-jupyter to
> Org core.  I think that would mainly mean the ob-jupyter.el file that is
> similar to the other ob-*.el files.  How would I go about contributing
> ob-jupyter.el in this specific situation?

You can prepare a patch adding ob-jupyter.el file to Org and send it to
this ML. You will also need an FSF copyright assignment (see
https://orgmode.org/worg/org-contribute.html#devs).

Best,
Ihor