On Fri, Jun 29, 2012 at 2:07 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.orgwrote:
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@acm.org> wrote:
At 28 Jun 2012 23:55:06 +0000, commits@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