On Wed, Sep 24, 2014 at 08:55:23PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote:
> >>I'm sorry, but this is awfully vague and contains nothing
> >>actionable.
> >The action I'd love to see would be "Yes, debugging is important, we
> >should add it at a high priority on the roadmap and encourage the
> >language community to work with the tooling community to make sure
> >the experience is polished" ;)
>
> I make similar statements all the time. It doesn't result in action on
> anyone's part. I don't tell people what to do - they work on aspects
> of D that interest them.
>
> Even people who ask me what to work on never follow my suggestions.
> They work on whatever floats their boat. It's my biggest challenge
> working on free software :-)
Yeah, this is characteristic of free software. If this were proprietary
software like what I write at work, the PTBs would just set down items
X, Y, Z as their mandate, and everyone would have to work on it, like it
or not. With free software, however, if something isn't getting done,
you just gotta get your hands dirty and do it yourself. Surprisingly,
many times what comes out can be superior to the cruft churned out by
"enterprise" programmers who were forced to write something they didn't
really want to.
[...]
> Note that I find gdb well nigh unusable even for C++ code, so to me an
> unusable debugger is pretty normal and I don't think much about it.
> :-) It doesn't impair my debugging sessions much.
printf debugging FTW! :-P
> 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.
[...]
I don't agree with that. I think symbolic debuggers should be improved
so that they *can* become useful with high level abstractions. For
example, if debuggers could be made to understand templates and
compile-time constants, they could become much more useful than they are
today in debugging high-level code.
For example, the idea of stepping through lines of code (i.e. individual
statements) is a convenient simplification, but really, in modern
programming languages there are multiple levels of semantics that could
have a meaningful concept of "stepping forward/backward". You could step
through individual expressions or subexpressions, step over function
calls whose return values are passed to an enclosing function call, or
step through individual arithmetic operations in a subexpression. Each
of these levels of stepping could be useful in certain contexts,
depending on what kind of bug you're trying to track down. Sometimes
having statements as the stepping unit is too coarse-grained for certain
debugging operations. Sometimes they are too fine-grained for high
levels of abstractions. Ideally, there should be a way for the debugger
to dissect your code into its constituent parts, at various levels of
expression, for example:
statement: [main.d:123] auto x = f(x,y/2,z) + z*2;
==> variable allocation: [hoisted to beginning of function]
==> evaluate expression: f(x,y/2,z) + z*2
==> evaluate expression: f(x,y/2,z)
==> evaluate expression: x
==> load x
==> evaluate expression: y/2
==> load y: [already in register eax]
==> load 2: [part of operation: /]
==> arithmetic operation: /
==> evaluate expression: z
==> function call: f
==> evaluate expression: z*2
==> load z: [already in register ebx]
==> load 2: [optimized away]
==> arithmetic operation: / [optimized to z<<1]
==> evaluate sum
==> expression result: [in register edx]
==> assign expression to x
==> store x
The user can choose which level of detail to zoom into, and the debugger
would allow stepping through each operation at the selected level of
detail (provided it hasn't been optimized away -- if it did, ideally the
debugger would tell you what the optimized equivalent is).
T
--
Public parking: euphemism for paid parking. -- Flora
