Opening two debuggers in a single doit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Opening two debuggers in a single doit

Eliot Miranda-2
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Bob Arning-2

I tried this in 5.1 and it worked

Debugger class>>

morphicOpenOn: process context: context label: title contents: contentsStringOrNil fullView: full
    "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

    | errorWasInUIProcess debugger |
    ErrorRecursion ifTrue: [
        "self assert: process == Project current uiProcess -- DOCUMENTATION ONLY"
        ErrorRecursion := false.
        "^ Project current handleFatalDrawingError: title"].    <============commented this out
...


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    



Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Bob Arning-2
In reply to this post by Eliot Miranda-2

oh, and it used to work out of the box


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    



Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Eliot Miranda-2
In reply to this post by Bob Arning-2
Bob,

    thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question. So if one moves the ErrorRecursion := false outside of the addDeferredUIMessage: block everything works.  i.e. now the code reads:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely].
ErrorRecursion := false ].

and the old code doesn't work:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely.
ErrorRecursion := false ]].

So there question is, what are the tests for the ErrorGuard and ErrorRecursion?  I need to run these before committing the fix above.

Bob, way to go!  Thank you.

On Wed, Jan 24, 2018 at 3:52 PM, Bob Arning <[hidden email]> wrote:

I tried this in 5.1 and it worked

Debugger class>>

morphicOpenOn: process context: context label: title contents: contentsStringOrNil fullView: full
    "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

    | errorWasInUIProcess debugger |
    ErrorRecursion ifTrue: [
        "self assert: process == Project current uiProcess -- DOCUMENTATION ONLY"
        ErrorRecursion := false.
        "^ Project current handleFatalDrawingError: title"].    <============commented this out
...


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

timrowledge

> On 24-01-2018, at 4:05 PM, Eliot Miranda <[hidden email]> wrote:
>
> Bob,
>
>     thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question.

While we’re fixing that it might be a good idea to get rid of (or otherwise fix) Debugger class>>#morphicOpenContext:label:contents: There are no senders in the image, it uses a simulation guard prim, it generally looks like a partial version of morphicOpenOn:context:label:contents:fullView: that got abandoned.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SCEU: Simulate Correct Execution, Usually



Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Tobias Pape

> On 25.01.2018, at 01:20, tim Rowledge <[hidden email]> wrote:
>
>
>> On 24-01-2018, at 4:05 PM, Eliot Miranda <[hidden email]> wrote:
>>
>> Bob,
>>
>>    thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question.
>
> While we’re fixing that it might be a good idea to get rid of (or otherwise fix) Debugger class>>#morphicOpenContext:label:contents: There are no senders in the image, it uses a simulation guard prim, it generally looks like a partial version of morphicOpenOn:context:label:contents:fullView: that got abandoned.
>

Hold your horses :D
It _is_ sent, indirectly, via:

openContext: aContext label: aString contents: contentsStringOrNil
        "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

        ^ Project current
                dispatchTo: self
                addPrefixAndSend: #OpenContext:label:contents:
                withArguments: { aContext . aString . contentsStringOrNil }

Which, in turn, is also sent...

Best regards
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

timrowledge

> On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
>
> Hold your horses :D
> It _is_ sent, indirectly, via:
>
> openContext: aContext label: aString contents: contentsStringOrNil
> "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."
>
> ^ Project current
> dispatchTo: self
> addPrefixAndSend: #OpenContext:label:contents:
> withArguments: { aContext . aString . contentsStringOrNil }
>
> Which, in turn, is also sent…

Good grief. What an excellent way to confuse our tools. Most definitely not a technique I’d ever suggest teaching.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Don't document the program; program the document.



cbc
Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

cbc


On Wed, Jan 24, 2018 at 4:31 PM, tim Rowledge <[hidden email]> wrote:

> On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
>
> Hold your horses :D
> It _is_ sent, indirectly, via:
>
> openContext: aContext label: aString contents: contentsStringOrNil
>       "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."
>
>       ^ Project current
>               dispatchTo: self
>               addPrefixAndSend: #OpenContext:label:contents:
>               withArguments: { aContext . aString . contentsStringOrNil }
>
> Which, in turn, is also sent…

Good grief. What an excellent way to confuse our tools. Most definitely not a technique I’d ever suggest teaching.

Nope.

Now, how to fix the sendersOf to detect something pathological like this...

cbc


cbc
Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

cbc


On Wed, Jan 24, 2018 at 4:35 PM, Chris Cunningham <[hidden email]> wrote:


On Wed, Jan 24, 2018 at 4:31 PM, tim Rowledge <[hidden email]> wrote:

> On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
>
> Hold your horses :D
> It _is_ sent, indirectly, via:
>
> openContext: aContext label: aString contents: contentsStringOrNil
>       "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."
>
>       ^ Project current
>               dispatchTo: self
>               addPrefixAndSend: #OpenContext:label:contents:
>               withArguments: { aContext . aString . contentsStringOrNil }
>
> Which, in turn, is also sent…

Good grief. What an excellent way to confuse our tools. Most definitely not a technique I’d ever suggest teaching.

Nope.

Now, how to fix the sendersOf to detect something pathological like this...

cbc

This would work:

openContext: aContext label: aString contents: contentsStringOrNil
<calledMethods: #( morphicOpenContext:label:contents: mvcOpenContext:label:contents: ) >
"Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

^ Project current
dispatchTo: self
addPrefixAndSend: #OpenContext:label:contents:
withArguments: { aContext . aString . contentsStringOrNil }

Then, also do this for the other siblings like this, as found in Project class>baseSelectors

baseSelectors
"The list of known base selectors that may be dispatched to project specific
implementations. For example, #OpenLabel:in: will be dispatched to #mvcOpenLabel:in:
for its MVC specific implementation. Add new base selectors here if additional methods
are added as targets of the dispatchTo:addPrefixAndSend:withArguments: mechanism."

^ {
#StartUpLeftFlush .
#StartUpWithCaption:icon:at:allowKeyboard: .
#OpenLabel:in: .
#Open: .
#Open .
#OpenOn:context:label:contents:fullView: .
#ResumeProcess:
}

Downside (well, one of them) is that additional project classes are added, you'd need to then update the methods.  And remember to add in these funky messages as well, obviously.

cbc


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

David T. Lewis
In reply to this post by timrowledge
On Wed, Jan 24, 2018 at 04:31:57PM -0800, tim Rowledge wrote:

>
> > On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
> >
> > Hold your horses :D
> > It _is_ sent, indirectly, via:
> >
> > openContext: aContext label: aString contents: contentsStringOrNil
> > "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."
> >
> > ^ Project current
> > dispatchTo: self
> > addPrefixAndSend: #OpenContext:label:contents:
> > withArguments: { aContext . aString . contentsStringOrNil }
> >
> > Which, in turn, is also sent???

Oops, sorry. Fixed in System-dtl.996.

The original #flag: methods were in Project>>dispatchTo:addPrefixAndSend:withArguments:
and the replacement mechanism is to use <hasLiteralTest: #isDispatchSelector:
to identify the target methods. I guess I left this one out when I converted to
the (much nicer) pragmas.

>
> Good grief. What an excellent way to confuse our tools. Most definitely not a technique I???d ever suggest teaching.

Indeed, please do not include this in your curriculum.

I felt badly about inventing this in the first place, but it was the best
I could come up with, and I checked with Andreas and he said that it was
not too horrible, so we went with it.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

David T. Lewis
In reply to this post by cbc
On Wed, Jan 24, 2018 at 04:35:11PM -0800, Chris Cunningham wrote:

> On Wed, Jan 24, 2018 at 4:31 PM, tim Rowledge <[hidden email]> wrote:
>
> >
> > > On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
> > >
> > > Hold your horses :D
> > > It _is_ sent, indirectly, via:
> > >
> > > openContext: aContext label: aString contents: contentsStringOrNil
> > >       "Open a notifier in response to an error, halt, or notify. A
> > notifier view just shows a short view of the sender stack and provides a
> > menu that lets the user open a full debugger."
> > >
> > >       ^ Project current
> > >               dispatchTo: self
> > >               addPrefixAndSend: #OpenContext:label:contents:
> > >               withArguments: { aContext . aString . contentsStringOrNil }
> > >
> > > Which, in turn, is also sent???
> >
> > Good grief. What an excellent way to confuse our tools. Most definitely
> > not a technique I???d ever suggest teaching.
> >
> > Nope.
>
> Now, how to fix the sendersOf to detect something pathological like this...
>
> cbc

See the method comment in #dispatchTo:addPrefixAndSend:withArguments:

The mechanism is this pragma:

        <hasLiteralTest: #isDispatchSelector:>

Implementation is in Project class>>isDispatchSelector: which identifies the
target selectors. Apparently I left one of the selectors out of the list,
hence the confusion here.

Marcel has made considerable improvements to Squeak Projects in recent years,
and one good effect that I have noticed is that he has been able to reduce
the use of these dispatch methods.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
Guys,

    I get that the selector sending issue is an issue, but it's tangental.  I would like to know if it is safe to commit this fix.  Can anyone go through the tests that necessitate ErrorRecursion et al?

On Wed, Jan 24, 2018 at 4:05 PM, Eliot Miranda <[hidden email]> wrote:
Bob,

    thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question. So if one moves the ErrorRecursion := false outside of the addDeferredUIMessage: block everything works.  i.e. now the code reads:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely].
ErrorRecursion := false ].

and the old code doesn't work:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely.
ErrorRecursion := false ]].

So there question is, what are the tests for the ErrorGuard and ErrorRecursion?  I need to run these before committing the fix above.

Bob, way to go!  Thank you.

On Wed, Jan 24, 2018 at 3:52 PM, Bob Arning <[hidden email]> wrote:

I tried this in 5.1 and it worked

Debugger class>>

morphicOpenOn: process context: context label: title contents: contentsStringOrNil fullView: full
    "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

    | errorWasInUIProcess debugger |
    ErrorRecursion ifTrue: [
        "self assert: process == Project current uiProcess -- DOCUMENTATION ONLY"
        ErrorRecursion := false.
        "^ Project current handleFatalDrawingError: title"].    <============commented this out
...


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    







--
_,,,^..^,,,_
best, Eliot



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

marcel.taeumel
In reply to this post by Eliot Miranda-2
Hi Eliot,

we should not do that. ;-) It is essential to try opening and drawing that debugger first before we flip ErrorRecursion back to false.

I will look into your scenario. You are right, this should work:

[1 halt] fork.
Processor yield.
2 halt.

Best,
Marcel

Am 25.01.2018 01:05:19 schrieb Eliot Miranda <[hidden email]>:

Bob,

    thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question. So if one moves the ErrorRecursion := false outside of the addDeferredUIMessage: block everything works.  i.e. now the code reads:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely].
ErrorRecursion := false ].

and the old code doesn't work:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely.
ErrorRecursion := false ]].

So there question is, what are the tests for the ErrorGuard and ErrorRecursion?  I need to run these before committing the fix above.

Bob, way to go!  Thank you.

On Wed, Jan 24, 2018 at 3:52 PM, Bob Arning <[hidden email]> wrote:

I tried this in 5.1 and it worked

Debugger class>>

morphicOpenOn: process context: context label: title contents: contentsStringOrNil fullView: full
    "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

    | errorWasInUIProcess debugger |
    ErrorRecursion ifTrue: [
        "self assert: process == Project current uiProcess -- DOCUMENTATION ONLY"
        ErrorRecursion := false.
        "^ Project current handleFatalDrawingError: title"].    <============commented this out
...


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

marcel.taeumel
Well, I moved the flag inside the deferred call. It works fine for me. :-)

See, if it works for you as well.

http://forum.world.st/The-Trunk-Tools-mt-794-mcz-tp5064330.html
http://forum.world.st/The-Trunk-Morphic-mt-1390-mcz-tp5064331.html

Best,
Marcel

Am 25.01.2018 08:57:01 schrieb Marcel Taeumel <[hidden email]>:

Hi Eliot,

we should not do that. ;-) It is essential to try opening and drawing that debugger first before we flip ErrorRecursion back to false.

I will look into your scenario. You are right, this should work:

[1 halt] fork.
Processor yield.
2 halt.

Best,
Marcel

Am 25.01.2018 01:05:19 schrieb Eliot Miranda <[hidden email]>:

Bob,

    thank you!!  morphicOpenOn:context:label:contents:fullView: is indeed the method in question. So if one moves the ErrorRecursion := false outside of the addDeferredUIMessage: block everything works.  i.e. now the code reads:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely].
ErrorRecursion := false ].

and the old code doesn't work:

Project current addDeferredUIMessage:
[ debugger := self new
process: process
controller: nil
context: context.
full
ifTrue: [ debugger openFullNoSuspendLabel: title ]
ifFalse:
[ debugger
openNotifierContents: contentsStringOrNil
label: title ].
debugger errorWasInUIProcess: errorWasInUIProcess.
"Try drawing the debugger tool at least once to avoid freeze."
Project current world displayWorldSafely.
ErrorRecursion := false ]].

So there question is, what are the tests for the ErrorGuard and ErrorRecursion?  I need to run these before committing the fix above.

Bob, way to go!  Thank you.

On Wed, Jan 24, 2018 at 3:52 PM, Bob Arning <[hidden email]> wrote:

I tried this in 5.1 and it worked

Debugger class>>

morphicOpenOn: process context: context label: title contents: contentsStringOrNil fullView: full
    "Open a notifier in response to an error, halt, or notify. A notifier view just shows a short view of the sender stack and provides a menu that lets the user open a full debugger."

    | errorWasInUIProcess debugger |
    ErrorRecursion ifTrue: [
        "self assert: process == Project current uiProcess -- DOCUMENTATION ONLY"
        ErrorRecursion := false.
        "^ Project current handleFatalDrawingError: title"].    <============commented this out
...


On 1/24/18 6:31 PM, Eliot Miranda wrote:
Hi All,

    I'm comparing two close copies of a class in attempting a complex refactoring, comparing the original code with the close copy.  In doing this I need to open up two debuggers to step through the two computations simultaneously.  If I try it this way, where the two JITs break at a particular bytecode:

[:m :opts|
 [StackToRegisterMappingCogit cog: m options: opts] fork.
 Processor yield.
 AltStackToRegisterMappingCogit cog: m options: opts]
value: TabbedPalette class>>#unload
value: #(ObjectMemory Spur64BitCoMemoryManager
debugBytecodePointers #(59)
compilationTrace 0).

I get an emergency evaluator :-(, and if I type restart I only ever get one debugger.  What's the right way to do this?

To boil down the example I need this to work:

    [1 halt] fork.
    Processor yield.
    2 halt

i.e. I want to be able to get two debuggers, one open on 1 halt, and the other on 2 halt.
_,,,^..^,,,_
best, Eliot



    







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

Bert Freudenberg
In reply to this post by David T. Lewis
On 25 January 2018 at 02:51, David T. Lewis <[hidden email]> wrote:
On Wed, Jan 24, 2018 at 04:35:11PM -0800, Chris Cunningham wrote:
> On Wed, Jan 24, 2018 at 4:31 PM, tim Rowledge <[hidden email]> wrote:
>
> >
> > > On 24-01-2018, at 4:25 PM, Tobias Pape <[hidden email]> wrote:
> > >
> > > Hold your horses :D
> > > It _is_ sent, indirectly, via:
> > >
> > > openContext: aContext label: aString contents: contentsStringOrNil
> > >       "Open a notifier in response to an error, halt, or notify. A
> > notifier view just shows a short view of the sender stack and provides a
> > menu that lets the user open a full debugger."
> > >
> > >       ^ Project current
> > >               dispatchTo: self
> > >               addPrefixAndSend: #OpenContext:label:contents:
> > >               withArguments: { aContext . aString . contentsStringOrNil }
> > >
> > > Which, in turn, is also sent???
> >
> > Good grief. What an excellent way to confuse our tools. Most definitely
> > not a technique I???d ever suggest teaching.
> >
> > Nope.
>
> Now, how to fix the sendersOf to detect something pathological like this...
>
> cbc

See the method comment in #dispatchTo:addPrefixAndSend:withArguments:

The mechanism is this pragma:

        <hasLiteralTest: #isDispatchSelector:>

Implementation is in Project class>>isDispatchSelector: which identifies the
target selectors. Apparently I left one of the selectors out of the list,
hence the confusion here.

​See if you like what I put in System-bf.997, and if so, move it from Inbox to Trunk?​

Gets rid of the hard-coded list, but might have a few false positives.

Marcel has made considerable improvements to Squeak Projects in recent years,
and one good effect that I have noticed is that he has been able to reduce
the use of these dispatch methods.

​+1

- Bert -​



Reply | Threaded
Open this post in threaded view
|

Re: Opening two debuggers in a single doit

David T. Lewis
On Thu, Jan 25, 2018 at 05:00:01PM +0100, Bert Freudenberg wrote:

> On 25 January 2018 at 02:51, David T. Lewis <[hidden email]> wrote:
> > On Wed, Jan 24, 2018 at 04:35:11PM -0800, Chris Cunningham wrote:
> >
> > See the method comment in #dispatchTo:addPrefixAndSend:withArguments:
> >
> > The mechanism is this pragma:
> >
> >         <hasLiteralTest: #isDispatchSelector:>
> >
> > Implementation is in Project class>>isDispatchSelector: which identifies
> > the
> > target selectors. Apparently I left one of the selectors out of the list,
> > hence the confusion here.
> >
>
> ???See if you like what I put in System-bf.997, and if so, move it from Inbox
> to Trunk????
>
> Gets rid of the hard-coded list, but might have a few false positives.
>

Much better, thanks. Moved to trunk.

Dave