Marcus
would not it make sense to emit a bytecode marker (kind of no-op) so
that the tools can get more information
about the encoded computation and get some abtsraction?
Stef
Le 16/1/15 18:22, Andrei Chis a écrit :
On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker <[email protected]
<mailto:[email protected]>> wrote:
> On 16 Jan 2015, at 12:12, Andrei Chis
<[email protected] <mailto:[email protected]>>
wrote:
>
> For me it's ok like it is now.
>
>
> I updated the GTDebuggers to use slots.
> For example you can use the bytecode one to see what actually
gets executed (and even step into the code of the slot).
>
> <Screen Shot 2015-01-16 at 4.06.03 PM.png>
>
Wow! And just like that, the byte code debugger is actually very
useful to see what happens for real with Slots…. very useful
especially when
you emit you own byte code for a Slot.
> Now the other problem is that because reading a slot uses
#send:read: the debugger will now stop at that instruction so one
has to do an explicit step over to read the actual slot.
> The logic that performs this check is now isolated in
#stepToFirstInterestingBytecodeIn: so we could updated it to take
slots into account.
>
Yes, that would be nice.
I made an issue:
https://pharo.fogbugz.com/f/cases/14743/The-debugger-should-skip-the-reading-of-slots
Now there is still the issue of stepping into a slot write, when
stepping into instructions.
One solution could be to have a setting that makes the debugger slot
sensitive (stepping into enters both slot reads and slot writes).
However, with the bytecode debugger one can easily step into slots.
Cheers,
Andrei
Marcus
