Le 01/05/2015 13:43, Clément Bera a écrit :
2015-05-01 11:58 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>>:
Le 01/05/2015 11:50, Marcus Denker a écrit :
On 01 May 2015, at 11:48, stepharo <steph...@free.fr
<mailto:steph...@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?
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
