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
On Fri, Sep 30, 2016 at 5:29 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
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 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 initializeBytecodeTableForSque akV3PlusClosuresSistaV1Hybrid 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?
Wrong questions. The VM I build and the VM built by opensmalltalk VMs work fine. (I said it after your inlined answer in the previous mail)
I don't know how the VM from Pharo latest is generated, it could be from older non working sources or maybe some setting is missing. I am pretty sure everything will work fine once the merge with opensmalltalk will be finished.
Today I was working on having all the kernel tests pass with FullBlockClosure. It seems something is not working with process scheduling when using FullBlocks. I wonder what is going on. I may need help on that.
Yesterday I worked with the sista runtime. It seems that the optimizer takes many wrong inlining decisions, I need to investigate why. I have some benchmarks crashing due to recursive dynamic deoptimization, else the others are running. I need to understand what is going wrong there too.
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 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
vm-dev@lists.squeakfoundation.org