Dependency on skulpt - would pyodide work too?

[psychemedia]

pyodide, Mozilla's "Python scientific stack, compiled to WebAssembly" provides access to a full Python stack inside the browser.

How tightly coupled is BlockPy to Skulpt?

Is it possible to separate out the front end UI from the py environment on the back?

For example, could the Skulpt dependency be replaced by a pyodide dependency?

Could something like ThebeLab or Juniper be used to provide access to a remote Jupyter managed kernel?

Does this Jupyter extension (jupyterlab-outsource) demonstrate a BlockPy reusable or co-optable way of running a Blockly UI connected to a Jupyter kernel in a Jupyter environment?

[acbart]

Currently, it's not trivial, but it is certainly doable. One of the major projects this summer is to separate out the block/text component into its own repo. As you can see, we're very early into that work, having only formally started that repository a few days ago. Ultimately, the separate BlockMirror component would be usable in any other kind of web-based environment - and we explicitly want it in Jupyter Notebooks.

A major question right now, actually, is whether Skulpt would be a dependency of BlockMirror. I had some students experimenting with Antlr4's JS target this semester, and we were able to produce a Parse Tree. Unfortunately, all the existing work has been with Abstract Syntax Trees, so I would need to do some additional work to get PSTs into the AST format. Skulpt very recently (as of this week) updated its parser for 3.7, and I've already made progress on updating BlockPy's skulpt to that new version.

I haven't done timing tests on either one, but surprisingly the file size of JUST an Antlr Python parser vs. the entire Skulpt runtime is not that different, at least uncompressed and not minified (~800kb vs ~1200kb). Some attempts to isolate just Skulpt's parser revealed little savings (a few hundred KB). So I'm currently leaning towards letting Skulpt be a strange heavy dependency on BlockMirror.

[psychemedia]

So by saying "the separate BlockMirror component would be usable in any other kind of web-based environment" do you mean that eg the UI could be connected to a Skulpt backend, but that it could equally be connected to something else (assuming the AST could be sensibly communicated)?

Hmmm, I wonder how the jupyterlab-outsource blockly extension works... I also need to play with that, I think....

I wonder if one way of starting to pick things apart in to that sort of format would be to start off trying to run the UI in a Jupyter context using a Skulpt kernel, eg https://github.com/Calysto/skulpt_python , which I guess would mean:

1. packaging the UI components for rendering in the Jupyter context;
2. adding Jupyter comms between the UI and the skulpt interpreter / kernel.

There's also been quite a few demos recently of notebook widgets updating state back in the kernel that make use of the low level widget comms that keep rendered widgets and kernel state in synch. Having the UI as an ipywidget could simplify things there, but I guess ties things into Jupyter too much. Unless the abstraction of the BlockPy UI into its own package meant that that could then be more easily wrapped or extended as an ipywidget.

(I have no idea if any of the above makes sense; just trying to think things through with the sketchy knowledge I have about what may or may not be possible and what the routes to it may or may not be...)

[acbart]

So by saying "the separate BlockMirror component would be usable in any other kind of web-based environment" do you mean that eg the UI could be connected to a Skulpt backend, but that it could equally be connected to something else (assuming the AST could be sensibly communicated)?

Right, although the AST communication is very simplistic. From BlockPy's perspective, there is no AST, just the textual source code. BlockMirror will basically be a component that visually has Blockly, CodeMirror, and a tabbed toolbar above them. Internally, Skulpt will be used to convert the CodeMirror's textual source code into an AST that can be parsed into blocks for Blockly - but that's a strictly internal detail that doesn't affect the black box perspective of anyone using BlockMirror. For them, it'll just be a drop-in replacement for an editor like CodeMirror.

Interesting to see the Skulpt Python Kernal. With the recent improvements in Skulpt, I wonder if there's potential there to do some more interesting things in JN. Still, there won't be a full MatPlotLib implementation in Skulpt for a long time, so that's always going to be a limiting factor.

[psychemedia]

Right, re: things like Matplotlib. That was partly what prompted my question about pyodide... It's still early days for it, but I think there could be interesting things done with it; eg https://epiphany.pub/ hit my radar yesterday which seems to make use of it.

[psychemedia]

In passing, https://github.com/deathbeds/jupyterlab-outsource provides a JupyterLab based Blockly UI for creating programs with an equivalent Python code view updated live alongside in Jupyter notebook.

(The reverse path, changing code in the notebook, does not seem to update the Blockly view.)

[acbart]

Eyeballing it, looks like they're using the standard Python set of Blockly blocks. I was hoping they'd do some special ones for Pandas/MatPlotLib/etc. integration. But hey, nice that folks are interested in Block Python.

Progress is continuing on BlockMirror. Yesterday, I finally resolved a major performance issue in the new Skulpt parser, which actually now outperforms the old version of the parser we've been using. Right now, I've started working on support for all the Python AST nodes - I'd like to have 100% Python language support. There's about a hundred and I'm only a few in, but I'm hoping things will move fast. After that, I just have to set up some event handling and the beta version of BlockMirror should hopefully be ready.

[psychemedia]

I'm not sure I've seen many customisation packs for particular packages.

On the briefest of searches, I can find one for creating SPARQL queries ( http://sparqlblocks.org/ ) but that's about it? I'm not sure what custom blocks ML for Kids project might support? (API calls, maybe?)

[acbart]

The beta version of BlockMirror is ready: https://github.com/blockpy-edu/BlockMirror

We're hoping to have some VT students integrate it into Jupyter Notebooks this fall as a new widget. That might also lead to eventually adding some better support for Pandas et al, although we're not currently there yet.

[psychemedia]

Ooh... that's exciting (the beta, and esp. the potential for Jupyter widgetisation).

Is there an online / live demo anywhere?

FWIW, there's been work elsewhere on a recent integration of ProseMirror into JupyterLab: https://github.com/jupytercalpoly/jupyterlab-richtext-mode . (I personally prefer notebook integrations; JupyterLab affords a different way of working to the one I've become habituated to!)

[acbart]

At some point, I should generate GitHub Pages and let the internal test page be publicly accessible more easily. But, the new version of BlockPy uses BlockMirror, so you can check it out here: http://think.cs.vt.edu/blockpy/blockpy/load

You should be able to upload almost any Python file and have it turned into blocks. The list of currently unsupported features is here: blockpy-edu/BlockMirror#1

The remaining unsupported features probably won't get implemented until next summer - fortunately, I don't think the upgrade path is as awful as it used to be, thanks to the vast improvements made to Skulpt internally.

[psychemedia]

Great, thanks... will give it a go...

…

On Wed, 28 Aug 2019 at 12:10, Austin Cory Bart ***@***.***> wrote: At some point, I should generate GitHub Pages and let the internal test page be publicly accessible more easily. But, the new version of BlockPy uses BlockMirror, so you can check it out here: http://think.cs.vt.edu/blockpy/blockpy/load You should be able to upload almost any Python file and have it turned into blocks. The list of currently unsupported features is here: blockpy-edu/BlockMirror#1 <blockpy-edu/BlockMirror#1> The remaining unsupported features probably won't get implemented until next summer - fortunately, I don't think the upgrade path is as awful as it used to be, thanks to the vast improvements made to Skulpt internally. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=AAAUILHLS4Q4RGDQYVYIQ5DQGZMIZA5CNFSM4H2S4Z62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KYA5Q#issuecomment-525697142>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAUILBONS5AHRJEX7UPJU3QGZMIZANCNFSM4H2S4Z6Q> .

[psychemedia]

An observation on the skulptness of BlockPy - there is a skulpt Jupyter kernel that might make for a simpler integration. Not sure if / how it works with JupyterLab?

[acbart]

Now that's an interesting concept. Though I think one of the major appeals of Jupyter is that you get a real Python environment with fast and feature-complete MatPlotLib, Pandas, and Numpy. I'm not sure you get a whole lot by switching over to JS side, besides greatly reduced server requirements. Still, I suppose there could be some potentials with things like WebASM. After all, most of those libraries speed is from the C side, not the Python side.

[psychemedia]

Yes, agreed with the full scipy stack availability for a Jupyter Py kernel.

I was just wondering if considering other kernels might help simplify some integration steps.

When it comes to WASM, I don't think I've seen any in-browser WASM Jupyter kernels, though maybe https://github.com/minrk/jskernel suggests a route to that (what are benefits? Security / not executing code on server? Reduce server load?).

In JupyterLab, I wonder if https://github.com/deathbeds/jyve would provide a route to Pyodide? ("A Jyve Kyrnel runs in JupyterLab and has full, unsafe access to the many of the capabilities of your browser").

Something like https://epiphany.pub/ does offer a notebook like experience with Pyodide code execution, but the code isn't open.

[acbart]

This was a good discussion, but as far as the original issue goes: we're all in on Skulpt now. I've invested too much time to consider other things. Still, I really hope someone gets excited about BlockMirror and makes a Jupyter Notebook extension. Perhaps I can find an undergrad this fall. It'd be so straightforward...

[psychemedia]

I've been dabbling with a simple robot simulator that runs against skulpt inside an ipywidget; if I ever get free time again, I might see if a similar approach could work to embed blockpy into notebooks.

More interesting perhaps would be getting BlockMirror to run as an extension in a Jupyter notebook or JupyterLab context. There is a jupyter notebook WYSIWYG extension out there already but it's based around TimyMCE; that said, it may be provide a useful crib for how to wrap BlockMirror? If I ever get any free time again, I will try to look at it...