Why does debugger browse open on Object?
Locked
Why does debugger browse open on Object?
 
|
Hi - I've always meant to ask this question as it often catches me out.
When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. Why isn't there an easy way to open a browser on the real receiver of the message? Am I missing an obvious button, or is it really use Spotter and retype the name of the class? Interestingly - Create does the useful thing to create a method where you want? It seems so obvious, but most Smalltalks seem to adopt this approach? I guess I can add it - but surprised I have to really. Tim Sent from my iPhone |
Re: Why does debugger browse open on Object?
|
|
Hi Tim, all
2017-07-19 14:34 GMT-03:00 Tim Mackinnon <[hidden email]>: > Hi - I've always meant to ask this question as it often catches me out. > > When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. > > It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... > > But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. Yesterday I was going to ask about this behavior, which has been nagging me for some time. I feel better reading it isn't only me who's sensitive to this friction. I don't understand why it is like this, but I assume it is because of a common behavior of browsing the receiver object in the stack frame without considering particular cases like Object>>doesNotUnderstand: I'll be happy if you find a way to implement it, as a System Option or via a shortcut modifier. Regards! Esteban A. Maringolo |
|
|
Hi,
> On 19 Jul 2017, at 19:56, Esteban A. Maringolo <[hidden email]> wrote: > > Hi Tim, all > > 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <[hidden email]>: >> Hi - I've always meant to ask this question as it often catches me out. >> >> When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. >> >> It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... >> >> But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. > > Yesterday I was going to ask about this behavior, which has been > nagging me for some time. I feel better reading it isn't only me who's > sensitive to this friction. > > I don't understand why it is like this, but I assume it is because of > a common behavior of browsing the receiver object in the stack frame > without considering particular cases like Object>>doesNotUnderstand: > > I'll be happy if you find a way to implement it, as a System Option or > via a shortcut modifier. In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. Maybe now is time to retry ;) Esteban > > Regards! > > Esteban A. Maringolo > |
Re: Why does debugger browse open on Object?
|
|
It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need).
Not sure how you get an icon on the button (create doesn't either). Maybe I can propose it for 7. Possibly call it "browse receiver"? (A bit long though) Tim Sent from my iPhone > On 19 Jul 2017, at 19:55, Esteban Lorenzano <[hidden email]> wrote: > > Hi, > >> On 19 Jul 2017, at 19:56, Esteban A. Maringolo <[hidden email]> wrote: >> >> Hi Tim, all >> >> 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <[hidden email]>: >>> Hi - I've always meant to ask this question as it often catches me out. >>> >>> When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. >>> >>> It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... >>> >>> But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. >> >> Yesterday I was going to ask about this behavior, which has been >> nagging me for some time. I feel better reading it isn't only me who's >> sensitive to this friction. >> >> I don't understand why it is like this, but I assume it is because of >> a common behavior of browsing the receiver object in the stack frame >> without considering particular cases like Object>>doesNotUnderstand: >> >> I'll be happy if you find a way to implement it, as a System Option or >> via a shortcut modifier. > > In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. > Maybe now is time to retry ;) > > Esteban > >> >> Regards! >> >> Esteban A. Maringolo >> > > |
Re: Why does debugger browse open on Object?
|
|
Sure propose a fix.
On Thu, Jul 20, 2017 at 12:31 AM, Tim Mackinnon <[hidden email]> wrote: > It turns out it's trivial - just create a subclass of DebugAction (the create one has all the pieces you need). > > Not sure how you get an icon on the button (create doesn't either). > > Maybe I can propose it for 7. > > Possibly call it "browse receiver"? (A bit long though) > > Tim > > Sent from my iPhone > >> On 19 Jul 2017, at 19:55, Esteban Lorenzano <[hidden email]> wrote: >> >> Hi, >> >>> On 19 Jul 2017, at 19:56, Esteban A. Maringolo <[hidden email]> wrote: >>> >>> Hi Tim, all >>> >>> 2017-07-19 14:34 GMT-03:00 Tim Mackinnon <[hidden email]>: >>>> Hi - I've always meant to ask this question as it often catches me out. >>>> >>>> When you get a typical debugger on doesNotUnderstood: I find that typically I've muddled up a method name - so I want to quickly browse the receiver of my mistake and understand what methods it actually has that I can use. >>>> >>>> It seems that the browse button is exactly that, and the debugger helpfully shows MyClass(Object) doesNotUnderstand.... >>>> >>>> But browse actually opens on Object >>doesNotUnderstand: which while technically correct is not really that helpful. >>> >>> Yesterday I was going to ask about this behavior, which has been >>> nagging me for some time. I feel better reading it isn't only me who's >>> sensitive to this friction. >>> >>> I don't understand why it is like this, but I assume it is because of >>> a common behavior of browsing the receiver object in the stack frame >>> without considering particular cases like Object>>doesNotUnderstand: >>> >>> I'll be happy if you find a way to implement it, as a System Option or >>> via a shortcut modifier. >> >> In fact, some years ago Camillo Bruni implemented a solution for this (it was opening the debugger in the place where the DNU was originated) but I think it was deactivated because people was not so happy. >> Maybe now is time to retry ;) >> >> Esteban >> >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >> >> > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |