@RUTGERS.ARPA:goun%cadlac.DEC@decwrl.ARPA (02/22/85)
From: goun%cadlac.DEC@decwrl.ARPA (Roger H. Goun) > I'm not looking to bring back the memory dump. What I *would* like > to see, though, is some form of interactive debugging which promotes > the finding of more than one bug in a run. No, I don't have any > suggestions. Even in an interactive environment, fixing, recompiling, and reexecuting a program each time a single bug is discovered can be a time-consuming task, especially on a heavily loaded system. Often when I discover a program error while using a symbolic debugger, I will "patch" around the error and continue the debugging run. This is usually accomplished simply by depositing the proper value in some variable. I've found this technique to be a great timesaver. -- Roger Goun ARPA: goun%cadlac.DEC@decwrl.ARPA UUCP: {allegra, decvax, ihnp4, ucbvax}!decwrl!dec-rhea!dec-cadlac!goun USPS: Digital Equipment Corp., APO-1/B4 100 Minuteman Road; Andover, MA 01810-1098 Tel: (617) 689-1675
radford@calgary.UUCP (Radford Neal) (02/27/85)
Would someone please explain what's so wrong with fixing only one bug
in a run? Seems to me it is good practice NOT to try to fix more than
one problem at a time. This avoids possible interactions which weren't
anticipated.
Of course, if the compiler is slow you may be forced into making more
than one fix at a time, but it's still undesirable in itself.
I think what people are really trying to say is that programmers should
spend more time looking at, and understanding, their programs, rather
than mindlessly setting breakpoints. I can agree with this, but I'm not
convinced that interactive environments really encourage the opposite
among good programmers.
Radford Neal
The University of Calgary