Lots of characters lost while typing in Unix

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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 <[hidden email]>:
>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

> 2009/4/20 John M McIntosh <[hidden email]>:
>> 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.
>

>> 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 <[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
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> 2009/4/20 Igor Stasenko <[hidden email]>:
>> 2009/4/20 John M McIntosh <[hidden email]>:
>>> 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 <[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
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.
>
> 2009/4/20 Nicolas Cellier <[hidden email]>:
>> 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 <[hidden email]>:
>>> 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
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On Mon, Apr 20, 2009 at 5:58 PM, Igor Stasenko <[hidden email]> wrote:
>> 2009/4/20 Stéphane Ducasse <[hidden email]>:
>>> 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.
>

>
> 2009/4/20 Igor Stasenko <[hidden email]>:
>> 2009/4/20 Stéphane Ducasse <[hidden email]>:
>>> 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?
>

>
>
> 2009/4/20 Nicolas Cellier <[hidden email]>
>>
>> ... 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
>