Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Interactive Shell #177

Open
wants to merge 12 commits into
base: canon
Choose a base branch
from
Open

Conversation

AstraLuma
Copy link
Member

@AstraLuma AstraLuma commented Nov 16, 2018

Add a REPL mode, allowing you to interact with a live ppb engine.

TODO:

  • Ctrl+C needs to interrupt the REPL, not the engine
  • Better way to edit sprite/scene classes after the fact (including updating live objects)
  • Do we want the repl itself to receive events?
  • Interacting with the scene is awkward. Magic scene builtin that gets updated?
  • Can we have print() be interjected somehow? Updating sys.stdout and sys.stderr is fraught and tricky (since input(), readline, etc use these as well)
  • Do we want to use eg ipython if its available?

@AstraLuma
Copy link
Member Author

I think the busy loop of the pygame-based engine is making this slow to react.

@pathunstrom
Copy link
Collaborator

Haven't looked at the code yet, answering the questions I can first.

Do we want the repl itself to receive events?

This sounds like an ouroboros to me. Do you have an idea of what we'd gain from such? (Well, aside from making a magic builtin work more easily.)

Interacting with the scene is awkward. Magic scene builtin that gets updated?

Go for it. If we operate on the assumption that only one engine exists at a time. (We can make that assumption.)

Can we have print() be interjected somehow? Updating sys.stdout and sys.stderr is fraught and tricky (since input(), readline, etc use these as well)

I am unsure I understand the intent of the question?

Do we want to use eg ipython if its available?

If we can do it, I'd say this is totally a good idea.

@AstraLuma
Copy link
Member Author

Regards to print(), by "interjecting", mean "print and then redisplay the input line", so print() in any game objects don't disrupt the repl input.

Getting the repl to receive events isn't hard. Just write a system with an __event__() that looks at the repl locals instead of self.

@AstraLuma
Copy link
Member Author

So I updated this so the initial scene is tied to the repl, which is working well. These scene gets stored to the variables scene, and defining events handlers in the repl works perfectly.

Being able to just define event handlers is really nice. Updating them is not. Need to add a thing to allow defining multiple handlers for the same event.

Proper Ctrl-C handling feels somewhere between "black magic" and "nigh impossible", so for now I've just disabled it altogether.

Also, catch exceptions from repl-defined handlers, so they just get printed instead of crashing the entire engine.

Haven't attempted to deal with print() yet, but logging is handled nicely.

@AstraLuma
Copy link
Member Author

I'm thinking about redoing this.

First of all, I think event handlers defined in the repl should run as a system, not on some default scene, removing a lot of magic.

I could actually be convinced that running a REPL in parallel to the engine is a bad idea. This would also remove a lot of magic around maintaining REPL coherency.

@pathunstrom pathunstrom changed the base branch from master to canon June 27, 2020 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants