[OT] Which IDE / Editor do you use?

[H. S. Teoh]

On Sat, Sep 14, 2013 at 02:25:43PM +0200, Paolo Invernizzi wrote:
> On Saturday, 14 September 2013 at 07:28:33 UTC, Nick Sabalausky
> wrote:
> >
> >Any time I use a debugger I get sooo sick of having to reset and hit
> >"step" a million times (or muck around with conditional breakpoints,
> >which never seem to be intuitive - *if* they even work at all) every
> >single time I want to see (or remember) what happened *before*.  But
> >with writeln - I already see the whole relevant trace at a glance,
> >and all with exactly the same tools and interfaces I'm already using.
> >
> >Writeln debugging rocks my world.
> 
> Give me a way to writeln the callstack frames at a certain point,
> and I'll take that: until this, I still need a debugger for
> following the program flow.

I'm pretty sure this is possible with a little effort. In fact, this
would be a game-changer to writeln debugging. I should take a look at
the stack unwinding code in druntime sometime and see if I can knock
something together that does this.

One trick my coworkers like to use sometimes (with C/C++) is to insert
an infinite loop into the program at the suspected problem spot, then at
runtime when it reaches 99% CPU, kill -11 to force a segfault to
generate a stack trace (we have a stacktrace generator hooked up to the
signal handler). I've used that a couple o' times, and it's surprisingly
effective, I must say. We found that sometimes this is the only approach
that is effective, since the path to get to the problem spot may be
completely non-trivial to reach from a debugger (may involve fork()'s,
dynamically-loaded .so's, and event loops dispatches triggered by
real-time network data that would be excruciatingly slow to step through
manually in a debugger).

Still, if there was a way to print a stacktrace *without* terminating
the program, that would be an invaluable addition to our toolset.


> And no, adding a writeln everywhere you call that function is not a
> solution.
[...]

True, this is one of the weak points of writeln debugging. Though I
usually start from the top-level, so generally by the time I get to a
specific function I already know how it got there.

OTOH, even displaying callstack may not help if your code is heavy on
callbacks (or in D, delegates) invoked from event loops. The original
context that registered the callback is long gone by the time the
function actually runs, so the callstack only goes down to the event
dispatcher, which is no help.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.