On Mon, Oct 3, 2016 at 3:00 PM, Thibault Raffaillac < thibault.raffaillac@inria.fr> wrote:
I am not very fond of event loops in general, because they imply "many inputs, one output" (process all pending events, then update screen).
For Morphic this is fine, because it displays on one screen, refreshing
at/around its frequency. But there might be other screens, or network-output, file-output, which have different refresh frequencies. Then you would want to process input events as they trigger rather than storing them in a queue, such that whichever output destination sees the most up-to-date state of the program.
One upfront queue with several workers is the way to do this fast and in a scalable way. Nothing new under the sun, Tuxedo has been doing this for eons, as is any decent TP framework. https://en.wikipedia.org/wiki/Tuxedo_(software) Most of this has been rehashed a lot of times bringing nothing new to the table. Best closest thing for free would be RabbitMQ. Works fine. Even has an MQTT component, which makes it great for IoT.
Javascript has this cool function, requestAnimationFrame, which sets a one-time callback right before the next redraw. In essence it is an output event, allowing some form of reactive programming (no loop, only callbacks on input and output).
Yes, this is a nice one. This guy uses it a lot to super good effect: https://www.livecoding.tv/killroy/ - e.g. https://www.livecoding.tv/killroy/videos/xy8P1-prototypes-and-experiments-ja...
In Pharo we have InputEventFetcher>>registerHandler: which is great for getting input callbacks, but nothing for output :/ WorldState>>addDeferredUIMessage: is probably a closest match, yet it is bound to Morphic, preventing experiments on UI/video games.
Any alternatives?
This? http://www.smalltalkhub.com/#!/~Guille/ReactiveExtensions Maybe this (but not the same thing really) https://github.com/SquareBracketAssociates/PharoLimbo/blob/master/Xtreams/Xs... For video games, well, the ususal update/render with framerate adjustment is the typical loop. If the render is too slow vs the expected one things are skipped, several updates for a render. And user input is picked at one point during the update bit. Not really the same as a windowed GUI. Note that Windows has a queue per app these days (in 3.x days, it was a single queue for all of Windows, which is why things froze a lot. Same as current Pharo). Note also that in Pharo, the InputEventFetcher etc is just the default way and one can have an image doing things otherwise. Display is the raw thing, primitives can do whatever, so if you feel like it, you can reinvent something fully different on the platform.
Thibault
Here is some interesting event loop stuff from Tcl.
I wish we had some easy Tk UI building things in Pharo.
Spec is okay but not intuitive. As it is the only thing that exposes the myriad of various Morphs we have and shields us (somewhat) from the underlying details, we have to use it, but its explorability is really detrimental to the livecoding side of Pharo.
Phil