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... > >
