On 24-01-2018, at 4:05 PM, Eliot Miranda eliot.miranda@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SCEU: Simulate Correct Execution, Usually

On 24-01-2018, at 4:25 PM, Tobias Pape Das.Linux@gmx.de 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; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.

On Wed, Jan 24, 2018 at 4:35 PM, Chris Cunningham cunningham.cb@gmail.com wrote:

On Wed, Jan 24, 2018 at 4:31 PM, tim Rowledge tim@rowledge.org wrote:

...

...

On 24-01-2018, at 4:25 PM, Tobias Pape Das.Linux@gmx.de 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

On 25 January 2018 at 02:51, David T. Lewis lewis@mail.msen.com 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 tim@rowledge.org wrote:

...

...

On 24-01-2018, at 4:25 PM, Tobias Pape Das.Linux@gmx.de 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 -​

On Wed, Jan 24, 2018 at 04:31:57PM -0800, tim Rowledge wrote:

...

On 24-01-2018, at 4:25 PM, Tobias Pape Das.Linux@gmx.de 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

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 eliot.miranda@gmail.com: 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 <arning315@comcast.net [mailto:arning315@comcast.net]> 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

Hi Marcel,

On Thu, Jan 25, 2018 at 1:04 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

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

See, if it works for you as well.

It does. Thank you!

BTW, here's how I'm using it:

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

It stops two nearly identical JIT compilations of a method at a given bytecode, saving me huge amounts of time stepping to a specific point in two separate debuggers.

The need for editWithLabel: comes in a scan over all the methods in the system where I open the disassembled machine code generated by each JIT, a diff of the disassembly where the two differ, and an explorer on the CompiledMethod. From that I puzzle out which bytecode caused the difference and then move to my first example to debug. Contrast this with two simulations of an image where the different results become apparent long after bugs in the code produced by the incomplete refactoring of AltStackToRegisterMappingCogit, and simulation proceeds at a stately pace.

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 marcel.taeumel@hpi.de: 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 eliot.miranda@gmail.com: 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 arning315@comcast.net 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