[Vm-dev] Problem understanding #cannotInterpret

[Mariano Martinez Peck]

On Sun, Jan 16, 2011 at 1:26 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> AFAIK, #cannotInterpret: is sent to super
>

yes, I know, this is why in my case I implemented that in the superclass.


>
>
> >
> > Now, this is working, but there is something I DO NOT UNSERSTAND. When I
> try to do the "inst basicIdentityHash" the VM will send the #cannotInterpret
> to ProxySuperclass because the methodDict was nil in ClassProxyInstVar. Ok,
> perfect. What I don't understand is how the method #cannotInterptet can be
> run perfeclty in this case, since I am doing a "self class restore" there.
> Remember I removed the shortcut bytecode, so #class is sent like any normal
> message. So, my question is, when sending "self class", why the VM doesn't
> call #cannotInterpter again like it did it when I did "   inst
> basicIdentityHash."  ?  in other words...why the VM isn't entering in a loop
> ?   There is something I am not seeing.
> >
>
> check the bytecode of method. A special sends, which shortcutted using
> different bytecode.
>

Yes, but I disable them, by evaluating: "(ParseNode classVarNamed:
'StdSelectors') removeKey: #class ifAbsent: []."


>
> To avoid self sends, which will lead to infinite loop, you can use the
> message's lookupClass to send message to class side:
>
> aMessage lookupClass restore.
>


This is a good trick!!!  This was really helpful Igor.

Anyway, now I found which was my problem. I mean, I understood why it was
not causing a loop and was working instead. The thing is that I evaluated
"(ParseNode classVarNamed:  'StdSelectors') removeKey: #class ifAbsent:
[]."  but then I check the the implemenation of #cannotInterpret and it was
still using the shortcut bytecode for #class. Why ?  because I forget a
Compiler recompileAll!!!!   hehehehe :)

thanks

Mariano


>
> > Thanks for any help in advance,
> >
> > Mariano
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110117/1583945c/attachment.htm