p5 notebook #45
Comments
|
Cool, thanks for the heads-up.
We should definitely figure out how to work the concept of browser kernels,
which understand the full kernel spec, into a lab core PR... I've found it
challenging to keep the API up properly, and there's a lot it could offer.
I've also been percolating on how to get frontend language servers into
jupyterlab-lsp, as well... And having that with p5 would be helpful, no
doubt.
The iframe approach is a great jump start... But eventually i think this
kind of work will need a way to move into a worker. Even loading Pyodide,
which is still the brass ring jyve is striving for, can definitely be
taxing.
I have toyed with doing a bespoke frontend (e.g start with a text box and a
Jyve kernel, and build UI from there), but eventually the thought tends
towards features that lab just already has. I think there's a lot of space
for theme-only reduction and plugin replacement to get to more pleasing
minimalism, such that other peoples' plugins just work. Maybe the best hook
for that right now is probably "presentation mode"?
…On Mon, Mar 23, 2020, 10:40 Jeremy Tuloup ***@***.***> wrote:
Hey folks,
Really cool stuff here. Just a quick post to let you know that I've
recently been experimenting with similar ideas to build a notebook
interface for p5.js: https://github.com/jtpio/p5-notebook
The approach is similar (using IFrames for the kernel), with slight
differences:
- the p5 notebook is a custom frontend built using lab components,
started from the notebook example in core lab
<https://github.com/jupyterlab/jupyterlab/tree/master/examples/notebook>
- it also uses its own (incomplete) "Jupyter Server in the browser",
since the goal would be to eventually store and manage notebooks in the
browser (for example using localStorage), manage kernels, and to some
extent cover most of the notebook server API.
- the focus is to build a very minimal notebook UI for p5.js users,
kind of similar to this proof of concept but giving it a "Jupyter look":
https://github.com/aparrish/nb5js-proof-of-concept. Also with the idea
of having something similar to the p5 online editor
<https://editor.p5js.org/> but for notebooks, that runs entirely in
the browser.
- for now it inlines IFrames in the cell outputs to make it look like
a real output. Although technically these other IFrames are copies of the
real one used by the kernel. Each time a cell is executed in the main
kernel, it is also executed in the other IFrames (they act as "views").
- most of this is not really specific to p5 and could be extracted
into separate packages, a bit like what jyve does. But for now having it
all in one place makes it easier to iterate on.
Anyway I just wanted to share this so that we can try to make all of this
work together at some point!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#45>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALCRDSZWOPPYQJRH2MV3LRI5YEHANCNFSM4LR5PSBA>
.
|
|
Also on the file system: my original goal for jyve was to support dat or
ipfs, and indeed I got a demo working in the beaker browser, back when it
supported both stacks. The nice thing about these is that they would
provide an ideal mechanism to serve both the "host" application (jyve, p5n,
etc) as well as user data... Once you hit "publish" and get that hash, you
could easily share your app/content, and with day, you could even update
it, and subscribers would be notified.
Since then, both APIs have been rounded out a lot, and we did a pretty cool
demo with jupyterlab-dat for a sort of "notecast". This also provided a
chat-per-dat, built as a bespoke notebook/servicemanager, which could be
used to share additional notebooks.
…On Mon, Mar 23, 2020, 16:36 Nicholas Bollweg ***@***.***> wrote:
Cool, thanks for the heads-up.
We should definitely figure out how to work the concept of browser
kernels, which understand the full kernel spec, into a lab core PR... I've
found it challenging to keep the API up properly, and there's a lot it
could offer.
I've also been percolating on how to get frontend language servers into
jupyterlab-lsp, as well... And having that with p5 would be helpful, no
doubt.
The iframe approach is a great jump start... But eventually i think this
kind of work will need a way to move into a worker. Even loading Pyodide,
which is still the brass ring jyve is striving for, can definitely be
taxing.
I have toyed with doing a bespoke frontend (e.g start with a text box and
a Jyve kernel, and build UI from there), but eventually the thought tends
towards features that lab just already has. I think there's a lot of space
for theme-only reduction and plugin replacement to get to more pleasing
minimalism, such that other peoples' plugins just work. Maybe the best hook
for that right now is probably "presentation mode"?
On Mon, Mar 23, 2020, 10:40 Jeremy Tuloup ***@***.***>
wrote:
> Hey folks,
>
> Really cool stuff here. Just a quick post to let you know that I've
> recently been experimenting with similar ideas to build a notebook
> interface for p5.js: https://github.com/jtpio/p5-notebook
>
> The approach is similar (using IFrames for the kernel), with slight
> differences:
>
> - the p5 notebook is a custom frontend built using lab components,
> started from the notebook example in core lab
> <https://github.com/jupyterlab/jupyterlab/tree/master/examples/notebook>
> - it also uses its own (incomplete) "Jupyter Server in the browser",
> since the goal would be to eventually store and manage notebooks in the
> browser (for example using localStorage), manage kernels, and to some
> extent cover most of the notebook server API.
> - the focus is to build a very minimal notebook UI for p5.js users,
> kind of similar to this proof of concept but giving it a "Jupyter look":
> https://github.com/aparrish/nb5js-proof-of-concept. Also with the
> idea of having something similar to the p5 online editor
> <https://editor.p5js.org/> but for notebooks, that runs entirely in
> the browser.
> - for now it inlines IFrames in the cell outputs to make it look like
> a real output. Although technically these other IFrames are copies of the
> real one used by the kernel. Each time a cell is executed in the main
> kernel, it is also executed in the other IFrames (they act as "views").
> - most of this is not really specific to p5 and could be extracted
> into separate packages, a bit like what jyve does. But for now having it
> all in one place makes it easier to iterate on.
>
> Anyway I just wanted to share this so that we can try to make all of this
> work together at some point!
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#45>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAALCRDSZWOPPYQJRH2MV3LRI5YEHANCNFSM4LR5PSBA>
> .
>
|
|
Thanks @bollwyvl for the input!
You mean the Lab API and the changes with new major releases?
Having support for Pyodide would be the killer feature 👍 (and I see that #27 is getting there progressively). It should be relatively straightforward to have a generic worker kernel for JavaScript. With of course the caveat of not being able to access the DOM (unless some proxy / virtual dom is used maybe). But it would still be interesting to have it as a plain JS kernel and as an alternative to the other JS kernels out there.
This is something that has come up quite often indeed. Many folks like the simpler look and features of the classic notebook, and it sounds like there could be good reasons for having more minimal frontends. Presentation mode is a good compromise but it still leaves a bit of chrome on the screen. |
Right: the kernel/session stuff seems to be particularly volatile, and does change on point releases in ways that break jyve, because of the weird monkeypatches. I took a serious swing at 1, and gave up (not a lot of extra time for it). Will be taking a look at lab 2. I've lobbied in the past for additional API extension points to make things more composable, it's a matter of a) having time, b) getting jyve stuff working with something like
Right: here's (one of) the kernel-side examples we've used to cut down the noise: https://gist.github.com/tonyfast/e2e574e6fa3dcc4a4557f486d8bf0d70 It's mostly hygeinic, only firing when presentation mode is hot. It would not be a big deal to package this into an extension, plus a little more fancy stuff, but the key thing is when you're presenting/working, you can focus on the goods. But you're still paying for 5mb on the wire. From a size-on-wire perspective: the p5notebook
and have everything be built from there, with a lot more laziness... but building up an app is not everyone's cup of tea. |
|
Closing since there is now a reboot happening in https://github.com/jtpio/jupyterlite. And the |
|
Yup, is cool. Would also see offering the "slow reveal" iframe approach vs
build-and-then-do-nonjs-magic, but that's another issue.
Once lite supports federated extension, certainly consider making the p5
kernel one! While it will be nice to have a distribution just for p5, being
able to combine multiple things is fun! Indeed, there's the opportunity to
show interesting interactions _between_ client kernels in a way that isn't
straightforward with zmq kernels.
|
Hey folks,
Really cool stuff here. Just a quick post to let you know that I've recently been experimenting with similar ideas to build a notebook interface for p5.js: https://github.com/jtpio/p5-notebook
The approach is similar (using IFrames for the kernel), with slight differences:
localStorage), manage kernels, and to some extent cover most of the notebook server API.Anyway I just wanted to share this so that we can try to make all of this work together at some point!
The text was updated successfully, but these errors were encountered: