Hacker News Reader

Comment by limmeau | Hacker News Reader

I can really recommend debugging with command-line gdb (inside a text editor, of course; we're not barbarians). The transcript that lets you look back at the past of your debug session really adds a new dimension to the debug experience that a plain IDE integration just does not offer.

(Time-travelling debuggers are OK, too, I guess)

View on HN

What do you mean by transcript? I used gdb a while ago and it's mostly similar to a regular terminal application with readline.

By transcript, I mean every command and every response in the debug session. Usually, in the beginning, I do not know yet what I'm looking for, and set breakpoints at points that may be interesting, and when I reach the breakpoints, I look at variables. Later, when I reach the point where things have gone wrong, I can look at variable values now, but also at the result of every previous query. This helps me answer questions like: was this object here already in that queue over there when the previous request came in?

I can also attach the debug session to an issue in order for others or future me to understand what was happening then. In a purely GUI-driven debugger, I can copy&paste a stack trace of the final point, but the history is lost.

I've used scripts + logging in the past:

https://sourceware.org/gdb/onlinedocs/gdb/Logging-Output.htm...

Maybe that is what OP means by a transcript.

Just like I was doing with XEmacs in 1995...

There is so much a modern IDE debugging session is capable of.

What do you mean “inside a text editor”? What’s the workflow that you describe like?

I think it just means inside your editor's terminal, where there's usually some modest integrations like it detecting a source/line reference and either jumping you there or at least making it clickable.

VSCode for sure does this.

I cannot for the life of me get gdb to debug a remote in VS Code. The debugger runs, and breakpoints work and integrate, but the console is dead. '-exec print foo' does nothing.

GUD in Emacs (M-x gdb) is another example of this. You are still interacting with the gdb cli but also get some source code buffer integration.

gud-gdb in Emacs, yes.

Time travel to the UNIX world of early X Windows days.

Now picture XEmacs and Emacs, running gdb as subprocess, with a little pointed finger showing the current line and a stop sign for breakpoints.

The lower buffer shows the usual gdb repl and output.

Time travel to the late 70s and use the lisp machine debugger.

I always felt the drive towards mouse-driven tools in the PARC world (InterLisp/SmallTalk/CedarMesa) was actually a regression because of the loss of history ("how the hell did I get here?")

They also had a proper REPL, and the reason I stay with Java and .NET ecosystems, is because they are the closest we can get back to the Xerox experience, after the UNIX divergence.

Still available with DDD and various plugins to vim/emacs/vscode

Reply on news.ycombinator.com