mcdonald@fornax.UUCP (Ken Mcdonald) (03/04/90)
A little while ago, I sent out a message concerning problems I was having
with THINK C 4.0--it wouldn't print properly, and it caused system
crashes after quitting the program. This is the followup to that, along
with some suggestions--and kudos!
I messed around with THINK C for quite a while, trying to get the printing
to work. No go, it kept on spewing out gibberish. Finally, I replaced
all my system files. Now THINK C wouldn't print at all. In desperation,
I tried to print from FullWrite, which graciously informed me that it
couldn't print until I chose a printer. When it did print, it also
spewed gibberish. The problem--a loose printer cable!
Moral--just because two problems occur together, don't assume they have
the same cause. Because THINK C was causing my system to crash, I assumed
it was the reason for my printer spewing gibberish, when the real reason
was because I had moved the printer.
Suggestion--THINK C really oughta warn people if they haven't chosen a
printer. As it is, it just doesn't do anything, and I spent a good half-
hour trying to get it to work before I clued into the problem.
The second problem, that of the system crashing after I exit from THINK C
(even when I haven't run any of my own code) still remains, although it
seems to have been reduced after I turfed a bunch of INITs. I haven't been
able to track down the exact problem, and don't really have the time to
put a lot of effort into it.
On the plus side, the last few days mark the first time I've had to
really use THINK C. The debugger is wonderful! Congrats all 'round,
Rich, to you and the people involved in this language. One suggestion
here--I find myself running debugging sessions which are very similar
to one another, in that I want to look at the same variables, set the
same breakpoints, etc. It would be nice if there were a way for the
debugger to remember these settings. It would be even nicer if, right
in the source code, a programmer could specify where breakpoints should
be set, which expressions should appear in the data window, etc.
Hope the above has been of some use. To someone. Somewhere.
Ken McDonald
{mcdonald@cs.sfu.ca}wilkins@jarthur.Claremont.EDU (Mark Wilkins) (03/04/90)
In article <390@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: >I find myself running debugging sessions which are very similar >to one another, in that I want to look at the same variables, set the >same breakpoints, etc. It would be nice if there were a way for the >debugger to remember these settings. It would be even nicer if, right >in the source code, a programmer could specify where breakpoints should >be set, which expressions should appear in the data window, etc. YES, yes yes yes YES yes yes YES !!!!!! There is nothing more frustrating than debugging a TCL program, and being able to visualize EXACTLY where in the code you want to go WITH NO MEANS TO GET THERE! Even if there were an "Open file..." option somewhere in the debugger so that a given source file could be opened that would be a BIG improvement!! -- Mark Wilkins wilkins@jarthur.claremont.edu
dks@shumv1.uucp (D. K. Smith) (03/05/90)
In article <390@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: [deleted bunch of stuff about THINK C 4.0... sounds like Init'itis too me :-) ] >It would be even nicer if, right >in the source code, a programmer could specify where breakpoints should >be set, which expressions should appear in the data window, etc. Place the statement "Debugger();" '...right in your source code...' I think this traps to the same address as the _Debugger in assembly code. dk smith ------------------------------------------------------------------------ dks@shumv1.ncsu.edu | ude.uscn.1vmuhs@skd -my opinions reflect my opinions. | .snoinipo ym tcelfer snoinipo ym- ------------------------------------------------------------------------
philip@Kermit.Stanford.EDU (Philip Machanick) (03/05/90)
In article <390@fornax.UUCP>, mcdonald@fornax.UUCP (Ken Mcdonald) writes: > A little while ago, I sent out a message concerning problems I was having > with THINK C 4.0--it wouldn't print properly, and it caused system > crashes after quitting the program. This is the followup to that, along > with some suggestions--and kudos! > [lots deleted] > > same breakpoints, etc. It would be nice if there were a way for the > debugger to remember these settings. It would be even nicer if, right > in the source code, a programmer could specify where breakpoints should > be set, which expressions should appear in the data window, etc. > > Hope the above has been of some use. To someone. Somewhere. > > Ken McDonald > {mcdonald@cs.sfu.ca} THINK Pascal allows you to save settings. Breakpoints can be saved with the source, if you save as THINK Pascal, instead of plain text. The Instant and Observe windows can be individually saved; in fact, you can save more than one of each for a given project, which means you can keep a bunch of different debugging contexts, and open them as needed. Why doesn't the same manufacturer do all this for its C environment? Is this a case of a left and right hand that don't talk to each other? I can see the attraction of specializing an environment to a language (not to mention keeping the impementation teams small and manageable), but wouldn't it be great if THINK C and Pascal were available out of one environment? Philip Machanick philip@pescadero.stanford.edu
siegel@endor.harvard.edu (Rich Siegel) (03/05/90)
In article <4805@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > > There is nothing more frustrating than debugging a TCL program, and being >able to visualize EXACTLY where in the code you want to go WITH NO MEANS TO >GET THERE! Even if there were an "Open file..." option somewhere in the >debugger so that a given source file could be opened that would be a BIG >improvement!! If the debugger is running, you can open a file in the environment, and choose "Debug" from the Source menu; this will open the file in the debugger. The file will be scrolled to the selection range in the requested file. User's manual, Chapter 11, page 141 ("Viewing other files in the source window."); version 4.0. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~
siegel@endor.harvard.edu (Rich Siegel) (03/05/90)
In article <1990Mar4.194322.27068@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >contexts, and open them as needed. Why doesn't the same manufacturer do >all this >for its C environment? Is this a case of a left and right hand that >don't talk to >each other? I can see the attraction of specializing an environment to a >language >(not to mention keeping the impementation teams small and manageable), but >wouldn't it be great if THINK C and Pascal were available out of one >environment? THINK C and THINK Pascal originated as two different environments; THINK Pascal's roots date back to 1982, and THINK C came along later. The architectures are fundamentally different, and the designers are fundamentally different people, which is why the two products look different and act different. As time goes on, the two will probably grow together, resulting in a synthesis, the whole of which is greater than the sum of the parts. How's that for lots of SAT words? :-) R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~