chase@boulder.Colorado.EDU (A. Chase Turner) (09/28/90)
I am listing my experience in programming environments -- in descending order of preference: ParcPlace's ObjectWorks -- both Smalltalk and C++ Symbolic's Genera programming environment LightSpeed C on the Mac Sun's dbxtool (for C and C++) I rate NeXT's gdb and Edit at the very bottom. Don't get me wrong: I WANT to develop code on the NeXT platform but I am finding myself completely dismayed at the disjoint cycle of development I must waddle through: - Write and modify code with Edit. - Compile till gnu pukes. - Correct syntax by walking through line numbers returned by the compilier; associate line number with code using Edit's Select Line option. - Syntax is okay but application is not behaving correctly -- need to step through the code using gdb -- gave up because it is too primative of a user interface - Finally laced my code with printfs and successfully debugged my application code.... At this moment, I am looking at Communications of The ACM -- September 1990, page 92 -- an article written by Gibbs, Tsichritzis, and Casais -- and realizing that I am hitting the wall they describe in the article: I am having trouble finding classes, relationships between them, and not being able to easily modify code on the NeXT platform. The following are some brief examples of troubles I have had.... - mistyped a name in the .h and forgot to update the .m (or vice versa) - added a method in my .m and forgot to include it in my .h (or vice versa) - mistyped the file name - used lower case for a .h or .m file -- ie) myObject.m instead of MyObject.m - don't know were to find the appropiate include file for some class - using the UNIX approach, debugging is a seperate task from code writing. Intead of interactive debugging environments where one can insert breakpoints, observe stack and object values, etc, i must use two terminal windows, Edit, and printfs. I am blowing off some steam -- code I am trying to write today (in 6 hours time) took less than 1 hour in Smalltalk. My experience today is another process of "enrichment" where I learn that I should avoid the frustration that builds within me when I find myself trying to work with primative tools for developing application code.... But why must it be that way, NeXT? Why is it that I can buy a $500 Lightspeed C compilier for the Macintosh which runs circles around your development environment?! I *KNOW* the emphasis of your platform is on the AppKit -- but why let the basic programming tools (such as "direct manipulation" interface linking all the programming steps -- browsing, modification, testing and running code) fall out of step with the other parts of your development environment? In 2.0, simply linking Edit with gdb so that when code pukes, gdb will associate a line number in the Edit window with the error isn't good enough--I want gdb to show me *exactly* where the parse error occurred. Or, that I can click in an Edit window to set a breakpoint -- or view the variables in the current context of a step operation... I hope that when 2.0 is finally ready for shipment, you will suprise me with an Objective-C structured code browser that allows me to edit class definitions, automatically generate .h and .m files, and integrates with the gdb so that I can step through code, etc....
jacob@gore.com (Jacob Gore) (09/28/90)
/ comp.sys.next / chase@boulder.Colorado.EDU (A. Chase Turner) / Sep 27, 1990 / > I am finding myself completely dismayed at the disjoint cycle of > development I must waddle through: > - Write and modify code with Edit. > - Compile till gnu pukes. > - Correct syntax by walking through line numbers returned by > the compilier; associate line number with code using > Edit's Select Line option. > - Syntax is okay but application is not behaving correctly -- > need to step through the code using gdb -- gave up > because it is too primative of a user interface > - Finally laced my code with printfs and successfully debugged > my application code.... Yuck! You're using the wrong tools. Use Emacs. Write (or modify) your code, compile it (M-x compile), step through syntax errors (C-x `); debug it with gdb mode (M-x gdb), which shows the source you're stepping through in a window to the actual source, opening files as needed (can even do some editing right on the spot!). Sure, a class browser would be nice. But you're making your life much harder than it has to be. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
scott@NIC.GAC.EDU (09/28/90)
chase@boulder.Colorado.EDU (A. Chase Turner) writes:
I rate NeXT's gdb and Edit at the very bottom.
[Lot's of complaints about NeXT development deleted ]
I agree 100%. I doubt it will be in 2.0 - everytime I've asked about it
(going on about a year, now), whoever I asked sort of says that they
feel that's not their job.
Bull. They got us a compiler, a debugger, an editer. Get us a _real_
debugger. gdb running under X is not what I want, either. Something
very professional would be nice. I used to like Logitech's M2 run-time
debugger, and I've heard they've done much better with their latest
(can't remember the name - I've been fully weaned of PCs, thankfully).
OK, now to do something about it. I want a debugger. You want a
debugger. There's one in the third-party catalog, but who knows how
good (or bad) that is? What we need is a cheap debugger.
Who'd be interested in one? ShareWare? How deep is your interest
(as in "how deeply can you reach for a good debugger")? A _good_
debugger would be hard, probably much harder than a wimpy terminal
emulator, though I guess speed wouldn't be nearly the constraint
that Stuart's speed was. I'm _almost_ willing, but don't need to
throw 400 hours after nothing . . . . though I _do_ need a debugger.
scott hess
scott@gac.edu
Independant NeXT Developer (Stuart and new Terminal)
NeXT Campus Consultant (Not much, really)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)asd@mace.cc.purdue.edu (Kareth) (09/28/90)
In <9009271958.AA00928@next-3.gac.edu> scott@NIC.GAC.EDU writes: >chase@boulder.Colorado.EDU (A. Chase Turner) writes: > I rate NeXT's gdb and Edit at the very bottom. >[Lot's of complaints about NeXT development deleted ] >Who'd be interested in one? ShareWare? How deep is your interest ME! >(as in "how deeply can you reach for a good debugger")? A _good_ Right now, pretty shallow, but once I have my machine and start programming... >debugger would be hard, probably much harder than a wimpy terminal >emulator, though I guess speed wouldn't be nearly the constraint >that Stuart's speed was. I'm _almost_ willing, but don't need to >throw 400 hours after nothing . . . . though I _do_ need a debugger. What would be nice is to have SaberC. Any of you seen that? It runs on Sun's and X platforms, and is REALLY slick in my opinion. There is even an editor so that you can write your own code and compile it all from within the program. It will show graphically linked lists (whatever kind), and it will update it on the fly. I couldn't begin to describe a decent portion of all it's features. It's loaded. Now I would LOVE to see that. I know people who swear by it, allowing them to debug VERY quickly, and it finds bugs that cc, lint, gcc, gdb, whatever don't! It's a marvelous package from everything I've heard. -k
jfrancis@umaxc.weeg.uiowa.edu (Jeff Francis,Home Number,,3540765) (09/28/90)
From article <9009271958.AA00928@next-3.gac.edu>, by scott@NIC.GAC.EDU: > Who'd be interested in one? ShareWare? How deep is your interest > (as in "how deeply can you reach for a good debugger")? A _good_ > debugger would be hard, probably much harder than a wimpy terminal > emulator, though I guess speed wouldn't be nearly the constraint > that Stuart's speed was. I'm _almost_ willing, but don't need to > throw 400 hours after nothing . . . . though I _do_ need a debugger. Why don't you just write a graphical front-end to gdb using pseudo-terminals? -jpf ------------------------------------- Jeff Francis CS Student, University of Iowa jfrancis@umaxc.weeg.uiowa.edu -------------------------------------
scott@NIC.GAC.EDU (09/28/90)
Why don't you just write a graphical front-end to gdb using pseudo-terminals? Breakpoints which watch the values of a variable and break at a certain value. Dynamic update of various graphical views of variables. Ability to have a decent front end without having to parse half of the world. Views of source, data, etc. Easy browsing of objects and structures with pointers to structures. what else? Give me some time . . . Actually, that parsing part's the hard part, IMHO. Doing it yourself would be faster, cleaner, and probably simpler in the end. Also, it'd be easier to get a simple prototype running, I think. scott hess scott@gac.edu Independant NeXT Developer (Stuart) NeXT Campus Consultant (Not much, really) GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
gumby@Cygnus.COM (David Vinayak Wallace) (09/28/90)
gdb 4.0 has all of that, except it doesn't run in the NeXT environment. The version which DOES run on the NeXT forked off quite a while ago, but porting it would still be less work than writing one from scratch! It doesn't have all the interpreting stuff like saber, unfortunately. The Unix/Mach world still has a long, long way to go to catch up with the lisp machine and the Dorado.
dd26+@andrew.cmu.edu (Douglas F. DeJulio) (09/28/90)
chase@boulder.Colorado.EDU (A. Chase Turner) writes: > I am listing my experience in programming environments -- in > descending order of preference: > > ParcPlace's ObjectWorks -- both Smalltalk and C++ > Symbolic's Genera programming environment > LightSpeed C on the Mac > Sun's dbxtool (for C and C++) > > I rate NeXT's gdb and Edit at the very bottom. You are making a mistake. You should use gnu-emacs, and use gdb-mode. You're not using the software that's available to you. With the emacs/gdb combination, you can have a source file in one windown and the debugger in another, and as you step through the program with the debugger, a little arrow shows you where you are in the source. You can go to the source and hit a key, and the debugger will set a breakpoint there. There are lots of nifty features you could and should be using. From within gnu-emacs you can compile. Then, when the compiler shows errors, you can hit the "show me the next error" key combination and the apropriate source file will be opened, and the cursor will be placed on the offending line. Use the tools you've already got! -- Doug DeJulio dd26@andrew.cmu.edu
gerrit@nova.cc.purdue.edu (Gerrit Huizenga) (09/28/90)
A lot of people have expressed the need for a good development environment on the NeXT. Is Saber-C good enough for you? If so, let you local NeXT Reps know and make sure they carry back that knowledge to NeXT, Inc. I believe that NeXT agrees that Saber-C would be good for their machine and would like to see Saber do a port, hopefully a very complete port. It's up to you to make sure that if the port were to be done, there would be enough people to buy it to keep the price from going through the roof. If NeXT can convince Saber C that there are not only enough people to pay for the cost of the port, but also enough that the price can be reasonable (i.e. tagged onto something like a campus license for a "small" fee) then we all win. gerrit
scott@nic.gac.edu (09/28/90)
dd26+@andrew.cmu.edu (Douglas F. DeJulio) writes: chase@boulder.Colorado.EDU (A. Chase Turner) writes: > I am listing my experience in programming environments -- in > descending order of preference: > > ParcPlace's ObjectWorks -- both Smalltalk and C++ > Symbolic's Genera programming environment > LightSpeed C on the Mac > Sun's dbxtool (for C and C++) > > I rate NeXT's gdb and Edit at the very bottom. You are making a mistake. You should use gnu-emacs, and use gdb-mode. Yes, emacs does alot. Yes, emacs and gdb get along. No, I do not want to use emacs and gdb to debug. Yes, I use emacs. Yes, I tried it. No, I did not like it. End of discussion? Even if many people _can_ use emacs/gdb to debug, NeXT is _still_ sorely lacking a graphical debugger. emacs is a big job - you cannot just jump into emacs and debug without prior experience. In fact, I maintain that if you really want to use emacs at all, you pretty much have to use it constantly, and invest a great deal of time in this (I had to). You might say that that would be good. I think the NeXT should have tools to debug the interface written using the interface. Otherwise, why not just let Stuart replace Workspace and be done with it? scott hess scott@gac.edu Independant NeXT Developer (Stuart) NeXT Campus Consultant (Not much, really) GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
jmunkki@hila.hut.fi (Juri Munkki) (09/29/90)
In article <8b0fl7i00VI8F4JDp4@andrew.cmu.edu> dd26+@andrew.cmu.edu (Douglas F. DeJulio) writes: >You are making a mistake. You should use gnu-emacs, and use gdb-mode. >You're not using the software that's available to you. With the >emacs/gdb combination, you can have a source file in one windown and >the debugger in another, and as you step through the program with the >debugger, a little arrow shows you where you are in the source. You >can go to the source and hit a key, and the debugger will set a >breakpoint there. There are lots of nifty features you could and >should be using. If user interfaces are so easy to create with the NeXT, why hasn't anyone created a gdb-mode for edit or as a standalone application? ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scott@sage.uchicago.edu (Scott Deerwester) (09/29/90)
In article <27092@boulder.Colorado.EDU>, chase@boulder (A. Chase Turner) writes: >I am listing my experience in programming environments -- in >descending order of preference: > > ParcPlace's ObjectWorks -- both Smalltalk and C++ > Symbolic's Genera programming environment > LightSpeed C on the Mac > Sun's dbxtool (for C and C++) > >I rate NeXT's gdb and Edit at the very bottom. > >Don't get me wrong: I WANT to develop code on the NeXT platform >but I am finding myself completely dismayed at the disjoint cycle of >development I must waddle through: > > - Write and modify code with Edit. > - Compile till gnu pukes. > - Correct syntax by walking through line numbers returned by > the compilier; associate line number with code using > Edit's Select Line option. > - Syntax is okay but application is not behaving correctly -- > need to step through the code using gdb -- gave up > because it is too primative of a user interface > - Finally laced my code with printfs and successfully debugged > my application code.... > I find myself in a very different cycle. I just got done spending two weeks writing a NeXT application that includes: - An Interface Builder built front end with a custom view in it - A couple of my own classes, one of which is the custom view - Some pswrapped PostScript, with a few associated Objective C functions The application evolved over the two weeks from something that does little more than stick the custom view on the screen in a window so I could debug the PostScript to a relatively sophisticated application that reads data from files, etc. My cycle is something like this: - Once: - Muck with Interface Builder to define classes, outlets, actions, connections, look and feel, yada yada.. - Unparse the classes I've defined. - Save from IB - Loop: - From IB: - Parse files to define new outlets/actions. - Connect things - From Emacs: - Edit the Objective C and/or pswrap source files - M-x compile - ^X-`, ^X-n to step through and fix my syntax errors - M-x gdb - Use ^X-SPC to set breakpoints, and run the thing Works very well. I was able to build an app that I like a lot in two weeks that would have taken me months in any other platform I've programmed in. Granted, I didn't use Edit -- don't much like it -- and I interfaced to gdb from gnumacs, but hey, that was supposed to be the idea, wasn't it? Add that to my favorite C mode in gnumacs, and I even limit the number of syntax errors I get, since the editor checks my braces for me. I was also able to read your article, compose my response to it, and verify that all of the stuff I just said actually works, all from gnumacs... ------- Scott Deerwester | Internet: scott@tira.uchicago.edu | ~{P;N,5B~} Center for Information and | Phone: 312-702-6948 | Language Studies | 1100 E. 57th, CILS | University of Chicago | Chicago, IL 60637 |
jmunkki@hila.hut.fi (Juri Munkki) (09/30/90)
In article <1990Sep28.213826.4709@midway.uchicago.edu> scott@sage.uchicago.edu (Scott Deerwester) writes: >Granted, I didn't use Edit -- don't much like it -- >and I interfaced to gdb from gnumacs, but hey, that was supposed to be >the idea, wasn't it? Add that to my favorite C mode in gnumacs, and I >even limit the number of syntax errors I get, since the editor checks >my braces for me. > >I was also able to read your article, compose my response to it, and >verify that all of the stuff I just said actually works, all from >gnumacs... This decides it for me. I no longer want to develop software for the NeXT. I know this is a religious issue, but I absolutely refuse to use Emacs. It doesn't work the way I do and I don't think I'm going to change the way I work or take the time to reprogram Emacs to do what I want. As long as Emacs is considered the only realistic programming tool and interface, I will not get myself a NeXT. If Symantec ever releases a Think C compiler for the NeXT, I will reconsider the point, since I like the NeXT hardware and most of the ideas in the user interface and system software. Flame me, if you really feel you have to, but remember that this is just my personal opinion and not something that you should feel as well. ____________________________________________________________________________ / Juri Munkki / Helsinki University of Technology / Wind / Project / / jmunkki@hut.fi / Computing Center Macintosh Support / Surf / STORM / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
glenn@heaven.woodside.ca.us (Glenn Reid) (10/01/90)
In article <1990Sep29.170939.14728@santra.uucp> jmunkki@hila.hut.fi (Juri Munkki) writes: >This decides it for me. I no longer want to develop software for the NeXT. >I know this is a religious issue, but I absolutely refuse to use Emacs. >It doesn't work the way I do and I don't think I'm going to change the >way I work or take the time to reprogram Emacs to do what I want. Obviously you've never actually done any development on a NeXT. Regardless of whether you use Emacs or not, you can get work done in half or one third the time it takes you on any other platform (in my experience). You don't have to use Emacs. Sure, the debugging cycle could use some improvement, but even doing it "the hard way" with gdb and Edit, it is much better than most environments. And never underestimate the value of Digital Librarian. Just wait for the first time you look up something in the Librarian and it opens up the documentation right to a page with some example code on it, you copy the code out of the documentation, paste it into your source code, tweak a few of the names, compile, and it works the first time. You shouldn't decide you "no longer want to develop software for the NeXT" on the basis of a few postings to the net. There are a few ups and downs, but unless not changing the way you work is more important to you than writing excellent applications, you should give it a try. Just my opinions, naturally. Your mileage may vary. Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
paul@surf.sics.bu.oz (Paul Davis) (10/02/90)
In article <1990Sep29.170939.14728@santra.uucp>, jmunkki@hila.hut.fi (Juri Munkki) writes: > In article <1990Sep28.213826.4709@midway.uchicago.edu> scott@sage.uchicago.edu (Scott Deerwester) writes: > >Granted, I didn't use Edit -- don't much like it -- > >and I interfaced to gdb from gnumacs, but hey, that was supposed to be > >the idea, wasn't it? That wasn't my idea. I never imagined that a machine as advanced as the NeXT, one that emphasized the interface, would have a programming environ as antiquated as Emacs. I had assumed that when I left the mainframe world in 1979 I had kissed emacs goodbye forever. > This decides it for me. I no longer want to develop software for the NeXT. > I know this is a religious issue, but I absolutely refuse to use Emacs. > It doesn't work the way I do and I don't think I'm going to change the > way I work or take the time to reprogram Emacs to do what I want. > > As long as Emacs is considered the only realistic programming tool and > interface, I will not get myself a NeXT. If Symantec ever releases a > Think C compiler for the NeXT, I will reconsider the point, since I > like the NeXT hardware and most of the ideas in the user interface and > system software. I feel the same disappointment in the compiler/debugger/editor link. I have been using THINK C 4 and THINK Pascal 3 on the Mac; and I would like an editor that has scroll bars, mouse selections AND a compiler interface AND a debugger interface. I am not willing to trade the first two for the last; and so will survive with Edit I suppose. Too bad. On the other hand, I am CRAZY about the Interface Builder and also like the ability to execute code from GDB, something THINK would not do. What about an object browser? Have I missed something or is that missing too? paul ------------------------------- cut here ----------------------------------- Paul Davis Internet/AUSNET: paul@terrapin.bus.bu.oz.au School of Business Mail to: P.O. Box 65 Bond University Bond University phone: (075) 952 291 fax: 953 3220 QLD 4229 Australia Let my inspiration flow, in token rhyme suggesting rhythm... Terrapin (work)Station... *** Founder, President and co-member of the Australian NeXT User's Group ***
dd26+@andrew.cmu.edu (Douglas F. DeJulio) (10/02/90)
paul@surf.sics.bu.oz (Paul Davis) writes: > I would like an editor that has scroll bars, mouse selections AND a > compiler interface AND a debugger interface. I am not willing to > trade the first two for the last; and so will survive with Edit I > suppose. Too bad. I wonder if either Emacs version 19 or John Myers' "front end" for Emacs on the NeXT would make this person happy.
brown@apollo.uhura.cc.rochester.edu (Eric Brown) (10/04/90)
Please don't write the NeXT off. I've written a lot of code with THINK C and agree it's a great environment, but the NeXT is very similar. The InterfaceBuilder has a project type window which when you click on a file automatically opens it in the Edit application. Edit is very close to THINKs editor. 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. The real problem with developing on the NeXT is there's nothing like 'Macintosh Revealed' that I've found yet. You must kind of jump in head first, but it's kind of fun. Best of Luck, Eric. NeXT Campus Consultant, University of Rochester -- _____________________________________________________________________________ | Remember when sex was safe and hang gliding was dangerous? | |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| | Eric Brown 940 Mt. Hope Ave | Rochester, NY 14620 | | ARPAnet,Internet: brown@ee.rochester.edu | Phone : (716) 271-7167 | | UUCP: {allegra,seismo}!rochester!ur-valhalla!brown | | +===============================================+=============================+
olson@sax.cs.uiuc.edu (Bob Olson) (10/05/90)
In article <BROWN.90Oct3213936@apollo.uhura.cc.rochester.edu> 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