5 ms·

Alternatively, use a debugger. This issue would have become obvious in seconds if he had stepped through it with a debugger. Of course if you only have gdb as a

by roel_v 15y ago

Alternatively, use a debugger. This issue would have become obvious in seconds if he had stepped through it with a debugger. Of course if you only have gdb as a debugger, that's easier said than done - I'd too rather stab myself in the eye with a hot poker than using gdb again. Proper tools make issues like this much less painful to solve.

pestaa 15y ago
What was it so painful about it you had to highlight gdb specifically? I'm just starting out with it, so far it seems a lot more flexible than its visual counterparts do.
- jrockway 15y ago
  Agreed. I've spent a lot of time in gdb and have never had any problems with it. I think he probably wants some GUI where the watches automatically update, or where -O3'd code magically executes as though the compiler didn't do any optimizations on it.
  - burgerbrain 15y ago
    "r where -O3'd code magically executes as though the compiler didn't do any optimizations on it." That seems like one hell of an invitation for Heisenbugs. Are there debuggers that actually do that?
    - swaits 15y ago
      Nope.
    - kragen 15y ago
      Google [dynamic deoptimization].
- roel_v 15y ago
  Its lack of easily seeing the surrounding code you're stepping through. Its cumbersome ways of use (having to type commands for inspecting variables rather than just being able to point at them). Its difficulty of learning it. And all of that for no benefit - I spend hours learning vim too, but at least there I got flexibility and a supremely powerful editor in return; but there is nothing gdb can do that the Visual Studio debugger can't. And there you just set a breakpoint and press run, while for gdb it takes you a day just to get integration with your editor set up the first time. I'm not sure what you mean with 'flexible' - a debugger is by its very nature interactive, so the typical advantages of text-based tools don't apply. But of course YMMV etc.
  - scott_s 15y ago
    It depends on your mental model and how comfortable you are with the commands. It's similar to the disconnect between navigating a file system on the command line and through a GUI.
  - ori_b 15y ago
    gdb -tui
  - jrockway 15y ago
    gdb can "list" and "where", which gives you the lexical and dynamic contexts respectively. Here come the downvotes... but if you don't know the code running in the debugger well enough to remember the details, well, you've found your bug. Read and understand your code very carefully before you waste your time single-stepping through it. (This is the biggest problem I see with developers that use IDEs -- they forget that they have a brain, and that your brain is always going to be faster than clicking shit in Eclipse.)
    - roel_v 15y ago
      Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function, But even then, single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst.
jobu 15y ago
Alternatively, use a decent IDE. Visual Studio and XCode both did the correct syntax coloring when I tried his bug. I don't code on linux anymore to compare emacs or vim, but if they don't handle it correctly I would submit a bug with them.
icebraining 15y ago
There's always DDD: http://www.gnu.org/s/ddd/ http://www.gnu.org/s/ddd/

by roel_v 15y ago

pestaa 15y ago

What was it so painful about it you had to highlight gdb specifically? I'm just starting out with it, so far it seems a lot more flexible than its visual counterparts do.

jrockway 15y ago
Agreed. I've spent a lot of time in gdb and have never had any problems with it. I think he probably wants some GUI where the watches automatically update, or where -O3'd code magically executes as though the compiler didn't do any optimizations on it.
- burgerbrain 15y ago
  "r where -O3'd code magically executes as though the compiler didn't do any optimizations on it." That seems like one hell of an invitation for Heisenbugs. Are there debuggers that actually do that?
  - swaits 15y ago
    Nope.
  - kragen 15y ago
    Google [dynamic deoptimization].
roel_v 15y ago
Its lack of easily seeing the surrounding code you're stepping through. Its cumbersome ways of use (having to type commands for inspecting variables rather than just being able to point at them). Its difficulty of learning it. And all of that for no benefit - I spend hours learning vim too, but at least there I got flexibility and a supremely powerful editor in return; but there is nothing gdb can do that the Visual Studio debugger can't. And there you just set a breakpoint and press run, while for gdb it takes you a day just to get integration with your editor set up the first time. I'm not sure what you mean with 'flexible' - a debugger is by its very nature interactive, so the typical advantages of text-based tools don't apply. But of course YMMV etc.
- scott_s 15y ago
  It depends on your mental model and how comfortable you are with the commands. It's similar to the disconnect between navigating a file system on the command line and through a GUI.
- ori_b 15y ago
  gdb -tui
- jrockway 15y ago
  gdb can "list" and "where", which gives you the lexical and dynamic contexts respectively. Here come the downvotes... but if you don't know the code running in the debugger well enough to remember the details, well, you've found your bug. Read and understand your code very carefully before you waste your time single-stepping through it. (This is the biggest problem I see with developers that use IDEs -- they forget that they have a brain, and that your brain is always going to be faster than clicking shit in Eclipse.)
  - roel_v 15y ago
    Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function, But even then, single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst.

jobu 15y ago

Alternatively, use a decent IDE. Visual Studio and XCode both did the correct syntax coloring when I tried his bug. I don't code on linux anymore to compare emacs or vim, but if they don't handle it correctly I would submit a bug with them.

icebraining 15y ago

There's always DDD: http://www.gnu.org/s/ddd/ http://www.gnu.org/s/ddd/