-
Notifications
You must be signed in to change notification settings - Fork 29
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
Implement Scratch-like sequencer behavior #214
base: master
Are you sure you want to change the base?
Conversation
This matches how Scratch behaves, and means we don't have to mess around with _layerOrder anymore.
This matches how Scratch does it.
fireTrigger now returns a list of started scripts instead of a promise that resolves when they're finished running. We can wait for those scripts to finish using the new waitForTriggers function, which will yield in a loop until they're done running.
Data that pertains to the state of a *running* script is now part of a new Thread class, meaning Trigger no longer stores any state of its own.
These don't do anything right now, but will be used to determine whether to keep stepping threads or yield until next frame.
We can just wait for the timeout by yielding, then clear the speech bubble ourselves. This means we don't have to worry about the timeout affecting things if the script has been stopped or restarted.
Instead of yielding in a loop until a promise resolves, we "park" the thread. This should help avoid some busy-waits, especially if we ever implement turbo mode.
I've sat on this and a few other PRs for a few days because I've had other things going on. What I'm realizing is that as fall approaches I need to dedicate more of my time and energy to preparing for my first year of full-time teaching (high school math), which means less time for Leopard. Leopard is a hobby for me, and I'm sure from time to time throughout the school year I will continue to work on it for fun, but I'm going to take a break from the responsibility I assigned to myself over the summer, which was to proactively work and respond to issues, PRs, and user feedback. What that means practically, for this PR, is that I will look at it eventually, but I'm not going to make any promises about exactly when. If two trusted parties want to review each other's work and contribute without my involvement (such as @towerofnix and @adroitwhiz) that is, of course, lovely and encouraged. |
Thanks @PullJosh — we're in a bit of a similar boat too... it's sort of like this for everyone, sometimes, but there just ends up being stuff you're part of beyond the projects that still really matter to you, right? We're evaluating and working on our priorities right now!! And clearly you are too. It counts for a lot! So, same here! We totally want to keep working on stuff here. (And in our other projects, too.) But it's as time allows, and as we're able to find a place among the rest of life, y'know. We love reviewing code and we also love testing it - it's just a question of where and when that fits, for us, which we'll keep figuring out. Thanks for the heads up and for sharing where you're at, it means a lot!! Edit edit: Also, good luck with your first year teaching, seriously!! And congrats embarking on that ✨ |
Thank you! I'm very excited! 😃 And I can totally imagine a world where Leopard continues to make progress just at an inconsistent rate as we occasionally have the time, energy, and desire to do something for a bit here and there. |
Depends on #210.
This PR makes a few changes as progress towards #212:
Trigger
and into its own class calledThread
. Threads can:Generator functions that are running as Leopard threads can await promises without having to be async themselves using the new
Thread.await
function.