On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker <marcus.denker@inria.fr> wrote:

> On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei@gmail.com> 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