🚀 go-pugleaf

In article <KANZE.95Oct23143738@slsv7xt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> In article <46861u$748@ubszh.fh.zh.ubs.com> jis@ubszh.net.ch (Johnston
|> Ian (by ubsswop)) writes:

[snip]

|> |> 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. 

Yup, this is one of the points I mention in follow-up to another poster.

|> 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.

Or in vendor-supplied code, yes.

[snip]

|> |> 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?

Is this with or without the swapper in memory too? <g>

|> |> 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.)

It might save you having to go into the office to prove that someone
else's code is broken :-) :-)

|> 
|> |> 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:-).

How true. You say tomato ...

Ian