On Fri, Jan 16, 2015 at 4:22 PM, Marcus Denker <[email protected]> wrote:
> > > On 16 Jan 2015, at 12:12, Andrei Chis <[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 >
