symmetryinvestments / jupyter-wire

Jupyter wire protocol implementation enabling D plugins to be jupyter kernels
Boost Software License 1.0
13 stars 4 forks source link

jupyter-wire not working with jupyter lab #27

Open joequant opened 3 years ago

joequant commented 3 years ago

I've got the basic kernel build, but juypterlab doesn't seem to be connecting to it. Is there a way of turning on logging so that I can debug what's going on.

joequant commented 3 years ago

Okay I'm using jupyterlab --debug and I can see that the kernel and server are passing messages. However, the status bar remains "unknown" and kernelspy is not showing any messages.

Any ideas on how to debug?

joequant commented 3 years ago

Okay. More information here. The jupyter-wire kernel works fine with jupyter-notebook, but there is some issue with jupyter lab. Will look at the code to see what could be the issue.

joequant commented 3 years ago

Asking for help on the jupyter discourse server

https://discourse.jupyter.org/t/jupyter-notebook-kernel-not-working-on-jupyter-lab/6726

skoppe commented 3 years ago

Jupyter-wire was written against jupyter-notebook. I suppose they are much alike, but surely there must be some protocol differences. Lets see what they say on the discourse.

jasongrout commented 3 years ago

It should work the same on both, I think. Can you get a message log of messages sent/received for both the notebook and lab and see what the difference is? What version of notebook and lab are we talking about here?

skoppe commented 3 years ago

Should be straightforward by adding logging to:

https://github.com/symmetryinvestments/jupyter-wire/blob/master/source/jupyter/wire/connection.d#L178 https://github.com/symmetryinvestments/jupyter-wire/blob/master/source/jupyter/wire/connection.d#L195

@joequant can you supply this?

joequant commented 3 years ago

thanks.. It turns out that by building with the verbose flag, I got what I needed. The logging on the kernel side is sufficient, so I'm working by adding logging on the jupyter side to see what's broken there. There seems to be no problems with the connectivity and and it's passing messages back and forth just fine, but something is cause jupyterlab but not jupyter notebook to break.

The major difference that I'm seeing is that jupyter-wire is setting username to None. Will see if that causes problems on the jupyter side.

joequant commented 3 years ago

Okay, I found part of the problem. For some reason jupyter-lab is causing the username field to return None while, jupyter notebook is causing the username field to return a value. It works if I force jupyter lab to return a value in the username field.

joequant commented 3 years ago

Also "basic" works in jupyterlab with the (possibly wrong) fix. However, I'm still having problems with the widgets demo in jupyterlab. It's sending over the packet with the "Void()" but not the packet of data with widget information.

joequant commented 3 years ago

Part of the issue seems to be that for dlang Null strings and empty strings are the same thing, whereas for Python "" and None are different. Setting username to "" seems to fix some issues. Although widgets are still not appearing.

jasongrout commented 3 years ago

It sounds like you are making great progress. Quick note: the kernel protocol has the username field being a string (https://jupyter-client.readthedocs.io/en/stable/messaging.html#message-header). It looks like our message creation function defaults to the empty string: https://github.com/jupyterlab/jupyterlab/blob/781c61561b4531774418e44212eb0547f5b9beaa/packages/services/src/kernel/messages.ts#L144. If jlab is sending a null value, that seems odd and would be good to track down. If the kernel is sending a null value, that sounds like something that should be fixed in the kernel.

jasongrout commented 3 years ago

It looks like the jlab message validation function (IIRC used for incoming messages) does check that the username is a string: https://github.com/jupyterlab/jupyterlab/blob/781c61561b4531774418e44212eb0547f5b9beaa/packages/services/src/kernel/validate.ts#L49