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

auto updates from issue tracker now blocked (was: Put issues from cog issue tracker into pharo issue tracker)

by David T. Lewis

We have gotten well over 100 updates to the vm-dev list for issues being moved around between various issue trackers. This is excessive and seems to be of little relevance to the vm-dev list. As list admin for the vm-dev list, I am responsible for keeping things like this under control. Unless I hear a convincing argument to the contrary, I will disable the cog(a)googlecode.com updates 24 hours from now. Dave On Thu, Aug 08, 2013 at 04:04:44PM +0200, Henrik Johansen wrote: > > On Aug 8, 2013, at 3:03 , Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> > >> I guess that solves the question around the fate of the cog issue tracker: I > >> didn't mean a deprecation or similar, people can continue using it as they > >> want. I put for that links so people can go back and forth between the issue > >> trackers. My unique and good intention was to make those issues more > >> visible. > > > > Thanks, Guillermo. > > I think everyone understands that your intention was for good, but > > when you don't inform > > people properly they tend to think worst (including me) > > > > :) > > > > -- > > Best regards, > > Igor Stasenko. > > > > Especially when you end up spamming VM-dev with Cog issue tracker updates saying "Moved to fogbugz". > Even with the modified updates, why you'd need to mirror an existing tracker for a related but distinct project into the Pharo tracker, with the synchronization issues that might cause, js still a bit beyond me. > > Cheers, > Henry >

Aug. 8, 2013

[update 3.0] #30328

by StÃ©phane Ducasse

Aug. 8, 2013

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

by StÃ©phane Ducasse

On Aug 8, 2013, at 7:37 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, Esteban Lorenzano wrote: > >> that's a restriction made by the service we choose. > > So it is you, who have chosen the restriction. > >> issues are publicly visible here: >> >> http://bugs.pharo.org >> >> and there you also can register your self so you can also edit issues in fogbugz. >> so yes... is public in the "non-restricted access" meaning of the word. > > The barrier is way to high for anyone without an account to access the tracker. All links to issues on this mailing list point to fogbugz.com. Finding the matching issue on bugs.pharo.org seems to be kinda impossible. > For example can you point me to the publicly visible link for this case https://pharo.fogbugz.com/f/cases/11144 (without checking pharo.fogbugz.com ofc)? > > Also bugs.pharo.org doesn't seem to be up-to-date. For example I can't find the recently moved issues from the Cog tracker. Levente we did not take fogbuz because it forces people to log to edit bugs. We took it because google removed the script API of google code. We had really something else to do than to change a bug tracker when it was not the moment nor our wishes. Now fogbugz people nicely offered us to host and be able to use software that costs 25$ per site per month. So we decided to give a try and it has the cost that we cannot edit bugs without being log and a complex interface but we are happy that we do not have to run mantis or another bug tracker by ourselves. Now guillermo saw that squeakers use the squeak bug tracker to track Cog VM bugs so there is no point for us to have two bugtrackers to deal with. So this is simple I guess and this bug tracker stays a public one. Anybody on earth willing to have an access can get one. S. > > > Levente > >> >> Esteban >> >> On Aug 8, 2013, at 4:57 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: >> >>> Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 8 August 2013 13:35, Levente Uzonyi >>> <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, >>> StÃ©phane Ducasse wrote: > > g the issue on a public tracker means >>> private? > > > > > > How is that a "public tracker"? > > > > can you >>> elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or >>> what makes you think it is not public? > >>> >>> Take the first bug fix from the Pharo Summer release details at >>> <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s >>> erves-no-purpose> >>> >>> This gives a the fogbugz log in page so to get info you need to login so >>> not public (also are the bugs indexed by google?) >>> >>> >>> -- >>> Mark >>> >>> >> >>

Aug. 8, 2013

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

by Levente Uzonyi

On Thu, 8 Aug 2013, Esteban Lorenzano wrote: > that's a restriction made by the service we choose. So it is you, who have chosen the restriction. > issues are publicly visible here: > > http://bugs.pharo.org > > and there you also can register your self so you can also edit issues in fogbugz. > so yes... is public in the "non-restricted access" meaning of the word. The barrier is way to high for anyone without an account to access the tracker. All links to issues on this mailing list point to fogbugz.com. Finding the matching issue on bugs.pharo.org seems to be kinda impossible. For example can you point me to the publicly visible link for this case https://pharo.fogbugz.com/f/cases/11144 (without checking pharo.fogbugz.com ofc)? Also bugs.pharo.org doesn't seem to be up-to-date. For example I can't find the recently moved issues from the Cog tracker. Levente > > Esteban > > On Aug 8, 2013, at 4:57 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: > >> Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 8 August 2013 13:35, Levente Uzonyi >> <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, >> StÃ©phane Ducasse wrote: > > g the issue on a public tracker means >> private? > > > > > > How is that a "public tracker"? > > > > can you >> elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or >> what makes you think it is not public? > >> >> Take the first bug fix from the Pharo Summer release details at >> <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s >> erves-no-purpose> >> >> This gives a the fogbugz log in page so to get info you need to login so >> not public (also are the bugs indexed by google?) >> >> >> -- >> Mark >> >> > > >

Aug. 8, 2013

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

by Igor Stasenko

well, strictly speaking, being indexed by google is not synonym to being public. (and, of course, that don't means we don't miss or want it) On 8 August 2013 18:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that's a restriction made by the service we choose. > issues are publicly visible here: > > http://bugs.pharo.org > > and there you also can register your self so you can also edit issues in fogbugz. > so yes... is public in the "non-restricted access" meaning of the word. > > Esteban > > On Aug 8, 2013, at 4:57 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: > >> Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 8 August 2013 13:35, Levente Uzonyi >> <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, >> StÃ©phane Ducasse wrote: > > g the issue on a public tracker means >> private? > > > > > > How is that a "public tracker"? > > > > can you >> elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or >> what makes you think it is not public? > >> >> Take the first bug fix from the Pharo Summer release details at >> <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s >> erves-no-purpose> >> >> This gives a the fogbugz log in page so to get info you need to login so >> not public (also are the bugs indexed by google?) >> >> >> -- >> Mark >> >> > > -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] [Vm-dev] Changes in the repositories for the VM

by Igor Stasenko

I'd like to add many thanks to developers of FileTree project who made this possible. Thanks to that we can keep all VM sources in single repository, C and Smalltalk ones. -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by StÃ©phane Ducasse

> Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and that consequently the Pharo VM as compiled won't run on any Linux distro older than 17 months? No we will support several linux versions. Stef

Aug. 8, 2013

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

by Esteban Lorenzano

that's a restriction made by the service we choose. issues are publicly visible here: http://bugs.pharo.org and there you also can register your self so you can also edit issues in fogbugz. so yes... is public in the "non-restricted access" meaning of the word. Esteban On Aug 8, 2013, at 4:57 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: > Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 8 August 2013 13:35, Levente Uzonyi > <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, > StÃ©phane Ducasse wrote: > > g the issue on a public tracker means > private? > > > > > > How is that a "public tracker"? > > > > can you > elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or > what makes you think it is not public? > > > Take the first bug fix from the Pharo Summer release details at > <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s > erves-no-purpose> > > This gives a the fogbugz log in page so to get info you need to login so > not public (also are the bugs indexed by google?) > > > -- > Mark > >

Aug. 8, 2013

Changes in the repositories for the VM

by Esteban Lorenzano

Hi, Ok, we finally decided to make some changes longtime postponed, to improve our way of building the VM. Squeak guys are still using the old mechanism, so this just applies to Pharo and the continuous integration under the Pharo umbrella... but please notice that ANY vm flavor can be built with this source repository. The first change was to put all sources together. No more MCZ files to keep VMMaker and plugins and platform sources as a GIT repository. We are using filetree to keep source files, so is just like a different kind of monticello repository. With this, now a commit is atomic and the platform sources will be in sync with VMMaker sources. Also, that simplifies a lot the ConfigurationOfCog file, since the commit number is the version number... now we just need the baseline (not version anymore). So now you can checkout a version of the repository and do: ConfigurationOfCog loadGit. and that's all :) (from our point of view, this simplification is an huge advantage over the older process). The second change is just a relocation. Now the VM source lives in GitHub :) The reason of this move is because GitHub has a lot more functionality than the old Gitorious, also most of the people using filetree are already using GitHub so is easier for them to fork, etc. Also, it is hyped so we wanted to be in that wave ;) The new repository can be found at: https://github.com/pharo-project/pharovm Cheers, Esteban

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Esteban Lorenzano

well... no. something happened with the build, because it should be executable in a 1.5 years old linux. in the middle term, we are going to adopt an approach similar to VW (one VM for one image version), and we will support some years of backward compatibility. But not infinite, of course, because work is too much :) Now... the "latest" VM is unstable. Is not a release and of course it will be problems. When we release it, it will be version to run in several versions... it should be as simple as add a slave into our build server. cheers, Esteban On Aug 8, 2013, at 4:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 August 2013 15:40, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: >> Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and >> that consequently the Pharo VM as compiled won't run on any Linux distro >> older than 17 months? >> > > You are not forced to use latest VM, you can always download and use > 5-year old VM, which will (hopefully) > work for you. > :) > > Now if platform (linux) moves, we must follow. And that is not a question to me. > > -- > Best regards, > Igor Stasenko. >

Aug. 8, 2013

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

by news{＠bestley.co.uk

Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 August 2013 13:35, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Thu, 8 Aug 2013, StÃ©phane Ducasse wrote: > > g the issue on a public tracker means private? > > > > > > How is that a "public tracker"? > > > > can you elaborate? > https://pharo.fogbugz.com/ > is publicly accessible, no? or what makes you think it is not public? > Take the first bug fix from the Pharo Summer release details at <https://pharo.fogbugz.com/f/cases/10014/World-menu-System-Switch-User-s erves-no-purpose> This gives a the fogbugz log in page so to get info you need to login so not public (also are the bugs indexed by google?) -- Mark

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Igor Stasenko

On 8 August 2013 15:40, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and > that consequently the Pharo VM as compiled won't run on any Linux distro > older than 17 months? > You are not forced to use latest VM, you can always download and use 5-year old VM, which will (hopefully) work for you. :) Now if platform (linux) moves, we must follow. And that is not a question to me. -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Laszlo Zsolt Kiss

I wrote about just the latest Pharo VM.The stable Â version of Pharo VM is working well on the Debian 7. ----- Original Message ----- From: andres.valloud(a)gmail.com "Pharo Development List" To:"Pharo Development List" Cc: Sent:Thu, 08 Aug 2013 06:40:37 -0700 Subject:Re: [Pharo-dev] Pharo VM latest on the Debian 7 Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and that consequently the Pharo VM as compiled won't run on any Linux distro older than 17 months? On 8/8/13 5:52 , Igor Stasenko wrote: > Yes. It is known issue. > Now there's little we can do, except from building VM for debian > platform separately. > > On 8 August 2013 11:43, Laszlo Zsolt Kiss wrote: >> 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.so6: 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 Henrik Johansen

On Aug 8, 2013, at 3:03 , Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> I guess that solves the question around the fate of the cog issue tracker: I >> didn't mean a deprecation or similar, people can continue using it as they >> want. I put for that links so people can go back and forth between the issue >> trackers. My unique and good intention was to make those issues more >> visible. > > Thanks, Guillermo. > I think everyone understands that your intention was for good, but > when you don't inform > people properly they tend to think worst (including me) > > :) > > -- > Best regards, > Igor Stasenko. > Especially when you end up spamming VM-dev with Cog issue tracker updates saying "Moved to fogbugz". Even with the modified updates, why you'd need to mirror an existing tracker for a related but distinct project into the Pharo tracker, with the synchronization issues that might cause, js still a bit beyond me. Cheers, Henry

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Andres Valloud

Are you saying the Pharo VM requires glibc version 2.15 of March 2012, and that consequently the Pharo VM as compiled won't run on any Linux distro older than 17 months? On 8/8/13 5:52 , Igor Stasenko wrote: > Yes. It is known issue. > Now there's little we can do, except from building VM for debian > platform separately. > > On 8 August 2013 11:43, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> wrote: >> 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 13:35, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, StÃ©phane Ducasse 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? > > > How is that a "public tracker"? > can you elaborate? https://pharo.fogbugz.com/ is publicly accessible, no? or what makes you think it is not public? > > Levente > > >> >>> 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. >>> >> >> > -- Best regards, Igor Stasenko.

Aug. 8, 2013

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

by Igor Stasenko

On 8 August 2013 14:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I guess that solves the question around the fate of the cog issue tracker: I > didn't mean a deprecation or similar, people can continue using it as they > want. I put for that links so people can go back and forth between the issue > trackers. My unique and good intention was to make those issues more > visible. Thanks, Guillermo. I think everyone understands that your intention was for good, but when you don't inform people properly they tend to think worst (including me) :) -- Best regards, Igor Stasenko.

Aug. 8, 2013

Re: [Pharo-dev] Pharo VM latest on the Debian 7

by Igor Stasenko

Yes. It is known issue. Now there's little we can do, except from building VM for debian platform separately. On 8 August 2013 11:43, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> wrote: > 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 > > -- Best regards, Igor Stasenko.

Aug. 8, 2013

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

by Guillermo Polito

I sent this mail to the vm mailing list: "I mirrored the issues from the cog issue tracker inside the pharo one, so they have more visibility for people only working the pharo issue tracker. Issues in both trackers have a link pointing to its pair, in case someone wants to do the follow up. In any case, my idea was to enhance visibility and use one tool for all issues, not to deprecate either issue tracker. In the meanwhile I saw there are many issues that are probably already integrated, others that probably deserve to have a look and integrate them :). And of course, I realized that I the issue tracker spammed seriously this list. I apologize for that! Best, Guille" I guess that solves the question around the fate of the cog issue tracker: I didn't mean a deprecation or similar, people can continue using it as they want. I put for that links so people can go back and forth between the issue trackers. My unique and good intention was to make those issues more visible. On Thu, Aug 8, 2013 at 1:35 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Aug 2013, StÃ©phane Ducasse 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? >> > > How is that a "public tracker"? > > > Levente > > > >> 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

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

by Levente Uzonyi

On Thu, 8 Aug 2013, StÃ©phane Ducasse 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? How is that a "public tracker"? Levente > >> 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

[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

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

by StÃ©phane Ducasse

>> >> > > 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

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

by Igor Stasenko

On 7 August 2013 19:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 6:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 >>> >>> They are under the Pharo-VM project. >>> >>> That way we can handle them easily. >>> >> >> I don't like this move. > > why > > having everything in a single place is good. > 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. -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fwd: Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > now can we get a working keyboard? Yes here Hi, Guille built a new vm with an attept of fixing the key combinations problem. Can you test it? http://files.pharo.org/vm/pharo/ (and pick the latest for your platform) Thanks, Esteban > > On Wednesday, August 7, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Agree with everything you said. > > As i said, my impression was that Guille pushed unfininowshed/incomplete pieces. > > And that is what i against. > > Because if we go that way, then someone will start pushing changes > > which even don't compile. > > > > I hope i made my point clear, what blessed means. It is not synonym > > to 'stable'. > > > > > > On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). > >> Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). > >> > >> VM development is not stable right now, same way it is not stable 3.0 > >> Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). > >> Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. > >> But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. > >> > >> So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. > >> > >> Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. > >> For that, what we should have is: > >> - all sources in just one repository, including vmmaker (I'm working on that) > >> - create a tag (that we can branch and backport stuff) each release. > >> > >> no need to stress about :) > >> > >> my 2c > >> > >> Esteban > >> > >> > >> On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >>> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >>>> > >>>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>>>> > >>>>> My understanding how it should be: > >>>>> - you work in own branch (and in git, repository clone is already a > >>>>> branch, just on your computer). > >>>>> If you want to make it public you need to make own branch on gitorious > >>>>> and commit there. > >>>>> - once you finished with changes and tested it , you are free to merge > >>>>> with blessed > >>>>> (no need to have GODs permission to do that, or make pull requests) > >>>> > >>>> > >>>> We did all that. We tested it with Ben because he needed the change to send > >>>> ctrl events from the vm to the image, which were not sent. We tested in our > >>>> computers, and we had no much trouble. > >>>> > >>>> - I do not use delete key because I don't have one > >>>> - circumflex accent (return) was working with my keyboard layout > >>>> > >>>> So the vm was to me in a completely usable state. > >>>> > >>>>> > >>>>> > >>>>> now i understand we are humans and not immune to mistakes, but i > >>>>> insist that committing to blessed > >>>> > >>>> > >>>> 'blessed' is a crappy name for a repository. And the idea that the code in > >>>> this repository is always working flawlessly is nonsense. For example, we > >>>> had for months the problem with the smallinteger in there. > >>>> > >>>> And then, the unstable is in another repository then? Where is that > >>>> repository? Why do we have to make another repository for that and not just > >>>> a branch (in the same repo, not in my machine)? > >>>> > >>> > >>> so what you proposing? lets everyone put own unfinished changes into > >>> same repository > >>> without synchronization and see how it flies? > >>> it won't fly, i can tell you even without trying. > >>> > >>>>> > >>>>> should be done after some manual testing and checking it don't breaks > >>>>> things badly, and of course > >>>>> blessed is not for committing the unfinished code , which in the > >>>>> middle of work. > >>>> > >>>> > >>>> First, we considered it as finished. What you found was a bug, not a pending > >>>> to do task. > >>>> > >>> > >>> Ah, in that case it is perfectly ok then. > >>> It is your messages in previous mails gave me impression that > > -- > --- > 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 > > >

Aug. 7, 2013

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

by StÃ©phane Ducasse

On Aug 7, 2013, at 6:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 >> >> They are under the Pharo-VM project. >> >> That way we can handle them easily. >> > > I don't like this move. why having everything in a single place is good. > If moving issues from one > tracker to another would help fixing them in some magical way, i would > be doing this every day. > > > >> Guille > > > -- > Best regards, > Igor Stasenko. >

Aug. 7, 2013

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

by Igor Stasenko

On 7 August 2013 17:56, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 > > They are under the Pharo-VM project. > > That way we can handle them easily. > I don't like this move. If moving issues from one tracker to another would help fixing them in some magical way, i would be doing this every day. > Guille -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fwd: Keyboard events is broken.

by phil＠highoctane.be

now can we get a working keyboard? On Wednesday, August 7, 2013, Igor Stasenko <siguctua(a)gmail.com> wrote: > Agree with everything you said. > As i said, my impression was that Guille pushed unfininowshed/incomplete pieces. > And that is what i against. > Because if we go that way, then someone will start pushing changes > which even don't compile. > > I hope i made my point clear, what blessed means. It is not synonym > to 'stable'. > > > On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). >> Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). >> >> VM development is not stable right now, same way it is not stable 3.0 >> Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). >> Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. >> But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. >> >> So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. >> >> Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. >> For that, what we should have is: >> - all sources in just one repository, including vmmaker (I'm working on that) >> - create a tag (that we can branch and backport stuff) each release. >> >> no need to stress about :) >> >> my 2c >> >> Esteban >> >> >> On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>> My understanding how it should be: >>>>> - you work in own branch (and in git, repository clone is already a >>>>> branch, just on your computer). >>>>> If you want to make it public you need to make own branch on gitorious >>>>> and commit there. >>>>> - once you finished with changes and tested it , you are free to merge >>>>> with blessed >>>>> (no need to have GODs permission to do that, or make pull requests) >>>> >>>> >>>> We did all that. We tested it with Ben because he needed the change to send >>>> ctrl events from the vm to the image, which were not sent. We tested in our >>>> computers, and we had no much trouble. >>>> >>>> - I do not use delete key because I don't have one >>>> - circumflex accent (return) was working with my keyboard layout >>>> >>>> So the vm was to me in a completely usable state. >>>> >>>>> >>>>> >>>>> now i understand we are humans and not immune to mistakes, but i >>>>> insist that committing to blessed >>>> >>>> >>>> 'blessed' is a crappy name for a repository. And the idea that the code in >>>> this repository is always working flawlessly is nonsense. For example, we >>>> had for months the problem with the smallinteger in there. >>>> >>>> And then, the unstable is in another repository then? Where is that >>>> repository? Why do we have to make another repository for that and not just >>>> a branch (in the same repo, not in my machine)? >>>> >>> >>> so what you proposing? lets everyone put own unfinished changes into >>> same repository >>> without synchronization and see how it flies? >>> it won't fly, i can tell you even without trying. >>> >>>>> >>>>> should be done after some manual testing and checking it don't breaks >>>>> things badly, and of course >>>>> blessed is not for committing the unfinished code , which in the >>>>> middle of work. >>>> >>>> >>>> First, we considered it as finished. What you found was a bug, not a pending >>>> to do task. >>>> >>> >>> Ah, in that case it is perfectly ok then. >>> It is your messages in previous mails gave me impression that -- --- 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

Aug. 7, 2013

Put issues from cog issue tracker into pharo issue tracker

by Guillermo Polito

https://pharo.fogbugz.com/default.asp?pre=preSaveFilterProject&ixProject=6 They are under the Pharo-VM project. That way we can handle them easily. Guille

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

Agree with everything you said. As i said, my impression was that Guille pushed unfinished/incomplete pieces. And that is what i against. Because if we go that way, then someone will start pushing changes which even don't compile. I hope i made my point clear, what blessed means. It is not synonym to 'stable'. On 7 August 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). > Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). > > VM development is not stable right now, same way it is not stable 3.0 > Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). > Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. > But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. > > So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. > > Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. > For that, what we should have is: > - all sources in just one repository, including vmmaker (I'm working on that) > - create a tag (that we can branch and backport stuff) each release. > > no need to stress about :) > > my 2c > > Esteban > > > On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> My understanding how it should be: >>>> - you work in own branch (and in git, repository clone is already a >>>> branch, just on your computer). >>>> If you want to make it public you need to make own branch on gitorious >>>> and commit there. >>>> - once you finished with changes and tested it , you are free to merge >>>> with blessed >>>> (no need to have GODs permission to do that, or make pull requests) >>> >>> >>> We did all that. We tested it with Ben because he needed the change to send >>> ctrl events from the vm to the image, which were not sent. We tested in our >>> computers, and we had no much trouble. >>> >>> - I do not use delete key because I don't have one >>> - circumflex accent (return) was working with my keyboard layout >>> >>> So the vm was to me in a completely usable state. >>> >>>> >>>> >>>> now i understand we are humans and not immune to mistakes, but i >>>> insist that committing to blessed >>> >>> >>> 'blessed' is a crappy name for a repository. And the idea that the code in >>> this repository is always working flawlessly is nonsense. For example, we >>> had for months the problem with the smallinteger in there. >>> >>> And then, the unstable is in another repository then? Where is that >>> repository? Why do we have to make another repository for that and not just >>> a branch (in the same repo, not in my machine)? >>> >> >> so what you proposing? lets everyone put own unfinished changes into >> same repository >> without synchronization and see how it flies? >> it won't fly, i can tell you even without trying. >> >>>> >>>> should be done after some manual testing and checking it don't breaks >>>> things badly, and of course >>>> blessed is not for committing the unfinished code , which in the >>>> middle of work. >>> >>> >>> First, we considered it as finished. What you found was a bug, not a pending >>> to do task. >>> >> >> Ah, in that case it is perfectly ok then. >> It is your messages in previous mails gave me impression that it is >> 'not done yet' >> but 'work in progress' and change is not finished. >> >>> Second, I have not the time to change to and learn every keyboard layout to >>> test, nor to plug every external keyboard and see how it behaves. So if you >>> think we should have done that, it will never be finished, and we will die >>> with what we have. >>> >>> Third, we need an unstable official branch for the pharo vm code for people >>> to test. To me, as blessed is the only repository out there, it is the only >>> place where I can put it. >>> >> >> It is blessed in terms that every change you pushing there is blessed >> by you (as developer), >> which means "i recommend to use new version by others". >> And until you can bless your own changes you should not push them into >> this repository, >> while obviously you free to push/commit them elsewhere. >> >>>> >>>> >>>> That is my only issue , that you committed code which is not yet >>>> finished, and makes VM unusable, >>> >>> >>> Now again. To me the latest vm was completely usable. How can I prove that >>> the change is then finished if I do not test with every existing device and >>> layout? >>> >>> So people has to test it. And let's be realistic: given the few people using >>> nowadays the latest pharo vm, if I put my code in my own personal >>> repository, how many people will download my experimental VM to test it from >>> my hidden branch in my hidden and personal repo? I guess almost none. >>> >>> No one tests => never proved => never finished => never merged => dies >>> >> Agreed. >> >>> That does not work. >>> >>> So if bleesed is the stable branch, which is the latest unstable branch? Do >>> we need many repositories for that? >>> >> >> it is not stable branch, it is development. >> stable versions come time to time, we can tag them as stable. >> >>>> and we cannot release VM with important fix to smallinteger bug before >>>> you finish, which turns yourself >>>> into a bottleneck. >>> >>> >>> You can always go to the vm log >>> >>> https://gitorious.org/cogvm/blessed/commits/master >>> >>> and check my last commits and try to rollback them in any case. This change >>> was only two lines of code. I'm of course not the code owner. >>> >>> >>> Now, I'm tired to argue. I want to solve this by stating: >>> - how do we get the latest unstable and where should the code be >>> - how do we get the latest stable and where should the code be >>> >>> Something else is that I have the feeling that we are discussing because of >>> the stupid "blessed" name. So I did this: >>> - create a new pharovm repo inside https://gitorious.org/cogvm, the old >>> blessed repo stays the same >>> - I copied everything from the repo blessed to pharovm, including history >>> - I created a blessed branch, which should in the future have the properties >>> you like <=> latest stable >>> - let master for latest bleedingEdge (not experimental, but maybe buggy) >>> >>> And then if we want other branches we create them. >>> >>> https://gitorious.org/cogvm/pharovm >> >> just one question: why adding 'blessed' branch if you think it is stupid? >> name it stable then, since you don't understand/value of blessing or >> consider it is stupid >> and unnecessary. >> but again, we don't need 'stable' as separate branch.. makes little sense, >> since we can just tag certain versions as stable, like everyone else does. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Please test: New PharoVM built

by Igor Stasenko

me too. On 7 August 2013 13:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks I will try it now. > > Stef > On Aug 7, 2013, at 1:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> Guille built a new vm with an attept of fixing the key combinations problem. >> Can you test it? >> >> http://files.pharo.org/vm/pharo/ >> >> (and pick the latest for your platform) >> >> Thanks, >> Esteban >> >> > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

IMO is no point on ask for keeping an "all-time-stable" VM in the development process (it is even a contradiction). Is the same as asking for a 3.0 stable before release (yes, is the same... we are trying to have same process for both). VM development is not stable right now, same way it is not stable 3.0 Want stable stuff? you need to take the stable VM and Pharo 2.0 (even with the bugs we all know). Ok, we (the pharo developers community) cannot do that, we need to work on the bleeding edge and because of that, some times we get uncomfortable situations. But then we all know how hard is to have a functionality working properly and well tested. Our only way to do that is to put it in the development trunk and ask for feedback. So... yes, I'm sorry it annoys some time to time, but latest-VM will have periods in which it doesn't work as expected... is the only way this small community can advance: Developers introduce a functionality, community tests and provide feedback, then loop. Now, what we should have is a better way of mark stuff.. so we can backport stuff et all. For that, what we should have is: - all sources in just one repository, including vmmaker (I'm working on that) - create a tag (that we can branch and backport stuff) each release. no need to stress about :) my 2c Esteban On Aug 7, 2013, at 4:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> My understanding how it should be: >>> - you work in own branch (and in git, repository clone is already a >>> branch, just on your computer). >>> If you want to make it public you need to make own branch on gitorious >>> and commit there. >>> - once you finished with changes and tested it , you are free to merge >>> with blessed >>> (no need to have GODs permission to do that, or make pull requests) >> >> >> We did all that. We tested it with Ben because he needed the change to send >> ctrl events from the vm to the image, which were not sent. We tested in our >> computers, and we had no much trouble. >> >> - I do not use delete key because I don't have one >> - circumflex accent (return) was working with my keyboard layout >> >> So the vm was to me in a completely usable state. >> >>> >>> >>> now i understand we are humans and not immune to mistakes, but i >>> insist that committing to blessed >> >> >> 'blessed' is a crappy name for a repository. And the idea that the code in >> this repository is always working flawlessly is nonsense. For example, we >> had for months the problem with the smallinteger in there. >> >> And then, the unstable is in another repository then? Where is that >> repository? Why do we have to make another repository for that and not just >> a branch (in the same repo, not in my machine)? >> > > so what you proposing? lets everyone put own unfinished changes into > same repository > without synchronization and see how it flies? > it won't fly, i can tell you even without trying. > >>> >>> should be done after some manual testing and checking it don't breaks >>> things badly, and of course >>> blessed is not for committing the unfinished code , which in the >>> middle of work. >> >> >> First, we considered it as finished. What you found was a bug, not a pending >> to do task. >> > > Ah, in that case it is perfectly ok then. > It is your messages in previous mails gave me impression that it is > 'not done yet' > but 'work in progress' and change is not finished. > >> Second, I have not the time to change to and learn every keyboard layout to >> test, nor to plug every external keyboard and see how it behaves. So if you >> think we should have done that, it will never be finished, and we will die >> with what we have. >> >> Third, we need an unstable official branch for the pharo vm code for people >> to test. To me, as blessed is the only repository out there, it is the only >> place where I can put it. >> > > It is blessed in terms that every change you pushing there is blessed > by you (as developer), > which means "i recommend to use new version by others". > And until you can bless your own changes you should not push them into > this repository, > while obviously you free to push/commit them elsewhere. > >>> >>> >>> That is my only issue , that you committed code which is not yet >>> finished, and makes VM unusable, >> >> >> Now again. To me the latest vm was completely usable. How can I prove that >> the change is then finished if I do not test with every existing device and >> layout? >> >> So people has to test it. And let's be realistic: given the few people using >> nowadays the latest pharo vm, if I put my code in my own personal >> repository, how many people will download my experimental VM to test it from >> my hidden branch in my hidden and personal repo? I guess almost none. >> >> No one tests => never proved => never finished => never merged => dies >> > Agreed. > >> That does not work. >> >> So if bleesed is the stable branch, which is the latest unstable branch? Do >> we need many repositories for that? >> > > it is not stable branch, it is development. > stable versions come time to time, we can tag them as stable. > >>> and we cannot release VM with important fix to smallinteger bug before >>> you finish, which turns yourself >>> into a bottleneck. >> >> >> You can always go to the vm log >> >> https://gitorious.org/cogvm/blessed/commits/master >> >> and check my last commits and try to rollback them in any case. This change >> was only two lines of code. I'm of course not the code owner. >> >> >> Now, I'm tired to argue. I want to solve this by stating: >> - how do we get the latest unstable and where should the code be >> - how do we get the latest stable and where should the code be >> >> Something else is that I have the feeling that we are discussing because of >> the stupid "blessed" name. So I did this: >> - create a new pharovm repo inside https://gitorious.org/cogvm, the old >> blessed repo stays the same >> - I copied everything from the repo blessed to pharovm, including history >> - I created a blessed branch, which should in the future have the properties >> you like <=> latest stable >> - let master for latest bleedingEdge (not experimental, but maybe buggy) >> >> And then if we want other branches we create them. >> >> https://gitorious.org/cogvm/pharovm > > just one question: why adding 'blessed' branch if you think it is stupid? > name it stable then, since you don't understand/value of blessing or > consider it is stupid > and unnecessary. > but again, we don't need 'stable' as separate branch.. makes little sense, > since we can just tag certain versions as stable, like everyone else does. > > > -- > Best regards, > Igor Stasenko. >

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> My understanding how it should be: >> - you work in own branch (and in git, repository clone is already a >> branch, just on your computer). >> If you want to make it public you need to make own branch on gitorious >> and commit there. >> - once you finished with changes and tested it , you are free to merge >> with blessed >> (no need to have GODs permission to do that, or make pull requests) > > > We did all that. We tested it with Ben because he needed the change to send > ctrl events from the vm to the image, which were not sent. We tested in our > computers, and we had no much trouble. > > - I do not use delete key because I don't have one > - circumflex accent (return) was working with my keyboard layout > > So the vm was to me in a completely usable state. > >> >> >> now i understand we are humans and not immune to mistakes, but i >> insist that committing to blessed > > > 'blessed' is a crappy name for a repository. And the idea that the code in > this repository is always working flawlessly is nonsense. For example, we > had for months the problem with the smallinteger in there. > > And then, the unstable is in another repository then? Where is that > repository? Why do we have to make another repository for that and not just > a branch (in the same repo, not in my machine)? > so what you proposing? lets everyone put own unfinished changes into same repository without synchronization and see how it flies? it won't fly, i can tell you even without trying. >> >> should be done after some manual testing and checking it don't breaks >> things badly, and of course >> blessed is not for committing the unfinished code , which in the >> middle of work. > > > First, we considered it as finished. What you found was a bug, not a pending > to do task. > Ah, in that case it is perfectly ok then. It is your messages in previous mails gave me impression that it is 'not done yet' but 'work in progress' and change is not finished. > Second, I have not the time to change to and learn every keyboard layout to > test, nor to plug every external keyboard and see how it behaves. So if you > think we should have done that, it will never be finished, and we will die > with what we have. > > Third, we need an unstable official branch for the pharo vm code for people > to test. To me, as blessed is the only repository out there, it is the only > place where I can put it. > It is blessed in terms that every change you pushing there is blessed by you (as developer), which means "i recommend to use new version by others". And until you can bless your own changes you should not push them into this repository, while obviously you free to push/commit them elsewhere. >> >> >> That is my only issue , that you committed code which is not yet >> finished, and makes VM unusable, > > > Now again. To me the latest vm was completely usable. How can I prove that > the change is then finished if I do not test with every existing device and > layout? > > So people has to test it. And let's be realistic: given the few people using > nowadays the latest pharo vm, if I put my code in my own personal > repository, how many people will download my experimental VM to test it from > my hidden branch in my hidden and personal repo? I guess almost none. > > No one tests => never proved => never finished => never merged => dies > Agreed. > That does not work. > > So if bleesed is the stable branch, which is the latest unstable branch? Do > we need many repositories for that? > it is not stable branch, it is development. stable versions come time to time, we can tag them as stable. >> and we cannot release VM with important fix to smallinteger bug before >> you finish, which turns yourself >> into a bottleneck. > > > You can always go to the vm log > > https://gitorious.org/cogvm/blessed/commits/master > > and check my last commits and try to rollback them in any case. This change > was only two lines of code. I'm of course not the code owner. > > > Now, I'm tired to argue. I want to solve this by stating: > - how do we get the latest unstable and where should the code be > - how do we get the latest stable and where should the code be > > Something else is that I have the feeling that we are discussing because of > the stupid "blessed" name. So I did this: > - create a new pharovm repo inside https://gitorious.org/cogvm, the old > blessed repo stays the same > - I copied everything from the repo blessed to pharovm, including history > - I created a blessed branch, which should in the future have the properties > you like <=> latest stable > - let master for latest bleedingEdge (not experimental, but maybe buggy) > > And then if we want other branches we create them. > > https://gitorious.org/cogvm/pharovm just one question: why adding 'blessed' branch if you think it is stupid? name it stable then, since you don't understand/value of blessing or consider it is stupid and unnecessary. but again, we don't need 'stable' as separate branch.. makes little sense, since we can just tag certain versions as stable, like everyone else does. -- Best regards, Igor Stasenko.

Aug. 7, 2013

becomeCompactSimplyAt: and Integer class>>initialize

by Martin Dias

Hi 1) I'm working on an issue related to compact classes index and I discovered that behaviours implement #becomeCompactSimplyAt:, which has this comment: "Make me compact, but don't update the instances. *For importing segments* ." This made me think that it's no longer needed in the image since we removed ImageSegment. In other hand, I don't know why sender might decide if the instances of the class must be updated or not... do you? 2) The only users in Pharo 3 are in: Integer class >> initialize "Integer initialize" "Ensure we have the right compact class index" "LPI has been a compact class forever - just ensure basic correctness" (LargePositiveInteger indexIfCompact = 5) ifFalse:[ (Smalltalk compactClassesArray at: 5) ifNil:[LargePositiveInteger becomeCompactSimplyAt: 5] ifNotNil:[self error: 'Unexpected compact class setup']]. (LargeNegativeInteger indexIfCompact = 4) ifFalse:[ (Smalltalk compactClassesArray at: 4) ifNil:[LargeNegativeInteger becomeCompactSimplyAt: 4] ifNotNil:[self error: 'Unexpected compact class setup']]. Now, looking for other users of #indexIfCompact, I see that here is the only place in the image where compact indexes are checked/fixed. 3) I wonder if we should remove both #becomeCompactSimplyAt: and Integer class>>initialize. Thank you in advance. MartÃn

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Guillermo Polito

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > My understanding how it should be: > - you work in own branch (and in git, repository clone is already a > branch, just on your computer). > If you want to make it public you need to make own branch on gitorious > and commit there. > - once you finished with changes and tested it , you are free to merge > with blessed > (no need to have GODs permission to do that, or make pull requests) > We did all that. We tested it with Ben because he needed the change to send ctrl events from the vm to the image, which were not sent. We tested in our computers, and we had no much trouble. - I do not use delete key because I don't have one - circumflex accent (return) was working with my keyboard layout So the vm was to me in a completely usable state. > > now i understand we are humans and not immune to mistakes, but i > insist that committing to blessed > 'blessed' is a crappy name for a repository. And the idea that the code in this repository is always working flawlessly is nonsense. For example, we had for months the problem with the smallinteger in there. And then, the unstable is in another repository then? Where is that repository? Why do we have to make another repository for that and not just a branch (in the same repo, not in my machine)? > should be done after some manual testing and checking it don't breaks > things badly, and of course > blessed is not for committing the unfinished code , which in the > middle of work. > First, we considered it as finished. What you found was a bug, not a pending to do task. Second, I have not the time to change to and learn every keyboard layout to test, nor to plug every external keyboard and see how it behaves. So if you think we should have done that, it will never be finished, and we will die with what we have. Third, we need an unstable official branch for the pharo vm code for people to test. To me, as blessed is the only repository out there, it is the only place where I can put it. > > That is my only issue , that you committed code which is not yet > finished, and makes VM unusable, > Now again. To me the latest vm was completely usable. How can I *prove*that the change is then finished if I do not test with every existing device and layout? So people has to test it. And let's be realistic: given the few people using nowadays the latest pharo vm, if I put my code in my own personal repository, how many people will download my *experimental* VM to test it from my hidden branch in my hidden and personal repo? I guess almost none. No one tests => never proved => never finished => never merged => dies That does not work. So if *bleesed* is the stable branch, which is the latest unstable branch? Do we need many repositories for that? and we cannot release VM with important fix to smallinteger bug before > you finish, which turns yourself > into a bottleneck. You can always go to the vm log https://gitorious.org/cogvm/blessed/commits/master and check my last commits and try to rollback them in any case. This change was only two lines of code. I'm of course not the code owner. Now, I'm tired to argue. I want to solve this by stating: - how do we get the latest *unstable* and where should the code be - how do we get the latest *stable* and where should the code be Something else is that I have the feeling that we are discussing because of the stupid "blessed" name. So I did this: - create a new pharovm repo inside https://gitorious.org/cogvm, the old blessed repo stays the same - I copied everything from the repo blessed to pharovm, including history - I created a blessed branch, which should in the future have the properties you like <=> latest stable - let master for latest bleedingEdge (not experimental, but maybe buggy) And then if we want other branches we create them. https://gitorious.org/cogvm/pharovm > -- > Best regards, > Igor Stasenko. > >

Aug. 7, 2013

Re: [Pharo-dev] Fix in Athens-Cairo

by Igor Stasenko

Just to make it clear: when you get zero-divide error, where you think the bug is , in #/ method, or maybe in code which passed zero as divisor? by analogy, when you want to draw an arc with zero length, which makes it non-arc, where you think the bug is, in code which implements drawing an arc or in code which provides wrong input? because this change actually hiding the mistakes, so instead of getting error and fixing it, user now will have hard times figuring out, why it not draws things as intended and where his mistake is. -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

My understanding how it should be: - you work in own branch (and in git, repository clone is already a branch, just on your computer). If you want to make it public you need to make own branch on gitorious and commit there. - once you finished with changes and tested it , you are free to merge with blessed (no need to have GODs permission to do that, or make pull requests) now i understand we are humans and not immune to mistakes, but i insist that committing to blessed should be done after some manual testing and checking it don't breaks things badly, and of course blessed is not for committing the unfinished code , which in the middle of work. That is my only issue , that you committed code which is not yet finished, and makes VM unusable, and we cannot release VM with important fix to smallinteger bug before you finish, which turns yourself into a bottleneck. -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] NB and OS specific tests

by Igor Stasenko

I agree, except that as far as i know there is no platform-specific tests yet. On 7 August 2013 09:49, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Igor, > > NB includes OS specific classes and examples that will/may require OS specific tests. > > IMHO it would make sense to change "NativeBoost-Tests" category into > > - "NativeBoost-Tests-Core" > - "NativeBoost-Tests-Mac" > - "NativeBoost-Tests-Unix" > - "NativeBoost-Tests-Win32" > > while still keeping "NativeBoost-Tests" as one package. Later the package can be > split easily (but only if necessary). > > So we have categories for the NB Core tests and OS specific tests similar to the other > packages/categories. > > I would further provide common superclasses for OS specific tests, for instance > > TestCase subclass: #NBWin32SpecificTest > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'NativeBoost-Tests-Win32' > > and similar NBUnixSpecificTest and NBMacSpecificTest also. > > By overriding their #isAbstract method we can make their hierarchy only be runnable on > the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, > Unix tests will not run on Mac, etc. > > Therefore we can control that the tests only run on the OS platform and find > out when things fail. > > What do you think? I can do it when there is another minute. > > Thx > Torsten -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fix in Athens-Cairo

by Igor Stasenko

On 7 August 2013 10:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Igor, > > I think have I found a bug when circle are drawn. > > I have added "(start = end) ifTrue: [ ^ self ]." in this method: > your change just makes it fool-proof. The bug is in user code which specifies wrong data (drawing arc with two coinciding points?) Anyways, i added it. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > AthensCairoPathBuilder>>arcTo: newEndPoint angle: angle cw: aBool > > " Add a clockwise arc segment, starting from current path endpoint and > ending at andPt. Angle should be specified in radians > " > > | start end center v radius startAngle endAngle cwAngle | > > angle isZero ifTrue: [ ^ self lineTo: newEndPoint ]. > > start := endPoint. > endPoint := end := self toAbsolute: newEndPoint. > > "we have to transform the input. because Cario expects > the center , radius, starting and ending angle, > and we have the starting point, the ending point , and the angle. > " > aBool ifTrue: [cwAngle := angle] ifFalse: [cwAngle := angle negated]. > > "Do nothing if the two points are the same" > (start = end) ifTrue: [ ^ self ]. > center := self calcCenter: start end: end angle: cwAngle. > v := (start - center). > radius := v r. > startAngle := self angleOfVector: v. > endAngle := self angleOfVector: (end-center). > aBool ifTrue: [ self arcCenterX: center x centerY: center y radius: radius startAngle: startAngle endAngle: endAngle ] > ifFalse: [ self arcNegativeCenterX: center x centerY: center y radius: radius startAngle: startAngle endAngle: endAngle ] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > I have attached a new version of the package. It simply defines this new method. > It would be great to have a solution in case the start and end points are the same. > > Cheers, > Alexandre > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Please test: New PharoVM built

by StÃ©phane Ducasse

thanks I will try it now. Stef On Aug 7, 2013, at 1:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Guille built a new vm with an attept of fixing the key combinations problem. > Can you test it? > > http://files.pharo.org/vm/pharo/ > > (and pick the latest for your platform) > > Thanks, > Esteban > >

Aug. 7, 2013

Please test: New PharoVM built

by Esteban Lorenzano

Hi, Guille built a new vm with an attept of fixing the key combinations problem. Can you test it? http://files.pharo.org/vm/pharo/ (and pick the latest for your platform) Thanks, Esteban

Aug. 7, 2013

Re: [Pharo-dev] NB and OS specific tests

by StÃ©phane Ducasse

Tx, I did the same except that when I want to integrate the package and I reload it I get this error. Now hypothesis one: - may be this is the verify logic that is not good, because I reload all the packages without order so may be we are in the case where a package is loaded before another one. I will check with igor. > Hi Stef, > > #nbBindingOf: is an extension on Behavior from the NativeBoost Core package. > I tried and it works: > > - using Pharo2.0 Latest update: #20603 > - adding http://smalltalkhub.com/#!/~Pharo/NativeBoost > - loading latest version of Core, Examples, Pools, Mac, Unix, Win32, Tests > > All NB tests pass. > > Thx > T. >

Aug. 7, 2013