Livecoding Mode for Python

[catilac]

Leverage bevy_ecs to watch the currently running sketch for changes and hotswap on successfully compiling edits

Edit: I'm currently working on this, but there are some architectural questions I have.

Current Approach

I've created a new bevy Asset called Sketch and spawn that object at Startup.
When I make a change to sketch.py bevy will notice. yay

The question now is how does the actual reloading mechanism work for Python? And there is a larger question of how does this mechanism work for other language frontends (Processing4/java, lua, ocaml, scheme, ruby, etc...)

For Python (w/ pyo3)

1. Make a change to sketch.py
2. Bevy will observe and [emit an event]
3. processing_pyo3 crate will check if a reload is necessary
4. Using something like importlib.reload(), pyo3 can reload the module, and skip creating a new graphics context if it doesn't have to, and grab the new draw and setup functions.

+--------+        +------+
| Python |------->| Bevy |
+--------+        +------+
   ^                |
   |                |
   +-- onChange ----+

What about other language front-ends?

I suppose some custom plugin loading could work. The Sketch Asset could be something that Python introduces, so that would allow for us to only use any of that design only for our pyo3 implementation

The other front-ends would have to build their own systems, and we could expose hot-reloading related FFI methods?

I think at the moment, I really like the idea of just having a Python related Livecoding bevy plugin. I'm still learning about bevy's ECS system, but is it possible for us to represent our "scene graph" as an intermediary that can easily map to the existing entities in bevy?

ie:

def draw():
    background(220)

    fill(255, 0, 100)
    stroke(0)
    stroke_weight(2)
    rect(100, 100, 200, 150)

when I change stroke_weight, could bevy know to update, or refresh that particular entity?
or is it easier to just drop all the entities and re-run the sketch? I might be over thinking it.

For now I'm going to work towards getting python to hotreload.

[tychedelia]

A few thoughts:

1. I think have a Sketch asset that is managed by core libprocessing makes sense. This should basically just be a wrapper around source: String rather than including any language specific stuff. I think there are a lot of questions about stuff like state invalidation in particular language runtimes (what if the user accidentally has a closure over some value in file A in file B, etc), but this is mostly a language thing not a libprocessing thing.

2. I don't think that we want to reload the module, but re-inject the user's function in the active runtime. What this looks like in pyo3 is using something like py.run to do something like the following:

fn run() { // or some equivalent main loop
    // ...
    for sketch in processing_poll_sketch_changed() {
        py.run(sketch.source, Some(globals), None)?;
    }
}

See this chapter of the pyo3 book.

Nothing in our processing python module should have to reload, and the graphics context we implicitly create on module load should persist and be idempotent across module loads (ymmv depending on other language VM impls).

3. As for state, for stuff inside def sketch, this is all immediate mode and so is rebuild every frame anyway. For stuff outside of that, like globals or stuff we build in def setup, I think it's potentially a bit tricky... Ideally in a perfect world (a la lisp), we'd know exactly what part of the AST changed and just be able to update the single item in a file that the user changed. But most languages don't offer this capability (does python? has someone created some kind of python metaprogramming package for this? idk). So the unit of granularity when editing a file (i.e. rather than REPL) is probably that file. It's definitely worth considering how we could work around blowing away state on file reloads, but to some extent this isn't really a libprocessing problem but a language implementation problem. Like, this is why I want to build a processing lisp for my own work because this kind of thing works "out of the box" via REPL.

[catilac]

Thanks so much for the sanity check! I'll keep going the way I'm going. I just wanted to make sure I didn't build in some deeply misguided way.

I like the re-injection approach you've suggested as well. It looks like a nice way to not have to re-build the graphics context, or write smelly code to skip re-building.