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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]> wrote:


--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ok I will


> Michael
> P.S. Could someone please remove
> Collections-Sequenceable-michael_rueger.15
> from the inbox? It's a bogus version

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

These improvements looks great, thanks!

Out of curiosity: I am using the EventRecorderMorph class, are there any impact?

Hilaire






--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/4/17 Michael Rueger <[hidden email]>:

> 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?

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier wrote:
> 2009/4/17 Michael Rueger <[hidden email]>:
>
>> 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.html

Unless it actually was fixed in the meantime which I'm not aware of.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

hi mike

did you check why the menus are getting really slow?

Stef
On Apr 20, 2009, at 11:15 AM, Michael Rueger wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project