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