Is this a bug with Step "Over"?

> I think that's what "Step Through" is for.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4830738.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

> 3 timesRepeat: [Warning signal].
> 10 factorial
>
> Select the above in a workspace, select "debug it" then, in the
> debugger, click the "Over" button just once.
>
> 3 Warning pre-debuggers appear instantly and then the execution moves
> to the "factorial".
>
> Warnings have the opportunity to resume or cancel?  IOW, shouldn't it
> work more like as if it were a halt?
>
> 3 timesRepeat: [ self halt ].
> 10 factorial
>

> Warnings are Notifications, which resume silently if not handled. Only Errors
> (e.g. Halt) stop execution.
>
> Now if you take a look at Warning >> #defaultAction, you can see why a
> debugger appears at all -- which is not common for Notifications.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4830776.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

> Warning>>defaultAction
> "The user should be notified of the occurrence of an exceptional occurrence
> and given an option of continuing or aborting the computation. The
> description of the occurrence should include any text specified as the
> argument of the #signal: message."
> ToolSet
> debugContext: thisContext
> label: 'Warning'
> contents: self messageText, '\\Select Proceed to continue, or close this
> window to cancel the operation.' withCRs.
> self resume.
>
> contrast that with Halt's defaultAction:
>
> Halt>>defaultAction
> "No one has handled this error, but now give them a chance to decide how to
> debug it.  If none handle this either then open debugger (see
> UnhandedError-defaultAction)"
>
> UnhandledError signalForException: self
>
> With Halt's approach, the debugger can catch it, and catch subsequent halts;
> indeed the debugger can catch any unhandled exception raised within
> debugging.  But it can't, and shouldn't, squash the opeining of a debugger
> if the debugged code chooses to do so.
>
> One fix is to use Halt's defaultAction for Warning.  I think this is the
> right thing to do.  Another solution is to accept that Warning behaves
> bizarrely and leave it as is.  What do y'all think?

> 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.
>
> ---

> See Debugger class >> #openContext:label:contents:, which is in the control
> flow of Warning >> defaultAction. There, you can read "Processor
> activeProcess suspend", which seems to be ignored. Now go to pragma of that
> method. It says "<primitive: 19>", which is a simulation guard and hence
> important for a debugger's step-over.
>
> Can someone explain, how those simulation guards work or are supposed to
> work? There actually were some changes in the simulation code... but
> where...
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Is-this-a-bug-with-Step-Over-tp4830736p4833361.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

> 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.
>

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

>
>>
>> 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.