[Vm-dev] Something weird with prim 83/84/100

Boris Shingarov boris at shingarov.com
Sat Oct 29 20:50:29 UTC 2022


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-build/squeak.cog.spur_linux64x64.tar.gz 
(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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20221029/fca2ffa5/attachment.html>


More information about the Vm-dev mailing list