April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Input sensor rewrite

by Michael Rueger

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

April 20, 2009

Re: [Pharo-project] Delays Semaphores and Processes

by StÃ©phane Ducasse

Hi nicolas I tried and it loads :) > Delay startTimerEventLoop. > (ScriptLoader new buildConfigurationMapFor: > #('Kernel-nice.renggli.301.mcz' > 'KernelTests-nice.96.mcz' > 'System-Support-nice.11.mcz')) load. Now I will wait a bit to know what we do with the event rewrite because may be this is too premature and I would like to avoid to have to undo too much work. Stef On Apr 19, 2009, at 9:54 PM, Nicolas Cellier wrote: > My 16 KernelTests-Processes are green :) > > Forget all the SLICE-DelayFixFromMantis7321 stuff, it only add pain > and complexity... > I checked that entire changes related to mantis 7321 list can be > loaded with following instructions: > > Delay startTimerEventLoop. > (ScriptLoader new buildConfigurationMapFor: > #('Kernel-nice.renggli.301.mcz' > 'KernelTests-nice.96.mcz' > 'System-Support-nice.11.mcz')) load. > > If ever a problem occur, try again in several steps: > > (ScriptLoader new buildConfigurationMapFor: > #('Kernel-nice.renggli.299.mcz' > 'KernelTests-nice.95.mcz' > 'System-Support-nice.11.mcz')) load. > > Delay startTimerEventLoop. > (ScriptLoader new buildConfigurationMapFor: > #('Kernel-nice.renggli.301.mcz' > 'KernelTests-nice.96.mcz')) load. > > Or even in smaller grain... > > Cheers > > Nicolas > > 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> OK, I checked that mantis 6576 is superseded by 7321. >> >> To install DelayCleanup.1.cs it is necessary to write a ScriptLoader >> script like: >> script363 >> Delay startTimerEventLoop. >> (self buildConfigurationMapFor: >> #('Kernel-nice.renggli.300.mcz')) load >> >> Now, last thing to fix is remove SmallInteger maxVal//2 protection >> and test. >> >> 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> Andreas answered that the SmallInteger limit is obsolete since >>> http://bugs.squeak.org/view.php?id=6576 which was included in 3.10 >>> >>> So I will check that mantis 6576+7321, and change the >>> DelayTests>>#testBounds >>> >>> Then only the PREAMBLE problem will remain. >>> But I see this preamble can simply go in a ScriptLoader script. >>> >>> 2009/4/19 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> I took a look at http://bugs.squeak.org/view.php?id=7321 and >>>> http://code.google.com/p/pharo/issues/detail?id=688 >>>> >>>> I started publishing PharoInbox/SLICE-DelayFixFromMantis7321- >>>> nice to >>>> integrate Andreas' changes. >>>> >>>> Now I did integrate all but DelayCleanup.1.cs >>>> This change set does cure the failing testSemaphore in Pharo, but >>>> has >>>> two problems: >>>> 1) It requires a preamble, and I don't know how they are handled >>>> in Monticello >>>> 2) It probably does not include change about LargeInteger delays >>>> included in 3.9 >>>> (Dave kindly pointed me to http://bugs.squeak.org/view.php?id=854) >>>> 3) it makes DelayTests>>#testBounds fail >>>> >>>> >>>> I think that the limit of (SmallInteger maxVal//2) is not >>>> necessary... >>>> if LargeInteger delay fix is in the image. >>>> I can try to fix 2) mixing Andreas and Tim fixes. >>>> What about 1) ? >>>> >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Some bugs with the last version of pharo (10281) and pharo-dev (10284)

by StÃ©phane Ducasse

this is strange because I only get that with 10284 but not 10282/2 Stef On Apr 20, 2009, at 9:39 AM, Laval Jannik wrote: > Hi all, > > I would like to use the new version of pharo but I have some bugs: > > Pharo-dev: > - When I open for the first time the latest version of pharo-dev, it > is impossible to use the copy-paste command > > Pharo and pharo-dev: > - it is impossible to open a Monticello browser because of an error > "invalid utf8 input detected" > - in the workspace of pharo-dev, there is the same error when I would > like to run this line in a workspace: > Installer monticello http: 'http://www.squeaksource.com'; project: > 'Moose'; install: 'MooseLoader'. > > I use the last VM (4beta1). > > Thanks for your help. > > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by Michael Rueger

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

April 20, 2009

Re: [Pharo-project] Some visual artifacts in buttons (Watery 2theme)

by Gary Chambers

Added comment to #755 Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, April 19, 2009 4:33 PM Subject: Re: [Pharo-project] Some visual artifacts in buttons (Watery 2theme) > for UI glitch also put gazzaguru in the cc box. :) > > stef > > On Apr 19, 2009, at 3:39 PM, Igor Stasenko wrote: > >> 2009/4/19 Damien Cassou <damien.cassou(a)gmail.com>: >>> Please report an issue on the issue tracker. >>> >> #755 >> >>> 2009/4/19 Igor Stasenko <siguctua(a)gmail.com>: >>>> Hello, >>>> just in case if you not already seen it.. >>>> These artifacts (a button labels blended with background) is appear >>>> only, when you draggin a morph in hand. >>>> If you just place morph over background - no visible artifacts >>>> appear. >>>> >>>> On screenshot, the button label is blended with Pharo logo, placed >>>> on >>>> background. It seems like somewhere, it not sets an opacity values >>>> correctly for button labels, which allows you to see through the >>>> cached form (which used when you dragging morph in hand). >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by StÃ©phane Ducasse

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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by Michael Rueger

Nicolas Cellier wrote: > 2009/4/17 Michael Rueger <m.rueger(a)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

April 20, 2009

Re: [Pharo-project] Input sensor rewrite

by Nicolas Cellier

2009/4/17 Michael Rueger <m.rueger(a)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?

April 20, 2009