Re: Ok sorry, it is just a book gives no feedback.

[Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)]

In article <938qom$ptd$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> I find that people who "detest" certain styles of working and
> working environments sometimes lack the flexibility to deal
> with difficult situations. It sounds for instance like you
> would be really stuck if you were in a hiesenbug situation
> where the bug does not appear if you operate in the presence
> of the debugger. This can most certainly happen with some kinds
> of erroneous programs, or where timing problems are an issue.

Been there, done that, got the T-shirt.  I detested it.
I think one of the great debugger advances has been to
use a small engine in the process being debugged and
put the great bulk of the debugger (GUI, etc.) into
another process where it will not impact addresses,
etc.  (Of course that does not eliminate the heisenbug
possibility, but it reduces it in my experience). The
advent of this approach, however, was probably motivated
as much by kernel mode symbolic debugging as by taking
pity on those of us who were bitten by problems that go
away in the presence of the debugger.

> Indeed in real time programs, the paradigm of breakpoint and
> examine often breaks down badly. Yes, there are some
> asyncrhonous debugging tools around (like OCS Aprobe) which
> can be very valuable in such situations, but sometimes, a
> judiciously placed put_line can be the most efficient and
> effective debugging approach. If you are sure you "detest"
> such an approach, you may end up proceeding in less than
> an optimal manner. Flexibility is always a plus.

Detesting something is different from being unable to do it--
but I would expect code labeled PURE to be thoroughly debugged
outside that realtime environment through unit test and test
coverage analysis.

> Larry, I take it you are still stuck in an Ada 83 environment,
> where this particular issue does not arise? (I say that because
> it is quite a familiar problem to Ada 95 programmers :-)

I am quite happy programming in Ada 83, even for compilers that
support Ada 95, in order to preserve portability.  In our past
discussions in this newsgroup when I point out operating systems
without Ada 95 support you have said they are not popular operating
systems with ACT customers.