bob@imsvax.UUCP (Bob Burch) (10/12/87)
Again from Ted Holden concerning TCDebug: It turns out that the version of TCDebug I posted does contain a request that it not be posted to BBSs other than Compuserve; sorry about that. I would have honored the request had I read it, the truth is that I don't use debuggers and had noticed a great deal of traffic on Usenet concerning TC and the possibilities of debugers for it and sought to do a public service, ,, several of my coworkers having pulled TCDebug off of Compuserve. Since such happenings seem to me to be unavoidable, I would have to suggest that anyone concerned that much with where a piece of free-ware/share-ware goes simply should not post it anywhere until it is ready. I mean, trying to specify where share-ware goes is like trying to harness the wind. To my knowledge, TCDebug is now on several BBSs, two of which were mentioned in another recent posting to Usenet. Of the several items I personally have donated to the air-waves as share-ware, most notably VMUSIC, the only request I have ever made of users is that they not be sold as opposed to passed around. I would like to make another suggestion to anyone else interested in writing the world's ultimate debugger, which obviously includes both MicroSoft and Borland: take a hard, hard look at the debugging feature of UNIVACs (or UNI-SYSs) 10Rxx mainframe fortran compiler. I have been completely underwhelmed with ALL of the mini/micro debugging aids I have seen so far for what I regard as a compelling reason. They all seem to be based on the idea of single-stepping; in real life, most of the really bad things I've ever seen happen to computer programs seem to happen in the middle of some 200 line loop on about the 500'th pass through that loop. Who in hell wants to single step their way through that? The Univac mainframe debugging aids basically generate a running tally of subroutine calls, points passed through, value changes of specified variables etc. and that tally is there for the programmer to examine after the program goes bad. He can thereby get a hell of a good idea of what all happened leading up to the end. Granted, it helps not to have the machine crash when the program abends as is almost always the case with PCs, which also precludes the possibility of closing such a tally file. Problems of a less serious nature, I've always figured I could faster with printfs and a fast compiler than with any of the micro debugging aids I've seen so far. Ted Holden HT Enterprises . :1