> > >> Well, we need to have that discussion then, since we can't roll back: the > slots are already there, and I guess that with the Meta links, we will have > to do something about it. > > So, what would it take to improve the debugger? >
Since you can add meta links to any ast node the best approach would be to change the debugger to work at the AST level and not the bytecode level. Right now stepOver steps over a bytecode instruction and then calls #stepToSendOrReturn. I made an attempt to gave the debugger step over slot writes/reads but it is not nice at all. In a debugger at the ast level we can have actions like stepInto/Over Slot, stepInto/Over metalink, etc > Do we need to consider that the execution model shown in the debugger > needs to be a bit further away from the vm execution model? In moose we have two views for the debugger: one is the default one and the other the bytecode view. In the bytecode view you always step over one bytecode intruction and see the real stack with no hidden contexts. Cheers, Andrei > > Thierry > > > I agree with Stef that there should be a warning telling you that >> shouldn't override such selectors if you don't know what you are doing. >> >> Btw control flow selectors are not the only special selectors. You >> cannot override #== anywhere in Pharo too. >> >> >> You now have a compiler which does not make those selectors special, >> and you want to keep them special? >> >> They're kept special in any case, for compiler developers and non >> compiler developers. We do not have a compiler and a VM that do not make >> those selectors special (Yes, this is not only a compiler problem, it's >> a VM + compiler problem). As far as I know, only the Self VMs and >> compilers do not keep those selectors special. >> > > > > >> Thierry >> >> >> Marcus >> >> >> >> >> >> > >
