On 25/09/2014 07:22, H. S. Teoh via Digitalmars-d wrote:
> Nevertheless, I think there is still room for debuggers to improve.
> Recently, for example, I learned that gdb has acquired the ability to
> step through a program backwards. Just missed the point in your program
> where the problem first happened? No problem, just step backwards until
> you get back to that point! Neat stuff. (How this is implemented is left
> as an exercise for the reader. :-P)

IIRC, that was only implemented for a few architectures, and none of them where the PC architectures. (Rather it was used a lot for embedded targets architectures, for which GDB is used a lot as well)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 25/09/2014 04:55, Walter Bright wrote:
> I've also found that the more high level abstractions are used, the less
> useful a symbolic debugger is. Symbolic debuggers are only good for
> pedestrian, low level code that ironically is also what other methods
> are very good at, too.

Err... are you talking in the context of D, or programming in general?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Thu, 02 Oct 2014 13:18:43 +0100
Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Err... are you talking in the context of D, or programming in general?
i'm not using interactive debuggers for 10+ years. the only use of GDB for me is doing post-mortem inspection. i found that logging and integrated control console lets me debug my code faster than any interactive debug session can.

besides, i found that i spent alot of time doing "next, next, next, run-to-bp, next, next" in interactive debugger instead of sitting down and think a little. ;-)

On Thursday, 2 October 2014 at 12:59:37 UTC, ketmar via Digitalmars-d wrote:
> i'm not using interactive debuggers for 10+ years. the only use of GDB
> for me is doing post-mortem inspection. i found that logging and
> integrated control console lets me debug my code faster than any
> interactive debug session can.

CLI based debugging in gdb is painful. Whether logging or using a debugger is faster really depends IMO. I think regular tracing/logging is easier when you debug recursive stuff like parser or regexp engines, but a debugger is easier when you have NULL dereferencing issues, when you are getting wrong values in complex calculations or when loops don't terminate when they are supposed to.

On Thu, 02 Oct 2014 15:11:37 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> CLI based debugging in gdb is painful.
i used alot of frontends too. martian ddd, then kde's frontend, then tried cgdb. and some other i can't even remember. it's not about bad interface. ;-)

> but a debugger is easier when you have NULL dereferencing issues
this is segfault and coredump. and then... yes, i'm loading that coredump in gdb and doint bt and various prints if necessary.

> when you are getting wrong values in complex calculations
logging can help here too. if we have valid input and garbage output... well, we know where bug is. plus validation of all data, asserts and so on. that's why i love D with it's static asserts, in, out, and invariants. and integrated unittests.

sure, i'm not a guru and just talking about personal expirience here. i found myself much more productive after throwing interacteve debuggers out of the window. ;-)

On Thursday, 2 October 2014 at 15:29:17 UTC, ketmar via Digitalmars-d wrote:
> sure, i'm not a guru and just talking about personal expirience here. i
> found myself much more productive after throwing interacteve debuggers
> out of the window. ;-)

Debugging preferences are very personal, I would think so. :-)

The first time I used an interactive source level debugger was in the late 80s using Turbo Pascal, I thought it was magically great, like a revelation! My reference was writing assembly and using a monitor/disassembler to debug… Source level debugging was quite a step up!

But I agree that debuggers can be annoying, reconfiguring them is often more troublesome than just adding some printf() hacks. I find them indispensable when I am really stuck though: "duh, I have spent 15 minutes on this, time to fire up the debugger".

In environments like javascript/python I often can find the problem just as fast by just using the interactive console if the code is written in a functional style.

The more global state you have and the less functional your style is, the more useful a debugger becomes IMO.

> But I agree that debuggers can be annoying, reconfiguring them is often more troublesome than just adding some printf() hacks. I find them indispensable when I am really stuck though: "duh, I have spent 15 minutes on this, time to fire up the debugger".


 Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it up like its still 1980.

On Thu, 02 Oct 2014 16:13:31 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> In environments like javascript/python I often can find the problem just as fast by just using the interactive console if the code is written in a functional style.
actually, i'm cheating here, 'cause most of my reasonably complex
software has well-hidden interactive console inside, so i can connect
to it to inspect the internal state and execute some (sometimes
alot ;-) of internal commands. and i must say that integrating such
console in C projects was tiresome. with D i can do it almost
automatically, skipping annoying "variable registration" and wrappers
for functions.

the first thing i wrote in D was "console module" -- just to test if all that "CTFE, and traits, and metaprogramming" promises are real. and then i became immediately hooked to D. ;-)

On Thu, 02 Oct 2014 16:22:38 +0000
po via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

>   Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it
> up like its still 1980.
did you updated your antivirus today?

On Thursday, 2 October 2014 at 16:22:39 UTC, po wrote:
>  Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it up like its still 1980.

:-) Well, gdb is not my favourite, but it works well on C code.  I think this holds for all kinds of debuggers (including VS and XCode)… In all debuggers you have to configure which expressions to watch, how to format them if they are complex and where the breakpoints go.

Printf logging with conditionals, asserts and recursive test-functions can often be just as easy as a debugger, if not easier, when working on complex algorithms/messy state machines/deep data structures/data with custom indirection (using ints, rather than pointers).