Hi. *In short: * normally you don't, but for some reasons right now you do. Try a VM from here <https://bintray.com/opensmalltalk/vm/cog/201609292318#files/> [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. So... I've just compiled another VM to check and it could run the image. I've just checked with the VM from openSmalltalk <https://bintray.com/opensmalltalk/vm/cog/201609292318#files/> [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 <https://github.com/OpenSmalltalk/opensmalltalk-vm> [2] you have a link by clinking "download" to the latest bintray releases. Those releases are built automatically and very frequently. [1] https://bintray.com/opensmalltalk/vm/cog/201609292318#files/ [2] https://github.com/OpenSmalltalk/opensmalltalk-vm On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess <[email protected]> wrote: > Do we need a special vm for testing sista bytecode backend? > I enabled sista in the compiler settings and evaluating > > [ ] class > > crashes the vm. > > > nicolai >
