I see, InputEventFetcher default class -> InputEventPollingFetcher and InputEventPollingFetcher>>#eventLoop "Fetch pending raw events from the VM. This method is run at high priority." | delay | delay := Delay forMilliseconds: 100. 100ms is very high! Pharo VM requires blockClosure, which make them recent. I think all these VM have primitive 93 for asynchronously signaling the availability of events. No ? 2009/4/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Yes may be the event cleaning of mike cleaned too much. So I hope that mike will provide a fix soon :)

Stef On Apr 19, 2009, at 5:01 PM, Nicolas Cellier wrote:

...

Since latest 10284 Pharo update, i experience lost of keystroke vanishing.

_______________________________________________ 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

Has anyone looked at how much CPU this sucks down, I'd hope the *new* logic uses less CPU when Squeak is doing nothing, than the current one which is polling every 1/50 of a second On 19-Apr-09, at 5:14 PM, Igor Stasenko wrote:

There is a mistake in update. This method is redundant. The problem is solved by simply removing that method. A method in base class (InputEventFetcher ) works with default 10 ms delays. I have posted this on issue tracker.

-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

2009/4/20 Igor Stasenko <siguctua@gmail.com>:

2009/4/20 John M McIntosh <johnmci@smalltalkconsulting.com>:

...

Has anyone looked at how much CPU this sucks down, I'd hope the *new* logic uses less CPU when Squeak is doing nothing, than the current one which is polling every 1/50 of a second

I don't think this process eating much CPU. By my observations the most CPU hungry process (even if squeak idle) is Morphic world, which awakes each 20ms.

To be more concrete, the source of problems is a big delay (100ms) in event polling sensor. Since morphic world cycle is 20ms, its better to have same , or even smaller delay in event polling process. Otherwise, a 4 of 5 morphic world cycles receives no new events. But this not excusing the event eating behavior.. IMO something in morphic event handling is done wrong which flushing even queue or ignoring input (by considering it obsolete).

...

On 19-Apr-09, at 5:14 PM, Igor Stasenko wrote:

...

There is a mistake in update. This method is redundant. The problem is solved by simply removing that method. A method in base class (InputEventFetcher ) works with default 10 ms delays. I have posted this on issue tracker.

-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com = = = ========================================================================

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.

Nicolas Cellier wrote:

Why not using the event driven superclass rather than the polling subclass ?

because afaik not all VMs (Windows) support it. See my other mail. Michael

2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Would a platform specific code or infrastructure help there?

There should be some kind of detection algorythm , which can switch between polling and waiting on input semaphore. My proposal is to change the primitive (primInterruptSemaphore: aSemaphore ) to return boolean value, showing that input semaphore signaling is available. Then the code can use polling or waiting depending on returned result (the primitive in older VM's don't return informal value - it just returns a receiver). Andreas disagree with this approach, saying that same could be achieved w/o changes in VM by checking if input semaphore ever signaled, and if so, then switch from polling (which should be installed by default) to waiting. Both ways is doable, and should work well, it just shows our different approach.

...

Nicolas Cellier wrote:

...

Why not using the event driven superclass rather than the polling subclass ?

because afaik not all VMs (Windows) support it. See my other mail.

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

-- Best regards, Igor Stasenko AKA sig.

2009/4/20 Michael Rueger <m.rueger@acm.org>:

On Mon, Apr 20, 2009 at 5:58 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

Would a platform specific code or infrastructure help there?

There should be some kind of detection algorythm , which can switch between polling and waiting on input semaphore. My proposal is to change the primitive (primInterruptSemaphore: aSemaphore ) to return boolean value, showing that input semaphore signaling is available.

I disagree, changing the VM and still not fixing it is not really an option. If I understood Andreas correctly the signalling is not hard to implement and then we could abandon polling altogether.

Well, its all about backward compatibility. Sure, if Pharo ships with only newest VM, then there no need in having these workarounds.

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

2009/4/20 Igor Stasenko <siguctua@gmail.com>:

2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

Would a platform specific code or infrastructure help there?

There should be some kind of detection algorythm , which can switch between polling and waiting on input semaphore. My proposal is to change the primitive (primInterruptSemaphore: aSemaphore ) to return boolean value, showing that input semaphore signaling is available. Then the code can use polling or waiting depending on returned result (the primitive in older VM's don't return informal value - it just returns a receiver). Andreas disagree with this approach, saying that same could be achieved w/o changes in VM by checking if input semaphore ever signaled, and if so, then switch from polling (which should be installed by default) to waiting. Both ways is doable, and should work well, it just shows our different approach.

Andreas is right on this point, though your proposition makes thing simpler. But if he didn't introduce support for event-driven loop in windows VM, he is wrong: feeding a polling loop with an event-loop is easy, the reverse is not. I bet he spent more time arguing in the thread, than necessary for introducing requested change in the VM :) ... unless... I tried this in windows: (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]') InputEventFetcher deinstall; install. InputEventFetcher default. -> an InputEventFetcher It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the inputSemaphore? Nicolas

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>

...

... unless... I tried this in windows: (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]')

InputEventFetcher deinstall; install. InputEventFetcher default. -> an InputEventFetcher

It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the inputSemaphore?

Err, I did not installEventSensorFramework

InputEventFetcher deinstall. InputEventSensor installEventSensorFramework.

... and the image become unresponsive

i had some problems with reinstalling event fetcher too. Let's wait for Mike, to show us the proper doits for reinstalling event fetching process.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

2009/4/20 Igor Stasenko <siguctua@gmail.com>:

Another thing, that i think it would be better is to not have an instance side methods. Since we never need a multiple instances of InputEventFetcher in system, then instead of singleton scheme, it would be better to move all methods and ivars to class side - simply because a class is already singleton. This will help to avoid discrepancies, like we just met.

Thinking a bit more about it.. It could stay separated (instance/class side). But there are two things is missing IMO: - reinstalling a new event fetcher should preserve the list of handlers - an access to collection of eventHandlers should be guarded by semaphore, because there could be a concurrency issues when one process handling an event, while another one trying to install new event handler to same collection. maybe more appropriate would be to remove startup/shutdown methods from event fetcher, and merge things in InputEventSensor, to make sure everything is ok , and sensor always speaking with currently installed event fetcher.

2009/4/20 Igor Stasenko <siguctua@gmail.com>:

...

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

...

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>

...

... unless... I tried this in windows: (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]')

InputEventFetcher deinstall; install. InputEventFetcher default. -> an InputEventFetcher

It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the inputSemaphore?

Err, I did not installEventSensorFramework

InputEventFetcher deinstall. InputEventSensor installEventSensorFramework.

... and the image become unresponsive

i had some problems with reinstalling event fetcher too. Let's wait for Mike, to show us the proper doits for reinstalling event fetching process.

...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.

Igor Stasenko wrote:

Another thing, that i think it would be better is to not have an instance side methods. Since we never need a multiple instances of InputEventFetcher in system, then instead of singleton scheme, it would be better to move all methods and ivars to class side - simply because a class is already singleton. This will help to avoid discrepancies, like we just met.

-10000 Using singleton instances is a proven design pattern. And, you never know if you won't need more than one input fetcher ;-) Michael

sorry to be pedantic but Michael's right. even if the second client of the class is a test where you make an instance on the fly, assert a few things and clean it up. You then have at least 2 instances. the singleton and short-lived adhoc ones. systems with dependencies on global state or behaviour are very hard to test. cheers, Mike On Mon, Apr 20, 2009 at 6:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:

2009/4/20 Michael Rueger <m.rueger@acm.org>:

...

Igor Stasenko wrote:

...

Another thing, that i think it would be better is to not have an instance side methods. Since we never need a multiple instances of InputEventFetcher in system, then instead of singleton scheme, it would be better to move all methods and ivars to class side - simply because a class is already singleton. This will help to avoid discrepancies, like we just met.

-10000

Using singleton instances is a proven design pattern. And, you never know if you won't need more than one input fetcher ;-)

Clearly, this is not the case, because your code hosted on a single VM ;) and its the only source of events for fetcher.

...

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/4/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

2009/4/20 Igor Stasenko <siguctua@gmail.com>:

...

2009/4/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

Would a platform specific code or infrastructure help there?

There should be some kind of detection algorythm , which can switch between polling and waiting on input semaphore. My proposal is to change the primitive (primInterruptSemaphore: aSemaphore ) to return boolean value, showing that input semaphore signaling is available. Then the code can use polling or waiting depending on returned result (the primitive in older VM's don't return informal value - it just returns a receiver). Andreas disagree with this approach, saying that same could be achieved w/o changes in VM by checking if input semaphore ever signaled, and if so, then switch from polling (which should be installed by default) to waiting. Both ways is doable, and should work well, it just shows our different approach.

Andreas is right on this point, though your proposition makes thing simpler. But if he didn't introduce support for event-driven loop in windows VM, he is wrong: feeding a polling loop with an event-loop is easy, the reverse is not. I bet he spent more time arguing in the thread, than necessary for introducing requested change in the VM :) ... unless... I tried this in windows: (SmalltalkImage current vmVersion. -> 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]')

InputEventFetcher deinstall; install. InputEventFetcher default. -> an InputEventFetcher

It seems to work like a charm, doesn't that mean that VM IS SIGNALLING the inputSemaphore?

yeah, except that, if you inspect the Sensor, its eventFetcher ivar still points to instance of InputEventPollingFetcher. It works, but not like charm.. keyboard input is still a more sluggish that with 10ms polling. :( Which makes me wonder why its so.

Nicolas

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

On Mon, Apr 20, 2009 at 10:28 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

Igor this is important for importnt bug to post in the list so that I can add them to the list of urgent stuff to integrate

Sorry, my mistake: http://code.google.com/p/pharo/issues/detail?id=757 -- Damien Cassou http://damiencassou.seasidehosting.st