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

Re: [Pharo-project] Tests

by Michael Roberts

It's possible that the baseline mechanism isn't accurate. I'll check that. Someone could also verify the baselines. That would help. Cheers, Mike On Sunday, July 5, 2009, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Running the tests in the latest core (10371), I get the following > results: > 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors > > Comparing to the last result in 10292cl [1]: > 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors > > > > I wonder how it is possible to get from 3029 to 5154 tests? > > Cheers, > > Adrian > > > > [1] http://code.google.com/p/pharo/wiki/BaselineTestResults > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 5, 2009

[Pharo-project] Tests

by Adrian Lienhard

Running the tests in the latest core (10371), I get the following results: 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors Comparing to the last result in 10292cl [1]: 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors I wonder how it is possible to get from 3029 to 5154 tests? Cheers, Adrian [1] http://code.google.com/p/pharo/wiki/BaselineTestResults ___________________ http://www.adrian-lienhard.ch/

July 5, 2009

Re: [Pharo-project] Pharo Sprint in Berne, Switzerland

by Adrian Lienhard

Hi all, The sprint of yesterday was a success and great fun. Thanks to all participants! For some details and pictures, see http://www.adrian-lienhard.ch/blog?dialog=pharo-sprint-in-bern-july-4-2009 Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/ On Jun 25, 2009, at 22:48 , Adrian Lienhard wrote: > Hi all, > > We are going to do a Pharo sprint in Bern on Saturday, July 4. > > http://code.google.com/p/pharo/wiki/PharoSprints > > Please add yourself to the list if you plan to attend (or send me a > mail so I can add you). > > The main goal is to get closer to a first beta release. If you wish to > work on other stuff, e.g., OmniBrowser, please propose this here so we > can organize a bit in advance. > > Cheers, > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 5, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by John M McIntosh

On 4-Jul-09, at 12:08 PM, Schwab,Wilhelm K wrote: > Adrian, > > I share Stef's enthusiasm for your suggested process. Thanks for > taking my prods about speed in the constructive spirit in which they > are intended. > > One concern though: is the benchmark of opening and closing browsers > able to give a realistic comparison of performance? Time to open a > debugger is probably worth noting, but the things that concern me > most with the browsers are poor response to keyboard input, time > delays selecting a new class or method, and (most notably) time > required to recompile a class; changing the category can take > several seconds in my experience. I should note that in testing with a limited memory VM say 40MB it seemed that every other time I opened a browser window it would toss a memory failure walkback. So I'd suggest althought time is important, has any one looked at how much memory is required to do the process? This allocation seemed temporary btw. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 4, 2009

Re: [Pharo-project] What will be the standard browser in Pharo?

by Schwab,Wilhelm K

Adrian, I share Stef's enthusiasm for your suggested process. Thanks for taking my prods about speed in the constructive spirit in which they are intended. One concern though: is the benchmark of opening and closing browsers able to give a realistic comparison of performance? Time to open a debugger is probably worth noting, but the things that concern me most with the browsers are poor response to keyboard input, time delays selecting a new class or method, and (most notably) time required to recompile a class; changing the category can take several seconds in my experience. Re keyboard input, I suspect characters are being lost; in fairness, that is difficult to test, because it requires typing quickly and accurately. Still, Pharo strikes me as just not being able to keep up, and it's worse with the package browser. You are of course correct to keep free type and Shout on the list of suspects, though I must say that Shout has always struck me as eerily fast. In short, I do not dispute that the difference is speed is small, especially for the open/close that is benchmarked. However, there is simply no "extra speed" to waste. Ideally, benchmarks should compare the different browsers with and without shout and free type, rounded corners, etc., and should separate selecting a new class and method. Some of my trouble might stem from using Linux for much of my work. I cannot describe the extent of my frustration with Windows - I've had it and then some. I'll stop the rant there (yes, I could go on for a while yet<g>). However, I cannot in good conscience join the "Linux is faster than Windows" crowd, and I am willing to consider the possibility that the display handling in the linux vm (no accusations, just in the interest of intellectual honesty) might have room for improvement, and/or the design of X-windows might not help. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, July 03, 2009 4:48 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What will be the standard browser in Pharo? yes yes yes! Stef On Jul 3, 2009, at 10:15 AM, Adrian Lienhard wrote: > Hi Bill, > > Performance is certainly important. Please don't stop bugging us to > make progress at this front too ;) > > What we should start with is to identify which features makes it slow. > > I recently posted basic benchmarks [1], but we need to identify single > features so that we know where to optimize or which features should > better be disabled. > > What would help is if you could tell us what exactly is slow (at the > moment I'm mainly working in the core image without freetype fonts and > speed feels ok on my MacBook Pro). > Cheers, > Adrian > > [1] > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009905. > html > > > On Jul 3, 2009, at 00:29 , Schwab,Wilhelm K wrote: > >> Stef, >> >> Understood, but since you appear to be leaving open things that I >> consider to be drastic (removing traits), it only seems reasonable to >> try the faster browser on some slower machines to see what impact it >> makes. It would not take too much prodding for me to be able to give >> some guidance along the lines of "not enough impact to be of help" or >> "well worth adopting." _Something_ is eating up a lot of clock >> cycles at present. >> >> Bill >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Mariano Martinez Peck >> Sent: Thursday, July 02, 2009 4:25 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] What will be the standard browser in >> Pharo? >> >> "Ideally we would love to have a fast browser with package >> support:..." >> >> Notice the "ideally" and the "would" haha >> >> On Thu, Jul 2, 2009 at 8:22 PM, Schwab,Wilhelm K >> <bschwab(a)anest.ufl.edu <mailto:bschwab@anest.ufl.edu>> wrote: >> Stef, >> >> Is there a way to get the fast browser, or an image with it loaded? >> >> Bill >> >> >> -----Original Message----- >> From: >> pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-boun >> ces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-pro >>> ject-bounces(a)lists.gforge.inria.fr >>> ] On Behalf Of StÃ©phane Ducasse >> Sent: Thursday, July 02, 2009 3:30 PM >> To: >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge >> .inria.fr >>> >> Subject: Re: [Pharo-project] What will be the standard browser in >> Pharo? >> >> Hi oscar >> >> Ideally we would love to have a fast browser with package support: >> - dual browser >> - class extensions >> - traits >> - refactoring >> - icons >> >> Now apparently OBEnhancements was a bit dirty and this is not clear >> what colin will integrate or not. >> Lukas has a OB version which is fast but it does not have >> - dual browser >> - class extensions >> - traits >> - icons >> So david and lukas should talk a bit more and we could get the best >> of the worlds. >> Saturday we should have a discussion. Having a fast but powerful >> browser is important and right now if the browser does not support >> trait then we should remove traits from the image. >> Similarly we cannot work well without class extension support and >> other package related functionality. >> Stef >> >> >> >> On Jul 2, 2009, at 9:07 PM, Oscar Nierstrasz wrote: >> >>> >>> Hi Folks, >>> >>> I am trying to port Squeak by Example to Pharo by Example. I am a >>> bit confused about what is suppose dto be the standard browser now. >>> I thought it was the OB Package Browser, but Damien Cassou just gave >>> me a new image where the browser is an OB System Browser >>> (Categories, not packages). I cannot even see any more how to >>> switch between the two. >>> >>> Can someone enlighten me? (Then I can explain it in the book.) >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforg >>> e.inria.fr >>>> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2009

[Pharo-project] [ANN] new image

by StÃ©phane Ducasse

We released a new image. Stef ------------------------------------------------------ update10354 Replacing _ by := - fix remaining underscore assignements using the refactory rewrite engine. - Issue 604: Fix all the _ with := using Gwenael parser ------------------------------------------------------ update10355 Issue 59: 7109 ChangesOrganizer-pk (M4825) part one ------------------------------------------------------ update10356 Issue 59: 7109 ChangesOrganizer-pk (M4825) part two ------------------------------------------------------ update10357 Issue 59: 7109 ChangesOrganizer-pk (M4825) part three ------------------------------------------------------ update10358 Issue 899: MovingPointersToExcept http://code.google.com/p/pharo/issues/detail?can=2&q=899 - deprecated methods pointersTo:, pointersTo:except:, pointersToItem:of - added test in ToolsTest-PointerFinder - change all send to Utilities to PointerFinders ------------------------------------------------------ update10359 Issue 380: Remove CrLfFileStream and use MultiByteStream ------------------------------------------------------ update10360 Issue 836: Integrate ThreadSafeTranscript (new try) ------------------------------------------------------ update10361 Issue 927: SLICE-FixClassSelectionInTestRunner - fixed test runner class selection bug - move polymorph overrides to SUnitGUI package ------------------------------------------------------ update10362 - Halos are now available on middle click + shift todo: remove the preferences from the preferences class and preference browser ------------------------------------------------------ update10363 - Issue 906: Reorganize Compiler Tests - ScriptLoader eCompletion - Issue 926: Make PluggableListMorph resemble list views in other frameworks more closely - Issue 681 - Mantis6982-Issue681-Number-readFrom ------------------------------------------------------ update10364 Issue 443: Trait users identity set gets into inconsistent state Adrian and I have spent some time on fixing the bug. A fix has been produced. ------------------------------------------------------ update10365 - Step 1 of 3 (change superclass) - Issue 463: SmallDictionary should not be a subclass of Set (and Dictionary) - http://code.google.com/p/pharo/issues/detail?id=463 ------------------------------------------------------ update10366 - Step 2 of 3 (change methods) - Issue 463: SmallDictionary should not be a subclass of Set (and Dictionary) - http://code.google.com/p/pharo/issues/detail?id=463 ------------------------------------------------------ update10367 - Step 3 of 3 (remove methods) - Issue 463: SmallDictionary should not be a subclass of Set (and Dictionary) - http://code.google.com/p/pharo/issues/detail?id=463 ------------------------------------------------------ update10368 - Issue 463: SmallDictionary Tests http://code.google.com/p/pharo/issues/detail?id=463 - This is issue 409, tackling testCloseCauseFlushing in TranscriptTest. - implement BlockClosure >> #methodNode - Issue 931: implement method deprecation of Croquet http://code.google.com/p/pharo/issues/detail?id=931 - Issue 930: Trait fileout was broken because of override of new block closure - Issue 883: tallyIt is now working again Fix Tally it - 443 post load missing execution ------------------------------------------------------ update10369 - Croquet like deprecation missing part :( - Issue 517: nil does not understand sameAs: in StandardFileStream class>>retryWithGC:until:forFileNamed: - unroll introduction of BlockClosure>>methodNode ------------------------------------------------------ update10370 - issue 933: Fix BlockContext/ClosureTests http://code.google.com/p/pharo/issues/detail?id=933 ------------------------------------------------------ update10371 - fixed the save-section in world and host menu

July 4, 2009

[Pharo-project] [ANN] 10371

by StÃ©phane Ducasse

SavesAs menu item cleaning Stef

July 4, 2009

[Pharo-project] Clipboard startUp

by StÃ©phane Ducasse

Hi torsten you posted the following and I wanted to know whether we should not add something in the shutdown list. Stef initialize "SystemDictionary initialize" | oldList | oldList := StartUpList. StartUpList := OrderedCollection new. "These get processed from the top down..." #( Delay DisplayScreen Cursor InputEventFetcher ProcessorScheduler "Starts low space watcher and bkground." LanguageEnvironment FileDirectory "Enables file stack dump and opens sources." NaturalLanguageTranslator ShortIntegerArray ShortRunArray CrLfFileStream Clipboard ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList ifNotNil: [oldList do: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToStartUpList: theClass]]]. #( ImageSegment PasteUpMorph "ControlManager" ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList := ShutDownList. ShutDownList := OrderedCollection new. "These get processed from the bottom up..." #( Delay DisplayScreen InputEventFetcher Form "ControlManager" PasteUpMorph StrikeFont Color FileDirectory SoundPlayer HttpUrl Password PWS MailDB ImageSegment ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToShutDownList: cls]. ]. oldList ifNotNil: [oldList reverseDo: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToShutDownList: theClass]]].

July 4, 2009

[Pharo-project] [ANN] 10369

by StÃ©phane Ducasse

> > > - Croquet like deprecation > > - Issue 517: nil does not understand sameAs: in StandardFileStream > class>>retryWithGC:until:forFileNamed: > > - unroll introduction of BlockClosure>>methodNode > > Stef > > >

July 4, 2009

[Pharo-project] #933

by Adrian Lienhard

Some BlockContextTests fixed here: http://code.google.com/p/pharo/issues/detail?id=933 Philippe and Adrian

July 4, 2009