[squeak-dev] Daily Commit Log

Eliot Miranda eliot.miranda at gmail.com
Fri Jun 29 20:48:59 UTC 2012


Hi Yoshiki,

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 :)



> -- Yoshiki
>
>


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


More information about the Squeak-dev mailing list