Instantiating a ProtoObject subclass fails
tom95 opened this issue · comments
(ignore the second comment, had accidentally used sentTo: instead of sendTo:)
Still, we keep erroring after DNU is implemented because the DNU impl is called outside the sandboxed context during instance initialization, I believe.
Sorry, I cannot yet reproduce this issue. The following expressions all work for me in the sandbox in the same way as when executed directly:
ProtoObject new
MyEmptyProtoObejct new
MyEmptyProtoObejct new yourself
MyEmptyProtoObejct new identityHash
(this triggers a primitive)
What is the expression/block that is passed to Sandbox >> #evaluate:
?
Do you have the latest Trunk updates installed? There was a fix in Context >> #isPrimFailToken:
that was merged quite recently (I think <2 weeks) into the Trunk.
I'm not sure whether this relates, but something else that is currently not supported in the sandbox is the creation of custom subclasses. Once you edit a method dictionary from within the sandbox, you will get in trouble because the method lookup does not consider the sandbox object space at the moment. But this is not the problem you are suffering from right now, is it?
(ignore the second comment, had accidentally used sentTo: instead of sendTo:)
Haha, this happens to me all the time :D
Ah the issue's wording was very unclear, sorry!
It's in fact only if the ProtoObject is the receiver/context of the execution, so the scenario you get during autocompletion in Sandblocks.
Alright, now I was able to reproduce an issue by trying to guess the type of a block for ProtoObject new
in Sandblocks and it did not understand #class
. Was this the error you were referring to?
Funny. This incident actually was caused by a number of issues:
#class
is actually implemented onObject
only, but because it is compiled as a special message send, when executed directly, the VM will execute the primitive anyway. But this does not apply to the simulator, so it's easy to forget that you must not send#class
to any instance that might not haveObject
in its superclasses.- There was a bug in the simulator (
Context >> #send:to:with:lookupIn:
) that led to false error messages from the simulator, rather than executing#doesNotUnderstand:
onProtoObject
correctly.
Regarding 1, I just sent a small PR to Sandblocks, please see hpi-swa/sandblocks#58.
Regarding 2, I have uploaded a fix for this issue to the Trunk, see Kernel-ct.1425.
tl;dr: If you update your image, you should not see any debuggers any longer. If you also want non-nil guessed classes for ProtoObject new
, then please take a look at my Sandblocks PR. :-)
Working perfectly now! Thank you for the fixes and the sandblocks PR, I'll go ahead and close this issue now :)