brianm@ecst.csuchico.edu (Brian Meyerpeter) (02/26/91)
I am currently doing some research on debugging systems for object oriented environments. I have just finished looking at the Eiffel docs and what they call a debugger. I called ISE and asked, "Does Eiffel have a debugger?" They said of course. After my studies and $200 for the docs I would beg to differ. They have a class viewer that really doesn't do much. I would like to hear someone's experience with view in Eiffel. Do you really use it? Would you have liked something better? The only information I have with objective c is on the next. It uses an enhanced version of gnu's gdb. I like gdb but it isn't designed for oo programing. Have they done better since? Which is better?? Any responses will be appreciated. Thank you Brian Meyerpeter OPTX P.O. Box 6661 Chico, CA 95927
aHumanBeing@earth.planet.universe (02/26/91)
In article <1991Feb26.050535.11346@ecst.csuchico.edu> brianm@ecst.csuchico.edu (Brian Meyerpeter) writes: Would you have liked something better? of course. I like gdb but it isn't designed for oo programing. Have they done better since? no. Which is better?? boring.
richieb@bony1.bony.com (Richard Bielak) (02/26/91)
In article <1991Feb26.045704.11186@ecst.csuchico.edu> brianm@ecst.csuchico.edu (Brian Meyerpeter) writes: > > >I am currently doing some research on debugging systems for object oriented >environments. I have just finished looking at the Eiffel docs and what they >call a debugger. I called ISE and asked, "Does Eiffel have a debugger?" >They said of course. After my studies and $200 for the docs I would beg to >differ. They have a class viewer that really doesn't do much. > >I would like to hear someone's experience with view in Eiffel. Do you >really use it? Would you have liked something better? I have used the class viewer to debug Eiffel programs. I think it is better than it sounds from the description in the manual. Its major shortcoming is that you cannot set break points in your code (well, you can sort of insert breakpoints by placing "View(Current)" calls in you code, but that requires recompiling). However, the Viewer makes testing of single classes *very* easy. With the viewer you can execute each routine within a class "by hand" and examine the results. This is made especially easy by the Eiffel tester ("et") which will generate a dummy root class, compile it, run it and put in the viewer. This way you can make sure that one class works properly, before it is added to a larger program. This is not that easy to do in other languages. You can not only test your programs, but also find out how library classes behave. For example, I wanted to find out how the FILE class can be used to read directories. I did this without writing a single line of code with the command "et file". I never used "gdbg", but I use VAX/VMS debugger extensively. The VMS debugger is very good. The only debugger that I think is better, is the Benchmark Modula-2 debugger on the Amiga. Let me know if you have further questions. ...richie P.S. Here is a wild suggestion for a future debugger. It would be nice if the debugger kept track of which routines were tested. This way you could get a report or a warning at system build time that would list the code that was never executed. -- +----------------------------------------------------------------------------+ | Richie Bielak (212)-815-3072 | "The sights one sees at times makes one | | Internet: richieb@bony.com | wonder if God ever really meant for | | Bang: uunet!bony1!richieb | man to fly." -- Charles Lindbergh |
giacomet@haley.ecn.purdue.edu (Frederic Giacometti) (02/26/91)
In article <1991Feb26.045704.11186@ecst.csuchico.edu> brianm@ecst.csuchico.edu (Brian Meyerpeter) writes: > > >I am currently doing some research on debugging systems for object oriented >environments. I have just finished looking at the Eiffel docs and what they >call a debugger. I called ISE and asked, "Does Eiffel have a debugger?" >They said of course. After my studies and $200 for the docs I would beg to >differ. They have a class viewer that really doesn't do much. > >I would like to hear someone's experience with view in Eiffel. Do you >really use it? Would you have liked something better? > > >The only information I have with objective c is on the next. It uses >an enhanced version of gnu's gdb. I like gdb but it isn't designed for >oo programing. Have they done better since? > >Which is better?? I've worked and debugged programs both in Objective-C (on NeXT) and Eiffel on Sun-Sparc. I'd say that most of the traditionally painful bugs occuring in objective-C (programmer's distraction, type mismatch, screwed-up indices etc...) are pointed out by the Eiffel system at compilation time (thourough compilation analysis) or run-time (assertion control). I haven't really used the viewer which, I believe, is in a primitive stage; all my debuging is done with assertion monitoring. Sometimes, I've used the trace capability but that's it. I'd believe the assertion by Eiffel's authors that traditional debuggers are somehow obsolete in Eiffel to be relevant, if not true. I must also say that, unlike my experience with Objective-C or C, the debugging stage with Eiffel has been much limited. -- giacomet@ecn.purdue.edu
cox@stpstn.UUCP (Brad Cox) (03/03/91)
In article <1991Feb26.155726.9531@noose.ecn.purdue.edu> giacomet@haley.ecn.purdue.edu (Frederic Giacometti) writes: >all my debuging is done with assertion monitoring. Sometimes, I've >used the trace capability but that's it. I'd believe the assertion >by Eiffel's authors that traditional debuggers are somehow obsolete >in Eiffel to be relevant, if not true. I must also say that, unlike >my experience with Objective-C or C, the debugging stage with Eiffel >has been much limited. Why not use C or Objective-C's assertion monitoring? Simply #include "assert.h" and have at it. { assert(precondition); ...body... assert(postcondition); } Class invarients are, IMO, best expressed in a separate file, distinct from the class under test. I call these separate files "gauges" by analogy with inspection gauges of tangible domains like manufacturing. For more on this, see "Planning the Software Industrial Revolution"; IEEE Software; November 1990. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
tynor@hydra.gatech.edu (Steve Tynor) (03/04/91)
In article <6501@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: | In article <1991Feb26.155726.9531@noose.ecn.purdue.edu> giacomet@haley.ecn.purdue.edu (Frederic Giacometti) writes: | >all my debuging is done with assertion monitoring. Sometimes, I've | >used the trace capability but that's it. I'd believe the assertion | >by Eiffel's authors that traditional debuggers are somehow obsolete | >in Eiffel to be relevant, if not true. I must also say that, unlike | >my experience with Objective-C or C, the debugging stage with Eiffel | >has been much limited. | | Why not use C or Objective-C's assertion monitoring? Simply | #include "assert.h" and have at it. | { | assert(precondition); | ...body... | assert(postcondition); | } | Class invarients are, IMO, best expressed in a separate file, distinct | from the class under test. I call these separate files "gauges" by | analogy with inspection gauges of tangible domains like manufacturing. I disagree - class invariants are an integral specification of the class's behavior - they ought to be in the same place as the class specification (the class source file in Eiffel, the class header file in C++, I'll have to plead ignorance about ObjC). As much as I like <assert.h> in C and it's derivatives, it's not as good as the Eiffel assertion mechanism. The pre- and post-conditions of a routine and the class invariant are visible for all to see - not buried in the implementation. Of course, it's possible to have inline assertions (equivalent to the assert() macro) in Eiffel too (the `check' instruction). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Eiffel: Accept no substitutes Steve Tynor Georgia Tech Research Institute tynor@prism.gatech.edu