Hi Yoshiki,<br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 1:23 PM, Yoshiki Ohshima <span dir="ltr">&lt;<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At 28 Jun 2012 23:55:06 +0000,<br>
<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
&gt;<br>
&gt; Changes to Trunk (<a href="http://source.squeak.org/trunk.html" target="_blank">http://source.squeak.org/trunk.html</a>) in the last 24 hours:<br>
&gt;<br>
&gt; <a href="http://lists.squeakfoundation.org/pipermail/packages/2012-June/005402.html" target="_blank">http://lists.squeakfoundation.org/pipermail/packages/2012-June/005402.html</a><br>
&gt;<br>
&gt; Name: Network-eem.131<br>
&gt; Ancestors: Network-dtl.130<br>
&gt;<br>
&gt; Add some Croquet URI manipulation routines used by the<br>
&gt; Cog VMMaker to the base Network package.<br>
&gt;<br>
&gt; =============================================<br>
&gt;<br>
&gt; <a href="http://lists.squeakfoundation.org/pipermail/packages/2012-June/005403.html" target="_blank">http://lists.squeakfoundation.org/pipermail/packages/2012-June/005403.html</a><br>
&gt;<br>
&gt; Name: Kernel-eem.700<br>
&gt; Ancestors: Kernel-fbs.699<br>
&gt;<br>
&gt; Back out of my bogus fix to runUntilErrorOrReturnFrom:.<br>
&gt; My &quot;fix&quot; breaks non-local return in the debugger.<br>
&gt; I can&#39;t find my original case that justified the new code<br>
&gt; (although it was that in the debugger too much stack was<br>
&gt; unwound), and so it needs to be backed-out and we need<br>
&gt; to find good test cases to fix this correctly.<br>
&gt;<br>
&gt; =============================================<br>
<br>
The original code was something like:<br>
<br>
----------------------------------------------<br>
 Hello,<br>
<br>
I noticed that step executing the following code in debugger yields<br>
different results:<br>
<br>
-------------------<br>
test<br>
<br>
       3 &lt; 4 ifTrue: [<br>
               thisContext return: 42].<br>
       ^ 666.<br>
-------------------<br>
<br>
In the normal execution, you get 42 as expected, but if you debug it<br>
and step execute, #return: does not actuall return and you get 666.<br>
----------------------------------------------<br>
<br>
But this does not show the problem anymore it seems.  Something else<br>
changed since March 13th somehow fixed the problem.<br></blockquote><div><br></div><div>While I know you did spot that problem and we did fix it I also know that the bogus fix for  <span class="Apple-style-span" style="border-collapse:collapse;font-family:arial,sans-serif;font-size:14px">runUntilErrorOrReturnFrom: was due to a different problem.  In Newspeak we had a case in the debugger when one of our application breakpoints fired the debugger cut back too much stack.  Alas I can&#39;t find any notes on that problem or how to reproduce it.  At Cadence we&#39;re investing some effort into some good debugger tests.  Perhaps that experience will yield some similar tests for the Squeak debugger.  Avoiding regressions here when trying to fix the execution simulation machinery is, um, damned hard :)</span></div>
<div><span class="Apple-style-span" style="border-collapse:collapse;font-family:arial,sans-serif;font-size:14px"><br></span></div><div><span class="Apple-style-span" style="border-collapse:collapse;font-family:arial,sans-serif;font-size:14px"><br>
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Yoshiki<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>