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

Re: [Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock

by Damien Cassou

On Wed, Jun 17, 2009 at 2:32 PM, Marcus Denker<denker(a)acm.org> wrote: > I wonder if OB would not be much faster if the auto-category feature > would > be turned off? are you talking about the dynamic protocols (long methods, override...)? They are much faster than before. You can disable them to see if they are a source of slowdowns by going to the preference browser, 'dynamic protocols' category. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Nicolas Cellier

2009/6/17 Adrian Lienhard <adi(a)netstyle.ch> > > On Jun 17, 2009, at 13:37 , StÃ©phane Ducasse wrote: > > > I would really like that we do not lose it. > > May be lukas we should tagged them > > We should check the SunitExtension of keith to see if he has something > > to support > > supposed to fail tests. > > We have this already: #expectedFailures. > > Adrian Stephane was maybe thinking of an Annotation rewrite... > > > > > > On Jun 17, 2009, at 12:19 PM, Lukas Renggli wrote: > > > >>> The point remains:some well known failing tests that won't be > >>> solved should > >>> go in known failures. > >> > >> Yes, agreed. I thought a fix would soon be available, but that > >> doesn't > >> seem the case. > >> > >> Anyway, most Smalltalk choke on these tests. > >> > >> 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 > > > > > > _______________________________________________ > > 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 >

June 17, 2009

[Pharo-project] MIT ScaledDecimal (Issue 816) has not been integrated correctly

by Nicolas Cellier

in update10307 (script385) related to http://code.google.com/p/pharo/issues/detail?id=816 : ScaledDecimal2-Part1-nice.1.cs had a postscript to mutate old instances to new instances and not losse existing ScaledDecimals (at least the literals in ScaledDecimalTests). This has not been applied, so some ScaledDecimal now have a nil numerator and denominator. This makes some tests fail. Cure: detect and recompile these methods having a broken ScaledDecimal literal. I don't have time to give a code snippet by now... Nicolas

June 17, 2009

[Pharo-project] Thing which can help developing brand-new GUI framework

by Igor Stasenko

I just thought, that it would be nice having a morph (named WarpGate) which will act as an event sink for any events targeted to it. Then it can translate morphic events to any kind of event, which new framework expecting and dispatch them directly to it. A SystemWindow client area will act as a display surface for framework. -- Best regards, Igor Stasenko AKA sig.

June 17, 2009

Re: [Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock

by Marcus Denker

On 17.06.2009, at 04:39, Adrian Lienhard wrote: > Hi Nicolas, > > On Jun 16, 2009, at 22:10 , Nicolas Cellier wrote: > > [...] > >> <rant> >> Monticello is quite a drag, and pharo feels globally unresponsive >> (even the core image). > > Yep, responsiveness can be improved. The core feels quite fast for me > (on a MacBook Pro), but still, for example opening a browser is not > instantaneous. Also, if you type really fast, the characters start > appearing late (I think Bill complained about that recently). > > OB is another story. For me, its at the border of being usable because > of its slowness. I wonder if OB would not be much faster if the auto-category feature would be turned off? Marcus

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Adrian Lienhard

On Jun 17, 2009, at 13:37 , StÃ©phane Ducasse wrote: > I would really like that we do not lose it. > May be lukas we should tagged them > We should check the SunitExtension of keith to see if he has something > to support > supposed to fail tests. We have this already: #expectedFailures. Adrian > > On Jun 17, 2009, at 12:19 PM, Lukas Renggli wrote: > >>> The point remains:some well known failing tests that won't be >>> solved should >>> go in known failures. >> >> Yes, agreed. I thought a fix would soon be available, but that >> doesn't >> seem the case. >> >> Anyway, most Smalltalk choke on these tests. >> >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 17, 2009

Re: [Pharo-project] BlockContextTest

by Gabriel Cotelli

Tonight I prepare the list and post it... On Wed, Jun 17, 2009 at 4:28 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Gabriel > > Could you post a list of these methods? Probably it makes sense to > copy some of them over to BlockClosure to preserve compatibility for > external clients (we had this before, e.g., #argumentCount, IIRC which > is used by GLORP or Seaside). > > Else these tests can be removed. > > Adrian > > On Jun 17, 2009, at 02:28 , Gabriel Cotelli wrote: > > > Hi, > > > > I'm looking the failing tests... some tests defined in > > BlockContextTest > > relies on behavior not implemented in BlockClosure (but implemented > > in the > > old BlockContext)... > > > > If the only senders of this methods are in this test cases can I > > remove > > them? > > > > If I don't miss anything BlockContext should not be used anymore... > > > > Waiting for your comments... > > Gabriel > > _______________________________________________ > > 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 >

June 17, 2009

Re: [Pharo-project] testWhileModificationBeforeNotInlined

by Gabriel Cotelli

Sorry... I didn't notice the [] after the add: ... (so tired tonight :( ) in that case this test is Ok.. but the inlined version is failing.... 2009/6/17 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Ah, yes, I don't understand neither. > For me, the non inlined version seems to work already and gives #(5 5 5 5 > 5). > The inlined version fails and gives #(1 2 3 4 5), except if you fool the > Compiler with the trick I have indicated: > > testWhileModificationBefore > | index | > index := 0. > [ index < 5 ] whileTrue: [ > index := index + 1. > collection add: [1>2 ifTrue: [index:=0]. index ] ]. > self assertValues: #(5 5 5 5 5) > > The point remains:some well known failing tests that won't be solved should > go in known failures. > +1 for the inlined version of the test... (unless we want to fix it in the short term).... > > Nicolas > > > 2009/6/17 Lukas Renggli <renggli(a)gmail.com> > > > I suggest this test be moved in known failures. >> > Lukas ? >> >> I don't get it ;-) >> >> This looks fine to me. >> >> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 17, 2009

Re: [Pharo-project] [Fix] Issue890 Mantis6535 SortedCollection loose sortBlock

by StÃ©phane Ducasse

do we have an idea of the source of slow down? > > Pharo core 10432 SystemBrowser: 686.6ms > Pharo0.1-10342dev09.06.3 SystemBrowser: 940.8ms

June 17, 2009

[Pharo-project] Fwd: [squeak-dev] [FIX] MessageNotUnderstood: UndefinedObject>>something

by Damien Cassou

Seen on squeak-dev and submitted to the Pharo tracker: http://code.google.com/p/pharo/issues/detail?id=898 ---------- Forwarded message ---------- From: Bert Freudenberg <bert(a)freudenbergs.de> Date: Wed, Jun 17, 2009 at 1:55 PM Subject: [squeak-dev] [FIX] MessageNotUnderstood: UndefinedObject>>something To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Hi folks, we have all seen numerous questions from newbies like this: On 17.06.2009, at 13:25, Bert Freudenberg wrote: > > On 17.06.2009, at 12:56, Tim Patti wrote: >> >> I'm getting a debug window with MessageNotUnderstood: UndefinedObject>>binary. > > Which tells you that "fileHandle" is nil. IMHO it would help if we special-cased the MNU text for a nil receiver. In that case, I propose the message should read Â Â Â Â MessageNotUnderstood: receiver of "something" is nil which might point beginners to the actual cause. Attaching proposed fix. - Bert - -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 17, 2009