From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8c54bb73b6fd8d22 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: GDB Woes Continued... Date: 1998/02/02 Message-ID: #1/1 X-Deja-AN: 321402605 References: <6b07b3$inj$1@Masala.CC.UH.EDU> <01bd2e9b$76253380$562c5c8b@aptiva> <6b4k6k$30t$1@Masala.CC.UH.EDU> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 886439306 19553 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-02-02T00:00:00+00:00 List-Id: <<<> >> Clearly a lot of people depend on debuggers, so most certainly a good working debugger is an absolute necessity for a usable compiler system, since clearly customer demand is what establishes such needs. However, to explain my comment above. I continue to think that most people greatly overuse debuggers. It is much better to write error-free code in the first place, and if you do have errors, to think about what is wrong, and fix it, rather than spending ages in a debugger looking arond. Of course different people have different styles, but too many programmers today are introduced only to the hack-and-debug school of coding. It is interesting to present the clean-room model to typical programmers today (this is the approach in which developers are not permitted to run their code at all to test it, let alone to debug it -- the idea is to have the developers develop solid correct code, and then let a separate team do the testing). Many programmers cannot imagine writing code without testing it themselves. They are so used to the approximate-and-hack-into-shape approach. Of course there are always exceptions, where subtle interactions are best tracked down with a debugger, and a working debugger is especially important in such cases, but never forget, it is your *brain* that is the most important tool, not the compiler or the debugger :-) Going back to the use of GDB and Win95, one suggestion you might want to pursue is using NT instead of Win95. Win95 may be fine for word processing and playing games, but it seems far too unstable to be appropriate as a serious program development platform. We have certainly found NT to be much more reliable than Win95, and most of our customers using the NT/WIn95 version of GNAT are indeed using NT. GDB itself has always been more stable under NT (the delay in releasing it was solely because of the Win95 problems, since we realize that users of the public version are more likely NOT to be serious developers and to be fiddling with Win95). Still we do have some customers using WIn95, and they are certainly managing to get GDB up and running reasonably well. It is true that this is the 3.11 technology, which has a LOT of very substantial improvements in GDB and the debugging information available in Ada mode. Still, I don't think the reported problems here are to do with 3.10 vs 3.11, they seem more fundamental. If they are not installation problems, then it seems like there are some versions of Win95 that simply don't let you get past first base in loading GDB, very odd! Robert Dewar Ada Core Technologies