March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Cyril Ferlicot

On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Pablo. > > Dev branch approach not really works. Because any merge into master will > break master baseline. (notice that baseline is in same repo). > And managing merges by hand all the time is not a solution. > > Hi! If you don't want to manage the merges by hand you can maybe have two bsaelines? BaselineOfCalypso and BaselineOfCalypsoDev? -- Cyril Ferlicot https://ferlicot.fr

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

Hi Pablo. Dev branch approach not really works. Because any merge into master will break master baseline. (notice that baseline is in same repo). And managing merges by hand all the time is not a solution. 2018-03-05 15:57 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Yes, I understand for the developer version, you should have a developer > branch and use that. The problem is for the Pharo image only. > > On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> Hi, >> >> it is an issue of Calypso dependencies. I discussed it with Denis >> before Calypso integration and he would like to change it but, for >> now, it would make the development for him much harder because he >> needs a way how to load the latest bleeding edge versions of the >> packages and no one was able to tell him the proper way how to support >> both scenarios (loading of a specific release and loading of the >> development versions) with baselines without needing of duplicate >> them. >> >> Anyway, I agree that the current state must be fixed as soon as possible. >> >> Cheers, >> -- Pavel >> >> 2018-03-05 15:30 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: >> > Hello, >> > i have seen in the latest version of Pharo baselines pointing to >> > "floating" versions. A version that is not fixed. I want to know why >> this is >> > like that? >> > >> > To me this is basically wrong, because basically this goes against the >> idea >> > of having repeatable builds. Also using semantic versions with tags in >> Git >> > is wrong, as tags should be immutable (that is why you have to use >> --force >> > to update them, in Guille's words "If you have to force it, it is not >> > good"). >> > >> > Cheers, >> > >> > -- >> > Pablo Tesone. >> > tesonep(a)gmail.com >> >> > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

March 5, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #652: 21490 Lint cleanup DirectoryEntryTest

by Marcus Denker

> On 5 Mar 2018, at 16:03, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #652 was: FAILURE. > > The Pull Request #1023 was integrated: "21490 Lint cleanup DirectoryEntryTest" > Pull request url: https://github.com/pharo-project/pharo/pull/1023 > > Issue Url: https://pharo.fogbugz.com/f/cases/21490 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… now the ci job and the build fails due to this: Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo-linux-stable.zip unzip: cannot find or open pharo-vm/vm.zip, pharo-vm/vm.zip.zip or pharo-vm/vm.zip.ZIP. maybe the disk is full? Marcus

March 5, 2018

[Pharo 7.0-dev] Build #652: 21490 Lint cleanup DirectoryEntryTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #652 was: FAILURE. The Pull Request #1023 was integrated: "21490 Lint cleanup DirectoryEntryTest" Pull request url: https://github.com/pharo-project/pharo/pull/1023 Issue Url: https://pharo.fogbugz.com/f/cases/21490 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by tesonep＠gmail.com

Yes, I understand for the developer version, you should have a developer branch and use that. The problem is for the Pharo image only. On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > it is an issue of Calypso dependencies. I discussed it with Denis > before Calypso integration and he would like to change it but, for > now, it would make the development for him much harder because he > needs a way how to load the latest bleeding edge versions of the > packages and no one was able to tell him the proper way how to support > both scenarios (loading of a specific release and loading of the > development versions) with baselines without needing of duplicate > them. > > Anyway, I agree that the current state must be fixed as soon as possible. > > Cheers, > -- Pavel > > 2018-03-05 15:30 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > > Hello, > > i have seen in the latest version of Pharo baselines pointing to > > "floating" versions. A version that is not fixed. I want to know why > this is > > like that? > > > > To me this is basically wrong, because basically this goes against the > idea > > of having repeatable builds. Also using semantic versions with tags in > Git > > is wrong, as tags should be immutable (that is why you have to use > --force > > to update them, in Guille's words "If you have to force it, it is not > > good"). > > > > Cheers, > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > > -- Pablo Tesone. tesonep(a)gmail.com

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Pavel Krivanek

Hi, it is an issue of Calypso dependencies. I discussed it with Denis before Calypso integration and he would like to change it but, for now, it would make the development for him much harder because he needs a way how to load the latest bleeding edge versions of the packages and no one was able to tell him the proper way how to support both scenarios (loading of a specific release and loading of the development versions) with baselines without needing of duplicate them. Anyway, I agree that the current state must be fixed as soon as possible. Cheers, -- Pavel 2018-03-05 15:30 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Hello, > i have seen in the latest version of Pharo baselines pointing to > "floating" versions. A version that is not fixed. I want to know why this is > like that? > > To me this is basically wrong, because basically this goes against the idea > of having repeatable builds. Also using semantic versions with tags in Git > is wrong, as tags should be immutable (that is why you have to use --force > to update them, in Guille's words "If you have to force it, it is not > good"). > > Cheers, > > -- > Pablo Tesone. > tesonep(a)gmail.com

March 5, 2018

[Pharo 7.0-dev] Build #651: 21495 Remove unnecessary #test0CopyTest as this is inherited by TCopyTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #651 was: FAILURE. The Pull Request #1026 was integrated: "21495 Remove unnecessary #test0CopyTest as this is inherited by TCopyTest" Pull request url: https://github.com/pharo-project/pharo/pull/1026 Issue Url: https://pharo.fogbugz.com/f/cases/21495 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2018

Released versions in Pharo Bootstrap

by tesonep＠gmail.com

Hello, i have seen in the latest version of Pharo baselines pointing to "floating" versions. A version that is not fixed. I want to know why this is like that? To me this is basically wrong, because basically this goes against the idea of having repeatable builds. Also using semantic versions with tags in Git is wrong, as tags should be immutable (that is why you have to use --force to update them, in Guille's words "If you have to force it, it is not good"). Cheers, -- Pablo Tesone. tesonep(a)gmail.com

March 5, 2018

[update 6.0] #60539

by Marcus Denker

60539 ----- 21452 Backport read-only object support to pharo 6.1 https://pharo.fogbugz.com/f/cases/21452 <https://pharo.fogbugz.com/f/cases/21452> Thanks to Norbert for the backport Marcus

March 5, 2018

Re: [Pharo-dev] The 6.1 Space Monkey is unhappy

by Nicolas Anquetil

this sounds a bit like smart-test (that tries to identify the tests to re-run after a method is changed) Smarttest can work - on dynamic data: first run the tests to know what test cause what methods to be executed; then if such method is modified, re-run the associated tests - on static data: analyse senders of a method recursively to find the tests that could possibly call it 1- we are doing now experiment to find out what method (static or dynamic) is best. Surprisingly, the static method gives very good results (often better than dynamic) even if we all know that senders-of is not always very precise in smalltalk 2- may be something similar could be used to find out in the monkey what failing tests are caused by a new slice ? (going back from the changes in the slice to the tests, or forward from the failing test toward the changes in the slice ...) nicolas On 05/03/2018 14:29, Pavel Krivanek wrote: > 2018-03-05 14:14 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> Hi pavel >> >> when I'm back can you explain to me because I did not get it :). > :) it is simple. If you want to ignore issues that the slice is not > adding, you need to know which of them to ignore. That's why the > original monkey run all the validations twice - first time to collect > a list of failing tests in the fresh unchanged image and then with the > slice or configuration loaded. So it doubled the issue validation > time. > There are several alternative strategies like to cache the failing > test results for every build and use them for validations but the best > strategy is simply to keep the amount of failing tests in the clean > image on the zero level and force people to keep the system clean. The > original monkey hasn't exposed the list of ignored tests. So it was > possible that some test was ignored because of a temporal network > issue but for the second time it failed for o good reason and you even > didn't know. > > Cheers, > -- Pavel > >> Stef >> >> >> On Mon, Mar 5, 2018 at 11:07 AM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> 2018-03-05 10:54 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> On 5 Mar 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Hi Marcus, >>>>> >>>>> On 5 March 2018 at 09:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>>> >>>>>>> On 5 Mar 2018, at 09:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Esteban & Marcus, >>>>>>> >>>>>>> I'm getting repeated validation failures for: >>>>>>> >>>>>>> https://pharo.manuscript.com/f/cases/21431 >>>>>>> >>>>>>> >>>>>>> It's the same set of tests that fail each time, and as far as I can >>>>>>> tell they have nothing to do with the patch I submitted. >>>>>>> >>>>>>> Do you know if this is happening on other tests? >>>>>> I saw that Saturday but decided to wait till Monday (weekends are important..). >>>>>> >>>>>> So: no, I have *no* idea what happened. From one CI run to the next, >>>>>> suddenly around 160 tests related to Calypso started failing due to a missing method. >>>>>> >>>>>> Now starting from sometime today, this problem stoped. The last failing PR checks >>>>>> fail due to different reasonsâ¦ >>>>>> >>>>>> And I have no idea why. >>>>>> >>>>>> (And yes, we al know that >>>>>> 1) the PR checks need more compute power, too slow >>>>>> 2) we *need* to track down the reason why still *a lot* of times the PR fails >>>>>> even though it should not. >>>>>> >>>>>> The problem is that just keeping a build alive of this kind is a full time job.. that >>>>>> we have nobody doing, so many many people do as much as they can and we >>>>>> hope it will get betterâ¦.) >>>>> Thanks for the update. >>>>> >>>> Oh, and it was completely unrelated. Your change is for Pharo6... >>>> >>>>> I took a look at the failures and it appears that >>>>> >>>>> BehaviorTest>>testBehaviorRespectsPolymorphismWithTraitBehavior >>>>> ClassDescriptionTest>>testClassDescriptionRespectsPolymorphismWithTraitDescription >>>>> ClassTest>>testClassRespectsPolymorphismWithTrait >>>>> >>>>> are all failing due to changes in Fuel - methods were changed from >>>>> traits to local methods. >>>>> >>>> Yes, the problem is that the monkey (the contribution checker) fails as soon >>>> as there are errors even in the main image. >>>> >>>> The last Pharo6 has these tests failing, so now all contribution checks for >>>> Pharo6 fail. >>>> >>>> What needs to be done? >>>> >>>> -> your change can be accepted as we know it does not fail more fixes >>>> -> then we need fix the tests in Pharo6 >>>> -> in a perfect world we would update the slice checker to only fail for >>>> now test failingâ¦ (it used to be lille thatâ¦). >>> I must say that It made the validation two times slower, fragile and >>> led to the hiding of problems instead of solving them... >>> >>> -- Pavel >>> >>>> As I said: this is a full time jobâ¦ >>>> >>>> Marcus -- Nicolas Anquetil RMod team -- Inria Lille

March 5, 2018