feature: jupyterlab extension

[charles-cooper]

it would be cool to have https://github.com/vyperlang/titanoboa/blob/2c2a2664ad3fa566ddda8a43851cd6f14ab9276a/boa/integrations/jupyter.py work with jupyterlab (on account of jupyterlab being the new thing, it has an IDE and workspace etc). the current method for loading ethers does not seem to work though, it fails with require not defined, seems to be related to Calysto/calysto_processing#11 (comment). it looks like the thing to do is write a proper jupyterlab extension, which would be cool too since we could support vyper files natively.

[charles-cooper]

also debugger (cf. https://jupyterlab.readthedocs.io/en/stable/user/debugger.html) and kernel for vyper could be done

[DanielSchiavini]

Is the idea here to simply port the existing code into a proper plugin, or do we want to add/change the functionality as well?
If so it would be great to know what the new functions we want implement are (maybe in separate issues?)

[charles-cooper]

i think first port into a plugin, and then we can talk about adding additional functionality. the real issue that i'm trying to address here is that the way of jerry-rigging the required libraries that works for jupyter notebook does not work for jupyter labs.

[DanielSchiavini]

I created a plugin template in https://github.com/DanielSchiavini/titanoboa-jupyterlab

Update dec 5: trying to figure out how to add a comm target from the frontend. The kernel is not directly available like before. Alternatevely we could implement some other 2 way communication via ipython or tornado, but that's much more cumbersome.

[DanielSchiavini]

I got it working with API calls and shared memory, no websockets needed frontend and backend and the signer. There's still bugs to fix and tests to write, but this solution with shared memory is feasible and relatively simple.

[charles-cooper]

I got it working with API calls and shared memory, no websockets needed frontend and backend and the signer. There's still bugs to fix and tests to write, but this solution with shared memory is feasible and relatively simple.

very slick! i think i have a couple reservations about using shared_memory_dict -- it's another dependency, and it also seems insecure because it uses pickle for instance (but that seems easy to get around by using shared_memory directly instead) and pass via json, or use something builtin to the mp library -- https://docs.python.org/3/library/multiprocessing.html#sharing-state-between-processes

[charles-cooper]

btw, does this technique work with google colab somehow?

[DanielSchiavini]

We definitely don't need any extra dependencies, this was an easy way to proof the concept.
About Collab, I have no idea, and I wasn't able to find the restrictions quickly today. I can investigate more.

[DanielSchiavini]

I replaced the shared dict dependency with a SharedMemory object for each of the expected callbacks. DanielSchiavini/titanoboa-jupyterlab@2e86d6b

[DanielSchiavini]

The integration tests are failing in Github for some stupid reason (they pass locally).
I've managed to reproduce the issue locally, and track down an exception thru act, docker and jupyterlab to this line. It produces ["TypeError: Cannot read properties of undefined (reading 'get')","TypeError: Cannot read properties of undefined (reading 'get')"] which is about the most generic error in the planet and it can come from literally anywhere. And the error details are right there being ignored in the line. 😠
I'm trying to intercept the call somehow but it's not easy inside Github actions 😞

Of course we could ignore the included tests, but the pipelines are vital to easily produce a npm+pip package.

[DanielSchiavini]

I have 2 PRs with the implementation ready for review:

• JupyterLab+Colab extension #109
• Launch beta.vyperlang.org try.vyperlang.org#1