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 <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 16 Jan 2015, at 12:12, Andrei Chis <chisvasileandrei@gmail.com <mailto: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