On 23.06.2015, at 18:37, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Marcel,
On Jun 23, 2015, at 2:44 AM, "marcel.taeumel" Marcel.Taeumel@hpi.de wrote:
Hi, all.
I understood the changed behavior. Eliot is right, we need to update Warning
#defaultAction so that it behaves like Halt >> #defaultAction. Let me
explain why...
What is an Exception? An abstract base class for the exception handling system. What is an Error? A non-resumable exception. What is a Notification? A resumable exception that does not raise a debugger if unhandled. What is a Halt? A resumable exception that does raise a debugger if unhandled.
So what is a Warning? Actually in 4.5, warnings behave just like Halt, that is, as resumable exceptions that do raise debuggers if unhandled. In 4.6, this still works for normally executed ("do-it") code but not in the debugger.
Why is that?
We just extended "Processor activeProcess" to return the effective process, which is different to the active one while debugging due to Process >> #evaluate:onBehalfOf:, to support debugging process-local state. This is fine.
What changed from 4.5 to 4.6 in the control flow of Warning >> #defaultAction?
Eventually, we get to MorphicProject >> #spawnNewProcessIfThisIsUI. But now in 4.6, the comparison is *false when debugging* and hence *we do not spawn a new UI process*. Until then in 4.5, this spawning of a new UI process cleaned up debugger stuff in the current stack (see Debugger >> #informExistingDebugger:label:) and thus also *dropped the current progress of step-over*!
What was the current progress of step-over? Well, our example is this:
3 timesRepeat: [Warning signal]. Transcript showln: 10 factorial.
We want to step-over the #timesRepeat: call. Now go see Warning >> #defaultAction:
defaultAction ToolSet debugContext: thisContext label: 'Warning' contents: self messageText, '\Select Proceed to continue, or close this window to cancel the operation.' withCRs. self resume.
What we do not execute anymore if we spawn a new UI process -- due to the clean-up of the debugger stack -- is "self resume." That call just removes the Warning's calls from the stack. Thus, we keep going in the surrounding step-over progress and get all warnings at once.
In a nutshell, the current implementation of Warning >> #defaultAction exploits a very nasty side-effect in 4.5 (even a buggy one), which got finally fixed in 4.6 when we started evaluating code on behalf of another process.
Warning and Halt behave exactly the same. We should make Warning a subclass of Halt and extend the message text as in its current #default action. Warnings *are no* Notifications. They never were.
Any objections?
Quite the opposite. Let us make it so.
Why not vice versa? Halt being a Warning would be more natural to me than Warning being a Halt.
Best -Tobias
Best, Marcel
-- View this message in context: http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4833652.html Sent from the Squeak - Dev mailing list archive at Nabble.com.