On 18 Jul 2014, at 10:38, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jul 2014, at 10:26, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jul 2014, at 10:20, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jul 2014, at 10:16, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi,
when my image tries to run startup scripts I get:
Association(Object)>>doesNotUnderstand: #emitValue:
Should I report it?
Yes. It should not happen.
But startup script are very strange as they somehow hold onto compiled code.
Do you have a way to recreate it?
What happens is that somehow a global or class variable still is an association. (I just added tests that make sure that Smalltalk globals as well as all classPools are well formedâ¦)
I added tests in 099 to check that all binding are correct in Smalltalk globals and all classPools.
It seems that someone is adding global somehow with the wrong class (Association instead of GlobalVar (a subclass of Association).
But #at:put: should do the right thing in SystemDictionaryâ¦
The most likely candidate is Undeclared handling⦠yes, that has to be it. The unknown binding is put into Undeclared as an association and then just moved over, while it should switch the type (depending on if it is a global or a class var).
I will fix that.
as a workaround, you can add the method
emitValue: methodBuilder methodBuilder pushLiteralVariable: self.
I will add for now the workaround⦠I found the place where to fix it, too, but that needs then some testing. Marcus