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

Calypso question

by Stephane Ducasse

Hi denis I'm doing a pass on the architecture of calypso chapter :) as a way to force me to understand it better. Now I do not understand why the following does not work. | env classScope | env := ClySystemNavigationEnvironment currentImage. classScope := env selectScope: ClyClassScope of: {Point. Collection}. classScope allClasses another question packageScope query: (ClyMessageSenders of: #(do: x)) It is returning all the senders of do: and the senders of x or returning all the sender of do: and x Stef

Sept. 22, 2017

PharoLauncher feedback

by Stephane Ducasse

Hi christophe I took the bleeding edge and here are my report. - We need a signed VM because the security on mac is getting in our way. - I got PrimitiveFailed: CreatedDirectory in MacStore failed. So I do not know what to do :( I do not get why I cannot write on my download folder ;( but this error should be caught. - Pharo.app should be renamed PharoLauncher - the Quit menu is showing SqueakOSXApp and the about too. - There is a template 7.0 (beta) but it does not exist below Pharo60 We should not have Pharo 60 but Pharo 6.1 else it seems to work. well no :) I downloaded Pharo70 alpha and I got a problem with FT2Error primitive failed. May be this is normal. I do not know. Stef

Sept. 22, 2017

Re: [Pharo-dev] [ci-announces] [CI] July 28, 2017 Incident Report

by Stephane Ducasse

+1 On Fri, Sep 22, 2017 at 3:07 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > Kudos for providing a good incident report and explanation of the cause of the problem. > > I know little about this actual incident, but that it not important. It is really good > to see constructive responses to problems like this with a focus on inprovement and > problem prevention in the future. > > Dave > > On Thu, Sep 21, 2017 at 03:35:19PM +0200, Christophe Demarey wrote: >> July 28, 2017 Incident Report >> >> This summer, we experienced a hard incident on the Continuous Integration service infrastructure.Today we???re providing an incident report that details the nature of the incident and our response. >> We understand this service issue has impacted all Inria developers using the CI service and their valued time, and we apologize to everyone who was affected. >> >> Issue summary >> Due to a manipulation error, a lot of Virtual Machines (VM) hosted on CloudStack were destroyed and not recoverable! >> Jenkins servers are not concerned by this issue, so all Jenkins jobs and history are safe. >> >> Root cause >> After the successful migration of Jenkins servers and security fixes (July 18-19, 2017), a few projects were not able to reach their slaves hosted on the CI build farm. This problem was due to a synchronization problem between the CI database and CloudStack (powering the CI build farm) having its own way to manage projects and users (through domains). >> An attempt to reproduce and debug this problem on the qualification infrastructure failed. So, we added some logging on the production infrastructure. To avoid troubles to the production infrastructure, we limited the synchronization to one project. It was the mistake! >> The synchronization of one project led to the deletion of all other CloudStack domains (i.e. projects). Indeed, the synchronization code expected to get the full environment (all CI projects) and if it finds a domain not bound to a CI project, it deletes it... >> The synchronization process was aborted before its termination but it was too late. Some user Virtual Machines were still alive during some hours but were finally purged by CloudStack. >> It means we lost most VM and templates hosted on the CI build farm. >> >> Resolution and recovery >> It was impossible to recover destroyed virtual machines. CloudStack is configured to keep VM data 24 hours before actually destroying it but it does not work when the domain hosting the VM is destroyed. >> Primary storage hosting running VM is a high-performance and very expensive storage. That???s why the CI team chose (at the CI service setup) to do not backup VM but rather to rely on both the expunge delay and the snapshot / template mechanism to save VM state. This mechanism was useless in relation to this incident. >> Templates and snapshots are hosted on the secondary storage that is a redundant storage in two different buildings to ensure data reliability and recovery. The incident led CloudStack to perform a ?? clean ?? deletion of all the domain data including templates. That???s why they also became unavailable. >> >> We were able to rebuild all domains from the CI database but CI service users had to create new VM to replace the destroyed ones. >> >> Corrective and preventative measures >> All members of the CI team (DSI, SED) worked and are still working all together to find the best solution to mitigate the incident and prevent same situations in the future. >> The synchronization code responsible of the deletion of CloudStack domain has been deactivated. CloudStack domain deletion is a critical action and will no longer be automated. Deletions will be reviewed and approved by the CI team before being completed. >> This incident showed us that backup mechanism in place are not strong enough and we are now evaluating the cost to backup, with history: >> all VM, snapshots and templates or >> all snapshots and templates. >> We are also working on providing a way to download templates created on CloudStack so that you can easily get a copy of them. We encourage you to create templates for virtual machines that are time consuming to set up from scratch. >> >> >> Sincerely, >> The CI Team >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by Stephane Ducasse

good idea! Tx for the good spirit! I like to work with smart and nice people like you guys. I feel lucky. On Fri, Sep 22, 2017 at 6:59 PM, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi ClÃ©ment, > If you need help with the CI, I can also help you. We can create it as a > another parallel stage in the PR validation. So once it is stable we can > detect asap changes that break it. > > Cheers, > > > On 22 Sep 2017 18:45, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: > > Well we need to use them but the integration process is difficult to deal > with: we need to change the bootstrap to cross compile to the other bytecode > set. I need to have some time to focus on it amd I need the help of someone > understanding the bootstrap like Guille > > On Sep 22, 2017 18:31, "Stephane Ducasse" <stepharo.self(a)gmail.com> wrote: >> >> Hi clement >> >> let us know how we can help because he all want the new closures. >> >> Stef >> >> On Fri, Sep 22, 2017 at 11:11 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > I totally agree with you on this. >> > >> > For a while I had a CI job that was trying to execute Sista on the >> > latest >> > version of Pharo and VM, and sent me a mail when something had gone >> > wrong. I >> > disabled it when there was problems on the CI, I will make it work >> > again. >> > This way I am notified and I can update the Sista code as Pharo 7 is >> > developed. That helps a lot. >> > >> > On the Pharo CI the time to run tests matters hence I will try to find >> > another solution to test full block and the other bytecode set. I did >> > not do >> > that because I hope I can change Pharo to use full block by default >> > soon, >> > but since they're broken... >> > >> > Regards >> > >> > >> > >> > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> >> > wrote: >> >> >> >> >> >> > On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> Hi Clement, >> >> >> >> >> >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and >> >> > 6.1 >> >> > but it won't work every day during the alpha of Pharo 7 and no sane >> >> > framework developer can guarantee that. Sista does not work currently >> >> > in >> >> > Pharo 7 due to some changes breaking the full block closures, I am >> >> > going to >> >> > fix it but even then in the incoming months there is a high chance >> >> > that >> >> > another change in Pharo 7 breaks it again, so I would never recommend >> >> > to use >> >> > it with the alpha. >> >> >> >> >> >> thank you for your response. I didn't expect it to work (after all you >> >> label it "Alpha" and I ran into issues already) but my intention for >> >> the >> >> mail was a bit different. Let me try to briefly explain my motivation. >> >> In my >> >> experience: >> >> >> >> (1) Software not executed stops to work (or never "worked") >> >> (2) The earlier breakage is detected the less expensive it is to fix. >> >> >> >> My assumption is that Opal is part of Pharo and that we look at a >> >> regression of the Opal compiler and/or how it interacts with the rest >> >> of the >> >> image. As it might be easier to understand/fix it now than later I >> >> brought >> >> it up. From my point of view I wonder if we want to add ~50s to the CI >> >> process to execute: >> >> >> >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1. >> >> CompilationContext usesFullBlockClosure: true. >> >> OpalCompiler recompileAll. >> >> >> >> >> >> Is there any value in doing so? >> >> >> >> >> >> cheers >> >> >> >> holger >> >> >> >> >> >> PS >> >> >> >> (2) The intuitive explanation is that the cost of analysis is a lot >> >> lower >> >> the earlier the problem is detected. There are fewer potential changes >> >> that >> >> lead to the breakage and the people involved will remember what/why >> >> they did >> >> reducing the cost of fixing. Ideally things are found to be broken and >> >> fixed >> >> before integration. >> >> >> >> Maybe an analogy is old-school aviation navigation.. the earlier a >> >> mistake >> >> is found in navigation the closer to the original course... >> > >> > >> >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by ClÃ©ment Bera

Yeah we may need to do that as a transition to move them to production. Let's do that the first week of october Pablo On Sep 22, 2017 18:59, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote: Hi ClÃ©ment, If you need help with the CI, I can also help you. We can create it as a another parallel stage in the PR validation. So once it is stable we can detect asap changes that break it. Cheers, On 22 Sep 2017 18:45, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: Well we need to use them but the integration process is difficult to deal with: we need to change the bootstrap to cross compile to the other bytecode set. I need to have some time to focus on it amd I need the help of someone understanding the bootstrap like Guille On Sep 22, 2017 18:31, "Stephane Ducasse" <stepharo.self(a)gmail.com> wrote: > Hi clement > > let us know how we can help because he all want the new closures. > > Stef > > On Fri, Sep 22, 2017 at 11:11 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > I totally agree with you on this. > > > > For a while I had a CI job that was trying to execute Sista on the latest > > version of Pharo and VM, and sent me a mail when something had gone > wrong. I > > disabled it when there was problems on the CI, I will make it work again. > > This way I am notified and I can update the Sista code as Pharo 7 is > > developed. That helps a lot. > > > > On the Pharo CI the time to run tests matters hence I will try to find > > another solution to test full block and the other bytecode set. I did > not do > > that because I hope I can change Pharo to use full block by default soon, > > but since they're broken... > > > > Regards > > > > > > > > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> > > wrote: > >> > >> > >> > On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> > >> > >> Hi Clement, > >> > >> > >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and > 6.1 > >> > but it won't work every day during the alpha of Pharo 7 and no sane > >> > framework developer can guarantee that. Sista does not work currently > in > >> > Pharo 7 due to some changes breaking the full block closures, I am > going to > >> > fix it but even then in the incoming months there is a high chance > that > >> > another change in Pharo 7 breaks it again, so I would never recommend > to use > >> > it with the alpha. > >> > >> > >> thank you for your response. I didn't expect it to work (after all you > >> label it "Alpha" and I ran into issues already) but my intention for the > >> mail was a bit different. Let me try to briefly explain my motivation. > In my > >> experience: > >> > >> (1) Software not executed stops to work (or never "worked") > >> (2) The earlier breakage is detected the less expensive it is to fix. > >> > >> My assumption is that Opal is part of Pharo and that we look at a > >> regression of the Opal compiler and/or how it interacts with the rest > of the > >> image. As it might be easier to understand/fix it now than later I > brought > >> it up. From my point of view I wonder if we want to add ~50s to the CI > >> process to execute: > >> > >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1. > >> CompilationContext usesFullBlockClosure: true. > >> OpalCompiler recompileAll. > >> > >> > >> Is there any value in doing so? > >> > >> > >> cheers > >> > >> holger > >> > >> > >> PS > >> > >> (2) The intuitive explanation is that the cost of analysis is a lot > lower > >> the earlier the problem is detected. There are fewer potential changes > that > >> lead to the breakage and the people involved will remember what/why > they did > >> reducing the cost of fixing. Ideally things are found to be broken and > fixed > >> before integration. > >> > >> Maybe an analogy is old-school aviation navigation.. the earlier a > mistake > >> is found in navigation the closer to the original course... > > > > > >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by tesonep＠gmail.com

Hi ClÃ©ment, If you need help with the CI, I can also help you. We can create it as a another parallel stage in the PR validation. So once it is stable we can detect asap changes that break it. Cheers, On 22 Sep 2017 18:45, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: Well we need to use them but the integration process is difficult to deal with: we need to change the bootstrap to cross compile to the other bytecode set. I need to have some time to focus on it amd I need the help of someone understanding the bootstrap like Guille On Sep 22, 2017 18:31, "Stephane Ducasse" <stepharo.self(a)gmail.com> wrote: > Hi clement > > let us know how we can help because he all want the new closures. > > Stef > > On Fri, Sep 22, 2017 at 11:11 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > I totally agree with you on this. > > > > For a while I had a CI job that was trying to execute Sista on the latest > > version of Pharo and VM, and sent me a mail when something had gone > wrong. I > > disabled it when there was problems on the CI, I will make it work again. > > This way I am notified and I can update the Sista code as Pharo 7 is > > developed. That helps a lot. > > > > On the Pharo CI the time to run tests matters hence I will try to find > > another solution to test full block and the other bytecode set. I did > not do > > that because I hope I can change Pharo to use full block by default soon, > > but since they're broken... > > > > Regards > > > > > > > > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> > > wrote: > >> > >> > >> > On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> > >> > >> Hi Clement, > >> > >> > >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and > 6.1 > >> > but it won't work every day during the alpha of Pharo 7 and no sane > >> > framework developer can guarantee that. Sista does not work currently > in > >> > Pharo 7 due to some changes breaking the full block closures, I am > going to > >> > fix it but even then in the incoming months there is a high chance > that > >> > another change in Pharo 7 breaks it again, so I would never recommend > to use > >> > it with the alpha. > >> > >> > >> thank you for your response. I didn't expect it to work (after all you > >> label it "Alpha" and I ran into issues already) but my intention for the > >> mail was a bit different. Let me try to briefly explain my motivation. > In my > >> experience: > >> > >> (1) Software not executed stops to work (or never "worked") > >> (2) The earlier breakage is detected the less expensive it is to fix. > >> > >> My assumption is that Opal is part of Pharo and that we look at a > >> regression of the Opal compiler and/or how it interacts with the rest > of the > >> image. As it might be easier to understand/fix it now than later I > brought > >> it up. From my point of view I wonder if we want to add ~50s to the CI > >> process to execute: > >> > >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1. > >> CompilationContext usesFullBlockClosure: true. > >> OpalCompiler recompileAll. > >> > >> > >> Is there any value in doing so? > >> > >> > >> cheers > >> > >> holger > >> > >> > >> PS > >> > >> (2) The intuitive explanation is that the cost of analysis is a lot > lower > >> the earlier the problem is detected. There are fewer potential changes > that > >> lead to the breakage and the people involved will remember what/why > they did > >> reducing the cost of fixing. Ideally things are found to be broken and > fixed > >> before integration. > >> > >> Maybe an analogy is old-school aviation navigation.. the earlier a > mistake > >> is found in navigation the closer to the original course... > > > > > >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by ClÃ©ment Bera

Well we need to use them but the integration process is difficult to deal with: we need to change the bootstrap to cross compile to the other bytecode set. I need to have some time to focus on it amd I need the help of someone understanding the bootstrap like Guille On Sep 22, 2017 18:31, "Stephane Ducasse" <stepharo.self(a)gmail.com> wrote: > Hi clement > > let us know how we can help because he all want the new closures. > > Stef > > On Fri, Sep 22, 2017 at 11:11 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > I totally agree with you on this. > > > > For a while I had a CI job that was trying to execute Sista on the latest > > version of Pharo and VM, and sent me a mail when something had gone > wrong. I > > disabled it when there was problems on the CI, I will make it work again. > > This way I am notified and I can update the Sista code as Pharo 7 is > > developed. That helps a lot. > > > > On the Pharo CI the time to run tests matters hence I will try to find > > another solution to test full block and the other bytecode set. I did > not do > > that because I hope I can change Pharo to use full block by default soon, > > but since they're broken... > > > > Regards > > > > > > > > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> > > wrote: > >> > >> > >> > On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> > >> > >> Hi Clement, > >> > >> > >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and > 6.1 > >> > but it won't work every day during the alpha of Pharo 7 and no sane > >> > framework developer can guarantee that. Sista does not work currently > in > >> > Pharo 7 due to some changes breaking the full block closures, I am > going to > >> > fix it but even then in the incoming months there is a high chance > that > >> > another change in Pharo 7 breaks it again, so I would never recommend > to use > >> > it with the alpha. > >> > >> > >> thank you for your response. I didn't expect it to work (after all you > >> label it "Alpha" and I ran into issues already) but my intention for the > >> mail was a bit different. Let me try to briefly explain my motivation. > In my > >> experience: > >> > >> (1) Software not executed stops to work (or never "worked") > >> (2) The earlier breakage is detected the less expensive it is to fix. > >> > >> My assumption is that Opal is part of Pharo and that we look at a > >> regression of the Opal compiler and/or how it interacts with the rest > of the > >> image. As it might be easier to understand/fix it now than later I > brought > >> it up. From my point of view I wonder if we want to add ~50s to the CI > >> process to execute: > >> > >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1. > >> CompilationContext usesFullBlockClosure: true. > >> OpalCompiler recompileAll. > >> > >> > >> Is there any value in doing so? > >> > >> > >> cheers > >> > >> holger > >> > >> > >> PS > >> > >> (2) The intuitive explanation is that the cost of analysis is a lot > lower > >> the earlier the problem is detected. There are fewer potential changes > that > >> lead to the breakage and the people involved will remember what/why > they did > >> reducing the cost of fixing. Ideally things are found to be broken and > fixed > >> before integration. > >> > >> Maybe an analogy is old-school aviation navigation.. the earlier a > mistake > >> is found in navigation the closer to the original course... > > > > > >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by Stephane Ducasse

Hi clement let us know how we can help because he all want the new closures. Stef On Fri, Sep 22, 2017 at 11:11 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > I totally agree with you on this. > > For a while I had a CI job that was trying to execute Sista on the latest > version of Pharo and VM, and sent me a mail when something had gone wrong. I > disabled it when there was problems on the CI, I will make it work again. > This way I am notified and I can update the Sista code as Pharo 7 is > developed. That helps a lot. > > On the Pharo CI the time to run tests matters hence I will try to find > another solution to test full block and the other bytecode set. I did not do > that because I hope I can change Pharo to use full block by default soon, > but since they're broken... > > Regards > > > > On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> > wrote: >> >> >> > On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> Hi Clement, >> >> >> > Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1 >> > but it won't work every day during the alpha of Pharo 7 and no sane >> > framework developer can guarantee that. Sista does not work currently in >> > Pharo 7 due to some changes breaking the full block closures, I am going to >> > fix it but even then in the incoming months there is a high chance that >> > another change in Pharo 7 breaks it again, so I would never recommend to use >> > it with the alpha. >> >> >> thank you for your response. I didn't expect it to work (after all you >> label it "Alpha" and I ran into issues already) but my intention for the >> mail was a bit different. Let me try to briefly explain my motivation. In my >> experience: >> >> (1) Software not executed stops to work (or never "worked") >> (2) The earlier breakage is detected the less expensive it is to fix. >> >> My assumption is that Opal is part of Pharo and that we look at a >> regression of the Opal compiler and/or how it interacts with the rest of the >> image. As it might be easier to understand/fix it now than later I brought >> it up. From my point of view I wonder if we want to add ~50s to the CI >> process to execute: >> >> CompilationContext bytecodeBackend: OpalEncoderForSistaV1. >> CompilationContext usesFullBlockClosure: true. >> OpalCompiler recompileAll. >> >> >> Is there any value in doing so? >> >> >> cheers >> >> holger >> >> >> PS >> >> (2) The intuitive explanation is that the cost of analysis is a lot lower >> the earlier the problem is detected. There are fewer potential changes that >> lead to the breakage and the people involved will remember what/why they did >> reducing the cost of fixing. Ideally things are found to be broken and fixed >> before integration. >> >> Maybe an analogy is old-school aviation navigation.. the earlier a mistake >> is found in navigation the closer to the original course... > >

Sept. 22, 2017

Re: [Pharo-dev] Pharo7 and full block closures

by Stephane Ducasse

Hi holger I like your approach. Tx! Stef On Fri, Sep 22, 2017 at 10:58 AM, Holger Freyther <holger(a)freyther.de> wrote: > >> On 22. Sep 2017, at 13:33, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Hi Clement, > > >> Sista will work for the release of Pharo 7 as it did for Pharo 6 and 6.1 but it won't work every day during the alpha of Pharo 7 and no sane framework developer can guarantee that. Sista does not work currently in Pharo 7 due to some changes breaking the full block closures, I am going to fix it but even then in the incoming months there is a high chance that another change in Pharo 7 breaks it again, so I would never recommend to use it with the alpha. > > > thank you for your response. I didn't expect it to work (after all you label it "Alpha" and I ran into issues already) but my intention for the mail was a bit different. Let me try to briefly explain my motivation. In my experience: > > (1) Software not executed stops to work (or never "worked") > (2) The earlier breakage is detected the less expensive it is to fix. > > My assumption is that Opal is part of Pharo and that we look at a regression of the Opal compiler and/or how it interacts with the rest of the image. As it might be easier to understand/fix it now than later I brought it up. From my point of view I wonder if we want to add ~50s to the CI process to execute: > > CompilationContext bytecodeBackend: OpalEncoderForSistaV1. > CompilationContext usesFullBlockClosure: true. > OpalCompiler recompileAll. > > > Is there any value in doing so? > > > cheers > > holger > > > PS > > (2) The intuitive explanation is that the cost of analysis is a lot lower the earlier the problem is detected. There are fewer potential changes that lead to the breakage and the people involved will remember what/why they did reducing the cost of fixing. Ideally things are found to be broken and fixed before integration. > > Maybe an analogy is old-school aviation navigation.. the earlier a mistake is found in navigation the closer to the original course...

Sept. 22, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #149: 20442-open-the-welcome-window. case 20442

by Pavel Krivanek

We need to revert this merge. The resultant image crashes immediately. -- Pavel 2017-09-22 13:24 GMT+02:00 <ci-pharo-ci-jenkins2(a)inria.fr>: > There is a new Pharo build available! > > The status of the build #149 was: SUCCESS. > > The Pull Request #297 was integrated: "20442-open-the-welcome-window. > case 20442" > Pull request url: https://github.com/pharo-project/pharo/pull/297 > > Issue Url: https://pharo.fogbugz.com/f/cases/20442 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/149/ >

Sept. 22, 2017