<br><br><div class="gmail_quote">On Thu, Jan 26, 2012 at 11:38 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 26 January 2012 11:25, stephane ducasse <<a href="mailto:stephane.ducasse@gmail.com">stephane.ducasse@gmail.com</a>> wrote:<br>
><br>
>> phew... done reading through overquoting :)<br>
>><br>
>> +1000 to removing tryXYZprimitive:<br>
>><br>
>> I was always wondering what those methods for, until i met a need to<br>
>> support debugging when invoking nativeboost-prim methods,<br>
>> because it needs special handing when invoking methods with native<br>
>> code via debugger.<br>
>><br>
>> Then i understood that this mechanism is necessary.. yet a bit awkward..<br>
>><br>
>> Funny. Even after implementing the fix, I still do not understand why all these is needed. Can someone explain to a newbie why invoking primitives (whether they are normal primitives, named primitives or NB primitives) from the debugger is different than invoking them normally (as when they are invoked by normal code)<br>
><br>
> Yes I want to understand too.<br>
><br>
<br>
</div>Here the hint for you:<br>
- what should happen when you doing 'step in' on method, which has a primitive?<br>
<br>
Apparently, it should invoke that primitive , otherwise you will have<br>
difference between running and debugging modes,<br>
and will have different results, which makes debugger useless.<br>
So debugger should detect "somehow" if primitive was failed, and then<br>
step in into given method,<br>
or if its not, then step in = step over.<br>
<br>
And these 'tryXYZ ... ' is exactly for solving this dilemma.<br></blockquote><div><br>Thanks Igor. So I wrote what I understood. Problem is that I always write for newbies (like me) so if it is too obvios or too long to put it as comment, let me know.<br>
I would appreaciate if someone can validate what I wrote.<br>Today I will create a slice with mentioned solution + comments + removal of all those tryNamedPrimitive*.<br><br>----<br><br>"When using the debugger we want to run a method step by step. But what happens when we do a step into a <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">CompiledMethod</span> which has a primitive? If such a method is executed form outside the Debugger (normal scenario) the <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">VM</span> knows that such <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">CompiledMethod</span> has a primitive declaration and hence executes it. If it fails, then it continues executing all the <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">bytecode</span>s of the method. Otherwise, it just returns. <br>
<br>
Now, what is the problem with the Debugger? The problem is that if the primitive fail, we don't want that the <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">VM</span> directly executes all the remaining <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">bytecodes</span> of the method. Instead, we would like to go step by step <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">with</span> he Debugger, just as happens with normal methods. <br>
<br>
To solve the mentioned problem, we use the following trick: We have the
original compiled method (the one that has a primitive invocation), the
receiver and the arguments. So the idea is to use a template compiled
method that ONLY contains the primitive declaration (it doesn't include
all the original smalltalk code after the primitive). #<span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">tryNamedPrimitiveTemplateMethod</span> answers such a template method which looks like:<br>
<br>
<span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">tryNamedPrimitive</span><br>
<primitive:'to be set later' module:'to be ser later'><br>
^ <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">ContextPart</span> primitiveFailToken'<br>
<br>
Since this method does not change its <span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">bytecodes</span>
for every invocation, we can reuse it for all methods with primitives.
There are only 2 things we have to change in the template: the number of
arguments and the primitive declaration (to use the correct primitive
name and module name).<br>
<br>
Then what we do is to run that compiled method with the receiver and
arguments we have. The result is that we will be invoking almost the
same original method but a slightly different version that does not have
the smalltalk part after the primitive and that in contrast is sends #<span style="background:none repeat scroll 0% 0% yellow" class="J-JK9eJ-PJVNOc">primitiveFailToken</span>
(which tells the Debugger what to do after). If this method invocation
does not fail, then the Debugger continues debugging the sender of the
primitive method. In this case, the step in is the same as step over. If
the primitive fails, then the debugger continues executing the
smalltalk part after the primitive method. In this case, step in is a
real step in. "<br clear="all"><br><br><br><br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>