Debugger / Simulator cannot simulate (some) objects as methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugger / Simulator cannot simulate (some) objects as methods

cmfcmf
Hi,

when using simple objects as methods, the simulator (and therefore the
debugger also) raises an error if the object used as method does not
implement certain methods from CompiledMethod (e.g., numArgs). If such code
is debugged, the debugger opens a never-ending stream of error windows.

I am under the (possibly wrong) assumption that objects as methods should
_not_ need to implement the complete CompiledMethod protocol to be
compatible with simulation and debugging.

I have attached a failing test called Context2Test that uses the simulator
to simulate a call of an object as method. You can also see the
"never-ending stream of error windows" by placing a "self halt" at the top
of the test and then stepping through the first assertion using the "over"
button. WARNING: Might make your image unusable.

The root cause is the Context >> #send:to:with:lookupIn: method which
assumes that all methods are CompiledMethods. I have attached a simple fix
that works great for me – let me know what you think about it.

Best
Christian

Context2Test.st <http://forum.world.st/file/t372201/Context2Test.st>  
Context-sendtowithlookupIn.st
<http://forum.world.st/file/t372201/Context-sendtowithlookupIn.st>  



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

marcel.taeumel
Hi Christan,

the object-as-method support in the debuuger and code simulator has never been good. :-( Not back in Squeak 3.x, not now. Maybe we can fix some of the most urgent bugs. :-)

Best,
Marcel

Am 21.10.2020 15:09:35 schrieb cmfcmf <[hidden email]>:

Hi,

when using simple objects as methods, the simulator (and therefore the
debugger also) raises an error if the object used as method does not
implement certain methods from CompiledMethod (e.g., numArgs). If such code
is debugged, the debugger opens a never-ending stream of error windows.

I am under the (possibly wrong) assumption that objects as methods should
_not_ need to implement the complete CompiledMethod protocol to be
compatible with simulation and debugging.

I have attached a failing test called Context2Test that uses the simulator
to simulate a call of an object as method. You can also see the
"never-ending stream of error windows" by placing a "self halt" at the top
of the test and then stepping through the first assertion using the "over"
button. WARNING: Might make your image unusable.

The root cause is the Context >> #send:to:with:lookupIn: method which
assumes that all methods are CompiledMethods. I have attached a simple fix
that works great for me – let me know what you think about it.

Best
Christian

Context2Test.st
Context-sendtowithlookupIn.st




--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

Eliot Miranda-2
In reply to this post by cmfcmf
Hi,

> On Oct 21, 2020, at 6:09 AM, cmfcmf <[hidden email]> wrote:
>
> Hi,
>
> when using simple objects as methods, the simulator (and therefore the
> debugger also) raises an error if the object used as method does not
> implement certain methods from CompiledMethod (e.g., numArgs). If such code
> is debugged, the debugger opens a never-ending stream of error windows.
>
> I am under the (possibly wrong) assumption that objects as methods should
> _not_ need to implement the complete CompiledMethod protocol to be
> compatible with simulation and debugging.

Since the only gap that needs filling is from the retrieval of the object from the method dictionary to the send of run:asMethod:withAruuments: (or whatever the actual selector is) let me suggest that you create a wrapper class whose instances hold on to an object to be run as a method and the selector and argument count and respond to the required CompiledCode protocol.  Then modify the simulator at the point where it gets the result of the message lookup from the dictionary and wraps the result in one of these if it is neither CompiledCode (isCompiledCode) not nil. We don’t want to litter the simulation code with checks and the wrapper approach has the best chance.

Of course another test will be needed before a new contest is created, and maybe one test at the top of the tryPrimitive: method.

>
> I have attached a failing test called Context2Test that uses the simulator
> to simulate a call of an object as method. You can also see the
> "never-ending stream of error windows" by placing a "self halt" at the top
> of the test and then stepping through the first assertion using the "over"
> button. WARNING: Might make your image unusable.
>
> The root cause is the Context >> #send:to:with:lookupIn: method which
> assumes that all methods are CompiledMethods. I have attached a simple fix
> that works great for me – let me know what you think about it.
>
> Best
> Christian
>
> Context2Test.st <http://forum.world.st/file/t372201/Context2Test.st>  
> Context-sendtowithlookupIn.st
> <http://forum.world.st/file/t372201/Context-sendtowithlookupIn.st>  
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>

Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

Christoph Thiede

Hi Christian, hi all,


I already implemented the simulation of objects as methods in Kernel-ct.1339 (Inbox). It has been working fine for me since February - we only need to get things like this merged sooner to prevent everyone from reinventing the wheel. :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 21. Oktober 2020 16:59:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Debugger / Simulator cannot simulate (some) objects as methods
 
Hi,

> On Oct 21, 2020, at 6:09 AM, cmfcmf <[hidden email]> wrote:
>
> Hi,
>
> when using simple objects as methods, the simulator (and therefore the
> debugger also) raises an error if the object used as method does not
> implement certain methods from CompiledMethod (e.g., numArgs). If such code
> is debugged, the debugger opens a never-ending stream of error windows.
>
> I am under the (possibly wrong) assumption that objects as methods should
> _not_ need to implement the complete CompiledMethod protocol to be
> compatible with simulation and debugging.

Since the only gap that needs filling is from the retrieval of the object from the method dictionary to the send of run:asMethod:withAruuments: (or whatever the actual selector is) let me suggest that you create a wrapper class whose instances hold on to an object to be run as a method and the selector and argument count and respond to the required CompiledCode protocol.  Then modify the simulator at the point where it gets the result of the message lookup from the dictionary and wraps the result in one of these if it is neither CompiledCode (isCompiledCode) not nil. We don’t want to litter the simulation code with checks and the wrapper approach has the best chance.

Of course another test will be needed before a new contest is created, and maybe one test at the top of the tryPrimitive: method.

>
> I have attached a failing test called Context2Test that uses the simulator
> to simulate a call of an object as method. You can also see the
> "never-ending stream of error windows" by placing a "self halt" at the top
> of the test and then stepping through the first assertion using the "over"
> button. WARNING: Might make your image unusable.
>
> The root cause is the Context >> #send:to:with:lookupIn: method which
> assumes that all methods are CompiledMethods. I have attached a simple fix
> that works great for me – let me know what you think about it.
>
> Best
> Christian
>
> Context2Test.st <http://forum.world.st/file/t372201/Context2Test.st
> Context-sendtowithlookupIn.st
> <http://forum.world.st/file/t372201/Context-sendtowithlookupIn.st
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

cmfcmf
Hi, 

Christoph – great to hear that you also ran into this issue and have already proposed a very similar fix (your fix even being a bit more 'correct' than mine, since it avoids sending the class message)!

Eliot – thank you for your insights. If I'm not mistaken, your proposed solution would add additional restrictions to objects as methods (OAMs) during simulation and debugging. This is because OAMs are more flexible than CompiledMethods: For example, unlike a CompiledMethod, an OAM does not have a fixed number of arguments it can respond to. Take a look at the following OAM that responds to a message send with the number of arguments sent:

run: selector with: arguments in: aReceiver
    ^ arguments size

The proposed wrapper class would not be able to adequately respond to the numArgs message for this OAM.

I personally also don't feel like adjusting a single method inside the simulator by adding a check for OAMs would "litter the simulation code".

Best,
Christian

Am Do., 22. Okt. 2020 um 19:28 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi Christian, hi all,


I already implemented the simulation of objects as methods in Kernel-ct.1339 (Inbox). It has been working fine for me since February - we only need to get things like this merged sooner to prevent everyone from reinventing the wheel. :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 21. Oktober 2020 16:59:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Debugger / Simulator cannot simulate (some) objects as methods
 
Hi,

> On Oct 21, 2020, at 6:09 AM, cmfcmf <[hidden email]> wrote:
>
> Hi,
>
> when using simple objects as methods, the simulator (and therefore the
> debugger also) raises an error if the object used as method does not
> implement certain methods from CompiledMethod (e.g., numArgs). If such code
> is debugged, the debugger opens a never-ending stream of error windows.
>
> I am under the (possibly wrong) assumption that objects as methods should
> _not_ need to implement the complete CompiledMethod protocol to be
> compatible with simulation and debugging.

Since the only gap that needs filling is from the retrieval of the object from the method dictionary to the send of run:asMethod:withAruuments: (or whatever the actual selector is) let me suggest that you create a wrapper class whose instances hold on to an object to be run as a method and the selector and argument count and respond to the required CompiledCode protocol.  Then modify the simulator at the point where it gets the result of the message lookup from the dictionary and wraps the result in one of these if it is neither CompiledCode (isCompiledCode) not nil. We don’t want to litter the simulation code with checks and the wrapper approach has the best chance.

Of course another test will be needed before a new contest is created, and maybe one test at the top of the tryPrimitive: method.

>
> I have attached a failing test called Context2Test that uses the simulator
> to simulate a call of an object as method. You can also see the
> "never-ending stream of error windows" by placing a "self halt" at the top
> of the test and then stepping through the first assertion using the "over"
> button. WARNING: Might make your image unusable.
>
> The root cause is the Context >> #send:to:with:lookupIn: method which
> assumes that all methods are CompiledMethods. I have attached a simple fix
> that works great for me – let me know what you think about it.
>
> Best
> Christian
>
> Context2Test.st <http://forum.world.st/file/t372201/Context2Test.st
> Context-sendtowithlookupIn.st
> <http://forum.world.st/file/t372201/Context-sendtowithlookupIn.st
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>




Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

Eliot Miranda-2
Hi Christian,

On Oct 23, 2020, at 9:32 AM, Christian Flach <[hidden email]> wrote:


Hi, 

Christoph – great to hear that you also ran into this issue and have already proposed a very similar fix (your fix even being a bit more 'correct' than mine, since it avoids sending the class message)!

Eliot – thank you for your insights. If I'm not mistaken, your proposed solution would add additional restrictions to objects as methods (OAMs) during simulation and debugging. This is because OAMs are more flexible than CompiledMethods: For example, unlike a CompiledMethod, an OAM does not have a fixed number of arguments it can respond to. Take a look at the following OAM that responds to a message send with the number of arguments sent:

run: selector with: arguments in: aReceiver
    ^ arguments size

The proposed wrapper class would not be able to adequately respond to the numArgs message for this OAM.

Well a wrapper could have as much stats as one wanted, but ...


I personally also don't feel like adjusting a single method inside the simulator by adding a check for OAMs would "litter the simulation code".

Cool, glad to hear only one method is changed.  Can we not move this to trunk?


Best,
Christian

Am Do., 22. Okt. 2020 um 19:28 Uhr schrieb Thiede, Christoph <[hidden email]>:

Hi Christian, hi all,


I already implemented the simulation of objects as methods in Kernel-ct.1339 (Inbox). It has been working fine for me since February - we only need to get things like this merged sooner to prevent everyone from reinventing the wheel. :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Mittwoch, 21. Oktober 2020 16:59:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Debugger / Simulator cannot simulate (some) objects as methods
 
Hi,

> On Oct 21, 2020, at 6:09 AM, cmfcmf <[hidden email]> wrote:
>
> Hi,
>
> when using simple objects as methods, the simulator (and therefore the
> debugger also) raises an error if the object used as method does not
> implement certain methods from CompiledMethod (e.g., numArgs). If such code
> is debugged, the debugger opens a never-ending stream of error windows.
>
> I am under the (possibly wrong) assumption that objects as methods should
> _not_ need to implement the complete CompiledMethod protocol to be
> compatible with simulation and debugging.

Since the only gap that needs filling is from the retrieval of the object from the method dictionary to the send of run:asMethod:withAruuments: (or whatever the actual selector is) let me suggest that you create a wrapper class whose instances hold on to an object to be run as a method and the selector and argument count and respond to the required CompiledCode protocol.  Then modify the simulator at the point where it gets the result of the message lookup from the dictionary and wraps the result in one of these if it is neither CompiledCode (isCompiledCode) not nil. We don’t want to litter the simulation code with checks and the wrapper approach has the best chance.

Of course another test will be needed before a new contest is created, and maybe one test at the top of the tryPrimitive: method.

>
> I have attached a failing test called Context2Test that uses the simulator
> to simulate a call of an object as method. You can also see the
> "never-ending stream of error windows" by placing a "self halt" at the top
> of the test and then stepping through the first assertion using the "over"
> button. WARNING: Might make your image unusable.
>
> The root cause is the Context >> #send:to:with:lookupIn: method which
> assumes that all methods are CompiledMethods. I have attached a simple fix
> that works great for me – let me know what you think about it.
>
> Best
> Christian
>
> Context2Test.st <http://forum.world.st/file/t372201/Context2Test.st
> Context-sendtowithlookupIn.st
> <http://forum.world.st/file/t372201/Context-sendtowithlookupIn.st
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>





Reply | Threaded
Open this post in threaded view
|

Re: Debugger / Simulator cannot simulate (some) objects as methods

Christoph Thiede
In reply to this post by marcel.taeumel

Hi Marcel,


which bugs are there that are not fixed with Kernel-ct.1339? :-)


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 21. Oktober 2020 15:40:50
An: squeak-dev
Betreff: Re: [squeak-dev] Debugger / Simulator cannot simulate (some) objects as methods
 
Hi Christan,

the object-as-method support in the debuuger and code simulator has never been good. :-( Not back in Squeak 3.x, not now. Maybe we can fix some of the most urgent bugs. :-)

Best,
Marcel

Am 21.10.2020 15:09:35 schrieb cmfcmf <[hidden email]>:

Hi,

when using simple objects as methods, the simulator (and therefore the
debugger also) raises an error if the object used as method does not
implement certain methods from CompiledMethod (e.g., numArgs). If such code
is debugged, the debugger opens a never-ending stream of error windows.

I am under the (possibly wrong) assumption that objects as methods should
_not_ need to implement the complete CompiledMethod protocol to be
compatible with simulation and debugging.

I have attached a failing test called Context2Test that uses the simulator
to simulate a call of an object as method. You can also see the
"never-ending stream of error windows" by placing a "self halt" at the top
of the test and then stepping through the first assertion using the "over"
button. WARNING: Might make your image unusable.

The root cause is the Context >> #send:to:with:lookupIn: method which
assumes that all methods are CompiledMethods. I have attached a simple fix
that works great for me – let me know what you think about it.

Best
Christian

Context2Test.st
Context-sendtowithlookupIn.st




--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html



Carpe Squeak!