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.
=============================================
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.
-- Yoshiki
Hi Yoshiki,
On Fri, Jun 29, 2012 at 1:23 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.orgwrote:
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 :)
-- Yoshiki
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.
-- Yoshiki
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
squeak-dev@lists.squeakfoundation.org