On Fri, Jun 29, 2012 at 2:07 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>wrote:

> 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.
>

+1.  We need debugger tests.


>
> -- Yoshiki
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120629/7c42453a/attachment.htm