Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fatal error: $jupyterout unbound at toplevel #204

Open
johnW-ret opened this issue Jan 16, 2024 · 2 comments
Open

Fatal error: $jupyterout unbound at toplevel #204

johnW-ret opened this issue Jan 16, 2024 · 2 comments

Comments

@johnW-ret
Copy link

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
Copy link
Owner

akabe commented Jan 16, 2024

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:

let define_connection ~jupyterin ~jupyterout ~context =
(* Unsafe definition of channels in REPL *)
Evaluation.setvalue "$jupyterin" (Unix.in_channel_of_descr jupyterin) ;
Evaluation.setvalue "$jupyterout" (Unix.out_channel_of_descr jupyterout) ;
Evaluation.setvalue "$jupyterctx" context

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

@johnW-ret
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants