Is this a bug with Step "Over"?

On 23.06.2015, at 23:23, Chris Muller <[hidden email]> wrote:

>> Why not vice versa? Halt being a Warning would be more natural to me than Warning being
>> a Halt.
>
> We really should structure the class hierarchy based on the exception
> handling use-cases we want to support, not semantics.  If Halt
> inherited from Warning, then applications would no longer be able to
> halt separately from handling Warnings (except by handling Halt too,
> no way!).

Then they should be siblings in any case.
Best regards
        -Tobias

On Wed, Jun 24, 2015 at 2:04 PM, Tobias Pape <[hidden email]> wrote:
Should these have a new superclass whose name echos their common
handling wrt to the debugger?
(not that I'm clear on what that name would be)
cheers -ben

Hmm... we would still have a tooling problem. Remember all those load warnings and alike? They do not show the stack but a text box. User experience would change quite a bit if we change Warnings to behave like Halts... even with this one-line source code copy...

Best,
Marcel

And here is another bug (which is in the control flow of a regular exception):

Process >> debug: context title: title full: bool
        "Open debugger on self with context shown on top"

        | topCtxt |
        topCtxt := self isActiveProcess ifTrue: [thisContext] ifFalse: [self suspendedContext].
        (topCtxt hasContext: context) ifFalse: [^ self error: 'context not in process'].
        ToolSet debug: self context: context label: title contents: nil fullView: bool.

Because we cheat with #activeProcess and #effectiveProcess, #isActiveProcess will always be true and thus use thisContext, which would be wrong...? Hmpf... Stepping over code that raises exceptions seems to be quite brittle just now...

Process >> isActiveProcess
        ^ self == Processor activeProcess

ProcessorScheduler >> activeProcess
        ^activeProcess effectiveProcess

Process >> step
        ^Processor activeProcess
                evaluate: [suspendedContext := suspendedContext step]
                onBehalfOf: self

Best,
Marcel

I haven’t had a lot of time to follow this topic but a thought occurs;

Notification: hmm, somebody up the call-chain might want to let the user know about this
Warning: err, somebody up there might want to let the user look into this
Halt: ack! help! debug this!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PFM: Pray For Miracle

Then Exception should have 4 direct subclasses: Error, Notification, Warning, Halt?

Best,
Marcel

I think so but the most important thing is for the issues to be fixed.

On Thu, Jun 25, 2015 at 3:36 AM, marcel.taeumel <[hidden email]> wrote:

I thought it was Morphic-mt.793 that caused this but reverting it
still has the same problem.

On Thu, Jun 25, 2015 at 3:36 AM, marcel.taeumel <[hidden email]> wrote:

I still suspect the updates regarding ProcessorScheduler >> #effectiveProcess.

Best,
Marcel

Do you mean:
--------
Name: Kernel-eem.894
Author: eem
Time: 29 January 2015, 10:54:41.65 am
UUID: 4c8074eb-6db4-4d9b-bbfe-cd8f7197b999
Ancestors: Kernel-ul.893

Access a process's environment from effectiveProcess
to provide correct environment access when debugging.
--------
Funny thing is, when I diff that with its ancestor, none of those
changes are still in trunk, it appears they were reverted.  I tried
installing them but it didn't seem to help with the step-over Warning
nor the step-through lockup.

On Fri, Jun 26, 2015 at 12:29 AM, marcel.taeumel <[hidden email]> wrote:

Chris, I’m going to need a reminder of what is happening here since I haven’t experienced an debugger related lock-up recently.

I’ve tried on spur trunk, ‘plain’ cog trunk and ARM spur trunk.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
To steal ideas from one person is plagiarism; to steal from many is research.

Example 1:  Select debug it on the following.

      Object flushDependents do: [ : e | ]

Then click Over, Through.

--------

Example 2:  Select debug it on:

       Preferences preferenceAt: #serverMode ifAbsent: [ false ]

Then click Into, Through.


On Fri, Jun 26, 2015 at 2:09 PM, tim Rowledge <[hidden email]> wrote: