[Nix#9729] Make debugger traces less confusing (and other low hanging fruit) #71

New issue

Open

opened 2024-03-16 06:44:45 +00:00 by lix-bot · 0 comments

lix-bot commented

2024-03-16 06:44:45 +00:00

Member

Upstream-Issue: NixOS/nix#9729

Is your feature request related to a problem? Please describe.

The debugger has commands for two types of "traces".

:bt, which aligns with the call stack
:st, which shows the scope

I wouldn't think of the latter as a "trace" but rather just the scope.
Nonetheless, :st <num> selects from the :bt stack. I suppose the reasoning is that it switches the repl scope to a different call stack frame.

Describe the solution you'd like

Add :scope (and not :scope <num>). It behaves like :st. Hide :st and make it tell you to use :scope.

Add :frame <num> to select a scope from the backtrace. This matches GDB. (LLDB has frame select <num>.)

:bt is good and aligns with GDB and LLDB.

Maybe add a :scope <num> command for the purpose of accessing shadowed variables, or something more explicit like :scope leave <num>.

Clean up and clarify the :? help text.

Review the output printed by the commands. Some terms don't match well with the user's frame of reference; e.g. "Env level" -> "Scope level", and "static:" seems irrelevant. Drop the printed pointers?

Reverse the print order of the call stack (:bt), to match the order of --show-trace. (ie without changing the frame<->number mapping. 0 is still the latest frame, but will be printed last)

Describe alternatives you've considered

Not so much an alternative, but alternative naming can be considered.

Maybe make it more noun-verb like, like the CLI. Feels more LLDB-like, although hopefully more consistent.

:bt
:frame select 2
:scope
:scope select 2

Doesn't feel like a big difference though, and more effort to type that in.

Additional context

Priorities

Add 👍 to issues you find important.

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/9729 **Is your feature request related to a problem? Please describe.** The debugger has commands for two types of "traces". - `:bt`, which aligns with the call stack - `:st`, which shows the scope I wouldn't think of the latter as a "trace" but rather just the scope. Nonetheless, `:st <num>` selects from the `:bt` stack. I suppose the reasoning is that it switches the repl _scope_ to a different call stack frame. **Describe the solution you'd like** Add `:scope` (and not `:scope <num>`). It behaves like `:st`. Hide `:st` and make it tell you to use `:scope`. Add `:frame <num>` to select a scope from the backtrace. This matches GDB. (LLDB has `frame select <num>`.) `:bt` is good and aligns with GDB and LLDB. Maybe add a `:scope <num>` command for the purpose of accessing shadowed variables, or something more explicit like `:scope leave <num>`. Clean up and clarify the `:?` help text. Review the output printed by the commands. Some terms don't match well with the user's frame of reference; e.g. "Env level" -> "Scope level", and "static:" seems irrelevant. Drop the printed pointers? Reverse the print order of the call stack (`:bt`), to match the order of `--show-trace`. (ie without changing the frame<->number mapping. 0 is still the latest frame, but will be printed last) **Describe alternatives you've considered** Not so much an alternative, but alternative naming can be considered. Maybe make it more noun-verb like, like the CLI. Feels more LLDB-like, although hopefully more consistent. ``` :bt :frame select 2 :scope :scope select 2 ``` Doesn't feel like a big difference though, and more effort to type that in. **Additional context** **Priorities** Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).