Dear fellow VM hackers: There is something about the #perform: prims I do not understand.
If I send #perform: not giving it enough arguments, I would expect the primitive to fail through to the Smalltalk code in Object>>perform:withArguments:inSuperclass:.
But, sometimes it's indeed what happens and sometimes it's not what happens. In the attached test , if you run testDirect (in this morning's Squeak6) you will end up in the debugger (expected), but if you wrap in an extra send such as testIndirect, the prim will pass nil for the missing argument (to me this is unexpected). I also tested in last night's build of Cuis, and in Pharo8 (in the latter, the behavior is even weirder: if you replace the fail code to answer #somethingElse, you get #(somethingElse false false) instead of the #(false false false) in Squeak).
Anyone has any thoughts on this?
Hi Boris,
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.
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.
So I see a correct system. I'm not seeing what you're seeing.
On Fri, Oct 21, 2022 at 6:54 AM Boris Shingarov boris@shingarov.com wrote:
Dear fellow VM hackers: There is something about the #perform: prims I do not understand.
If I send #perform: not giving it enough arguments, I would expect the primitive to fail through to the Smalltalk code in Object>>perform:withArguments:inSuperclass:.
But, sometimes it's indeed what happens and sometimes it's not what happens. In the attached test , if you run testDirect (in this morning's Squeak6) you will end up in the debugger (expected), but if you wrap in an extra send such as testIndirect, the prim will pass nil for the missing argument (to me this is unexpected). I also tested in last night's build of Cuis, and in Pharo8 (in the latter, the behavior is even weirder: if you replace the fail code to answer #somethingElse, you get #(somethingElse false false) instead of the #(false false false) in Squeak).
Anyone has any thoughts on this?
Hi Eliot,
Probably I am doing something incredibly stupid.
I just re-downloaded today's 6.1alpha (Squeak6.1alpha-22266-64bit-202206021410-Linux-x64.tar.gz, 28902799 bytes long, md5sum = 6c1...63a), and tried first with the VM that comes inside that tarball (Smalltalk vmVersion -> 3195) and then with today's VM build from https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/download/latest-b... (3236277 bytes, md5 = cbf...6d8, Smalltalk vmVersion -> 3256).
With both 3195 and 3256, "run test" on testIndirect gives me a "Halt:" on an Array of 3 elements { false. false. false }. I can't get prim 100 to fail.
Boris
On 10/27/22 15:38, Eliot Miranda wrote:
Hi Boris,
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.
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.
So I see a correct system. I'm not seeing what you're seeing.
On Fri, Oct 21, 2022 at 6:54 AM Boris Shingarov boris@shingarov.com wrote:
Dear fellow VM hackers: There is something about the #perform: prims I do not understand. If I send #perform: not giving it enough arguments, I would expect the primitive to fail through to the Smalltalk code in Object>>perform:withArguments:inSuperclass:. But, sometimes it's indeed what happens and sometimes it's not what happens. In the attached test , if you run testDirect (in this morning's Squeak6) you will end up in the debugger (expected), but if you wrap in an extra send such as testIndirect, the prim will pass nil for the missing argument (to me this is unexpected). I also tested in last night's build of Cuis, and in Pharo8 (in the latter, the behavior is even weirder: if you replace the fail code to answer #somethingElse, you get #(somethingElse false false) instead of the #(false false false) in Squeak). Anyone has any thoughts on this?
-- _,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org