Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!olson From: olson@sax.cs.uiuc.edu (Bob Olson) Newsgroups: comp.sys.next Subject: Re: A plea for a Structured Objective-C code browser in 2.0 Message-ID: Date: 4 Oct 90 19:01:30 GMT References: <27092@boulder.Colorado.EDU> <1990Sep28.213826.4709@midway.uchicago.edu> <1990Sep29.170939.14728@santra.uucp> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Urbana-Champaign Lines: 22 In-Reply-To: brown@apollo.uhura.cc.rochester.edu's message of 4 Oct 90 01:39:36 GMT In article brown@apollo.uhura.cc.rochester.edu (Eric Brown) writes: > For now, you must just think of the NeXT development environment > as THINKs before they came out with the debugger. I'm sure > that a good debugger will be out soon enough. In fact, if you are > willing to run X, you can use xgdb which is graphically oriented. NeXT *does* have a good debugger ... gdb. It knows about threads, tasks, objective-c, c++ (in 2.0). Also in 2.0 you can tell gdb to display the source files in Edit, and will highlight the current line of the code as you single-step. Edit is also getting to be a nice environment (I usually use Emacs, but tried Edit today). It knows about ctags, so it's easy to bop about in the source files. You can run unix commands inside of Edit, and there is a command to open the selection that can take a selection of "Filename:34" and open up Filename to line 34 --- this means you can select the line an error occurred on in a make, do a command-O and be at the line of the error. I haven't figured out if it's possible to set gdb breakpoints from Edit yet, tho. --bob