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

Re: [Pharo-dev] 10 Pharo Consultants

by phil＠highoctane.be

Sweet. Thx. --- 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 12:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > 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 Norbert Hartl

+1 norbert Am 18.07.2013 um 13:11 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I'm sorry to endorse the role of naughty conservatism (probably a problem of age), but introducing a touch of damping to slow the system down don't hurt. > Anyway, any doer is responsible for his/her changes and can be prepared to rants, > Funnily I'm also being questionned in the same time for having changed ($a to: $z) to return a String rather than an OrderedCollection in Squeak, > We must accept that, every change is questionnable. > Personnaly I try to rationalize rants, and rationalize changes, or at least put them in a longer term perspective, but at the end, some changes must always be done arbitrarily. > > > 2013/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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] Cant Load NeoJson

by Sven Van Caekenberghe

Hi Vincent, Please try http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo but the config will go back to the other repository. I'll have a look at the server ASAP. Sven On 18 Jul 2013, at 13:16, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > Hi, > > I use NeoJson in my project and it accesses the http://mc.stfx.eu/Neo website. > > This site return : > > > GET /Neo HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: mc.stfx.eu > > Accept: */* > > > < HTTP/1.1 500 Internal Server Error > < Date: Thu, 18 Jul 2013 11:10:43 GMT > < Server: Zinc HTTP Components 1.0 > < Content-Type: text/plain;charset=utf-8 > < Content-Length: 48 > < Vary: Accept-Encoding > < Connection: close > < > MessageNotUnderstood: receiver of "now" is nil > > What is not I expected... > > Cheers, > Vincent >

July 18, 2013

[update 3.0] #30279

by Marcus Denker

30279 ----- 11173 Monticello class migrations do not work well with the new ClassBuilder https://pharo.fogbugz.com/f/cases/11173 11187 printing [self] shows source of Doit https://pharo.fogbugz.com/f/cases/11187 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.590.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.48.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-MarcusDenker.355.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-MarcusDenker.834.d…

July 18, 2013

Cant Load NeoJson

by Vincent Blondeau

Hi, I use NeoJson in my project and it accesses the http://mc.stfx.eu/Neo website. This site return : > GET /Neo HTTP/1.1 > User-Agent: curl/7.29.0 > Host: mc.stfx.eu > Accept: */* > < HTTP/1.1 500 Internal Server Error < Date: Thu, 18 Jul 2013 11:10:43 GMT < Server: Zinc HTTP Components 1.0 < Content-Type: text/plain;charset=utf-8 < Content-Length: 48 < Vary: Accept-Encoding < Connection: close < MessageNotUnderstood: receiver of "now" is nil What is not I expected... Cheers, Vincent

July 18, 2013

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

by Nicolas Cellier

I'm sorry to endorse the role of naughty conservatism (probably a problem of age), but introducing a touch of damping to slow the system down don't hurt. Anyway, any doer is responsible for his/her changes and can be prepared to rants, Funnily I'm also being questionned in the same time for having changed ($a to: $z) to return a String rather than an OrderedCollection in Squeak, We must accept that, every change is questionnable. Personnaly I try to rationalize rants, and rationalize changes, or at least put them in a longer term perspective, but at the end, some changes must always be done arbitrarily. 2013/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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] 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