Smalltalk › Squeak › Squeak - Dev

An idea for the debugger...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Eliot Miranda-2

An idea for the debugger...

Hi All,

I'm lazy and also I don't write the most elegant UI code but I had an idea I want realized so I thought I'd see if I could interest anyone in implementing it. Dora is doing amazing work with the Moldable Debugger but this is a poor man's alternative that can get us a lot of benefit.

In the JIT I find myself wanting to run a number of doit while debugging to print out information, change virtual breakpoint locations (where a variable is tested and if the JIT is at the right point halt is sent) etc. Typically one has to type these into the receiver inspector in the bottom left of the debugger. Having some strings in the paste buffer helps in not typing them but one has to load the paste buffer at least once before a debugging session and its tedious.

I modified the inspectors in VMMaker already so that one can choose the default base used to display numbers because hexadecimal is much more useful in looking at machine code, the GC, object headers, etc. So how about this...

A class may implement something like receiverMenuForDebugging, either on the instance or the class side. Whenever the receiver inspector is asked to open up the yellow/middle button menu on its list it checks for the presence of receiverMenuForDebugging and adds this as a submenu being the first item in the menu. So one can write all the application specific snippets one wants and invoke them quickly and conveniently from this menu.

Anyone interested in implementing this? It would make my day, hell it would make my month, and make my year so much nicer :-).

_,,,^..^,,,_

best, Eliot

marcel.taeumel

Re: An idea for the debugger...

Hi Eliot,

like this if you hit [SHIFT]+[YELLOW]?

... and implement this?

Object >> inspectorMenu: aMenu for: anInspector

"Can extend the inspector menu."

Smalltalk isMorphic ifFalse: [^ self].

aMenu

add: 'Dance ', self printString

target: self

selector: #explore.

Well, please find attached a change set. Have fun! ;-)

Best,

Marcel

Am 26.01.2018 18:36:23 schrieb Eliot Miranda <[hidden email]>:

Hi All,

I'm lazy and also I don't write the most elegant UI code but I had an idea I want realized so I thought I'd see if I could interest anyone in implementing it. Dora is doing amazing work with the Moldable Debugger but this is a poor man's alternative that can get us a lot of benefit.

In the JIT I find myself wanting to run a number of doit while debugging to print out information, change virtual breakpoint locations (where a variable is tested and if the JIT is at the right point halt is sent) etc. Typically one has to type these into the receiver inspector in the bottom left of the debugger. Having some strings in the paste buffer helps in not typing them but one has to load the paste buffer at least once before a debugging session and its tedious.

I modified the inspectors in VMMaker already so that one can choose the default base used to display numbers because hexadecimal is much more useful in looking at machine code, the GC, object headers, etc. So how about this...

A class may implement something like receiverMenuForDebugging, either on the instance or the class side. Whenever the receiver inspector is asked to open up the yellow/middle button menu on its list it checks for the presence of receiverMenuForDebugging and adds this as a submenu being the first item in the menu. So one can write all the application specific snippets one wants and invoke them quickly and conveniently from this menu.

Anyone interested in implementing this? It would make my day, hell it would make my month, and make my year so much nicer :-).

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

custom-inspector-menu.2.cs (5K) Download Attachment

timrowledge

Re: An idea for the debugger...

In reply to this post by Eliot Miranda-2

How about a persistent (for varying definitions) text morph view within debugger-land, functioning somewhat like the code view in an explorer. The current inspector views throw away anything when you change the inspector focus, which is both good and bad. Having a persistent place to run snippets would be useful. I’m not sure what the most convenient way to bind it would be. The explorer approach mostly works and is at least familiar even when it does something to annoy you.

I don’t think it would even have to be within the debugger window strictly speaking. Having an option to open it and put it out of the way could be useful. And we could pre-fill it with happy little lines of code applicable to the object(s) being debugged; imagine CodeProcessCogulator class>>debuggerSnippets returning a list of useful fragments.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.

Eliot Miranda-2

Re: An idea for the debugger...

In reply to this post by marcel.taeumel

Marcel, thank you!

On Fri, Jan 26, 2018 at 11:08 AM, Marcel Taeumel <[hidden email]> wrote:

Hi Eliot,

like this if you hit [SHIFT]+[YELLOW]?

... and implement this?

Object >> inspectorMenu: aMenu for: anInspector
"Can extend the inspector menu."

Smalltalk isMorphic ifFalse: [^ self].

aMenu
add: 'Dance ', self printString
target: self
selector: #explore.

Well, please find attached a change set. Have fun! ;-)

Best,
Marcel

Am 26.01.2018 18:36:23 schrieb Eliot Miranda <[hidden email]>:

Hi All,

I'm lazy and also I don't write the most elegant UI code but I had an idea I want realized so I thought I'd see if I could interest anyone in implementing it. Dora is doing amazing work with the Moldable Debugger but this is a poor man's alternative that can get us a lot of benefit.

In the JIT I find myself wanting to run a number of doit while debugging to print out information, change virtual breakpoint locations (where a variable is tested and if the JIT is at the right point halt is sent) etc. Typically one has to type these into the receiver inspector in the bottom left of the debugger. Having some strings in the paste buffer helps in not typing them but one has to load the paste buffer at least once before a debugging session and its tedious.

I modified the inspectors in VMMaker already so that one can choose the default base used to display numbers because hexadecimal is much more useful in looking at machine code, the GC, object headers, etc. So how about this...

A class may implement something like receiverMenuForDebugging, either on the instance or the class side. Whenever the receiver inspector is asked to open up the yellow/middle button menu on its list it checks for the presence of receiverMenuForDebugging and adds this as a submenu being the first item in the menu. So one can write all the application specific snippets one wants and invoke them quickly and conveniently from this menu.

Anyone interested in implementing this? It would make my day, hell it would make my month, and make my year so much nicer :-).

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

_,,,^..^,,,_

best, Eliot

marcel.taeumel

Re: An idea for the debugger...

In reply to this post by timrowledge

Hi Tim,

this sounds more like our Workspace needs a way to hijack another tool's bindings. ;-)

Best,

Marcel

Am 26.01.2018 20:23:48 schrieb tim Rowledge <[hidden email]>:
How about a persistent (for varying definitions) text morph view within debugger-land, functioning somewhat like the code view in an explorer. The current inspector views throw away anything when you change the inspector focus, which is both good and bad. Having a persistent place to run snippets would be useful. I’m not sure what the most convenient way to bind it would be. The explorer approach mostly works and is at least familiar even when it does something to annoy you.

I don’t think it would even have to be within the debugger window strictly speaking. Having an option to open it and put it out of the way could be useful. And we could pre-fill it with happy little lines of code applicable to the object(s) being debugged; imagine CodeProcessCogulator class>>debuggerSnippets returning a list of useful fragments.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.

timrowledge

Re: An idea for the debugger...

> On 27-01-2018, at 3:53 AM, Marcel Taeumel <[hidden email]> wrote:
>
> Hi Tim,
>
> this sounds more like our Workspace needs a way to hijack another tool's bindings. ;-)

How about a more polite “please Ms Workspace, accept my gift of some bindings from this Debugger”. Hijacking is so very 70’s.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Grogs does it take to change a lightbulb?”
"One. Something with manipulatory appendages will be along eventually."

Karl Ramberg

Re: An idea for the debugger...

In reply to this post by marcel.taeumel

Workspaces have the the ability to accept dropped morphs to bind to it, so you can send messages to the dropped morph.

Should be possible to use similar method to bind to a pane in the debugger.

Just have a menu item for the pane you can drag and drop in the Workspace.

Best,

Karl

On Sat, Jan 27, 2018 at 12:53 PM, Marcel Taeumel <[hidden email]> wrote:

Hi Tim,

this sounds more like our Workspace needs a way to hijack another tool's bindings. ;-)

Best,
Marcel

Am 26.01.2018 20:23:48 schrieb tim Rowledge <[hidden email]>:
How about a persistent (for varying definitions) text morph view within debugger-land, functioning somewhat like the code view in an explorer. The current inspector views throw away anything when you change the inspector focus, which is both good and bad. Having a persistent place to run snippets would be useful. I’m not sure what the most convenient way to bind it would be. The explorer approach mostly works and is at least familiar even when it does something to annoy you.

I don’t think it would even have to be within the debugger window strictly speaking. Having an option to open it and put it out of the way could be useful. And we could pre-fill it with happy little lines of code applicable to the object(s) being debugged; imagine CodeProcessCogulator class>>debuggerSnippets returning a list of useful fragments.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.

marcel.taeumel

Re: An idea for the debugger...

Hi Karl,

if you have too many levels of indirection, it might become difficult to use.

Nevertheless, dragging items from an inspector into a workspace might solve the problem to some extent. :) You would have to repeat the steps if you walk along the debugger's stack.

We can drag objects our of the regular inspector and object explorer. Does not work in the debugger though...

Best,

Marcel

Am 27.01.2018 22:08:34 schrieb karl ramberg <[hidden email]>:

Workspaces have the the ability to accept dropped morphs to bind to it, so you can send messages to the dropped morph.
Should be possible to use similar method to bind to a pane in the debugger.
Just have a menu item for the pane you can drag and drop in the Workspace.

Best,
Karl

On Sat, Jan 27, 2018 at 12:53 PM, Marcel Taeumel <[hidden email]> wrote:
Hi Tim,

this sounds more like our Workspace needs a way to hijack another tool's bindings. ;-)

Best,
Marcel

Am 26.01.2018 20:23:48 schrieb tim Rowledge <[hidden email]>:
How about a persistent (for varying definitions) text morph view within debugger-land, functioning somewhat like the code view in an explorer. The current inspector views throw away anything when you change the inspector focus, which is both good and bad. Having a persistent place to run snippets would be useful. I’m not sure what the most convenient way to bind it would be. The explorer approach mostly works and is at least familiar even when it does something to annoy you.

I don’t think it would even have to be within the debugger window strictly speaking. Having an option to open it and put it out of the way could be useful. And we could pre-fill it with happy little lines of code applicable to the object(s) being debugged; imagine CodeProcessCogulator class>>debuggerSnippets returning a list of useful fragments.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.