[squeak-dev] EncoderForV3PlusClosures still the preferred bytecode set encoder class?
marcel.taeumel at hpi.de
Wed Dec 16 08:36:51 UTC 2020
Please know that this regression only affects some downloads from files.squeak.org. If you maintain your local Trunk through the update stream, you should be with SistaV1 since March.
Am 16.12.2020 09:34:36 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Fabio, hi Dave, hi all!
Fixed in Kernel-mt.1364. I introduced that regression. Sorry.
Am 15.12.2020 19:27:56 schrieb David T. Lewis <lewis at mail.msen.com>:
On Tue, Dec 15, 2020 at 03:55:35PM +0100, Fabio Niephaus wrote:
> Hi all,
> The latest Squeak trunk (6.0alpha-20097) is still using
> EncoderForV3PlusClosures as the preferred bytecode set encoder class.
> So new methods are still being compiled with it (not necessarily a
> problem, because the VM can handle both V3 and Sista at the same
> Is this something we've done on purpose or something we should fix?
As far as I know it was not done on purpose, and yes it is something
we should fix.
We switched trunk to Sista back in March:
Time: 6 March 2020, 7:29:11.316779 pm
Change the Squeak default bytecode set to Sista in trunk.
Add CompiledCode>>multipleBytecodeSetsActive: to optionally inform the
VM that Sista is in use, see VMMaker.oscog-dtl.2711 and
Add CompiledCode>>useSista: convenience method for switching to and
from Sista bytecodes.
Package postscript activates the change to Sista bytecodes, which can
be reversed by evaluating CompiledCode useSista: false.
I don't know where things went wrong in the update stream, but I thought
that we were running Sista encoding all of this time :-(
This is also a good time to mention that the planned update for image
format number (to identify images requiring multiple bytecode support)
was discussed but not implemented in the VM. I'm not sure if there is
any further interest in this?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev