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, "[email protected]" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > wrote: > >> > >> > >> > On 22. Sep 2017, at 13:33, Clément Bera <[email protected]> > 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... > > > > > >
