Fatal error: $jupyterout unbound at toplevel

[johnW-ret]

I'm trying to work on getting Comms communication working with dotnet/interactive. To my understanding, I have to write a script that binds commands to actions and registers a type to dotnet_coe_handler_comm. I'm still new to this so I apologize if this is user error on my part.

I'm trying to play around with the Jupyter_comm interface, but if I try to #require "jupyter.comm";; in utop, I get a

>> Fatal error: $jupyterout unbound at toplevel
Exception: Misc.Fatal_error.
Error: Reference to undefined global `Jupyter_notebook__Unsafe'

Compiling a ml script that references jupyter.comm reveals additional information:

Raised at Misc.fatal_errorf.(fun) in file "utils/misc.ml", line 22, characters 14-31
Called from Jupyter_notebook__Unsafe.jupyterout in file "src/notebook/unsafe.ml", line 29, characters 10-42
Called from Topeval.load_compunit in file "toplevel/byte/topeval.ml", line 261, characters 11-23

I'm not sure if these are aggregate errors rolled into one? Poking around in the source, it feels like I'm doing some initialization step incorrectly, but I'm not experienced enough to know for sure, and getting an error only from a #require directive without using any of the contained types feels wrong.

[akabe]

jupyter.comm package cannot be imported in utop, ocaml toplevel, etc. It works on jupyter notebooks only.

$jupyterin and $jupyterout are used for connection of jupyter and the ocaml kernel. They are defined at initialization phase of REPL of the ocaml kernel:

https://github.com/akabe/ocaml-jupyter/blob/ed45f5f04f730dc6978559ef41b05d64fc509a75/src/repl/process.ml#L38-L42

Since utop is not a jupyter kernel, they are deliberately not defined in utop.

[johnW-ret]

Makes sense.

This issue can be closed according to its title, but before it is, I do have a question. This probably belongs in Discussion, but since I don't see it activated for this repository, I'll ask it here:

Does Jupyter_comm.Manager.Comm.create intentionally block evaluation until a response is received? That is the behavior that appears to be happening. dotnet/interactive creates a comms channel only after running an init script (usually meant to setup the comms target) on the target kernel, and in my case, create will block forever, meaning the payload is never received by the .NET kernel and cell evaluation never finishes.