August 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=win/… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 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/… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 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… 7 regressions found. KernelTests.Classes.BehaviorTest.testBehaviorRespectsPolymorphismWithTraitBehavior KernelTests.Classes.MetaclassTest.testMetaclassAndTraitClassRespectsPolymorphismRules KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testNotEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testOrEnvironment Refactoring.Tests.Environment.RBBrowserEnvironmentTest.testRemoveSelectorByAndAndNot Tests.Release.ReleaseTest.testInstanceSideMethodsWithNilKeyInLastLiteral

Aug. 8, 2013

[update 3.0] #30327

by Esteban Lorenzano

30327 ----- 11144 Merge Latest NativeBoost with Pharo 3.0 https://pharo.fogbugz.com/f/cases/11144

Aug. 8, 2013

Pharo VM latest on the Debian 7

by Laszlo Zsolt Kiss

Hi. The latest Pharo VM isnt working on Debian 7. The error message: /work/pharo3.0/bin/pharo: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found The Glibc version in Debian 7 is 2.13. Best regards Laszlo Zsolt KIss

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

On 8 August 2013 09:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Well, my intent was to keep working together on it and be as open as possible to >> people who may not work particularly on Pharo, but care/use Cog. >> >> >> Now my dilemma is, what is the fate of Cog tracker? >> >> On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> I think that's not true at all. >>> >>> Our git repo and our vmmaker repo are used to build only the pharo vm >>> flavor. If we make a fix it does not get magically integrated into eliots >>> cog. >>> >> >> Guillermo , it is not 'our' and never been. It belongs to community, >> and Pharo is just part of it. >> I had hard time convincing people to join and use git and tracker.. >> Now this move puts a big cross on all these efforts. >> >> >> Of course i understand the benefits of having everything at one place. >> And of course we (as Pharo team) are free to organize own work in a >> way we see fit. > > indeed but do not see the devil everywhere > why putting the issue on a public tracker means private? > well, perhaps then someone should communicate to me (and others) in detail, what it is about? and perhaps such actions should be communicated before doing? >> But i don't think we will find understanding if we start privatizing >> things which are not belong to us. >> Because initially this stuff was created without intent to be >> 'pharo-only' or for 'pharo-only'. > > > You see that clement is implementing clean blocks and that eliot wants to integrate his work in COG. > > > Stef > -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by StÃ©phane Ducasse

On Aug 7, 2013, at 8:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Well, my intent was to keep working together on it and be as open as possible to > people who may not work particularly on Pharo, but care/use Cog. > > > Now my dilemma is, what is the fate of Cog tracker? > > On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> I think that's not true at all. >> >> Our git repo and our vmmaker repo are used to build only the pharo vm >> flavor. If we make a fix it does not get magically integrated into eliots >> cog. >> > > Guillermo , it is not 'our' and never been. It belongs to community, > and Pharo is just part of it. > I had hard time convincing people to join and use git and tracker.. > Now this move puts a big cross on all these efforts. > > > Of course i understand the benefits of having everything at one place. > And of course we (as Pharo team) are free to organize own work in a > way we see fit. indeed but do not see the devil everywhere why putting the issue on a public tracker means private? > But i don't think we will find understanding if we start privatizing > things which are not belong to us. > Because initially this stuff was created without intent to be > 'pharo-only' or for 'pharo-only'. You see that clement is implementing clean blocks and that eliot wants to integrate his work in COG. Stef > >> Maybe they can benefit from the changes but they have to merge back as you >> esteban and igor merge in our branch. >> > > -- > Best regards, > Igor Stasenko. >

Aug. 8, 2013

Fwd: SmalltalkHub down

by Nicolas Cellier

---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2013/8/8 Subject: SmalltalkHub down To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> http://smalltalkhub.com/ -> 502 Proxy Error

Aug. 8, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Igor Stasenko

Well, my intent was to keep working together on it and be as open as possible to people who may not work particularly on Pharo, but care/use Cog. Now my dilemma is, what is the fate of Cog tracker? On 7 August 2013 20:29, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I think that's not true at all. > > Our git repo and our vmmaker repo are used to build only the pharo vm > flavor. If we make a fix it does not get magically integrated into eliots > cog. > Guillermo , it is not 'our' and never been. It belongs to community, and Pharo is just part of it. I had hard time convincing people to join and use git and tracker.. Now this move puts a big cross on all these efforts. Of course i understand the benefits of having everything at one place. And of course we (as Pharo team) are free to organize own work in a way we see fit. But i don't think we will find understanding if we start privatizing things which are not belong to us. Because initially this stuff was created without intent to be 'pharo-only' or for 'pharo-only'. > Maybe they can benefit from the changes but they have to merge back as you > esteban and igor merge in our branch. > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Put issues from cog issue tracker into pharo issue tracker

by Guillermo Polito

I think that's not true at all. Our git repo and our vmmaker repo are used to build only the pharo vm flavor. If we make a fix it does not get magically integrated into eliots cog. Maybe they can benefit from the changes but they have to merge back as you esteban and igor merge in our branch. Le 7 aoÃ»t 2013 20:10, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> a Ã©crit : > >> > >> > > > > That's exactly what i was thinking about when registered cog issue > tracker. > > And since Cog used not just by Pharo, it deserves own separate > repository. > > > > Now i would like to know, if somebody asked people who contributing to > Cog > > development but not to Pharo, if they would like to use Pharo issue > > tracker for that. > > > > Or maybe we don't have to care, then doing like this is a way to piss > them off. > > Indeed this is the drawback. > So when we close something on pharo and that it contributes > to cog we should update the cog one. > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > >

Aug. 7, 2013