Re: GDB Woes Continued...

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>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.
>
    This is very true for most types of "workstation-ish" programs. In
    most of the things I've built using Gnat on a Sun platform, I've
    found very little use for a debugger because you can usually bench
    check the code to be mostly error free from the beginning. (At
    least for the kinds of errors most commonly found with a debugger.
    If the program executes, but doesn't perform the task correctly
    because you've messed up a requirement somewhere, the debugger is
    going to be of little value.) Bench checking for routine errors
    also invariably leads to: "Gee! That's not supposed to be here..."
    sorts of discoveries which tend to minimize the fundamental flaws
    you don't see when checking for superficial flaws with a debugger.

    My experience is that the more clear you are about what a program
    or piece of a program is supposed to do, the more likely you are
    to get it right the first time. Some folks can do this in their
    heads up front - sometimes it has to come from more formal
    methods. But either way, if you understand it thoroughly, you tend
    to write clear, direct, to-the-point code which doesn't need to be
    debugged.

    Although I don't use gdb that much, I still think it's handy -
    especially when you end up with an error during elaboration &
    don't get a traceback to know what module caused the trouble. Gdb
    is pretty good at filling that gap. I'd have to agree that there
    is a bit of a dearth of good documentation, but with what's
    available that I've seen, you can get it to work.

>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).
>
    I've driven Win95 around a bit on laptops and other platforms and
    my experience is that it is a pretty pathetic attempt to label
    something an operating system. I've never had much trouble getting
    Win95 to crash - even using Micro$oft's own software. Granted, my
    experience is limited - a little like my experience with sitting
    on hot stoves, or poking sharp objects into my eyes. Maybe you get
    used to it after a while.

    WinNT has performed for me quite reliably. I've occasionally had
    some applications go casters-up, but they have never taken down
    the whole system. For any sort of serious development I'd find
    WinNT the right way to go.... with a single caveat:

    From what I've been able to determine, you can't really use WinNT
    successfully for real time work if by "real time" you mean cycle
    times under 20 milliseconds. (O.K., maybe if WinNT doesn't have to
    drive anything but your app, you can make things predictable. But
    if the machine runs your app and may also be called on to run
    other apps, you have some real problems with guaranteeing
    latencies such as responding to interrupts.) For some of these
    apps, you might be better off working with an MS-DOS environment,
    because you can pretty much move MS-DOS out of your way and
    guarantee response based on the bare hardware.

    And for real time (embedded) apps you'll find me changing my tune
    entirely about debuggers because this is usually the only
    visibility you have into what the software is doing. So much so
    that we build our lab tests for embedded boxes around a home grown
    debugger.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Languages don't kill people. *Programmers* do!"
        --  Rich Stewart - Language Lawyer & Language Control Opponent.
=============================================================================