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

<Programming> 2019: Call for Papers & Call for Workshop Proposals

by Fabio Niephaus

<Programming> 2019 : The Art, Science, and Engineering of Programming April 1-4, 2019, Genova, Italy http://2019.programming-conference.org The International Conference on the Art, Science, and Engineering of Programming is a new conference focused on programming topics including the experience of programming. We have named it <Programming> for short. <Programming> seeks for papers that advance knowledge of programming on any relevant topic, including programming practice and experience. Paper submissions and publications are handled by the the Art, Science, and Engineering of Programming journal (http://programming-journal.org) Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2019 accepts scholarly papers that advance knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. PAPER SUBMISSIONS: June 1, 2018 URL FOR SUBMISSIONS: http://programming-journal.org/submission/ Submissions covering several areas of expertise are accepted, including but not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** CALL FOR WORKSHOP PROPOSALS ******************************************************** To build a community and to foster an environment where participants can exchange ideas and experiences related to practical software development, <Programming> will host a number of workshops, during the days before the main conference. The workshops will provide a collaborative forum to exchange recent and/or preliminary results, to conduct intensive discussions on a particular topic, or to coordinate efforts between representatives of a technical community. They are intended as a forum for lively discussion of innovative ideas, recent progress, or practical experience on programming and applied software development in general for specific aspects, specific problems, or domain-specific needs. We also encourage practical, hands-on workshops in which participants actually experience one or several aspects of practical software development. WORKSHOP PROPOSAL SUBMISSIONS: First Deadline: July 1st, 2018 Second Deadline: September 1st, 2018 The duration of workshops is in general one day, but we encourage the submission of half-day workshop proposals on focused topics as well. In exceptional situations, e.g., for workshops that involve actual practice of programming-related activities, workshop organizers can request a 2 day workshop slot. If desired, the workshop proceedings can be published in the ACM Digital Library. ******************************************************** IMPORTANT DATES ******************************************************** Research paper submissions: June 1, 2019 Research paper first notifications: August 1, 2018 Research paper final notifications: September 7, 2018 Workshop proposals: July 1st, 2018 (first deadline) Workshop proposals: September 1st, 2018 (second deadline) ******************************************************** ORGANIZATION ******************************************************** General Chair: Davide Ancona, University of Genova Local Organizing Chair: Elena Zucca, University of Genova Program Chair: Matthew Flatt, University of Utah Organizing Committee: Walter Cazzola (Workshops Co-Chair), UniversitÃ degli Studi di Milano Stefan Marr (Workshops Co-Chair), University of Kent Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University of Potsdam Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of Potsdam Program Committee: Mehdi Bagherzadeh, Oakland University Walter Cazzola, UniversitÃ degli Studi di Milano Ravi Chugh, University of Chicago Joeri De Koster, Vrije Universiteit Brussel Christos Dimoulas, Northwestern University Susan Eisenbach, Imperial College London Richard P. Gabriel, Dream Songs, Inc. & HPI Jeremy Gibbons, University of Oxford Michael Greenberg, Pomona College Philipp Haller, KTH Royal Institute of Technology Robert Hirschfeld, HPI, University of Potsdam Eunsuk Kang, Carnegie Mellon University Stephen Kell, University of Cambridge Stefan Marr, University of Kent Tamara Rezk, Inria Joshua Sunshine, Carnegie Mellon University Steffen Zschaler, King's College London ******************************************************** <Programming> 2019 is kindly supported by AOSA ******************************************************** For more information, visit http://2019.programming-conference.org

May 4, 2018

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

by Pavel Krivanek

createPackageNamed: - solved by you browse - adds an ability for RBBrowserEnvironment to be browsed by Nautilus, no action needed asRingDefinition - for UndefinedObject, solved by Nautilus removal, no action needed addCategory:before: - solved by Nautilus removal, no action needed hasErrorTest - solved by Nautilus removal, no action needed inheritsFrom: - solved by Nautilus removal, no action needed compile:classified:notifying: - solved by Nautilus removal, no action needed traits - solved by Nautilus removal, no action needed hasPassedTest - solved by Nautilus removal, no action needed extendingPackages - solved by Nautilus removal, no action needed hasFailedTest - solved by Nautilus removal, no action needed #color - solved by Nautilus removal, no action needed annotateRubricText: - solved by Nautilus removal, no action needed The rest are the menu entries ( https://pharo.fogbugz.com/f/cases/21827/clean-NautilusRefactoring-menu-entr… ). So at least from the method extensions point of view, we should be safe. Thanks -- Pavel 2018-05-04 13:30 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > 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-f >>> rom-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

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