[squeak-dev] Daily Commit Log
Yoshiki Ohshima
Yoshiki.Ohshima at acm.org
Fri Jun 29 21:07:48 UTC 2012
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
More information about the Squeak-dev
mailing list
|