Re: Debugging Problem with Gnatbench under Eclipse

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 13.11.13 02:12, Adam Beneschan wrote:
> So the suggestions on this thread, that debuggers are largely irrelevant to Ada programmers, is one that gets my dander up a bit.  They can be useful tools.  And I'd encourage the OP to try to get the vendor to fix the problem, since it's a tool he might find useful in the future.


Could it be that Ada programmers just don't know debuggers? 8-)

Debuggers turn my unforgiving CPU into a much more lenient interpreter,
Its steps are under my control.

Debuggers provide for a kind of "virtual machine", or extended machine.
They add features with uses for the programmer without him or her adding
a single line of source text. I can manipulate the program as is, I can
see call chains easily, at every instruction I choose, in circumstances
I choose.

This turns debuggers into programmable simulators. They will assist,
for example, with test driven development. (Which includes finding bugs
in logic that do not have counterparts among the exceptions.) For example,

- Debuggers can test my assumptions (debugging a solution) like:
do I see actual parameters that I expected to be passed to procedure Foo
when the program calls Foo for the third time?

- Debuggers make me think of possible cases (debugging the specification):
Oh, I missed the case where 42 could end up in x.y.

During my daily (non-Ada) work, I sometimes wish I could use a debugger,
as adding all sorts of trace statements and then scanning log files
is cumbersome.

Even gdb, used with or without fancy Expect (or ELisp) programming,
understands the "commands" command.

So, for instance, a debugger procedure can
1 Stop at F in this situation
2 Show what's in the variables x, y, and z
3 IF y IS NOT IN {1,...,64} THEN:
3a show the call chain
3b set y to a known good value
4 continue