Skip to main content

News

Topic: miniSphere 5.0b4 (stable: 4.8.8) (Read 173043 times) previous topic - next topic

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2145
Sphere.exit() turned out to be problematic as it was implemented using a longjmp and apparently Allegro didn't like that, causing a crash on exit.  So I replaced it with Sphere.shutDown() which simply instructs the event loop to exit, similarly to how ExitMapEngine() works in Sphere 1.x.

I also brought back the Pact class!  With async/await and the event loop taking center stage in miniSphere 5.0, I figured there should be an easy way in the API to fulfill or reject promises out-of-band.  With Pact, as long as you hold a reference to both the promise and the pact it was made from, you can settle the promise at any time.  It's very intuitive and doesn't require understanding closures.
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2146
Quote
Sphere.exit() turned out to be problematic as it was implemented using a longjmp and apparently Allegro didn't like that, causing a crash on exit.  So I replaced it with Sphere.shutDown() which simply instructs the event loop to exit, similarly to how ExitMapEngine() works in Sphere 1.x.
I understand changing the code to make it function, but why did you also change the method name? Sphere.exit() is nice and obvious.

I also gotta say, by the way - nice work on all of this! :D

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2147
"exit" implies that the method is immediate (which it was), "shutdown" tells the reader that there's a process to it all.  Just as you can either press the power button to forcibly turn off the computer or click "shut down" which will cleanly shut down the OS but has rules to it (open processes must close first, busy apps can block it, etc.)  Subtle difference, but very important from an API design standpoint.  It's the same reason I renamed FileStream#size to fileSize: I want the API to be as intuitive and self-describing as possible to a person reading the code as it will be to the person writing it.
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2148
Well, I asked exactly because exit() is very self-explanatory as well, and just something I've seen around more in software I guess. But your explanation makes a lot of sense; I'm just going to have to remember the change if I ever use the function. :P

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2149
API design is a very subtle art and it's been my experience that method naming isn't always just about the immediate effect of a method.  Consider the difference between:
Code: (javascript) [Select]
Sphere.exit();
Dispatch.onUpdate(doStuff);

Versus:
Code: (javascript) [Select]
Sphere.shutDown()
Dispatch.onUpdate(doStuff);

One might reasonably expect the former to close the engine regardless of what comes after.  It wouldn't, because the new job added to Dispatch keeps the event loop alive.  "But I explicitly said to exit, what's going on?!"  Whereas, if one looks at the latter code, it's requested a shutdown, but then added a new process afterwards which effectively cancels the request (you can't shut down if there are active processes).  It makes more sense intuitively that a request to "shut down" would be canceled (since an OS shutdown can do this too), canceling an "exit" (which sounds atomic) seems nonsensical.

Consider the documentation for ExitMapEngine(), where the note laying out the caveat is significantly longer than the description of the API:
https://github.com/sphere-group/sphere/blob/master/sphere/docs/development/api.txt#L495-L499

And that note is *STILL* vague--what exactly causes MapEngine to return if not the exit call itself?  I know the answer to that because I'm familiar with the Sphere 1.x source code and know that it's single-threaded.  But to the uninitiated it's not nearly as obvious.  For example if you start a FlipScreen loop in an update script that will block the exit despite performing other event loop-y operations.  Which is why the miniSphere documentation is much more explicit about it:
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-core-api.txt#L236-L240

Control MUST return to the engine (i.e. ongoing JavaScript operations must run to completion) for the request to be honored.
  • Last Edit: October 04, 2017, 10:03:13 am by Fat Cerberus
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2150
miniSphere 5 beta 4 is on its way, it's just that I keep hitting really bad bugs that I have to fix.  Also I'm a refactoring fiend so a good deal of the regressions are my own fault, but let's not talk about that... ;)
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b3 (stable: 4.8.8)
Reply #2151
5.0b4 is out now! 8)

The entire Sphere Runtime has been completely overhauled and brought some breaking changes with it (although I tried to be as conservative as possible), see the API documentation to find out what you'll have to do to upgrade.  Notably, Thread.join() and Scene#run() are no longer blocking and instead return a promise that you can await.

Major changes in Beta 4 off the top of my head:

  • "fullScreen" manifest field: Specifies default fullscreen state for game, defaults to false
  • "sandbox" manifest field: Specifies enforcement level of SphereFS sandbox.  "full" is the default and matches previous behavior, "relaxed" allows write access to @/, and "none" disables the sandbox
  • --performance command line option for SpheRun (disables the stepping debugger)
  • Thread#on_update() in subclass can be async and use await
  • No more Sphere.run() or screen.flip(), v2 games must yield to the event loop (async/await makes this painless)
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b4 (stable: 4.8.8)
Reply #2152
Forgot to mention - because files were renamed, I strongly recommend uninstalling any previous version of miniSphere before installing 5.0b4 to ensure cruft from previous versions doesn't cause problems.
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Re: miniSphere 5.0b4 (stable: 4.8.8)
Reply #2153
Do you have an ETA on a stable 5.0 release? I'm not complaining, I just haven't been updating the AUR package. I'm pretty sure I'm the only person who actually uses it, but I don't want to update to a potentially unstable release, and I don't feel like creating a second AUR package for unstable builds.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 5.0b4 (stable: 4.8.8)
Reply #2154
I'm hoping to have the release ready by Halloween, but I'm not sure how feasible that is just yet.  There are a few showstoppers that may or may not be easy to fix:
https://github.com/fatcerberus/minisphere/issues?q=is%3Aissue+is%3Aopen+label%3Ashowstopper

So we'll see what happens.
miniSphere 5.0b4 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Re: miniSphere 5.0b4 (stable: 4.8.8)
Reply #2155
Alright, that's fine. Arch is known for being "bleeding edge", but I don't want to push something that isn't stable yet.