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

[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… 1 regressions found. NetworkTests.Kernel.NetNameResolverTest.testLocalHostName

July 18, 2013

[update 3.0] #30277

by Marcus Denker

30277 ----- 11184 ReleaseTest testUndeclaredFailed: for configurationSearchList https://pharo.fogbugz.com/f/cases/11184 11178 OCUnknownSelectorWarning(OCSemanticWarning)>>errorCode raises a DNU https://pharo.fogbugz.com/f/cases/11178 11171 ClassOrganization >> #hasComment is wrong https://pharo.fogbugz.com/f/cases/11171 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1179.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-CommandLine-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NewClassOrganizer-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/CodeImport-MarcusDenker.31.di…

July 18, 2013

Re: [Pharo-dev] buttons for browsing in the debugger

by StÃ©phane Ducasse

I was not even aware that they exist. Stef On Jul 17, 2013, at 3:57 PM, Andrei Vasile Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > If the debugging option ExtraDebuggerButtons is set to true a second row containing some actions for browsing code (senders, implementors, versions, etc) will be added under the one with > the stepInto, stepOver, etc buttons. > > Do you use this feature? > Do we want it in the new debugger? > > Andrei

July 18, 2013

Re: [Pharo-dev] CameraPlugin for (Pharo) VM

by StÃ©phane Ducasse

Thanks for the update. Now I understand the concerns of igor and igor should finish its already large todo. But somebody else can help. Stef > We once had a discussion already, to summarize: > - the camera plugin from scratch worked according to Bernat Romagosa [1] > - Stef checked the scratch license and said this license is not MIT so he do not want to see it in Pharo [2] [3] > > We didnt move on with this since we thought it is covered by Scratch license or since nobody really cared. > > But it looks like the Camera stuff is indeed released with MIT license (even before the discussion) > I just found by accident this old issue: > > http://bugs.squeak.org/view.php?id=7654 > > <quotes> > "two plugins that should be made available for standard VMs" > > "Per communication from Bert Freudenberg, source for CameraPlugin is > now available under MIT license:" > > "Here is the CameraPlugin code under MIT license." > </quote> > > Acccording to this issue the camera code was opened with MIT. The issue also includes the code. > > Can we check again - default support for camera would be a nice addition > to our Pharo universe. > > Thx > T. > > > [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051826.html > [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051838.html > [3] http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051843.html >

July 18, 2013

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

by Marcus Denker

On Jul 17, 2013, at 10:33 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 will not be changed. I just added isNotNot in addition to notNot. No deprecation, no refactoring. Marcus

July 18, 2013

Re: [Pharo-dev] Metacello doubt

by Dale K. Henrichs

July 18, 2013

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

by Nicolas Cellier

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 17, 2013

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

by Camillo Bruni

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 17, 2013

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

by Nicolas Cellier

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 17, 2013

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

by Camillo Bruni

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 17, 2013