You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on some small new features on forge debugger. I added a new "control" pane to display misc infos. There's a section called "Command", and I want the user be able to interact with the debugger. For example, it will now show input buffer (i.e. number + action)
New feature discussion
Currently forge debugger executes a transaction and collect all execution steps and display them. It lacks dynamic modifying values.
Although this requires a big refactor, it will be easier for debugging for special needs. One can simulate different scenarios and edge cases without altering the source code or redeploying contracts or re-execute with different params.
For refactoring, I think we have two paths to go. One is to change the debugger to a step-wise style, which does not execute the transaction at once. The other is to use an inspector containing an (address, pc, modification) tuple, and when a modification command is input, the transaction will be re-executed.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Given that the current state of external debuggers is still quite early I feel like it definitely still makes sense to iterate on the current version of the debugger and I'm supportive of your proposal.
If I understand you correctly this is something you would like to contribute? If so, let me know if you have any questions or run into any blockers.
Component
Forge
Describe the feature you would like
Background
I am working on some small new features on forge debugger. I added a new "control" pane to display misc infos. There's a section called "Command", and I want the user be able to interact with the debugger. For example, it will now show input buffer (i.e. number + action)
New feature discussion
Currently forge debugger executes a transaction and collect all execution steps and display them. It lacks dynamic modifying values.
Although this requires a big refactor, it will be easier for debugging for special needs. One can simulate different scenarios and edge cases without altering the source code or redeploying contracts or re-execute with different params.
For refactoring, I think we have two paths to go. One is to change the debugger to a step-wise style, which does not execute the transaction at once. The other is to use an inspector containing an (address, pc, modification) tuple, and when a modification command is input, the transaction will be re-executed.
Additional context
No response
The text was updated successfully, but these errors were encountered: