Re: [Pharo-dev] Debugger Button Positioning

[Eliot Miranda]

Hi Doru,

On Sat, Jun 16, 2018 at 2:25 AM, Tudor Girba  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

^ (self forDebugger: aDebugger)
icon: GLMUIThemeExtraIcons glamorousOver

could become

StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger


^ (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

 "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 
> wrote:
> >
> > Hi Tim,
> >
> > On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon  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
>  & .  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 
> wrote:
> >>
> >> Hi Henrik,
> >>
> >> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard 
> wrote:
> >> Hi,
> >>
> >> Moving the icons down to the middle row is as simple as changing:
> >>
> >> ***
> >> codeActionsPragmas
> 

Re: [Pharo-dev] Debugger Button Positioning

[Tudor Girba]

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.

Cheers,
Doru



> On Jun 16, 2018, at 8:58 AM, Eliot Miranda  wrote:
> 
> Hi Tim,
> 
> On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon  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 
>  & .  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  wrote:
>> 
>> Hi Henrik,
>> 
>> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard  
>> 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
>>   
>> 
>> 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."

Re: [Pharo-dev] Debugger Button Positioning

[Eliot Miranda]

Hi Tim,

On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon  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  & .  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  wrote:
>
> Hi Henrik,
>
> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard 
> 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
> 
>
> 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

Re: [Pharo-dev] Debugger Button Positioning

[Tim Mackinnon]

> 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?).

Tim


> On 15 Jun 2018, at 00:23, Eliot Miranda  wrote:
> 
> Hi Henrik,
> 
> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard  > 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
>
> 
> 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

Re: [Pharo-dev] Debugger Button Positioning

[Eliot Miranda]

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard 
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


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

Re: [Pharo-dev] Debugger Button Positioning

[Ben Coman]

On 15 June 2018 at 06:51, Ben Coman  wrote:

>
>
> On 15 June 2018 at 03:47, Henrik-Nergaard  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
>
>

Anyone know how to do an experiment duplicating the debugging buttons
vertically to the left of the code pane,
but only the small icon, no text ?

cheers -ben

Re: [Pharo-dev] Debugger Button Positioning

[Ben Coman]

On 15 June 2018 at 03:47, Henrik-Nergaard  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

Re: [Pharo-dev] Debugger Button Positioning

[Henrik-Nergaard]

Hi,

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

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

in GTGenericStackDebugger.

Best regards,
Henrik




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Debugger Button Positioning

[Cyril Ferlicot D.]

Le 14/06/2018 à 20:13, Eliot Miranda a écrit :
> Hi All,
> 

Hi,

>      I've been using Pharo intensively for the first time, Pharo 7.
> Forgive me for starting with a complaint, but I don't have time to state
> all the things that are great about it; you already now ;-)
> 

No problem. It's always easier to talk about the bad things than to good
ones. :) I hope you will like your usage of Pharo.

> One thing I find painful is the positioning of the debugger
> into/over/through buttons.  Because these are above the context list,
> and you read the code like I do, one has to mouse further to reach
> them.  I find my focus is on the highlighted method, and my cursor is
> typically within it (I'm dong implementors, or senders, or just looking
> at the code).  Further, there's lots of space between the Source tab and
> the "Where Is?" and "Browse" buttons.  Doesn't it make more sense to put
> the into/over/through buttons between the Source tab and the "Where Is?"
> button?  If not, doesn't it make sense to put a copy of the buttons
> there where they're in much easier reach?
> 

It was raised many times before but apparently it was not easy to change.

Peter did some scripts to change it and I currently use them.

The code can be found here:

https://github.com/jecisc/pharo-scripts/tree/master/settings/PharoSettings5.package

There are some extensions to the debugger and to replace the current
behaviour of the debugger I use Metalinks
(https://github.com/jecisc/pharo-scripts/blob/master/settings/PharoSettings5.package/Pharo5CommonSettings.class/class/addMetaLinksForDebugger.st)

If we can have a way to get it directly into the debugger it would be
great. :)

> _,,,^..^,,,_
> best, Eliot


-- 
Cyril Ferlicot
https://ferlicot.fr



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Debugger Button Positioning

[Esteban A. Maringolo]

On 14/06/2018 15:13, Eliot Miranda wrote:
> Hi All,
> 
>      I've been using Pharo intensively for the first time, Pharo 7.
> Forgive me for starting with a complaint, but I don't have time to state
> all the things that are great about it; you already now ;-)
> 
> One thing I find painful is the positioning of the debugger
> into/over/through buttons.  Because these are above the context list,
> and you read the code like I do, one has to mouse further to reach
> them.  I find my focus is on the highlighted method, and my cursor is
> typically within it (I'm dong implementors, or senders, or just looking
> at the code).  Further, there's lots of space between the Source tab and
> the "Where Is?" and "Browse" buttons.  Doesn't it make more sense to put
> the into/over/through buttons between the Source tab and the "Where Is?"
> button?  If not, doesn't it make sense to put a copy of the buttons
> there where they're in much easier reach?

I agree with you in all your remarks, and IMO not only the buttons
position is suboptimal, also their shortcuts.

But AFAIR this was discussed some time ago when the GTDebugger was set
as the default debugger.

But the discussion was settled to "you can create your own". Which I
don't like, but it's fair enough. :)

Regards!


-- 
Esteban A. Maringolo

[Pharo-dev] Debugger Button Positioning

[Eliot Miranda]

Hi All,

 I've been using Pharo intensively for the first time, Pharo 7. Forgive
me for starting with a complaint, but I don't have time to state all the
things that are great about it; you already now ;-)

One thing I find painful is the positioning of the debugger
into/over/through buttons.  Because these are above the context list, and
you read the code like I do, one has to mouse further to reach them.  I
find my focus is on the highlighted method, and my cursor is typically
within it (I'm dong implementors, or senders, or just looking at the
code).  Further, there's lots of space between the Source tab and the
"Where Is?" and "Browse" buttons.  Doesn't it make more sense to put the
into/over/through buttons between the Source tab and the "Where Is?"
button?  If not, doesn't it make sense to put a copy of the buttons there
where they're in much easier reach?

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