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

[Pharo-project] Fwd: MethodDictionary potential cleanups

by StÃ©phane Ducasse

> > > > On Fri, 17 Jul 2009 22:13:33 +0200, Ralph Boland wrote: > > > MethodDictionary has a method "growNoBecome". > > It is invoked by "MethodDictionary>>fullCheckNoBecome". > > It is invoked by "MethodDictionary>>at:putNoBecome:". > > It is invoked by ????? (that is nobody). > > > > Can anybody explain this or should I generate a bug report? > > Hi Ralph, > > when I saw this the first time, it seemed that the methods without > *become* in their name, would do a #become: but they did not. > > Even if somebody tried with aMethod #become:, sooner or later > the .image > would crash: #becom:ing methods that can be in use by the VM is > always a > very bad idea. So it rather looks like the methods you listed are 100% > pure[tm] rot or crap. > > > I have no idea if any of the Squeak forks exhibit the same behavior. > > I suggest to remove them or, if you feel inclined, to deprecate them. > > /Klaus > > > I am running Squeak 3.10.2. > > > > Ralph Boland > > > > > > > >

July 18, 2009

[Pharo-project] fork cleaning in CUIS

by StÃ©phane Ducasse

2009/7/17 Andreas Raab <andreas.raab <at> gmx.de>: > Juan Vuletich wrote: >> >> Some might remember >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/124960… >> . It was a discussion about the dangers of using the result of #fork and >> friends, and the convenience of first creating the process, storing it >> somewhere and later doing #resume. In this release of Cuis, all callers of >> #fork and friends that needed the return value were changed for that >> pattern, and now #fork and friends simply return nil. This is the way to >> avoid those nasty bugs. > > I really like that solution. It's simple and ensures people know what > they're doing. > +1 Good to know that someone put that discussion fruits into a practical plane, even if in own fork :) > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig.

July 18, 2009

Re: [Pharo-project] LocaleTest >> #testIsFontAvailable failing

by Adrian Lienhard

Thanks. I think this simplest thing to do is to change the isFontAvailable as follows: isFontAvailable | encoding f | encoding := self leadingChar + 1. f := TextStyle defaultFont. f isFontSet ifTrue: [ f fontArray at: encoding ifAbsent: [^ false]. ^ true ]. ^ encoding = 1 I.e., to not check with a fallback font as this concept does not seem implemented for all fonts. Adrian On Jul 18, 2009, at 11:29 , Philippe Marschall wrote: > Hi > > LocaleTest >> #testIsFontAvailable is raising an exception in my > image. The problem is that LanguageEnvironment >> #isFontAvailable > sends #fallbackFont to a LocigalFont which does not understand this > message. The #realFont of the logical font is a FreeTypeFont which > doesn't understand #fallbackFont as well. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

[Pharo-project] LocaleTest >> #testIsFontAvailable failing

by Philippe Marschall

Hi LocaleTest >> #testIsFontAvailable is raising an exception in my image. The problem is that LanguageEnvironment >> #isFontAvailable sends #fallbackFont to a LocigalFont which does not understand this message. The #realFont of the logical font is a FreeTypeFont which doesn't understand #fallbackFont as well. Cheers Philippe

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by StÃ©phane Ducasse

OK then we should ask david if - he addressed the check removal - found the problems with the menus? david? Stef On Jul 18, 2009, at 11:00 AM, Lukas Renggli wrote: >> can you disable the annotation pane too? > > Yeah, the annotation pane is extremely slow. I never use it myself. > >> Could you also load the packageBrowser so that we can pick the other >> one too? > > I don't think that would work with the code that is used in the image > Damien created. The OB code in this image does not contain the slow > extra checks that were hacked into the core code to make the package > browser functioning. Furthermore the normal browser is not really > useable if the package browser is loaded, because menu items are > missing and strangely positioned to the point it is not useable > anymore. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by Lukas Renggli

> can you disable the annotation pane too? Yeah, the annotation pane is extremely slow. I never use it myself. > Could you also load the packageBrowser so that we can pick the other > one too? I don't think that would work with the code that is used in the image Damien created. The OB code in this image does not contain the slow extra checks that were hacked into the core code to make the package browser functioning. Furthermore the normal browser is not really useable if the package browser is loaded, because menu items are missing and strangely positioned to the point it is not useable anymore. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by StÃ©phane Ducasse

On Jul 18, 2009, at 10:40 AM, Adrian Lienhard wrote: > > On Jul 18, 2009, at 10:28 , StÃ©phane Ducasse wrote: > >> can you disable the annotation pane too? > > +1 > >> Could you also load the packageBrowser so that we can pick the other >> one too? >> May be put also the highPerformance on > > This preference should be removed. It does not increase performance, > rather to the contrary it may make the image slower as it increases > the number of screen update cycles. Arghhhh trapped again I spotted some other obsolete preferences. > > Adrian > >> I would also remove the optional buttons because they just take >> space. >> (You see I can also be dogmatic). >> >> I imgaine that the roundcorner could be disable too to gain some >> cycles too. >> Stef >> >> On Jul 18, 2009, at 8:55 AM, Damien Cassou wrote: >> >>> I've just uploaded a new Pharo image. It is much faster now, but you >>> won't get the package browsing (only the category browsing). >>> >>> http://pharo-project.org/pharo-download >>> >>> For all the people who found Pharo slow, please tell me what you >>> think >>> of this one ! >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by Lukas Renggli

> but lukas what are you saying? > We removed them so what is the problem? Yes, that's excellent. The original compiler complained and warned in a lot of places, unnecessarily restricting and baby-sit people. IMHO, the current implementation in Pharo is much better. I really like how it works now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by Adrian Lienhard

On Jul 18, 2009, at 10:28 , StÃ©phane Ducasse wrote: > can you disable the annotation pane too? +1 > Could you also load the packageBrowser so that we can pick the other > one too? > May be put also the highPerformance on This preference should be removed. It does not increase performance, rather to the contrary it may make the image slower as it increases the number of screen update cycles. Adrian > I would also remove the optional buttons because they just take space. > (You see I can also be dogmatic). > > I imgaine that the roundcorner could be disable too to gain some > cycles too. > Stef > > On Jul 18, 2009, at 8:55 AM, Damien Cassou wrote: > >> I've just uploaded a new Pharo image. It is much faster now, but you >> won't get the package browsing (only the category browsing). >> >> http://pharo-project.org/pharo-download >> >> For all the people who found Pharo slow, please tell me what you >> think >> of this one ! >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by StÃ©phane Ducasse

I like the way that squeak raises a warning because this is an educational approach the system tells you that you are doing a mistake. Now people complained and we removed the warning and check in pharo and this is ok too. Stef On Jul 18, 2009, at 2:15 AM, Cameron Sanders wrote: > In Pharo, I originally create created the class with this: > > Object subclass: #FaFnBasicKeyLabelAssociations > instanceVariableNames: '' > classVariableNames: 'theSingleton' > poolDictionaries: '' > category: 'FA-FinanceMeta' > > And it compiled without complaint in Pharo. > > It was Squeak that complained during a load using Monticello. And > just now, I reverted back to the lower case version (as exampled up > above) and throws an "Error: theSingleton class variable name should > be capitalized; proceed to include it anyway" ... and it lets me > proceed. (I didn't read the full message previously and changed it.) > So Squeak allows it, but complains where Pharo didn't. > > Sounds like it was "by design" in both cases. > > (I have three spinoff questions which I will put forth with a > different subject line.) > > Thanks, > Cam > > > On Jul 17, 2009, at 6:04 PM, StÃ©phane Ducasse wrote: > >> this is strange can you show us the class definition. >> >> We removed the hard check that >> enforced that classVariable should be capitalized and instvar >> starting >> with a lower case. >> >> Lukas wrote some smallLint rules to check that >> >> Stef >> >> On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: >> >>> I just loaded the code I have been developing in Pharo into Squeak >>> (closure VM, using 4.10.2-7179web09.07 image base) and it had one >>> complaint while loading: >>> >>> Squeak (seemingly) requires an initial cap on class variable names. >>> [Maybe it allows it... but it popped up the debugger on an MC load.] >>> >>> Does Pharo allow the symbol to start with lower case by design, or >>> was >>> that act of omission? I am merely raising point to make certain it >>> is >>> an act of commission. >>> >>> -Cam >>> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009