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... 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