- Pharo-dev - lists.pharo.org

[Pharo-project] SmallLint and Manifest

by Simon Allier

Hi, I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). The new version is - refactoring friendly. Yes we listened to you :). - the browser has been improved. It works with the latest Spec. With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. Gofer new url: 'http://www.squeaksource.com/PharoTaskForces'; package: 'ConfigurationOfManifest'; load. ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load Simon

Sept. 10, 2012

[Pharo-project] RE : RE : Re: RE : RE : NewClassOrganizer

by GOUBIER Thierry

I think overall you're right about the implicit ... let's add a public and a private keyword to Pharo and enforce it :( I like to browse through existing code and see a long list of categories, carefully ordered from extensions all the way down to half a dosen private protocols, and recognize the care in which the author has organized and documented his code for my own, unimportant, benefit. As a aside, one of the aspect I like about RPackage is that it has the ability to accept multiple protocols as extensions, since it is not really tracking protocols, but methods directly. After, I also noticed that MC was able too, which would allow for documenting by using multiple protocols for large extensions sets such as RPackageOrganizer *Rpackage-SystemIntegration. So far, at the GUI level, I'm not making use of that :( Thanks for considering my wishes for the new ClassOrganization. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] Date d'envoi : dimanche 9 septembre 2012 14:08 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : Re: RE : RE : NewClassOrganizer On 2012-09-09, at 13:58, Philippe Back <philippe.back(a)gmail.com> wrote: > Cami, > > A general ordering of standard (so to speak) protocols would be nice indeed. > > But what about pretty local protocols? Like things in PetitParser for > example. Alphabetical would be a nuisance. I'd prefer something like tags on methods to properly denote this information. But true, ordering might help for readability... I am just no big fan of all this implicit stuff, that's why I say this goes into the UI where you properly tell the user what the ordering means (by say bars telling "private" or so...) anyways, with the new class organizer it should be pretty easy to switch between different kinds of representation since we will use real collections and not some half-dict-half-array breed.

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by StÃ©phane Ducasse

Thanks for checking that because we should address it. Stef On Sep 9, 2012, at 1:17 PM, Camillo Bruni wrote: > After Igor's remark about the loading speed of configs in 2.0 > I ran twice the same configuration in 1.4 and 2.0 and things load > incredibly slow under 2.0 > > Subjectively it seems that 2.0 spends ages loading Metacello / Gofer stuff. > > I'll dive a bit into it to see if somethings stands out... > > The two images with the Profiler opened: > http://dl.dropbox.com/u/18184943/LoadConfig1.4.zip > http://dl.dropbox.com/u/18184943/LoadConfig2.0.zip >

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Camillo Bruni

Doesn't really matter which config you use: Gofer it squeaksource: 'NativeBoost'; package: 'ConfigurationOfNativeBoost'; load. ConfigurationOfNativeBoost loadDevelopment On 2012-09-09, at 15:27, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Send me the doIt to install your confs and I will try to try it. > > On Sun, Sep 9, 2012 at 3:25 PM, Mariano Martinez Peck <marianopeck(a)gmail.com >> wrote: > >> >> >> On Sun, Sep 9, 2012 at 3:20 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> >>> On 2012-09-09, at 15:16, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >>>> allFileNames >>>> cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. >>>> ^ allFileNames ifNil: [ >>>> allFileNames := self loadAllFileNames] >>>> >>>> >>>> If you put a halt in the first if, you will see it stops... >>>> because cacheFileNames is nil. In 1.4 you have: >>>> >>>> allFileNamesOrCache >>>> ^ allFileNames ifNil: [self allFileNames] >>>> >>>> so it kind of always cached... so maybe this is a difference that >>> affects >>>> the results? >>> >>> >>> humm you might be right |(. so metacello should explicitely tell to cache >>> stuff in 2.0 then >>> >>> >>> >> >> I would do >> >> MCFileBasedRepository >> initialize >> cacheFileNames := true >> >> or something like test. But first, we should be sure this was really one >> of the causes of the slowdown >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Camillo Bruni

On 2012-09-09, at 15:25, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Sun, Sep 9, 2012 at 3:20 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2012-09-09, at 15:16, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >>> allFileNames >>> cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. >>> ^ allFileNames ifNil: [ >>> allFileNames := self loadAllFileNames] >>> >>> >>> If you put a halt in the first if, you will see it stops... >>> because cacheFileNames is nil. In 1.4 you have: >>> >>> allFileNamesOrCache >>> ^ allFileNames ifNil: [self allFileNames] >>> >>> so it kind of always cached... so maybe this is a difference that affects >>> the results? >> >> >> humm you might be right |(. so metacello should explicitely tell to cache >> stuff in 2.0 then >> >> >> > > I would do > > MCFileBasedRepository >> initialize > cacheFileNames := true > > or something like test. But first, we should be sure this was really one of > the causes of the slowdown you'll break the whole download optimizations if you enable these caches there, since it will never find the newly downloaded files again :P I think there is a method, something like cacheAllFileNamesDuring: or so...

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Mariano Martinez Peck

Send me the doIt to install your confs and I will try to try it. On Sun, Sep 9, 2012 at 3:25 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sun, Sep 9, 2012 at 3:20 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> >> On 2012-09-09, at 15:16, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> > allFileNames >> > cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. >> > ^ allFileNames ifNil: [ >> > allFileNames := self loadAllFileNames] >> > >> > >> > If you put a halt in the first if, you will see it stops... >> > because cacheFileNames is nil. In 1.4 you have: >> > >> > allFileNamesOrCache >> > ^ allFileNames ifNil: [self allFileNames] >> > >> > so it kind of always cached... so maybe this is a difference that >> affects >> > the results? >> >> >> humm you might be right |(. so metacello should explicitely tell to cache >> stuff in 2.0 then >> >> >> > > I would do > > MCFileBasedRepository >> initialize > cacheFileNames := true > > or something like test. But first, we should be sure this was really one > of the causes of the slowdown > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Mariano Martinez Peck

On Sun, Sep 9, 2012 at 3:20 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-09-09, at 15:16, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > allFileNames > > cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. > > ^ allFileNames ifNil: [ > > allFileNames := self loadAllFileNames] > > > > > > If you put a halt in the first if, you will see it stops... > > because cacheFileNames is nil. In 1.4 you have: > > > > allFileNamesOrCache > > ^ allFileNames ifNil: [self allFileNames] > > > > so it kind of always cached... so maybe this is a difference that affects > > the results? > > > humm you might be right |(. so metacello should explicitely tell to cache > stuff in 2.0 then > > > I would do MCFileBasedRepository >> initialize cacheFileNames := true or something like test. But first, we should be sure this was really one of the causes of the slowdown -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Camillo Bruni

On 2012-09-09, at 15:16, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > allFileNames > cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. > ^ allFileNames ifNil: [ > allFileNames := self loadAllFileNames] > > > If you put a halt in the first if, you will see it stops... > because cacheFileNames is nil. In 1.4 you have: > > allFileNamesOrCache > ^ allFileNames ifNil: [self allFileNames] > > so it kind of always cached... so maybe this is a difference that affects > the results? humm you might be right |(. so metacello should explicitely tell to cache stuff in 2.0 then

Sept. 9, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 338 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 9, 2012

Re: [Pharo-project] Configuration loading 1.4 vs 2.0

by Mariano Martinez Peck

allFileNames cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. ^ allFileNames ifNil: [ allFileNames := self loadAllFileNames] If you put a halt in the first if, you will see it stops... because cacheFileNames is nil. In 1.4 you have: allFileNamesOrCache ^ allFileNames ifNil: [self allFileNames] so it kind of always cached... so maybe this is a difference that affects the results? On Sun, Sep 9, 2012 at 3:14 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-09-09, at 15:12, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > I think instVar cacheFileNames is never initialized and hence, it follows > > > > cacheFileNames == true ifFalse: [ ^ self loadAllFileNames ]. > > where is that? > > > On Sun, Sep 9, 2012 at 2:35 PM, Camillo Bruni <camillobruni(a)gmail.com > >wrote: > > > >> > >> On 2012-09-09, at 14:24, Mariano Martinez Peck <marianopeck(a)gmail.com> > >> wrote: > >> > >>> I guess you tried both with an empty package-cache, right? > >> > >> yes, not much of a diff... > > > -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2012