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).
In update #139 I do the conversion on Undeclared move. (and remove the #emit method on Association). Please test if it works⦠Marcus