Hi Clément,
Hi.
In short:
normally you don't, but for some reasons right now you do. Try a VM from
here [1].
In long:
Normally you need a VM with the following slang to C compilation settings:
MULTIPLEBYTECODESETS true
bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresSistaV1Hybrid
which has been added recently to multiple VM builds, including the Pharo build if I am correct.
The latest Pharo VM on
files.pharo.org answers true to "Smalltalk vm supportsMultipleBytecodeSets", so it should be fine...
But, when I tried to run code with new bytecode set, it does not work indeed.
It's disconcerting that this is so mysterious.
- does an assert VM show up anything?
- is it a regression from integrating Lowcode?
- if you diff the generated code and try and filter out the Lowcode signal has anything changed?
- does the Sista simulator work?
- can we get help to produce a test suite?
- what other questions should we be asking?
So...
I've just compiled another VM to check and it could run the image.
I've just checked with the VM from
openSmalltalk [1] and both pharo.cog.spur and squeak.cog.spur could run the Pharo image with both bytecode set and full blocks.
It's not clear pharo.cog.spur is a complete Pharo VM as the migration process to opensmalltalk VM is still in progress, it may be a squeak VM with part of the extra Pharo plugins.
I believe something is temporarily wrong during the opensmalltalk pharo vm migration. I would recommend to use a VM from bintray to test those features until the migration is over.
On the
openSmalltalkVM git [2] you have a link by clinking "download" to the latest bintray releases. Those releases are built automatically and very frequently.
Locked
