Hi Clément,
On Sep 30, 2016, at 6:44 AM, Clément Bera <bera.clement@gmail.com> wrote:
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.
[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 <nicolaihess@gmail.com> 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