todd@stiatl.UUCP (Todd Merriman) (05/31/90)
In article <1990May30.190325.17541@athena.mit.edu> seaotter@athena.mit.edu (Mike) writes: > I am looking for advice/tips/suggestions for porting some fairly >simple c programs from UNIX (4.3 BSD) to VMS. Some use curses, some don't. Rule No. 1: don't bother trying to get VMS Curses to work like Berkely Curses. I just ain't going to happen. ...!emory!SalesTech.com!todd ...!emory!stiatl!todd Todd Merriman * 404-841-4000 * Atlanta, GA
phd_ivo@gsbacd.uchicago.edu (06/01/90)
>Rule No. 1: don't bother trying to get VMS Curses to work like Berkely >Curses. I just ain't going to happen. Rule No. 2: never trust the library routines. Rule No. 3: in particular, never trust the stdio libraries. The weird character I/O schemes on VMS wreak all kind of havoc. (Also, I found a bug in qsort() once!) Hint No. 1: the debugger---although generally quite nice---can't restart a program :-( /ivo welch ivo@next.agsm.ucla.edu
mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) (06/01/90)
In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes: >Hint No. 1: the debugger---although generally quite nice---can't restart >a program :-( Hmm, I can't figure out what you're trying to say with this. If you mean VMS doesn't dump a core, you need to use the command "Set Process/Dump". In order to debug that dump file, you need to use "Analyze/Proc/Full file". Of course, to get any real debugging pleasure, you have to compile and link for debugging, but it works just fine otherwise. >/ivo welch ivo@next.agsm.ucla.edu Darrin mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu
wallyk@tekfdi.FDI.TEK.COM (Wally Kramer) (06/01/90)
In article <46365@iuvax.cs.indiana.edu> mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) writes: > In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes: > >Hint No. 1: the debugger---although generally quite nice---can't restart > >a program :-( > > Hmm, I can't figure out what you're trying to say with this. ... I think what "phd_ivo" means is you can't re-run the program as though it just started from within the debugger. This is nice to do if you accidently step past the procedure that commits the dastardly deed you're looking for. It implies the debugger can reset the program being debugged to its initial state, including all (program) files closed, variables back to their initial value, etc. Of course, you could always exit the debugger and restart, but then you'd lose your nice window layout, patches, modes, definitions, breakpoints, watchpoints, etc., etc. Debugger maniacs: go get a copy of Turbo C++ Professional. I don't know if it's generally available, but I got advance notice (as a Turbo C Professional owner). The debugger is claimed to support "backwards single stepping" where it reverses the effects of the step!! I don't have any details as yet, but this is another solution for starting over. Turbo Debugger, naturally, has always had program restart (Ctrl-F2). (IMHO, Turbo C plus a PC [cost: $150 + $800+] is such a productive development environment that any medium to large VMS development is best started there. Disclaimer: I'm just a very satisfied customer.) wallyk@tekfdi.fdi.tek.com (Wally Kramer) 503 627 2363 Contractor from Step Technology, Inc. 503 244 1239
kassover@jupiter.crd.ge.com (David Kassover) (06/01/90)
In article <46365@iuvax.cs.indiana.edu> mdchaney@bronze.ucs.indiana.edu (M Darrin Chaney) writes: >In article <9528@tank.uchicago.edu> phd_ivo@gsbacd.uchicago.edu writes: >>Hint No. 1: the debugger---although generally quite nice---can't restart >>a program :-( > >Hmm, I can't figure out what you're trying to say with this. If you mean >VMS doesn't dump a core, you need to use the command "Set Process/Dump". >In order to debug that dump file, you need to use "Analyze/Proc/Full file". >Of course, to get any real debugging pleasure, you have to compile and >link for debugging, but it works just fine otherwise. Some debuggers I have seen, and I am not experienced with them, and no they weren't for VMS, or Unix, either, have the ability to restart the program from the beginning. I'm sure there's a reason the VMS Debugger does not have this feature (a minor inconvenience), good bad indifferent or ugly. If anyone reading this *knows* the reason, I'm sure we'd all like to hear about it. As long as we are pounding on the debugger, does anyone know, perhaps, if in a future version the user will be able to control the symbol table load algorithm? On my "favorite" image to debug, it takes about 10-20 minutes from my entering run/debug until I see the DBG> prompt. DEC's current answer, via my sysop, is "Add more memory/raise the working set". I'm surprised they didn't suggest a 9000 8-) -- David Kassover "Proper technique helps protect you against kassover@ra.crd.ge.com sharp weapons and dull judges." kassover@crd.ge.com F. Collins