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

Tobias Pape Das.Linux at gmx.de
Tue Jun 23 16:47:04 UTC 2015


On 23.06.2015, at 18:37, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Marcel,
> 
> 
> On Jun 23, 2015, at 2:44 AM, "marcel.taeumel" <Marcel.Taeumel at 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.




More information about the Squeak-dev mailing list