🚀 go-pugleaf

In article <46861u$748@ubszh.fh.zh.ubs.com> jis@ubszh.net.ch (Johnston
Ian (by ubsswop)) writes:

|> In article <467rgq$c77@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
|> |> Johnston Ian (by ubsswop) (jis@ubszh.net.ch) wrote:

|> |> |> On the contrary, I find an interactive debugger extremely useful. I routinely
|> |> |> run my code under the debugger -- before running it normally -- for visual
|> |> |> verification.

|> |> |> Besides, an interactive debugger is essential in the real world.

|> |> I guess I don't program in the real world then, because I don't have an
|> |> interactive debugger (unless you count the bundled adb) on my machine.
|> |> At my customer site, there *is* an interactive debugger, but in fact,
|> |> the application is so big that the debugger won't fit in memory with the
|> |> symbol table information.  So I've never used it.

|> Point taken.

|> Let's say that an interactive debugger is extremely useful, then.

For what?  About the only times I've gone into a debugger was to find
compiler bugs, and that was adb.  Occasionally, I've used gdb to prove
to someone else that the problem was in their code, and not in
mine:-).  But that's about it.

Generally speaking, the application level code is instrumented.  In
case of problems, this gives the information necessary to reproduce
the error (supposing the instrumentation was turned on when the error
occured), and to determine which module is affected.  At that point,
an additional test is added to the module unit test.  If the modules
are small enough, comparing the actual output with what was expected,
and a little reasoning, and the error is obvious.  (If it isn't
obvious to you, ask your buddy.  In my experience, the most obvious
and stupid errors are invisible when you are looking at your own
code.  But no matter how good you are, and how stupid your buddy is,
he will see it right away.)

|> So, you still haven't cut the size of that application down then, eh :-)?

Awww.  It fits in (virual) memory; what more do you want?

|> Are there no remote debuggers available on UNIX? That is, where the
|> debugger runs on a machine separate from the debuggee, with a small
|> debugger stub in the debuggee.

Actually, I think we have a remote debugger available.  I seem to
remember having heard something like that when we evaluated the
compiler.  I've never bothered finding out, though.  (For that matter,
I think gdb can also remote debug.)

|> Borland have had such a scheme on PCs for a while.

Then there must be one for Unix.  Every Unix fan knows: anything a PC
can do, Unix can do better:-).
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung