Instantiating a ProtoObject subclass fails

[tom95]

It appears that the isArray check for isPrimFailToken: will lead to trouble when working with an "incomplete" proxy, aka a ProtoObject that doesn't yet have a doesNotUnderstand:

[tom95]

Not sure if this relevant after the above has been fixed, but even after implementing DNU (which is by default of course forwarded to nil every time in the Sandbox), I get this follow-up error (cant open a debugger here, same exception gets thrown around):

[tom95]

(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.

[LinqLover]

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

[tom95]

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.

[LinqLover]

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:

1. #class is actually implemented on Object 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 have Object in its superclasses.
2. 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: on ProtoObject correctly.

Regarding 1, I just sent a small PR to Sandblocks, please see https://github.com/tom95/sandblocks/pull/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. :-)

[tom95]

Working perfectly now! Thank you for the fixes and the sandblocks PR, I'll go ahead and close this issue now :)