EncoderForV3PlusClosures still the preferred bytecode set encoder class?

Am 15.12.2020 19:27:56 schrieb David T. Lewis <[hidden email]>:

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
> time).
>
> Is this something we've done on purpose or something we should fix?
>
> Best,
> Fabio
>

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:

Name: Kernel-dtl.1310
Author: dtl
Time: 6 March 2020, 7:29:11.316779 pm
UUID: 683e4e14-fc18-4d55-a776-eece91f579f5
Ancestors: Kernel-mt.1309

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
http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html.

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?

http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html

Dave

Am 16.12.2020 09:34:36 schrieb Marcel Taeumel <[hidden email]>:

Hi Fabio, hi Dave, hi all!

Fixed in Kernel-mt.1364. I introduced that regression. Sorry.

Best,

Marcel

Am 15.12.2020 19:27:56 schrieb David T. Lewis <[hidden email]>:

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
> time).
>
> Is this something we've done on purpose or something we should fix?
>
> Best,
> Fabio
>

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:

Name: Kernel-dtl.1310
Author: dtl
Time: 6 March 2020, 7:29:11.316779 pm
UUID: 683e4e14-fc18-4d55-a776-eece91f579f5
Ancestors: Kernel-mt.1309

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
http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html.

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?

http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html

Dave

Am 16.12.2020 09:36:51 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

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.

Best,

Marcel

Am 16.12.2020 09:34:36 schrieb Marcel Taeumel <[hidden email]>:

Hi Fabio, hi Dave, hi all!

Fixed in Kernel-mt.1364. I introduced that regression. Sorry.

Best,

Marcel

Am 15.12.2020 19:27:56 schrieb David T. Lewis <[hidden email]>:

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
> time).
>
> Is this something we've done on purpose or something we should fix?
>
> Best,
> Fabio
>

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:

Name: Kernel-dtl.1310
Author: dtl
Time: 6 March 2020, 7:29:11.316779 pm
UUID: 683e4e14-fc18-4d55-a776-eece91f579f5
Ancestors: Kernel-mt.1309

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
http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html.

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?

http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html

Dave