At Fri, 29 Jun 2012 13:48:59 -0700,
Eliot Miranda wrote:
> 
> On Fri, Jun 29, 2012 at 1:23 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
> 
>     At 28 Jun 2012 23:55:06 +0000,
>     commits at source.squeak.org wrote:
>     >
>     > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours:
>     >
>     > http://lists.squeakfoundation.org/pipermail/packages/2012-June/005402.html
>     >
>     > Name: Network-eem.131
>     > Ancestors: Network-dtl.130
>     >
>     > Add some Croquet URI manipulation routines used by the
>     > Cog VMMaker to the base Network package.
>     >
>     > =============================================
>     >
>     > http://lists.squeakfoundation.org/pipermail/packages/2012-June/005403.html
>     >
>     > Name: Kernel-eem.700
>     > Ancestors: Kernel-fbs.699
>     >
>     > Back out of my bogus fix to runUntilErrorOrReturnFrom:.
>     > My "fix" breaks non-local return in the debugger.
>     > I can't find my original case that justified the new code
>     > (although it was that in the debugger too much stack was
>     > unwound), and so it needs to be backed-out and we need
>     > to find good test cases to fix this correctly.
>     >
>     > =============================================
>    
>     The original code was something like:
>    
>     ----------------------------------------------
>      Hello,
>    
>     I noticed that step executing the following code in debugger yields
>     different results:
>    
>     -------------------
>     test
>    
>           3 < 4 ifTrue: [
>                   thisContext return: 42].
>           ^ 666.
>     -------------------
>    
>     In the normal execution, you get 42 as expected, but if you debug it
>     and step execute, #return: does not actuall return and you get 666.
>     ----------------------------------------------
>    
>     But this does not show the problem anymore it seems.  Something else
>     changed since March 13th somehow fixed the problem.
> 
> 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
> 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
> 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 :)

Thanks!

I'm still curious which other change (unintentionally, perhaps)
"fixed" the test case above, however.

-- Yoshiki