- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 10 Pharo Consultants

by Sven Van Caekenberghe

Hi Phil, you will be in the next update. Thanks. Sven On 18 Jul 2013, at 11:37, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > PharoConsultant new > name: 'Philippe Back'; > location: 'Bierges, Belgium'; > email: 'phil(a)highoctane.be'; > website: 'http://highoctane.be'; > languages: 'French (native), Dutch, English'; > industryExperienceSince: 1992; > smalltalkExperienceSince: 2010; > pharoExperienceSince: 2010; > areasOfExpertise: 'domain models, specifications, web'; > yourself. > > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Featured on the Software Process and Measurement Cast > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller > > > > > On Thu, Jul 18, 2013 at 11:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > We're at 10 Pharo Consultants > > http://consultants.pharo.org > > and counting. Please send me your info by filling in the template: > > PharoConsultant new > name: 'John Doe'; > location: 'Paris, France'; > email: 'john(a)doe-consulting.com'; > website: 'http://doe-consulting.com'; > languages: 'English (native), French'; > industryExperienceSince: 1998; > smalltalkExperienceSince: 2010; > pharoExperienceSince: 2010; > areasOfExpertise: 'Business Applications, Distributed Systems, UX'; > yourself. > > Thanks, > > Sven > > -- > Sven Van Caekenberghe > Pharo Consultant > http://consultants.pharo.org#svenvancaekenberghe > > >

July 18, 2013

Re: [Pharo-dev] [update 3.0] #30276

by StÃ©phane Ducasse

Hi nicolas I agree :) So we should find the right balance. Stef > For FileSystem, there is a clear win, so I'd say the change is really worth. > 1) you add more capabilities > 2) more logical/convenient API > 3) more efficient implementation > 4) more scalable implementation > The optional compatibility layer you offered is the exact solution to the upgrade problem (you give a bit of time to maintainers) > I buy it. > > For and:and:and: etc... I agree with deprecation because such selector adds near to null > (I personnally changed many senders in Squeak, so I'm totally biased here). > > For isNotNil I'm not convinced at all. > To me, it's not much but noise. > There are currently 3 senders vs 890 for notNil. I imagine many more in many packages. > Think in mid/long term. What's your plans? Wait for the balance to slowly inverse? Rename all? > > For notEmpty, it's worse: 6 implementors. > So what's the new contract? any new implementor of notEmpty shall also implement isNotEmpty? > Or isNotEmpty is implemented in term of notEmpty in Object? > Currently, 5 out of 6 implementors of notEmpty do not implement isNotEmpty and 1 out of 2 implementor of isNotEmpty does not implement notEmpty. > It's not just noise, it's currently a mess! > > As for an automated rewrite rule, yes, this is some very usefull features for supporting such refactorings. > I'd say a pre-requisite. > But that force using several branches for cross version support, or worse, cross dialect support. > If all diffs are automated, that's ok, if some of the changes are manual, it's a pain (backport etc...) > > > 2013/7/17 Camillo Bruni <camillobruni(a)gmail.com> > there have been many similar decisions in the past, > I remember for instance the move from #and:and:and: or #or:or:or: which > weighs around the same as the #isNotNil. > > FileSystem or Slots are even on a bigger scale. > > Package maintenance in which sense, across different Pharo versions or different Smalltalk versions? > > Between Pharo versions should be more or less ok, since such changes (#isNotNil and Co) usually come with a proper deprecation. > > AFAIK there is someone working on detecting much more subtle changes in Pharo and provide lint rules on top. So I think we have to embrace changes. > > On 2013-07-17, at 22:49, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I wonder what is the decision process behind such change. > > Do you put in balance what you gain and what you loose? > > To me gain is near zero and these little changes stacked together put a > > useless burden on package maintenance. > > > > > > 2013/7/17 Camillo Bruni <camillobruni(a)gmail.com> > > > >> On 2013-07-17, at 22:32, Nicolas Cellier < > >> nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> So you would be ready to change notNil -> isNotNil and become a bit more > >>> incompatible with the rest of the world? > >> > >> that method is already present in the image. > >> > >>> I understand that the pair isEmpty/isNotEmpty may seem a bit more > >>> homogeneous, but I see no other selector constructed with (isNot isnt) > >>> while I see many others where is is omitted. > >>> I wonder what this kind of change really serve... > >> > >> For me they are consistent with all the other is* methods out there > >> returning booleans. > > >

July 18, 2013

Re: [Pharo-dev] [update 3.0] #30276

by StÃ©phane Ducasse

On Jul 17, 2013, at 11:03 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > there have been many similar decisions in the past, > I remember for instance the move from #and:and:and: or #or:or:or: which > weighs around the same as the #isNotNil. I do not think that this is the same because and:and:and: were not really used. Now we can have isNotNil and just notNil as backward compatibility. > FileSystem or Slots are even on a bigger scale. > Package maintenance in which sense, across different Pharo versions or different Smalltalk versions? > > Between Pharo versions should be more or less ok, since such changes (#isNotNil and Co) usually come with a proper deprecation. > > AFAIK there is someone working on detecting much more subtle changes in Pharo and provide lint rules on top. So I think we have to embrace changes. I would love the work of andre to be part of our delivery process. > > On 2013-07-17, at 22:49, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> I wonder what is the decision process behind such change. >> Do you put in balance what you gain and what you loose? >> To me gain is near zero and these little changes stacked together put a >> useless burden on package maintenance. >> >> >> 2013/7/17 Camillo Bruni <camillobruni(a)gmail.com> >> >>> On 2013-07-17, at 22:32, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> So you would be ready to change notNil -> isNotNil and become a bit more >>>> incompatible with the rest of the world? >>> >>> that method is already present in the image. >>> >>>> I understand that the pair isEmpty/isNotEmpty may seem a bit more >>>> homogeneous, but I see no other selector constructed with (isNot isnt) >>>> while I see many others where is is omitted. >>>> I wonder what this kind of change really serve... >>> >>> For me they are consistent with all the other is* methods out there >>> returning booleans. > >

July 18, 2013

Re: [Pharo-dev] [update 3.0] #30276

by StÃ©phane Ducasse

On Jul 17, 2013, at 10:32 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > So you would be ready to change notNil -> isNotNil and become a bit more incompatible with the rest of the world? > I understand that the pair isEmpty/isNotEmpty may seem a bit more homogeneous, but I see no other selector constructed with (isNot isnt) while I see many others where is is omitted. > I wonder what this kind of change really serveâ¦ I kind of agree. We should pay attention that we do not change for changing even. It is true that this is a bit frustating. Now what would be good is to have rules that can automatically transform code because they could be use when we want to change I would love also to have some rules when I edit the code because I always forget if it is better to use isNil ifNilâ¦.. Stef > Nicolas > > > 2013/7/17 Marcus Denker <marcus.denker(a)inria.fr> > 30276 > ----- > > 7300 Finder raise an error on asking for implementors > https://pharo.fogbugz.com/f/cases/7300 > > 10348 GroupAlreadyExists vs. GroupsAlreadyExists confusion > https://pharo.fogbugz.com/f/cases/10348 > > 11180 Add a filter to the config browser > https://pharo.fogbugz.com/f/cases/11180 > > 11172 notEmpty should be isNotEmpty > https://pharo.fogbugz.com/f/cases/11172 > > Diff information: > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1177.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.492.diff > http://smalltalkhub.com/mc/Pharo/Pharo30/main/GroupManager-MarcusDenker.43.… > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-MarcusDe… > > >

July 18, 2013

Re: [Pharo-dev] 10 Pharo Consultants

by phil＠highoctane.be

PharoConsultant new name: 'Philippe Back'; location: 'Bierges, Belgium'; email: 'phil(a)highoctane.be'; website: 'http:// <http://doe-consulting.com/>highoctane.be'; languages: 'French (native), Dutch, English'; industryExperienceSince: 1992; smalltalkExperienceSince: 2010; pharoExperienceSince: 2010; areasOfExpertise: 'domain models, specifications, web'; yourself. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Jul 18, 2013 at 11:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Hi, > > We're at 10 Pharo Consultants > > http://consultants.pharo.org > > and counting. Please send me your info by filling in the template: > > PharoConsultant new > name: 'John Doe'; > location: 'Paris, France'; > email: 'john(a)doe-consulting.com'; > website: 'http://doe-consulting.com'; > languages: 'English (native), French'; > industryExperienceSince: 1998; > smalltalkExperienceSince: 2010; > pharoExperienceSince: 2010; > areasOfExpertise: 'Business Applications, Distributed Systems, UX'; > yourself. > > Thanks, > > Sven > > -- > Sven Van Caekenberghe > Pharo Consultant > http://consultants.pharo.org#svenvancaekenberghe > > >

July 18, 2013

Re: [Pharo-dev] 10 Pharo Consultants

by StÃ©phane Ducasse

This looks good! I like the names I see :) Stef On Jul 18, 2013, at 11:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > We're at 10 Pharo Consultants > > http://consultants.pharo.org > > and counting. Please send me your info by filling in the template: > > PharoConsultant new > name: 'John Doe'; > location: 'Paris, France'; > email: 'john(a)doe-consulting.com'; > website: 'http://doe-consulting.com'; > languages: 'English (native), French'; > industryExperienceSince: 1998; > smalltalkExperienceSince: 2010; > pharoExperienceSince: 2010; > areasOfExpertise: 'Business Applications, Distributed Systems, UX'; > yourself. > > Thanks, > > Sven > > -- > Sven Van Caekenberghe > Pharo Consultant > http://consultants.pharo.org#svenvancaekenberghe > >

July 18, 2013

[update 3.0] #30278

by Marcus Denker

30278 ----- 11029 #testUnknownProcesses failing on build server https://pharo.fogbugz.com/f/cases/11029 11181 Clean up some dead code in Categorizer and subclass + ClassCategoreader https://pharo.fogbugz.com/f/cases/11181 11183 #halt cannot be properly debugged inside #ensure: blocks https://pharo.fogbugz.com/f/cases/11183 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.833.d… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KeyChain-MarcusDenker.41.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1523.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CodeImport-MarcusDenker.32.di…

July 18, 2013

Re: [Pharo-dev] 10 Pharo Consultants

by Norbert Hartl

Hmm, I thought John Doe would still work at ACME corp. :) Greatest entry so far! Norbert Am 18.07.2013 um 11:24 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > We're at 10 Pharo Consultants > > http://consultants.pharo.org > > and counting. Please send me your info by filling in the template: > > PharoConsultant new > name: 'John Doe'; > location: 'Paris, France'; > email: 'john(a)doe-consulting.com'; > website: 'http://doe-consulting.com'; > languages: 'English (native), French'; > industryExperienceSince: 1998; > smalltalkExperienceSince: 2010; > pharoExperienceSince: 2010; > areasOfExpertise: 'Business Applications, Distributed Systems, UX'; > yourself. > > Thanks, > > Sven > > -- > Sven Van Caekenberghe > Pharo Consultant > http://consultants.pharo.org#svenvancaekenberghe > >

July 18, 2013

Re: [Pharo-dev] Config browser with filter

by StÃ©phane Ducasse

+ 1 On Jul 17, 2013, at 8:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > honestly... I'm thinking that it was not a good idea to backport the spec conf browser to 2.0. > looks to me that is not ready for production, and we need time to make it ready (time that we have for 3.0, but not for a bugfix release). > > just my opinion > > Esteban > > On Jul 17, 2013, at 8:43 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> :) >> >> I have a catalogBuilder that starts to work so we will use configurations for generating >> some nice information. >> >> Stef >> >> On Jul 17, 2013, at 2:55 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >> >>> screen attached >>> >>> Pharo 2.0: Slice and issue 11179 together with a fix for broken buttons >>> Pharo 3.0: Slice and issue 11180 >>> >>> <configbrowserfilter.png> >> >> > >

July 18, 2013

10 Pharo Consultants

by Sven Van Caekenberghe

Hi, We're at 10 Pharo Consultants http://consultants.pharo.org and counting. Please send me your info by filling in the template: PharoConsultant new name: 'John Doe'; location: 'Paris, France'; email: 'john(a)doe-consulting.com'; website: 'http://doe-consulting.com'; languages: 'English (native), French'; industryExperienceSince: 1998; smalltalkExperienceSince: 2010; pharoExperienceSince: 2010; areasOfExpertise: 'Business Applications, Distributed Systems, UX'; yourself. Thanks, Sven -- Sven Van Caekenberghe Pharo Consultant http://consultants.pharo.org#svenvancaekenberghe

July 18, 2013