2015-05-01 13:59 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

Le 01/05/2015 13:43, Cl��ment Bera a ��crit :

2015-05-01 11:58 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com
<mailto:thierry.goubier@gmail.com>>:

�� Le 01/05/2015 11:50, Marcus Denker a ��crit :

�� On 01 May 2015, at 11:48, stepharo <stepharo@free.fr
�� <mailto:stepharo@free.fr>> 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