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

Pharo2 open bugs down to 2

by Marcus Denker

Hi, I did a pass over all the bugs reported for Pharo2. Those that where not really important I checked in Pharo3 and either closed them or moved them to later. We have 2 bugs left: https://pharo.fogbugz.com/f/filters/8/2-0-Work-Needed 11079 ProfStef tutorials unusable as one cannot do a doIt https://pharo.fogbugz.com/f/cases/11079 10860 Drag and drop change files on image, Cmd-click on the first doIt to get rid of it, then deadlyâ¦ https://pharo.fogbugz.com/f/cases/10860 Both are fixed in Pharo3 already, but the doit one maybe due to the quite large changes regarding the compiler integration. Marcus

July 18, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 2 regressions found. Tests.Traits.TraitFileOutTest.testFileOutTrait Tests.Traits.TraitTest.testPrinting

July 18, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 3 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory Tests.Traits.TraitFileOutTest.testFileOutTrait Tests.Traits.TraitTest.testPrinting

July 18, 2013

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

by StÃ©phane Ducasse

On Jul 18, 2013, at 1:11 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I'm sorry to endorse the role of naughty conservatism (probably a problem of age), No this is good to have people to kick our ass and I like because you are not blunt and your arguments are well funded to me. So there is no problem about 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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 18, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 18, 2013

[update 3.0] #30281

by Esteban Lorenzano

July 18, 2013

[update 3.0] #30280

by Esteban Lorenzano

30280 -------- 10992 Some methods in Class could be moved to TClass https://pharo.fogbugz.com/f/cases/10992/ (pass 1)

July 18, 2013

Re: [Pharo-dev] Cant Load NeoJson

by Sven Van Caekenberghe

On 18 Jul 2013, at 13:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I'll have a look at the server ASAP. http://mc.stfx.eu is OK again. Sorry for the inconvenience. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 18, 2013

New post on Voyage: Advanced queries

by Esteban Lorenzano

Hi, I just finished a section for the PharoForTheEnterprise book and I put it also as a blog post: http://smallworks.eu/web/blog/2013-07-18-Voyage-advanced-queries cheers, Esteban

July 18, 2013