Smalltalk › Squeak › Squeak - Dev

Opening two debuggers in a single doit

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Eliot Miranda-2

Opening two debuggers in a single doit

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

Bob Arning-2

Re: Opening two debuggers in a single doit

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

Bob Arning-2

Re: Opening two debuggers in a single doit

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

Eliot Miranda-2

Re: Opening two debuggers in a single doit

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

timrowledge

Re: Opening two debuggers in a single doit

> 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

Tobias Pape

Re: Opening two debuggers in a single doit

> 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

timrowledge

Re: Opening two debuggers in a single doit

> 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

Re: Opening two debuggers in a single doit

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

Re: Opening two debuggers in a single doit

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

David T. Lewis

Re: Opening two debuggers in a single doit

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

David T. Lewis

Re: Opening two debuggers in a single doit

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

Eliot Miranda-2

Re: Opening two debuggers in a single doit

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

marcel.taeumel

Re: Opening two debuggers in a single doit

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

marcel.taeumel

Re: Opening two debuggers in a single doit

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

Bert Freudenberg

Re: Opening two debuggers in a single doit

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.

- Bert -

David T. Lewis

Re: Opening two debuggers in a single doit

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