Finish Processing.py

[eah13]

Based on a large volume of user requests, we're considering a push to give processing.py much greater coverage of Processing's python mode.

As a review: Processing is a Java-based visual programming toolset for making animations, designed for teaching/learning. C-style syntax sucks, so there's a Python mode that is essentially a Python to Java transpiler that exposes the base language's capabilities via Python syntax. None of this works on the web but thanks to Atwood's law there's a JS project that attempts to replicate it. Brad put it into Skulpt because it's a great teaching tool.

Brad's original implementation takes the right approach, I think, of wrapping processing.js in Skulpt (which is of course the analog to what the original Python mode does anyways). If we completed this work, coverage would then theoretically be equivalent to processing.js's, which is everything not listed in red here I think. The supported processing.js version could also bump from 1.4.4 to 1.4.8.

Aside: There's a newer JS based project, p5.js, but it's probably a worse choice since its goal is not to replicate Processing's capabilities and there's no standard Python mode.

So, the basic plan is to finish what Brad started with a goal of full coverage of whatever the Venn diagram of processing.js and Python's Processing mode is.

For discussion:

• Who's interested in using this if we built it? Ditto for contributing.
• Any better ideas than the preliminary plan above?
• This could stay a part of the stdlib for backwards compatibility, but could also make sense as a third party lib if there are no objections to that. The benefit would be smaller package size as the full module might add several hundred lines (at least). The drawback would be that anyone who's got processing-based user code would need to configure the 3rd party lib to update skulpt. I'm OK either way.
• What to do with the existing processing package? Seems like we could keep it and build on it but if there are any things @bnmnetp would have done differently we've got a chance to do that now. If it seems best we could even consider a full rewrite but there would probably need to be a really good reason to do so.
• Any other considerations?

Various processing issues that may be addressed directly or rendered moot with a rewrite (from a simple search of open issues - I didn't check to see if they've been fixed but not closed):

564

531

378

375

172

[swirly]

Hello I don't know if this issue is still revelant. processing.py was made exclusively for python 2 and will not be ported to python 3, due to it's underlying conception with jython.

p5.js is something marvelous. It's inspired by processing and not a derivative work but a real new implementation. The ressources are very large. The coding train is a top educative ressource for example

p5py is the actual python 3 implementation of a python processing clone. It is in active developpement (for exemple, a new syntax on coordinates to implement compatibility has been recently commited). Just use it with pip install p5 :)

It's not always easy to use p5py because of the underlying libglfw library.

p5py could be (imho) translated directly to p5js in order to have p5py in skulpt

Graphic animations are always great to motivate pupils. I use skulpt to teach, but being limited to turtle is a real pain. Previously, I was using p5js in browser and the pupils were amazed. The wow effect was great.

Porting p5 to skulpt would help spread python

[s-cork]

I was working on the ffi ideas #1191 And I've come up with a way to proxy arbirtrary js objects.

Which means skulpt's implementation of p5 could be as simple as

function $builtinmodule() {
    return {
        __name__: new Sk.builtin.str("p5"),
        p5: Sk.ffi.remapToPy(window.p5),
        __doc__: new Sk.builtin.str("A skulpt implementation of the p5 library"),
    };
}

and then it should 🤞 just work

from p5 import p5

p = p5()

canvas = p.createCanvas(700, 410)
canvas.parent("turtle")

def draw():
    p.background(0)
    p.fill(255)
    p.rect(100,500,50,50)
    p.ellipse(50,50,80,80)

draw()

It also means that things like the document implementation can be changed to something like

function $builtinmodule () {
    return {
        __name__: new Sk.builtin.str("document"),
        document: Sk.ffi.remapToPy(window.document),
        jQuery: Sk.ffi.remapToPy(window.jQuery),
    };
}

And then they just work as expected!

[s-cork]

and here's a gist of a skulpt version of a p5 example

https://gist.github.com/s-cork/3397e26bc62e9d82a339372d1f613299

https://p5js.org/examples/simulate-particle-system.html

[albertjan]

Oh hey before you spend too much time on processing.py you should have a look at: https://github.com/trinketapp/processing.sk

[swirly]

and here's a gist of a skulpt version of a p5 example

https://gist.github.com/s-cork/3397e26bc62e9d82a339372d1f613299

https://p5js.org/examples/simulate-particle-system.html

HEY ! But this is a real marvel ! When this get to works, I wanna be a beta tester 👍 This would be a real game changer for my courses, where I have to run partly in the browser, and partly in IDE.

[swirly]

I was working on the ffi ideas #1191 And I've come up with a way to proxy arbirtrary js objects.

Which means skulpt's implementation of p5 could be as simple as

function $builtinmodule() {
    return {
        __name__: new Sk.builtin.str("p5"),
        p5: Sk.ffi.remapToPy(window.p5),
        __doc__: new Sk.builtin.str("A skulpt implementation of the p5 library"),
    };
}

and then it should 🤞 just work

from p5 import p5

p = p5()

canvas = p.createCanvas(700, 410)
canvas.parent("turtle")

def draw():
    p.background(0)
    p.fill(255)
    p.rect(100,500,50,50)
    p.ellipse(50,50,80,80)

draw()

It also means that things like the document implementation can be changed to something like

function $builtinmodule () {
    return {
        __name__: new Sk.builtin.str("document"),
        document: Sk.ffi.remapToPy(window.document),
        jQuery: Sk.ffi.remapToPy(window.jQuery),
    };
}

And then they just work as expected!

@s-cork , can you tell me how to use your code ? I've tried to include your code in my js script

function $builtinmodule() {
    return {
        __name__: new Sk.builtin.str("p5"),
        p5: Sk.ffi.remapToPy(window.p5),
        __doc__: new Sk.builtin.str("A skulpt implementation of the p5 library"),
    };
}

But then, it does not work Where have I to include this code ? Any help would be greatly appreciated

[s-cork]

1191 is just a draft and does not work as a standalone branch - I presented it there as just the ffi change ideas.

The above code extracts won't work on current versions of skulpt and I wouldn't recommend using my draft branch in production!

If you want to hack around feel free to use this branch https://github.com/s-cork/skulpt/tree/ffi_ but it's just proof of concept more than anything else. You'd have to clone that branch and build it to get the min.js file and include it in your project.

[swirly]

Interesting proof of concept indeed. Do you have in mind to make it soon a reality ? Any schedule about this ? I have to admit it's above my current level to help design this code, but I would gladly be a tester and report as far as I can

[nickmcintyre]

Hello! I've started adapting the existing processing module to work with p5.js over in this fork. The approach seems pretty straightforward thus far, and I think I'll have something practical by the end of the week.

My niche use case is teaching computational thinking in my high school school math classes. I plan to convert the coordinate system to a right-handed one (i.e., Quadrant I) in addition to some other modifications, but I'd love to help with a standard p5 module if y'all think it would be useful.

Curious what @GoToLoop and @tabreturn think.

[tabreturn]

Hey, @nickmcintyre --

This looks interesting! Thanks for the ping. Please let me/us know when you've got something together. Will you host it somewhere?

[nickmcintyre]

@tabreturn here are a couple of quick 2D and 3D examples on Glitch. I believe achieving parity with Skulpt's processing module will come quickly.

I've been waiting to attempt this for a few months. Pyodide start up time has been a real pain point for my students on Chromebooks, and Brython error messages are non-existent. Skulpt seems perfect for our needs, so I plan to switch the Computiful Editor over in the coming days.

[tabreturn]

Nice work, @nickmcintyre!

I noticed that writing something like a square() function with no arguments now produces a useful error message in the console: p5.js says: square() was expecting at least 3 arguments...