<br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 2:07 PM, Yoshiki Ohshima <span dir="ltr"><<a href="mailto:Yoshiki.Ohshima@acm.org" target="_blank">Yoshiki.Ohshima@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At Fri, 29 Jun 2012 13:48:59 -0700,<br>
<div><div class="h5">Eliot Miranda wrote:<br>
><br>
> On Fri, Jun 29, 2012 at 1:23 PM, Yoshiki Ohshima <<a href="mailto:Yoshiki.Ohshima@acm.org">Yoshiki.Ohshima@acm.org</a>> wrote:<br>
><br>
> At 28 Jun 2012 23:55:06 +0000,<br>
> <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
> ><br>
> > 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>
> ><br>
> > <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>
> ><br>
> > Name: Network-eem.131<br>
> > Ancestors: Network-dtl.130<br>
> ><br>
> > Add some Croquet URI manipulation routines used by the<br>
> > Cog VMMaker to the base Network package.<br>
> ><br>
> > =============================================<br>
> ><br>
> > <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>
> ><br>
> > Name: Kernel-eem.700<br>
> > Ancestors: Kernel-fbs.699<br>
> ><br>
> > Back out of my bogus fix to runUntilErrorOrReturnFrom:.<br>
> > My "fix" breaks non-local return in the debugger.<br>
> > I can't find my original case that justified the new code<br>
> > (although it was that in the debugger too much stack was<br>
> > unwound), and so it needs to be backed-out and we need<br>
> > to find good test cases to fix this correctly.<br>
> ><br>
> > =============================================<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 < 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>
><br>
> While I know you did spot that problem and we did fix it I also know that the bogus fix for runUntilErrorOrReturnFrom: was due to a different problem. In Newspeak we had a case in the<br>
> debugger when one of our application breakpoints fired the debugger cut back too much stack. Alas I can't find any notes on that problem or how to reproduce it. At Cadence we're investing<br>
> 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<br>
> simulation machinery is, um, damned hard :)<br>
<br>
</div></div>Thanks!<br>
<br>
I'm still curious which other change (unintentionally, perhaps)<br>
"fixed" the test case above, however.<br></blockquote><div><br></div><div>+1. We need debugger tests.</div><div> </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>