User experience reports

[al13n321]

A type of feedback I'm particularly interested in is raw reports of the experience of using the debugger for the first time (or first few times). Think videogame playtesting. E.g.:

• Describe what went through your head at every moment, e.g. "now how do I see this value as hex; is there documentation? readme said something about --help... I see, --help-watches... hm, weird syntax but ok... ok here's the value". What didn't go maximally smoothly, e.g. it took a while to find how to do something, or to get used to how something works (even if you don't have ideas how to improve it). What missing features you ran into.
• Maybe even record a screen cast, maybe even with stream-of-consciousness voice commentary.
• Bonus points for using a real program rather than a hello world, and trying something practical, e.g. investigating a bug or learning how something works.
• Don't worry about producing high-quality writing, or telling a coherent story, or not being too harsh, etc. Again consider videogame playtesting: the developer just wants an accurate description of the player's experience, to be able to tweak the game in a way that improves that experience (or to inform bigger changes to the game); the less accurate the report the less effective the tweaks.

Hope this makes sense.

Feel free to post something like this here. Or something not like this, no pressure. You can also send me an email.

[pliniker]

Ok I'll go...

There's this old debugger by Borland I used to use in DOS in the 90s - Turbo Debugger. It was amazing. You could see everything all at once: CPU registers, disassembly, memory as hex... things were simpler then though.

I was looking for a similar, contemporary experience as I had a particular use-after-free segfault in a release build I wanted to understand. I've never felt at home in gdb or lldb; ddd works but it's a sluggish ui and I prefer command line tools. I came across nnd and decided to try it.

Once I got debug syms in my release build, ALL the expected information displayed. I was very pleasantly surprised to see the debugger show me a Rust stack trace, let me pick a call frame and browse the local vars. It even showed a red "bad address" next to the local pointer variable that had gone wrong. I could even do this all by mouse clicks in the terminal window, which is the first thing I typically would try just to see things work before getting used to keyboard shortcuts.

A couple things that have felt unintuitive/awkward:

• It took a little while to realize that the "controls" pane displays keyboard controls contextual to the pane that is currently selected. This is actually fine, just not initially clear. Reading the pane text is not easy as it's quite dense and the meaning of some text isn't immediately obvious. But hey, just like Turbo Debugger in 1995 XD. Maybe hitting a help key could pop up a large pane where the shortcuts for each pane are given more explanation in a visually structured display?
• Another minor difficulty is scrolling a pane vertically, say the code or disassembly panes: 1) using mousewheel/trackpad feels too jumpy/moves too much at a time - I realize this may be my own input device configuration though, also, using the keyboard to scroll works just fine so not a big deal; 2) when scrolling back to where the currently selected stack frame's IP is at, it's not obviously highlighted which line of code that is.

What I really enjoy is that the discoverability is very good. Yes, the controls pane isn't easy to follow but just pressing all the keys to see what would happen out turned out to be harmless. Often in complex user interfaces, trying things out makes controls, dialogs, settings appear or disappear in ways that are unobvious how to undo. Not the case here!

Question: in the code pane, why do some function names have their first letter highlighted? What does it mean?

[al13n321]

Thanks!

• Controls pane: got it, I think I'll (1) use colors to indicate which keys are pane-specific (I did worry that it's unclear, but for some reason the obvious solution of using colors never occurred to me until now), (2) add a help dialog with... I guess just the same list of keys but with longer descriptions? And ideally all of --help-* text, maybe just as a sequence of pages to flip through.
  • Just pressing keys and seeing what happens is the intended way, good to know that it works!
• Scroll wheel sensitivity: it's actually configurable, see ~/.nnd/keys.default (vertical_scroll_sensitivity at the bottom, but read the comment at the top on how to edit the file). The default is 8 lines per scroll "event", which seems good for a clicky mouse wheel, but too sensitive for a macbook trackpad. Maybe I'll decrease it to 4.
• To scroll to IP there's a trick: switch stack frame back and forth (']' and '['). (Or do you mean it's not visually clear enough even after it auto-scrolls to the IP line, with the line highlighted in gray?)
• The highlights in code are locations of all "statements", according to debug info. It's where control can stop when stepping, and where breakpoints can be set. It's mentioned in --help-overview. I couldn't think of a natural way to indicate the meaning directly in the UI, lmk if you have an idea.

[pliniker]

Help: 🤔 to be honest it never occurred to me to use --help! Yeah I think if there is a help key that pops that up as a sequence of pages that would be a good alternative, plus the list of panes and a more detailed explanation of what key combos do what in each pane.

Scroll to IP: I think it felt not visually clear enough - like I didn't notice the green arrow right away and clicking on another line highlights that line. Maybe it could be permanently highlighted no matter where else you click, in a bolder color combo?

Highlights: okay that makes a ton of sense. Probably because I've been debugging a release build those highlighted characters are somewhat more randomly placed after all the compiler optimizations. I can't think of an improvement though. Here's a small thing - when the source code for a call frame isn't available, it's like source is still been shown but all blank lines - the highlight characters are still there floating on the blackness. Maybe if the source file isn't found, the souce pane should not try to render lines of code?

[al13n321]

Floating highlights are meant to be a feature: you can see a ghost of the file even when the file is not available. Does look confusing/broken though, idk what to do about it, will keep it as is for lack of better ideas.

[A1029384756]

my first experience opening this debugger when used to something like gdb was: "well this is a lot nicer". i've used gdb, lldb, and gdb through nvim-dap before and this felt like a step up in many ways. worked perfectly with odin and immediately felt right at home. one thing i didn't immediately grok was that the controls pane was context-sensitive and that the contents change when moving panes. some indication of what pane the controls are referencing would be helpful here.

one thing that also comes to mind as a point of potential concern is the controls pane. this is an excellent addition that has been immensely helpful in picking up the debugger but, could potentially become overcrowded if more features are added. some way of offloading that information to other parts of the ui might be worth investigating

i found the "continue to cursor" feature extremely nice when debugging a strange layout bug that was causing my textboxes to flicker to their previous state for one frame after submission. this allowed me to jump over larger blocks of code without having to mess with breakpoints i would have immediately removed

the final thing i noticed that was a bit of a gripe for me was that code panes, watches, etc persist between sessions, even when in completely different parts of the filesystem. this is great when i'm doing multiple debugging sessions within a single project but was a bit of a pain point when hopping over to other projects

[al13n321]

For saving state, I was thinking of a command line option for "session" name. Currently state lives in ~/.nnd/<number>/, and the <number> is assigned sequentially among concurrently running debugger instances. It would be trivial to allow an arbitrary name instead of <number>, and some special name for transient session whose state won't be saved.

[al13n321]

Added named sessions: use -n <name>, optionally read --help-files for details.