[squeak-dev] Re: Is this a bug with Step "Over"?

marcel.taeumel Marcel.Taeumel at hpi.de
Tue Jun 23 09:44:21 UTC 2015


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?

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.


More information about the Squeak-dev mailing list