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@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@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@freyther.de> wrote:
On 22. Sep 2017, at 13:33, Clément Bera <bera.clement@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...