September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Git support for windows

by Stephane Ducasse

So if you follow eliot suggestion methodDeclaration [ methodbody ] put the start in another line. because with methodDeclaration [ methodbody ] we do not identify the body as a rectangle I do not think that [ on the first line is a good idea. Remember that people will send code in email and that one day one guy (me) will extend the code browser and change my books. Stef On Mon, Sep 11, 2017 at 7:25 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes and this is not really good for method with multiple and long > selectors because you have to spot the end of the line > > Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ > "Allow the user to supply a point to serve as an arrowhead size. > Answer nil if we fail to get a good point" > | result | > result := UIManager default request: aPrompt initialAnswer: > defaultPoint asString. > result isEmptyOrNil ifTrue: [^ nil]. > ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] > > vs. > > Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint > [ > "Allow the user to supply a point to serve as an arrowhead size. > Answer nil if we fail to get a good point" > | result | > result := UIManager default request: aPrompt initialAnswer: > defaultPoint asString. > result isEmptyOrNil ifTrue: [^ nil]. > ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. > ] > > > On Sun, Sep 10, 2017 at 6:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> hehâ¦ the format I propose is like this: >> >> methodDeclaration [ >> methodbody >> ] >> >> I think that keeps good readability and I can parse it easily. >> >>> On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi esteban >>> for me having space around [ ] improves readibility. >>> I preferred >>> >>> methodDeclaration >>> [ >>> methodbody >>> ] >>> >>> over >>> >>> methodDeclaration >>> [ methodbody ] >>> >>> Especially in case of method body is blockish like while true/exception. >>> >>> But this is ok if people prefer >>> >>> methodDeclaration >>> [ methodbody ] >>> >>> >>> Now I do not like >>> >>> methodDeclaration [ >>> methodbody ] >>> >>> Stef >>> >>> On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> Point class >> x: anInt1 y: anInt2 >>>> [ >>>> ^ self new setX: anInt1 Y: anInt2] >>>> >>>> because trailing white space will only accumulate, something I see in Pharo >>>> and Squeak code. >>>> >>>> Alternatively have the output add white space if required and the input >>>> remove any and all trailing white space. >>>> >>>> >>>> in fact, Iâm working to remove the extra trailings this format can add. The >>>> idea is that parsed text == original text. Then, originally my format was >>>> >>>> methodDeclaration [ >>>> methodBody >>>> ] >>>> >>>> but now Iâm digging also into >>>> >>>> methodDeclaration [ >>>> methodBody ] >>>> >>>> (always keeping the identity of sources idea) >>>> >>>> cheers! >>>> Esteban >>>> >>> >> >>

Sept. 11, 2017

Re: [Pharo-dev] About Git support for windows

by Stephane Ducasse

Yes and this is not really good for method with multiple and long selectors because you have to spot the end of the line Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] On Sun, Sep 10, 2017 at 6:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hehâ¦ the format I propose is like this: > > methodDeclaration [ > methodbody > ] > > I think that keeps good readability and I can parse it easily. > >> On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi esteban >> for me having space around [ ] improves readibility. >> I preferred >> >> methodDeclaration >> [ >> methodbody >> ] >> >> over >> >> methodDeclaration >> [ methodbody ] >> >> Especially in case of method body is blockish like while true/exception. >> >> But this is ok if people prefer >> >> methodDeclaration >> [ methodbody ] >> >> >> Now I do not like >> >> methodDeclaration [ >> methodbody ] >> >> Stef >> >> On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> >>> Point class >> x: anInt1 y: anInt2 >>> [ >>> ^ self new setX: anInt1 Y: anInt2] >>> >>> because trailing white space will only accumulate, something I see in Pharo >>> and Squeak code. >>> >>> Alternatively have the output add white space if required and the input >>> remove any and all trailing white space. >>> >>> >>> in fact, Iâm working to remove the extra trailings this format can add. The >>> idea is that parsed text == original text. Then, originally my format was >>> >>> methodDeclaration [ >>> methodBody >>> ] >>> >>> but now Iâm digging also into >>> >>> methodDeclaration [ >>> methodBody ] >>> >>> (always keeping the identity of sources idea) >>> >>> cheers! >>> Esteban >>> >> > >

Sept. 11, 2017

Re: [Pharo-dev] argh, tests are failing!

by Stephane Ducasse

Hi torsten >From a process I think that we decided that external packages should be managed like the following: - PR (from people) to change the code in Pharo + issues a PR to Iceberg. - then Iceberg team merge PR + issue a new PR for Pharo integration So I think that this is what you describe too? Like that we do not have deadlock and can always have a stable version. Stef On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > to explain: > > we have lots of uncategorized methods and non commented classes. For some time we had to accept this ugly situation that old and legacy code. For Pharo 4 and 5 > I invested a lot of time to clean this up right before the release date. But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a mess again. > > Why? Because we introduced new features and code and never defined a certain level of quality for code we include. But our initial goal with Pharo was (and > hopefully still is) to cleanup things up and do better than before. > > So we should not forget about quality and so I spend some time last on this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit should be > in "running" as it was defined for TestCase subclasses. Also #hash and #= should be in "comparing" protocol. Also the goal is coming back to an image where > all methods are categorized and where all classes have a comment. > > But for me it absolutely makes no sense to reinvest the time over and over into the same cleanups while others can easily make a mess again. > > So we should RAISE THE QUALITY BAR to ensure that we keep with such a quality level. Especially as see each build to be a release and the real release once > a year often is more or less a snapshot. > > So I also wrote a new test called "ProperMethodCategorizationTest" and while cleaning up #hash it was green. So ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol > showed no problem and I committed and have sent a Pull request. This looked like any other new contribution. > > What I did not knew at this time was that Iceberg code is not in git repository - but managed externally. So while I fixed the code in my image with wrongly categorized hash > method in an Iceberg class (IceSemanticVersion) the system did not show me that this change did not move to GitHub. > > Now I know - but this has such bad side effect when we do changes and these packages are in the image - but not managed with the pharo repository. > > Long story short: one can not fix this situation with a simple PR as Iceberg code is not under the "pharo" repo umbrella. > > I already submitted a PR for Iceberg > > https://github.com/pharo-vcs/iceberg/pull/458 > > and Esteban included that already - but only in Iceberg. We now need to include Iceberg. > > Several lessons learned from my side: > - doing changes and having green tests in the image is not enough > - also doing a commit and PR does not mean all of your changes are on GitHub > - it is not a good situation when a part of the image code is managed with "pharo" repository and another part is managed externally - I see this as a problem of > the new process we should discuss and address > - we should nonetheless try to define tests to show the edges where we can improve and cleanup (without a test it would not have been noticed that while I did my best > to cleanup the current way of managing Iceberg prevented my fix to be into the image in the first place) > > I dont know what need to be done to include a new iceberg version or when this will happen from Estebans side - but as soon as it is done this test should be green again. > > Thanks > T. > > > Gesendet: Sonntag, 10. September 2017 um 18:24 Uhr > Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] argh, tests are failing! > > Yes we know but have no idea how to recategorise Iceberg protocols > > On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]> wrote: > > Of course you are right, the Integrators should really take care on it. > > Before it were only common random failures but the main problem is with this PR: > https://github.com/pharo-project/pharo/pull/264[https://github.com/pharo-pr… > > The new test testHashMethodNeedsToBeInComparingProtocol fails on classIceSemanticVersion > > -- Pavel > > > 2017-09-10 10:13 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com[mailto:guillermopolito@gmail.com]>: > Hi all, > > Since a couple of builds we have consistently failing the following tests: > > > GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testDeliverNow2/]GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testNotDeliveredDataShouldBeResent/]Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/Kernel.Tests.Processes/MutexTest/testFailedCriticalSectionShouldUnblockWaitingOne/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_2/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_3/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_4/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_5/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_6/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_7/] > > > Green builds are the only hard metric to say if the build is healthy or not. > > - We should not integrate anything until the build is green again... > > Also, we spent with Pablo a lot of time to have a green build in all platforms... I'd like to spend my time in other fun stuff than the CI :/ > > -- > > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr[http://www.cnrs.fr] > > > Web: http://guillep.github.io[http://guillep.github.io] > Phone: +33 06 52 70 66 13 >

Sept. 11, 2017

Re: [Pharo-dev] argh, tests are failing!

by Stephane Ducasse

Torsten for the recategorisation can you use the categoriser? Because I improved it a bit and like that we will get the same convention everywhere and not yours and mine differently managed. For example, initialize - release does not exist. In the automaticRecategoriser package I published a while ago (not the one in the image) you can find an analyser for a given selector. It shows the common usage and the outliers. There is also a method to automatically fix outliers and it handles * MCHttpRepository location: 'http://smalltalkhub.com/mc/StephaneDucasse/AutomaticMethodCategorizer/main' user: '' password: '' Tell me what you think. Stef On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > to explain: > > we have lots of uncategorized methods and non commented classes. For some time we had to accept this ugly situation that old and legacy code. For Pharo 4 and 5 > I invested a lot of time to clean this up right before the release date. But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a mess again. > > Why? Because we introduced new features and code and never defined a certain level of quality for code we include. But our initial goal with Pharo was (and > hopefully still is) to cleanup things up and do better than before. > > So we should not forget about quality and so I spend some time last on this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit should be > in "running" as it was defined for TestCase subclasses. Also #hash and #= should be in "comparing" protocol. Also the goal is coming back to an image where > all methods are categorized and where all classes have a comment. > > But for me it absolutely makes no sense to reinvest the time over and over into the same cleanups while others can easily make a mess again. > > So we should RAISE THE QUALITY BAR to ensure that we keep with such a quality level. Especially as see each build to be a release and the real release once > a year often is more or less a snapshot. > > So I also wrote a new test called "ProperMethodCategorizationTest" and while cleaning up #hash it was green. So ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol > showed no problem and I committed and have sent a Pull request. This looked like any other new contribution. > > What I did not knew at this time was that Iceberg code is not in git repository - but managed externally. So while I fixed the code in my image with wrongly categorized hash > method in an Iceberg class (IceSemanticVersion) the system did not show me that this change did not move to GitHub. > > Now I know - but this has such bad side effect when we do changes and these packages are in the image - but not managed with the pharo repository. > > Long story short: one can not fix this situation with a simple PR as Iceberg code is not under the "pharo" repo umbrella. > > I already submitted a PR for Iceberg > > https://github.com/pharo-vcs/iceberg/pull/458 > > and Esteban included that already - but only in Iceberg. We now need to include Iceberg. > > Several lessons learned from my side: > - doing changes and having green tests in the image is not enough > - also doing a commit and PR does not mean all of your changes are on GitHub > - it is not a good situation when a part of the image code is managed with "pharo" repository and another part is managed externally - I see this as a problem of > the new process we should discuss and address > - we should nonetheless try to define tests to show the edges where we can improve and cleanup (without a test it would not have been noticed that while I did my best > to cleanup the current way of managing Iceberg prevented my fix to be into the image in the first place) > > I dont know what need to be done to include a new iceberg version or when this will happen from Estebans side - but as soon as it is done this test should be green again. > > Thanks > T. > > > Gesendet: Sonntag, 10. September 2017 um 18:24 Uhr > Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] argh, tests are failing! > > Yes we know but have no idea how to recategorise Iceberg protocols > > On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]> wrote: > > Of course you are right, the Integrators should really take care on it. > > Before it were only common random failures but the main problem is with this PR: > https://github.com/pharo-project/pharo/pull/264[https://github.com/pharo-pr… > > The new test testHashMethodNeedsToBeInComparingProtocol fails on classIceSemanticVersion > > -- Pavel > > > 2017-09-10 10:13 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com[mailto:guillermopolito@gmail.com]>: > Hi all, > > Since a couple of builds we have consistently failing the following tests: > > > GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testDeliverNow2/]GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testNotDeliveredDataShouldBeResent/]Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/Kernel.Tests.Processes/MutexTest/testFailedCriticalSectionShouldUnblockWaitingOne/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_2/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_3/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_4/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_5/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_6/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_7/] > > > Green builds are the only hard metric to say if the build is healthy or not. > > - We should not integrate anything until the build is green again... > > Also, we spent with Pablo a lot of time to have a green build in all platforms... I'd like to spend my time in other fun stuff than the CI :/ > > -- > > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr[http://www.cnrs.fr] > > > Web: http://guillep.github.io[http://guillep.github.io] > Phone: +33 06 52 70 66 13 >

Sept. 11, 2017

New chapter for coming book: Messages

by Stephane Ducasse

Hi after this crazy esug I took a long bus and I wrote one missing chapter for the forhtcoming bus. I plan to have a first full version for 1 of October :) I reorganised and massively clean the book contents. Comments are welcome in any form. Stef https://github.com/SquareBracketAssociates/LearningOOPWithPharo

Sept. 11, 2017

Re: [Pharo-dev] poor state of fuel

by Norbert Hartl

> Am 10.09.2017 um 15:08 schrieb stephan <stephan(a)stack.nl>: > >> On 10-09-17 09:56, Norbert Hartl wrote: >> Just an update. Martin commited a new package that solves the encoding/decoding of SmallInteger and Character. Together with the patch from nicolas my dumps work again > > That sounds like something to backport to 6.1 > I'll check tomorrow if that also solves my vm crash > It works for 6.1 because that is what I'm using. Norbert > Stephan

Sept. 10, 2017

Re: [Pharo-dev] argh, tests are failing!

by Torsten Bergmann

Hi, to explain: we have lots of uncategorized methods and non commented classes. For some time we had to accept this ugly situation that old and legacy code. For Pharo 4 and 5 I invested a lot of time to clean this up right before the release date. But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a mess again. Why? Because we introduced new features and code and never defined a certain level of quality for code we include. But our initial goal with Pharo was (and hopefully still is) to cleanup things up and do better than before. So we should not forget about quality and so I spend some time last on this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit should be in "running" as it was defined for TestCase subclasses. Also #hash and #= should be in "comparing" protocol. Also the goal is coming back to an image where all methods are categorized and where all classes have a comment. But for me it absolutely makes no sense to reinvest the time over and over into the same cleanups while others can easily make a mess again. So we should RAISE THE QUALITY BAR to ensure that we keep with such a quality level. Especially as see each build to be a release and the real release once a year often is more or less a snapshot. So I also wrote a new test called "ProperMethodCategorizationTest" and while cleaning up #hash it was green. So ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol showed no problem and I committed and have sent a Pull request. This looked like any other new contribution. What I did not knew at this time was that Iceberg code is not in git repository - but managed externally. So while I fixed the code in my image with wrongly categorized hash method in an Iceberg class (IceSemanticVersion) the system did not show me that this change did not move to GitHub. Now I know - but this has such bad side effect when we do changes and these packages are in the image - but not managed with the pharo repository. Long story short: one can not fix this situation with a simple PR as Iceberg code is not under the "pharo" repo umbrella. I already submitted a PR for Iceberg Â https://github.com/pharo-vcs/iceberg/pull/458 and Esteban included that already - but only in Iceberg. We now need to include Iceberg. Several lessons learned from my side: - doing changes and having green tests in the image is not enough - also doing a commit and PR does not mean all of your changes are on GitHub - it is not a good situation when a part of the image code is managed with "pharo" repository and another part is managed externally - I see this as a problem of the new process we should discuss and address - we should nonetheless try to define tests to show the edges where we can improve and cleanup (without a test it would not have been noticed that while I did my best to cleanup the current way of managing Iceberg prevented my fix to be into the image in the first place) I dont know what need to be done to include a new iceberg version or when this will happen from Estebans side - but as soon as it is done this test should be green again. Thanks T. Gesendet:Â Sonntag, 10. September 2017 um 18:24 Uhr Von:Â "Stephane Ducasse" <stepharo.self(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] argh, tests are failing! Yes we know but have no idea how to recategorise Iceberg protocolsÂ Â On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]> wrote: Of course you are right, the Integrators should really take care on it.Â Â Before it were only common random failures but the main problem is with this PR: https://github.com/pharo-project/pharo/pull/264[https://github.com/pharo-pr… Â The new test testHashMethodNeedsToBeInComparingProtocol fails on classIceSemanticVersion Â -- Pavel Â 2017-09-10 10:13 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com[mailto:guillermopolito@gmail.com]>: Hi all, Â Since a couple of builds we have consistently failing the following tests: Â GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testDeliverNow2/]GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testNotDeliveredDataShouldBeResent/]Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/Kernel.Tests.Processes/MutexTest/testFailedCriticalSectionShouldUnblockWaitingOne/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_2/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_3/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_4/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_5/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_6/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_7/] Â Â Green builds are the only hard metric to say if the build is healthy or not. Â - We should not integrate anything until the build is green again... Â Also, we spent with Pablo a lot of time to have a green build in all platforms...Â I'd like to spend my time in other fun stuff than the CI :/ Â -- Â Â Â Guille Polito Â Research Engineer French National Center for Scientific Research - http://www.cnrs.fr[http://www.cnrs.fr] Â Â Web: http://guillep.github.io[http://guillep.github.io] Phone: +33 06 52 70 66 13

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Esteban Lorenzano

hehâ¦ the format I propose is like this: methodDeclaration [ methodbody ] I think that keeps good readability and I can parse it easily. > On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi esteban > for me having space around [ ] improves readibility. > I preferred > > methodDeclaration > [ > methodbody > ] > > over > > methodDeclaration > [ methodbody ] > > Especially in case of method body is blockish like while true/exception. > > But this is ok if people prefer > > methodDeclaration > [ methodbody ] > > > Now I do not like > > methodDeclaration [ > methodbody ] > > Stef > > On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> Point class >> x: anInt1 y: anInt2 >> [ >> ^ self new setX: anInt1 Y: anInt2] >> >> because trailing white space will only accumulate, something I see in Pharo >> and Squeak code. >> >> Alternatively have the output add white space if required and the input >> remove any and all trailing white space. >> >> >> in fact, Iâm working to remove the extra trailings this format can add. The >> idea is that parsed text == original text. Then, originally my format was >> >> methodDeclaration [ >> methodBody >> ] >> >> but now Iâm digging also into >> >> methodDeclaration [ >> methodBody ] >> >> (always keeping the identity of sources idea) >> >> cheers! >> Esteban >> >

Sept. 10, 2017

Re: [Pharo-dev] argh, tests are failing!

by Juraj Kubelka

Hi, I have checked the EventRecorderTests and it works on my computer. The only reason that it might not work on other cases is that there an assert for 'semaphore waitTimeoutMSecs: 200â. I can put higher timeout if necessary. The timeout 200 has worked for couple of years, right?. There might be another issue. Cheers, Juraj > El 10-09-2017, a las 10:13, Guillermo Polito <guillermopolito(a)gmail.com> escribiÃ³: > > Hi all, > > Since a couple of builds we have consistently failing the following tests: > > GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > > Green builds are the only hard metric to say if the build is healthy or not. > > - We should not integrate anything until the build is green again... > > Also, we spent with Pablo a lot of time to have a green build in all platforms... I'd like to spend my time in other fun stuff than the CI :/ > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Sept. 10, 2017

Re: [Pharo-dev] argh, tests are failing!

by Pavel Krivanek

Iceberg management is very different from others. Esteban needs to create a tag for a specific version which is then used in BaselineOfIDE>>#loadIceberg -- Pavel 2017-09-10 18:33 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Ah thanks. > So far I do not know how to integrate external project with the new > process. So I need to learn. > > On Sun, Sep 10, 2017 at 6:26 PM, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com> wrote: > > Le 10/09/2017 Ã 18:24, Stephane Ducasse a Ã©crit : > >> Yes we know but have no idea how to recategorise Iceberg protocols > >> > > > > The protocol is already recategorised in Iceberg dev branch. Now we need > > a new stable release of Iceberg and to integrated this release in Pharo. > > > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > > 59650 Villeneuve d'ascq France > > > >

Sept. 10, 2017