- Pharo-dev - lists.pharo.org

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

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

by Damien Cassou

On Wed, Jun 17, 2009 at 1:36 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > did you disable dynamic protocols? if dynamic protocols were the problem, they were only responsible of the 15% difference between the SystemBrowser and OB-one. The huge difference is between the Core and Pharo which means dynamic protocols are not responsible. -- 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] idea to have a better methodFinder :)

by Esteban Lorenzano

In short, Algernon is like spotligth for squeak :) I use it a LOT. So, I will port it to pharo as soon as I can find a little time. Said so, I need to advice: algernon and method finder are very diferent tools (I use both) Cheers, Esteban On 2009-06-17 07:15:17 -0300, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> said: > a quicksilver for Squeak > >>>> I don't know what Pragma is, but Algernon seems VERY good from my >>> point of view. I used it a lot in Squeak and now I really miss it on >>> Pharo. Algernon authors won't port it to Pharo (I asked them). > > :) > Wonderful. > >>> Perhaps when Pharo 1.0 is released I can spend some time to make it >>> work. >>> >> What is Algernon? >> >> Marcus >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> 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 StÃ©phane Ducasse

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

June 17, 2009

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

by StÃ©phane Ducasse

did you disable dynamic protocols? On Jun 17, 2009, at 12:17 PM, Adrian Lienhard wrote: > Thanks, I like benchmarks! I've run this in the recent Pharo-core and > Pharo images (on the class String): > > Pharo core 10432 SystemBrowser: 686.6ms > Pharo0.1-10342dev09.06.3 SystemBrowser: 940.8ms > Pharo0.1-10342dev09.06.3 OBSystemBrowser: 1087.1ms > > Similar to Lukas' results is that the OBSystemBrowser is not that much > slower than the normal SystemBrowser (slowdown of 15%). However, there > is a larger difference between the SystemBrowser in Pharo and in > Pharo- > core (37%). Hence other features seem to contribute to the slowdown: > freetype fonts, code highlighting, ...? > > Adrian > > On Jun 17, 2009, at 11:18 , Lukas Renggli wrote: > >>> OB is another story. For me, its at the border of being usable >>> because >>> of its slowness. >> >> Just for the record: OB included with the Seaside One-Click image is >> only marginally slower than the standard system browser. >> >> Opening and closing OB system browser on the class WACounter: >> 636.15 ms >> Opening and closing SystemBrowser on the class WACounter: 555.00 ms >> >> Lukas >> >> -=--=--=--=--=--=--=--=--=--=--=--=--=--=- >> >> " Omni Browser " >> [ browsers := (1 to: 20) >> collect: [ :each | OBSystemBrowser onClass: WACounter ]. >> browsers do: [ :each | >> each open. >> World doOneCycle ]. >> browsers do: [ :each | >> each close. >> World doOneCycle ] ] >> timeToRun / 20.0 >> >> " System Browser " >> [ browsers := (1 to: 20) >> collect: [ :each | Browser new setClass: WACounter selector: nil ]. >> browsers do: [ :each | >> Browser openBrowserView: (each openEditString: nil) label: 'System >> Browser'. >> World doOneCycle ]. >> browsers do: [ :each | >> each changed: #close. >> World doOneCycle ] ] >> timeToRun / 20.0 >> >> -=--=--=--=--=--=--=--=--=--=--=--=--=--=- >> >> -- >> 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] Automatic/periodic image saves

by John Thornborrow

Hi Lukas, Lukas Renggli wrote: > Hi John > > >> We've deployed a Pharo+Pier/Seaside image for our website, and >> (naturally) changes are made to the site via Pier. >> > > Wow, that's a cool site! Might I link it from the list on piercms.com? > > Yes, please do :) >> I'd like to know if there is a preferred method of saving the image to >> disk every, say, 12 hours? >> > > There is an image persistency strategy built into Pier. It saves the > image every hour by default, but only if something changed. Check the > FAQ on how to enable it: http://www.piercms.com/doc/faq#90421388. > > Cheers, > Lukas > > Great, thanks! Regards, John. Consider your responsibility to the environment - think before you print! ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

June 17, 2009

Re: [Pharo-project] Automatic/periodic image saves

by Lukas Renggli

Hi John > We've deployed a Pharo+Pier/Seaside image for our website, and > (naturally) changes are made to the site via Pier. Wow, that's a cool site! Might I link it from the list on piercms.com? > I'd like to know if there is a preferred method of saving the image to > disk every, say, 12 hours? There is an image persistency strategy built into Pier. It saves the image every hour by default, but only if something changed. Check the FAQ on how to enable it: http://www.piercms.com/doc/faq#90421388. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 17, 2009