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