On 15 June 2018 at 03:47, Henrik-Nergaard <draagren@outlook.com> wrote:

Hi,

Moving the icons down to the middle row is as simple as changing:

*** codeActionsPragmas ^ #( stackDebuggingActions codeDebuggingActions )

Thanks for the tip. Note this needs to be stackDebuggingAction cheers -ben

Hi Henrik, On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren@outlook.com> wrote:

Hi,

Moving the icons down to the middle row is as simple as changing:

*** codeActionsPragmas ^ #( stackDebuggingActions codeDebuggingActions ) *** *** stackDebuggingActionsPragmas ^ #() ***

in GTGenericStackDebugger.

Best regards, Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger <gtStackDebuggingAction> is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible. _,,,^..^,,,_ best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

Hi Tim, On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <tim@testit.works> wrote:

The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.

It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).

These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad.

Tim

On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren@outlook.com> wrote:

...

Hi,

Moving the icons down to the middle row is as simple as changing:

*** codeActionsPragmas ^ #( stackDebuggingActions codeDebuggingActions ) *** *** stackDebuggingActionsPragmas ^ #() ***

in GTGenericStackDebugger.

Best regards, Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in

StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger <gtStackDebuggingAction>

is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

_,,,^..^,,,_ best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

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

Hi Doru, On Sat, Jun 16, 2018 at 2:25 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

This is indeed an issue we should have solved. The concatenation of pragma selectors is unnecessary in this case, but we did not clean it up and it remained like this.

If the issue is that one wants generosity at the reference (in the actions methods that provide what should be pragma names) and specificity at the referent (the methods containing the pragmas) then one can add a second pragma and use and "and" function to insist on the pragma plus another qualifier. For example, StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger <gtStackDebuggingAction> ^ (self forDebugger: aDebugger) icon: GLMUIThemeExtraIcons glamorousOver could become StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger <stackDebuggingAction> <GlamorousDebugger> ^ (self forDebugger: aDebugger) icon: GLMUIThemeExtraIcons glamorousOver but I suspect that's not necessary here because all these methods exist in a class hierarchy that can provide the context and specificity required. But in this case it seems to me that there's a deeper weakness/opportunity. The meat of each class is the executeAction method, for example StepOverDebugAction >>executeAction self session stepOver: self currentContext why not add the pragma there and dispense with the gtStackDebuggingActionFor: methods altogether. For example, you could include a pragma identifying the method as an action, and a pragma to be used by a builder to add the action, or at least specify the parameters: StepOverDebugAction >>executeAction <stackDebuggingAction> <uiThemeIcon: #glamorousOver hotKey: $H> "This could be performed by a builder class specific to building glamorous debuggers, or glamorous tools, or..." self session stepOver: self currentContext This second pragma could have as many keywords and arguments as one wants, and serves to reduce the additional machinery one needs to "plug" something in. In general the pattern is to annotate some action or entry point method with pragmas that specify how the method fits in to some larger context, so for example, - an action method on a menu, where a single pragma can specify the label, icon, hot key, and menu name, using a message understood by a menu decorator that would perform the pragma to add it to the menu (and then if there is a hook on the class side that is looking for method additions and removals, menus in live tools can update as soon as a method containing such a pragma is added or removed) - an entry point for some exported interface, such as a COM interface, where the pragma specifies the types of the incoming parameters, and hence as the method is installed into some built interface, the relevant marshaling machinery is built, rather than being specified off to the side Used in this way, information about how a component fits in can be localized in the key method(s) providing the component, instead of being spread over several methods, reducing load on the programmer in comprehending and adding similar actions.

Cheers, Doru

...

On Jun 16, 2018, at 8:58 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Tim,

On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <tim@testit.works> wrote:

...

The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.

It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).

These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad.

Tim

...

On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren@outlook.com> wrote: Hi,

Moving the icons down to the middle row is as simple as changing:

*** codeActionsPragmas ^ #( stackDebuggingActions codeDebuggingActions ) *** *** stackDebuggingActionsPragmas ^ #() ***

in GTGenericStackDebugger.

Best regards, Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in

StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger <gtStackDebuggingAction>

is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

_,,,^..^,,,_ best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

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

-- www.tudorgirba.com www.feenk.com

"There are no old things, there are only old ways of looking at them."

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