[Pharo-project] Input sensor rewrite
Hi all, there is a updated version of the input sensor/event rewrite in the Pharo inbox: -load the config map Event-rewrite1.mcm (it's in the Event category in the repository) -load the slice EventRewrite2-michael_rueger.2 - in a workspace execute InputEventSensor installPollingEventSensorFramework voila... Sensor should now be an InputEventSensor. At a later point we can the remove the EventSensor and InputSensor classes. Michael P.S. Could someone please remove Collections-Sequenceable-michael_rueger.15 from the inbox? It's a bogus version
Hi Michael, for those who haven't followed this discussion, could you please explain the benefits of the new mechanism? Thank you On Fri, Apr 17, 2009 at 3:38 PM, Michael Rueger <m.rueger@acm.org> wrote:
Hi all,
there is a updated version of the input sensor/event rewrite in the Pharo inbox:
-load the config map Event-rewrite1.mcm (it's in the Event category in the repository) -load the slice EventRewrite2-michael_rueger.2 - in a workspace execute InputEventSensor installPollingEventSensorFramework
voila... Sensor should now be an InputEventSensor.
At a later point we can the remove the EventSensor and InputSensor classes.
Michael P.S. Could someone please remove Collections-Sequenceable-michael_rueger.15 from the inbox? It's a bogus version
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Damien Cassou http://damiencassou.seasidehosting.st
Damien Cassou wrote:
Hi Michael,
for those who haven't followed this discussion, could you please explain the benefits of the new mechanism?
(just realized the comments aren't up to date and even incomplete) Cleanup ------- -remove the old and confusing EventSensor and InputSensor classes and replace them with InputEventSensor. -remove backward compatibility and polling where possible Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher. Pluggability ------------ -events from the VM are now fetched by an InputEventFetcher "InputEventFetcher is responsible for fetching the raw VM events and forward them to the registered event handlers. Event fetching is done in a high priority process, so even with other processes (e.g. the Morphic UI process) being busy events will still be fetched." This finally gets rid of the input event tickler! InputEventHandlers can then listen to events. Current default listeners are the InputEventSensor for Morphic and UserInterruptHandler. This allows for alternative UI frameworks or other interesting stuff ;-) to register as a listener and deal with input events without ever having to deal with Morphic. Next on my list is to do exactly that with Miro and my experimental IMorph implementation, both built on Announcements. Michael
Nicolas Cellier wrote:
2009/4/17 Michael Rueger <m.rueger@acm.org>:
Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher.
Is it true in Pharo? which VM does not?
Windows http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/133978.... Unless it actually was fixed in the meantime which I'm not aware of. Michael
hi mike did you check why the menus are getting really slow? Stef On Apr 20, 2009, at 11:15 AM, Michael Rueger wrote:
Nicolas Cellier wrote:
2009/4/17 Michael Rueger <m.rueger@acm.org>:
Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher.
Is it true in Pharo? which VM does not?
Windows http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/133978....
Unless it actually was fixed in the meantime which I'm not aware of.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Does it imply that I was too prompt at harvesting the event rewrite? Stef On Apr 20, 2009, at 1:02 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
hi mike
did you check why the menus are getting really slow?
it is the polling interval. But any attempt to fix this currently result in a broken image after saving.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mike I also noticed that the copy and paste does not work with the input sensor rewrite. Stef On Apr 20, 2009, at 1:26 PM, Stéphane Ducasse wrote:
Does it imply that I was too prompt at harvesting the event rewrite?
Stef
On Apr 20, 2009, at 1:02 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
hi mike
did you check why the menus are getting really slow?
it is the polling interval. But any attempt to fix this currently result in a broken image after saving.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Does it imply that I was too prompt at harvesting the event rewrite?
no, not really. One question though is why key events get lost, they should not, even with long polling delays. Well, should... I've published a fix in Kernel-michael_rueger.renggli.295 It might be that the problems I ran into are caused by the Delay bugs fixed in later packages, but I figured out a way to make it work anyways. I'll now look at the copy paste problems. Michael
works great! I will release now then the delays fixes of nicolas. Then some extra cleans. On Apr 20, 2009, at 2:22 PM, Michael Rueger wrote:
Stéphane Ducasse wrote:
Does it imply that I was too prompt at harvesting the event rewrite?
no, not really.
One question though is why key events get lost, they should not, even with long polling delays. Well, should...
I've published a fix in Kernel-michael_rueger.renggli.295
It might be that the problems I ran into are caused by the Delay bugs fixed in later packages, but I figured out a way to make it work anyways.
I'll now look at the copy paste problems.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Not fixed, maybe some one could ask since Andreas claims he want's to fix that ASAP? Maybe at startup time choose which model to use based on the fact windows is the only vm that doesn't support the semaphore? On 20-Apr-09, at 2:15 AM, Michael Rueger wrote:
Nicolas Cellier wrote:
2009/4/17 Michael Rueger <m.rueger@acm.org>:
Not all VMs signal the input semaphore, that's why we currently us a polling event fetcher.
Is it true in Pharo? which VM does not?
Windows http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/133978....
Unless it actually was fixed in the meantime which I'm not aware of.
Michael
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Aright I thought I'd better peer at this since it impacts those slow hand held devices (aka iphones). I took a pharo0.1-10284dev09.04.4 and did update I then count bytecodes executed and print that in ioRelinquishProcessorForMicroseconds So this Pharo image takes 51 million byte codes execute before we sleep. Likely this is the point were all the startup: stuff runs to completion. no windows open 51,249,233 bytes codes to idle now we print how many milliseconds we have calculated the image can sleep until the next wakeup due to a pending delay. for example 3 ms, and how many bytecodes were executed since the last time we slept, 2,409. Note the pattern of sleeping 10,2,4,9 ms and bytescodes executed of 442, 2409... 2009-04-20 20:56:39.634 Squeak VM Opt[2523:813] 3 2009-04-20 20:56:39.635 Squeak VM Opt[2523:813] 2409 2009-04-20 20:56:39.646 Squeak VM Opt[2523:813] 10 2009-04-20 20:56:39.647 Squeak VM Opt[2523:813] 426 2009-04-20 20:56:39.650 Squeak VM Opt[2523:813] 2 2009-04-20 20:56:39.651 Squeak VM Opt[2523:813] 422 2009-04-20 20:56:39.658 Squeak VM Opt[2523:813] 5 2009-04-20 20:56:39.659 Squeak VM Opt[2523:813] 2409 2009-04-20 20:56:39.670 Squeak VM Opt[2523:813] 9 2009-04-20 20:56:39.672 Squeak VM Opt[2523:813] 426 2009-04-20 20:56:39.684 Squeak VM Opt[2523:813] 10 2009-04-20 20:56:39.686 Squeak VM Opt[2523:813] 2630 2009-04-20 20:56:39.694 Squeak VM Opt[2523:813] 7 2009-04-20 20:56:39.695 Squeak VM Opt[2523:813] 422 2009-04-20 20:56:39.697 Squeak VM Opt[2523:813] 1 2009-04-20 20:56:39.698 Squeak VM Opt[2523:813] 2409 2009-04-20 20:56:39.711 Squeak VM Opt[2523:813] 10 2009-04-20 20:56:39.715 Squeak VM Opt[2523:813] 426 2009-04-20 20:56:39.729 Squeak VM Opt[2523:813] 10 2009-04-20 20:56:39.730 Squeak VM Opt[2523:813] 2630 But lets go back and look at mmm well an WIkiServer image based on Pharo from Jan or so. no windows open. Well first I do a lot less work (on purpose) at startup time 3,833,928 bytes code to idle, yes only 6% of the work... (ask me where March 09 went... ) but the other change is the morphic polling loop will send me off to slumber land for 20 ms given it's poll freq I think is targeting 50 fps. and the bytecodes executed each cycle is usually 2478 so it's very consistent. In production I turn server mode on and sleep for 500 ms since the UI events are driven by UIKit from screen taps, it's *all* about battery life... 2009-04-20 21:09:54.992 Squeak VM Opt[2624:813] 20 2009-04-20 21:09:54.994 Squeak VM Opt[2624:813] 2478 2009-04-20 21:09:55.020 Squeak VM Opt[2624:813] 20 2009-04-20 21:09:55.021 Squeak VM Opt[2624:813] 2478 2009-04-20 21:09:55.042 Squeak VM Opt[2624:813] 19 2009-04-20 21:09:55.043 Squeak VM Opt[2624:813] 2478 2009-04-20 21:09:55.064 Squeak VM Opt[2624:813] 19 2009-04-20 21:09:55.066 Squeak VM Opt[2624:813] 2478' 2009-04-20 21:09:55.085 Squeak VM Opt[2624:813] 15 2009-04-20 21:09:55.090 Squeak VM Opt[2624:813] 2474 2009-04-20 21:09:55.112 Squeak VM Opt[2624:813] 20 2009-04-20 21:09:55.112 Squeak VM Opt[2624:813] 2736 2009-04-20 21:09:55.137 Squeak VM Opt[2624:813] 19 2009-04-20 21:09:55.138 Squeak VM Opt[2624:813] 2478 2009-04-20 21:09:55.160 Squeak VM Opt[2624:813] 20 2009-04-20 21:09:55.160 Squeak VM Opt[2624:813] 2478 So I think here then in 40 ms we do about 5000 byte code but the new solution does about 8,722 or 75% more work with a more fractured sleep time. A random squeak 3.10 alpha 7082 image with a window or two open gives 7,390,552 byte codes executed to idle. A boring cycle, I note the 3,434 versus the iphone image 2,478, but this 3.10 image has 3 windows up so likely there is a bit more Morphic cycle time being chewed up. 2009-04-20 21:23:30.632 Squeak VM Opt[2683:813] 19 2009-04-20 21:23:30.632 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.653 Squeak VM Opt[2683:813] 20 2009-04-20 21:23:30.654 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.678 Squeak VM Opt[2683:813] 20 2009-04-20 21:23:30.679 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.705 Squeak VM Opt[2683:813] 20 2009-04-20 21:23:30.706 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.728 Squeak VM Opt[2683:813] 20 2009-04-20 21:23:30.728 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.753 Squeak VM Opt[2683:813] 18 2009-04-20 21:23:30.755 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.777 Squeak VM Opt[2683:813] 20 2009-04-20 21:23:30.777 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.798 Squeak VM Opt[2683:813] 19 2009-04-20 21:23:30.799 Squeak VM Opt[2683:813] 3434 2009-04-20 21:23:30.819 Squeak VM Opt[2683:813] 19 2009-04-20 21:23:30.820 Squeak VM Opt[2683:813] 3434 I'd like to see how the PURE EVENT driven event processing works, but not sure how to do that. Also I'm not sure what changes are in progress given the flurry of notes on the mailing list today and this evening. PS For poll driven VMs, couldn't you stick the event polling back in the morphic polling loop and just run one loop process? -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
These improvements looks great, thanks! Out of curiosity: I am using the EventRecorderMorph class, are there any impact? Hilaire 2009/4/17 Michael Rueger <m.rueger@acm.org>
Hi all,
there is a updated version of the input sensor/event rewrite in the Pharo inbox:
-load the config map Event-rewrite1.mcm (it's in the Event category in the repository) -load the slice EventRewrite2-michael_rueger.2 - in a workspace execute InputEventSensor installPollingEventSensorFramework
voila... Sensor should now be an InputEventSensor.
At a later point we can the remove the EventSensor and InputSensor classes.
Michael P.S. Could someone please remove Collections-Sequenceable-michael_rueger.15 from the inbox? It's a bogus version
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Damien Cassou -
Hilaire Fernandes -
John M McIntosh -
Michael Rueger -
Nicolas Cellier -
Stéphane Ducasse