- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problems with the removal of Nautilus

by Pavel Krivanek

In an old image with Nautilus I did this: names := #('Nautilus' 'NautilusCommon' 'Nautilus-GroupManager' 'Nautilus-GroupManagerUI' 'QualityAssistant' 'QualityAssistantRecording' 'QualityAssistant-Test'). selectors := names flatCollect: [ :packageName | packageName asPackage extensionMethods collect: #selector as: Set ]. selectors reject: [ :each | senders := SystemNavigation default allSendersOf: each. senders allSatisfy: [ :sender | names includes: sender package name ] ]. This is the result of problematic extensions. Some of them are solved by the removal, most of them are menu entries in NautilusRefactorings. The mentioned selector #createPackageNamed: is there. "#(#codeRewritingClass: #methodRefactoring: #refactoringMenu: #varRefactoringSubMenu: #groupRefactoring: #createPackageNamed: #sourceCodeRefactoring: #refactoringSubmenu: #instVarRefactoring: #refactoringMethod: #browse #sourceCodeRefactoringMenu: #asRingDefinition #addCategory:before: #hasErrorTest #inheritsFrom: #compile:classified:notifying: #traits #hasPassedTest #extendingPackages #browsedEnvironment: #hasFailedTest #notifyViewedDiffFor:of: #repairIcon #color #annotateRubricText: #notifyBanInitiatedFor:of: #notifyCritique:AutoFixedFor:)" I will check them and make the issue entries. -- Pavel 2018-05-04 13:08 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > 2018-05-04 10:19 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi, >> >> I've just tried to create a new package in Calypso and I got bitten by >> this: >> >> https://pharo.fogbugz.com/f/cases/21804/Creating-a-Package- >> from-Calypso-produces-DNU >> >> Creating a new package was an extension of Nautilus, and was never >> introduced in RPackage. >> >> How should we procceed? How can we know all the "extensions" that were >> not so? >> > > I will try to check them > > -- Pavel > > >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> 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 >> > >

May 4, 2018

Re: [Pharo-dev] Problems with the removal of Nautilus

by Pavel Krivanek

2018-05-04 10:19 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi, > > I've just tried to create a new package in Calypso and I got bitten by > this: > > https://pharo.fogbugz.com/f/cases/21804/Creating-a- > Package-from-Calypso-produces-DNU > > Creating a new package was an extension of Nautilus, and was never > introduced in RPackage. > > How should we procceed? How can we know all the "extensions" that were not > so? > I will try to check them -- Pavel > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > 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 >

May 4, 2018

[Pharo 7.0-dev] Build #833: 21824-Remove-test-retries-in-CI

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

There is a new Pharo build available! The status of the build #833 was: SUCCESS. The Pull Request #1291 was integrated: "21824-Remove-test-retries-in-CI" Pull request url: https://github.com/pharo-project/pharo/pull/1291 Issue Url: https://pharo.fogbugz.com/f/cases/21824 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 4, 2018

Re: [Pharo-dev] Aboud CI test retries

by Guillermo Polito

On Fri, May 4, 2018 at 10:20 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 3 May 2018 at 23:35, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> Initially the pharo build had tests that were failing randomly. >> To cope with that, we introduced a retry of the tests. >> >> Nowadays, this situation is actually very rare. Tests that fail, fail >> always, and randomly failing tests are not seen so often... This means >> however, that in the case that a test is persistently failing, we are >> (uselessly) retrying it, and making jobs take 10-15 minutes longer for >> nothing. >> > > I'm curious... > are all tests retried, or only the failing one? > All of them. > > >> I propose that we remove the retries. >> >> - This will speed up the builds that are green and only penalize those >> that are not green. >> > > If all tests pass first time there should be no retries and such a green > build > should take the same time regardless whether retries are enabled or > not.... ? > True, I don't know what I wrote there ^^. What I meant is that builds that are not green will fail sooner. > > >> - Remove stress from our servers (that we use to have a higher ratio >> builds/hour :)) >> - Randomly failing tests will just need to manually retry the build. But >> since green builds take now ~15-20 minutes, which is in the same order of >> magnitude of the retries, we only penalize the one that found the hiccup. >> > > The "really annoying" random failures are just single failed test. > Perhaps assume if the count of failed tests is more than ten, then its not > a "random" failure and immediately fail that job. > But how can we distinguish between a real failing test and one that is random? > Rerunning max ten tests shouldn't add much to job time. > But maybe the benefit isn't worth the added complexity to do it like that. > The thing is also that we have to implement something custom for that. And I'd like to put my effort on other things that add more value in the short term... > > cheers -ben > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

May 4, 2018

Re: [Pharo-dev] Problems with the removal of Nautilus

by Guillermo Polito

Can someone check this https://github.com/pharo-project/pharo/pull/1293 ? On Fri, May 4, 2018 at 10:19 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi, > > I've just tried to create a new package in Calypso and I got bitten by > this: > > https://pharo.fogbugz.com/f/cases/21804/Creating-a- > Package-from-Calypso-produces-DNU > > Creating a new package was an extension of Nautilus, and was never > introduced in RPackage. > > How should we procceed? How can we know all the "extensions" that were not > so? > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > 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 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

May 4, 2018

Re: [Pharo-dev] Aboud CI test retries

by Ben Coman

On 3 May 2018 at 23:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > Initially the pharo build had tests that were failing randomly. > To cope with that, we introduced a retry of the tests. > > Nowadays, this situation is actually very rare. Tests that fail, fail > always, and randomly failing tests are not seen so often... This means > however, that in the case that a test is persistently failing, we are > (uselessly) retrying it, and making jobs take 10-15 minutes longer for > nothing. > I'm curious... are all tests retried, or only the failing one? > I propose that we remove the retries. > > - This will speed up the builds that are green and only penalize those > that are not green. > If all tests pass first time there should be no retries and such a green build should take the same time regardless whether retries are enabled or not.... ? > - Remove stress from our servers (that we use to have a higher ratio > builds/hour :)) > - Randomly failing tests will just need to manually retry the build. But > since green builds take now ~15-20 minutes, which is in the same order of > magnitude of the retries, we only penalize the one that found the hiccup. > The "really annoying" random failures are just single failed test. Perhaps assume if the count of failed tests is more than ten, then its not a "random" failure and immediately fail that job. Rerunning max ten tests shouldn't add much to job time. But maybe the benefit isn't worth the added complexity to do it like that. cheers -ben

May 4, 2018

Problems with the removal of Nautilus

by Guillermo Polito

Hi, I've just tried to create a new package in Calypso and I got bitten by this: https://pharo.fogbugz.com/f/cases/21804/Creating-a-Package-from-Calypso-pro… Creating a new package was an extension of Nautilus, and was never introduced in RPackage. How should we procceed? How can we know all the "extensions" that were not so? -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

May 4, 2018

[Pharo 7.0-dev] Build #832: 21822-Fix-Zn-Tests-due-to-encryptedgooglecom-moving

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

There is a new Pharo build available! The status of the build #832 was: SUCCESS. The Pull Request #1290 was integrated: "21822-Fix-Zn-Tests-due-to-encryptedgooglecom-moving" Pull request url: https://github.com/pharo-project/pharo/pull/1290 Issue Url: https://pharo.fogbugz.com/f/cases/21822 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 3, 2018

[Pharo 7.0-dev] Build #831: 21821-Integrate-Iceberg-075

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

There is a new Pharo build available! The status of the build #831 was: SUCCESS. The Pull Request #1287 was integrated: "21821-Integrate-Iceberg-075" Pull request url: https://github.com/pharo-project/pharo/pull/1287 Issue Url: https://pharo.fogbugz.com/f/cases/21821 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 3, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Guillermo Polito

Just for the record https://pharo.fogbugz.com/f/cases/21825/Improve-Catalog-loading https://github.com/pharo-project/pharo/pull/1292 Feel free to review or to propose other PRs, Guille

May 3, 2018