<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Boris,<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">   in trunk Squeak 6.1 alpha, VM Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3256] 5.20221022.0042, I get the debugger both ways. Both routes, testDirect & testIndirect result in a notifier failing in primitives 83, 84 & 100.  The failure code for #100, Object>>#perform:withArguments:inSuperclass:, infers that the number of arguments is incorrect.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When I modify the source of these methods to include the primitive error code then in each failure the VM correctly supplies the #'bad number of arguments' error code.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So I see a correct system.  I'm not seeing what you're seeing.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 21, 2022 at 6:54 AM Boris Shingarov <<a href="mailto:boris@shingarov.com">boris@shingarov.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> Dear fellow VM hackers:<br>
There is something about the #perform: prims I do not understand.<br>
<br>
If I send #perform: not giving it enough arguments, I would expect the <br>
primitive to fail through to the Smalltalk code in <br>
Object>>perform:withArguments:inSuperclass:.<br>
<br>
But, sometimes it's indeed what happens and sometimes it's not what <br>
happens.  In the attached test , if you run testDirect (in this <br>
morning's Squeak6) you will end up in the debugger (expected), but if <br>
you wrap in an extra send such as testIndirect, the prim will pass nil <br>
for the missing argument (to me this is unexpected).  I also tested in <br>
last night's build of Cuis, and in Pharo8 (in the latter, the behavior <br>
is even weirder: if you replace the fail code to answer #somethingElse, <br>
you get #(somethingElse false false) instead of the #(false false false) <br>
in Squeak).<br>
<br>
Anyone has any thoughts on this?<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>