2015-05-01 13:59 GMT+02:00 Thierry Goubier <[email protected]>:
> Le 01/05/2015 13:43, Clément Bera a écrit : > >> >> >> 2015-05-01 11:58 GMT+02:00 Thierry Goubier <[email protected] >> <mailto:[email protected]>>: >> >> Le 01/05/2015 11:50, Marcus Denker a écrit : >> >> >> On 01 May 2015, at 11:48, stepharo <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> >> To make the whole thing easier to understand we need to >> distinguish the two bugs. >> >> 1) or: is somehow special. No, it is not. We fixed that, >> but the fix was broken. >> >> >> This is wrong. They are special for non compiler developer. I explain >> why below. >> >> See my other mail. >> I would add two different kind of rules to help people and >> slow the use of redefinition of special selectors. >> >> >> >> I do not understand why. >> >> >> I side with Marcus there. Why? >> >> >> Why ? >> >> Because you can't debug them normally. If they're executed normally, you >> cannot step into sends using these selectors on the contrary to any >> other send because they are inlined, which is light because most of the >> time you don't want to step into these selectors. If they're executed on >> non boolean, the debugger shows the whole #mustBeBoolean, >> #mustBeBooleanIn: and #ExecuteUnoptimizedIn: stack of noise, and that's >> assuming the ExecuteUnoptimizedIn: would work in any case without errors. >> >> They are very special because they can't be debugged as other selectors. >> And I'm not talking about rare cases which make these selectors only >> slightly special, like for example where you run out of literals in a >> method, the method is not shown in the list of senders of the special >> selectors it uses. >> >> Debugging has already become much harder now that we have slots: the >> debugger highlights an instance variable in a frame whereas there are >> frames below, so you now have to understand slots to debug code. It is >> not possible to make the debugger compliant with slots because the >> debugger has access only to the bottom 20 frames of the active stack for >> other good reasons such as a very deep recursive stack, and if the >> instance variable access with a slot is not in these bottom 20 frames, >> the debugger can't detect it. >> >> Now in addition, you're telling me that for some selectors in specific >> cases instead of the regular stack I will have #mustBeBoolean, >> #mustBeBooleanIn: and #ExecuteUnoptimizedIn: inserted into the stack. So >> to debug code, you have to understand this hack too. >> >> What is the next step ? Do you want the debugger to show a stack mainly >> unrelated to what the programmer wrote that only compiler developers can >> understand ? Are we also in Pharo in the philosophy where we don't care >> about how bad is the debugger ? >> > > 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? > > 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? That's the way to go. I think some people like Camille are already working on it. Basically, you need abstraction over what is happening which is implemented in the image instead of the VM for simplicity and maintenance, and what the programmer wants to see which is relevant for him. For optimized selectors, one could mark the methods with pragmas as 'Do not show in debugger' and in addition rewire the bytecode to source code mapping from the method compiled on-the-fly executed in ExecuteUnoptimizedIn: to the regular method. But as I stated for Slots, it is more complicated. The debugger cannot detect if the stack is currently in a slot access, as it has access only to the bottom 20 frames. Having the debugger access the full stack is a bad idea as it would slow it considerably, making the debugger unusable on devices such as the raspberry pie, and hard to use to debug recursive code. Maybe a solution could be that if the compiled bytecode for a slot has an interrupt point (branch, back jump, send), then it could change a state in the process, probably encoded in the process instance variables, and as the debugger has access to the process it is showing it would know. > > > 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 >> >> >> >> >> >> > >
