Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New debugger extension model to display dynamic extensions #739

Merged

Conversation

adri09070
Copy link
Contributor

@adri09070 adri09070 commented Apr 9, 2024

New Dynamic Debugger Extension System

This PR introduces a new debugger extension model to display extensions dynamically. These "dynamic" extensions are displayed only if they are activated (that goes without saying) and only if we are in a specific context.

Description of the New Debugger Extension System

The debugger extension determines if it can be displayed in a debugger via the method:

TStDebuggerExtension>>#acceptsPredicate:  aStDebuggerContextPredicate

   ^ true "By default, a debugger extension is static"

This method uses the debugger's context predicate to determine if the extension should be displayed or not. We could discuss: Should the method use a debugger as parameter instead of a context predicate? The extension would have more parameters to decide if it should display itself or not, but is it necessary ?

This induces two big changes in the update of extensions:

  • When an extension is (de)activated which sends an StDebuggerExtensionToggleAnnouncement to the debugger, the debugger now should consider the current context predicate, because if it is refused by the toggled extension, the extension toggle should be ignored: it has no effect
  • The context predicate can change after each action in the debugger, including steps (correct me if I'm wrong). So the extensions should be updated accordingly. Instead of just updating the instanciated presenters, we should check if there are:
    • extensions that were activated but that didn't accept the debugger context predicate until now, in which case it should be added now.
    • extensions that were activated and that did accept the debugger context predicate until now, in which case it should be removed from the extension tools.

This can be summed up by the two following boolean tables.

Boolean table describing the action to take according to the current debugger context predicate when a debugger extension has been (de)activated, resulting in a StDebuggerExtensionToggle announcement:

showInDebugger state change accepts predicate action on extension
/ false nothing
 false -> true true display
true -> false true hide

Boolean table describing the action to take according to the current showInDebugger state of an extension, when an action has been performed in the debugger, resulting in a potential change of status in the debugger context predicate:

showInDebugger state accepts predicate change action on extension
false  / nothing
true false -> false nothing
true true -> true nothing
true false -> true display
true true -> false hide

Introducing a New Dynamic Debugger Extension: Creating Method Extension

This debugger extension is displayed by default in the system settings:

image

This extension only appears if a DNU is raised and opens a debugger:

image

It has the exact same function as the "Create" button in the debugger toolbar, except that this extension allows the user to create the missing method while choosing the class or trait in the class hierarchy in which it should be installed, as well as the protocol under which it should be installed.
Whereas the "Create" button creates the missing class in the class of the receiver of the missing message, under a protocol chosen by the system.

With this extension, once you create the method by clicking the "Add method" button, the method has been created, the extension is not displayed anymore, and you can then proceed the execution (or debug it, of course):

image

StevenCostiou and others added 27 commits September 19, 2023 07:42
…nstances can override if they should be shown in a debugger depending of the selected context
…is no extension registered then there is no extension pane.
…ated in the debugger and should not be manually configureable.
…hould be displayed (by default: in any context)
… displayed at the moment, taking into account the current context predicate
…n is (de)activated (via StDebuggerExtensionActivationToggle) + doing nothing if the context predicate does not allow to display the extension anyway
…king into account the new context predicate to update debugger extensions after each step
…tension instead of a presenter owned by a debugger extension
… check that it is displayed/hidden when it should be
@adri09070 adri09070 added enhancement New feature or request debugger labels Apr 9, 2024
@adri09070
Copy link
Contributor Author

@StevenCostiou

@StevenCostiou StevenCostiou changed the base branch from Pharo12 to Pharo13 April 29, 2024 10:15
@StevenCostiou
Copy link
Member

The failing test seem unrelated?
I am reveiwing the changes now.

@adri09070
Copy link
Contributor Author

The failing test seem unrelated? I am reveiwing the changes now.

The test fails in a fresh Pharo 13 image so it is unrelated

Copy link
Member

@StevenCostiou StevenCostiou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good for merge.
Just one minor change that would be great ;)

@StevenCostiou StevenCostiou merged commit ba73b13 into pharo-spec:Pharo13 May 3, 2024
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugger enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants