Lots of characters lost while typing in Unix
Locked
12
12
Re: Lots of characters lost while typing in Unix
 
|
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. 2009/4/20 Igor Stasenko <[hidden email]>: > 2009/4/20 Nicolas Cellier <[hidden email]>: >> >> >> 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 >> > 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 >> [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 |
Re: Lots of characters lost while typing in Unix
|
|
2009/4/20 Igor Stasenko <[hidden email]>:
> 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 <[hidden email]>: >> 2009/4/20 Nicolas Cellier <[hidden email]>: >>> >>> >>> 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 >>> >> 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 >>> [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. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Lots of characters lost while typing in Unix
|
|
In reply to this post by Igor Stasenko
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Lots of characters lost while typing in Unix
|
|
In reply to this post by Igor Stasenko
2009/4/20 Igor Stasenko <[hidden email]>:
> 2009/4/20 Igor Stasenko <[hidden email]>: >> 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 and then a old event fetcher can simply #become: to a new one. sorry for flooding :) > - 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 <[hidden email]>: >>> 2009/4/20 Nicolas Cellier <[hidden email]>: >>>> >>>> >>>> 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 >>>> >>> 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 >>>> [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. >> > > > > -- > 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 |
Re: Lots of characters lost while typing in Unix
|
|
In reply to this post by Michael Rueger-6
2009/4/20 Michael Rueger <[hidden email]>:
> 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 ;-) > ;) and its the only source of events for fetcher. > Michael > > _______________________________________________ > 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 |
Re: Lots of characters lost while typing in Unix
|
|
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 <[hidden email]> wrote: > 2009/4/20 Michael Rueger <[hidden email]>: >> 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 >> [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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Lots of characters lost while typing in Unix
|
|
2009/4/20 Michael Roberts <[hidden email]>:
> 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. > Thanks, for argument! I'm also trying to be pedantic when proposing this. :) My point was, that its obviously an overkill to have a singleton<class> linked with singleton<instance> without strong evidences where multiple instances could be useful. > cheers, > > Mike > > On Mon, Apr 20, 2009 at 6:43 PM, Igor Stasenko <[hidden email]> wrote: >> 2009/4/20 Michael Rueger <[hidden email]>: >>> 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 >>> [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 >> > > _______________________________________________ > 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |