Daily Commit Log

At 28 Jun 2012 23:55:06 +0000,
[hidden email] 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.

-- Yoshiki

At Fri, 29 Jun 2012 13:48:59 -0700,

Eliot Miranda wrote:
>
> On Fri, Jun 29, 2012 at 1:23 PM, Yoshiki Ohshima <[hidden email]> wrote:
>
>     At 28 Jun 2012 23:55:06 +0000,
>     [hidden email] 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