niko@du248-16.cc.iastate.edu (Schuessler Nikolaus E) (09/22/90)
In article <4480@sage.cc.purdue.edu> ar4@sage.cc.purdue.edu (Piper Keairnes) writes: >In <110701@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: > >>Has anyone been able to succesfully run/use the Think C (4.02) Debugger >>on system 7.0a9? > >Come to think of it, has anyone been able to get the debugger to work on the >Mac IIcx? I work with ThinkC 4.0 at home on an SE and took it in to work one >day to try it out on a IIcx. When the debugger option is set (as normal), >the program executes without the debugger and runs normally, just without >the debugger... Hey, mine works fine on my IIcx... Do you have >= 2M on the IIcx. I upgraded recently to 4.02 and system 6.05 and it still seems to work the same... -- ------------------------------------------------------------------------------ Niko Schuessler "On a two semester mission to engineer where niko@iastate.edu no-one has engineered before.... :-) " ------------------------------------------------------------------------------
phils@chaos.cs.brandeis.edu (Phil Shapiro) (09/24/90)
In article <1990Sep22.150113.22935@news.iastate.edu> niko@du248-16.cc.iastate.edu (Schuessler Nikolaus E) writes: . In article <4480@sage.cc.purdue.edu> ar4@sage.cc.purdue.edu (Piper Keairnes) writes: . >In <110701@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: . > . >>Has anyone been able to succesfully run/use the Think C (4.02) Debugger . >>on system 7.0a9? . > . >Come to think of it, has anyone been able to get the debugger to work on the . >Mac IIcx? I work with ThinkC 4.0 at home on an SE and took it in to work one . >day to try it out on a IIcx. When the debugger option is set (as normal), . >the program executes without the debugger and runs normally, just without . >the debugger... . . Hey, mine works fine on my IIcx... Do you have >= 2M on the IIcx. I . upgraded recently to 4.02 and system 6.05 and it still seems to work . the same... If the debugger doesn't come up at all, check the following: 1) Are you running MultiFinder? 2) Is the debugger in the same folder as ThC? 3) Is there enough extra memory for the debugger (~ 200K default)? It's amazing the number of people who forget to turn on MultiFinder. -phil shapiro, symantec tech support -- Phil Shapiro phils@chaos.cs.brandeis.edu
gft_robert@gsbacd.uchicago.edu (11/14/90)
-------- Speaking of the THINK C debugger: It's a pretty nice graphical source-level debugger. BUT it seems really kludgy in many ways, at least compared to the THINK Pascal debugger. My main beef is having to type in the variables I wish to examine. I HATE this, particularly since these variable names aren't kept around between runnings of the program in development. This considerably lengthens the edit-run-debug-edit cycle. (Or does someone know a way to keep them around?). Much better is THINK Pascal's method of having all variables immediately available for examination, and having variables for different procs in different places in the debugger window. In THINK C I tend to end up with 5 windows each named "*theTable" (for example), each tracking a variable thru the call chain. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/14/90)
In article <1990Nov13.223209.16268@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes:
Speaking of the THINK C debugger:
It's a pretty nice graphical source-level debugger. BUT it seems
really kludgy in many ways, at least compared to the THINK Pascal
debugger.
My main beef is having to type in the variables I wish to examine.
I HATE this, particularly since these variable names aren't kept
around between runnings of the program in development. This
considerably lengthens the edit-run-debug-edit cycle. (Or does
someone know a way to keep them around?).
If you select an expression in the data window (any expression that
doesn't have a function call), you can copy it to the data window by
using Command-D.
Much better is THINK Pascal's method of having all variables
immediately available for examination, and having variables for
different procs in different places in the debugger window. In
THINK C I tend to end up with 5 windows each named "*theTable" (for
example), each tracking a variable thru the call chain.
I typically make a lot of use of the "clear" key to remove windows (or
data window entries). Also, if you want to reevalute an expression in
a different context, you can use the "Set Context" menu item.
I happen to prefer the Think C debugger for a number of reasons (I
hate scrolling through tons of local or global variables, I often want
to have many structures expanded, etc.) I suppose in a perfect
environment we could pick and choose the particular interface pieces
we like best.
-phil
--
Phil Shapiro Technical Support Analyst
Language Products Group Symantec Corporation
Internet: phils@chaos.cs.brandeis.edurg2c+@andrew.cmu.edu (Robert Nelson Gasch) (11/15/90)
This is probably incredibly stupid, but I havn't been able to figure it out yet and it's really annoying: I'm using Think C 3.0 and have 7 files with (my) code in the project. When I choose 'use debugger', I can only use it on 3 of the files, the other four are not marked by the little 'diamond'. The manual doesn't really say anything about this and I havn't been able to figure it out. How do I get the other files to be recognized by the debugger? Any suggestions would be greatly welcome --> Rob
Jim.Matthews@dartmouth.edu (Jim Matthews) (11/15/90)
In article <1990Nov13.223209.16268@midway.uchicago.edu>, gft_robert@gsbacd.uchicago.edu writes: > > Speaking of the THINK C debugger: > > It's a pretty nice graphical source-level debugger. BUT it seems really > kludgy in many ways, at least compared to the THINK Pascal debugger. Just to be contrary, (and in case Symantec is listening), I'll offer the opposite opinion :-). I think the THINK C debugger is one of the best parts of THINK C, while LightsBug is one reason I use MPW for my Pascal work. Part of that has to do with the kludgy way TP runs programs in its own heap, but I also find the TC debugging interface to be more productive. > My main beef is having to type in the variables I wish to examine.... .. > Much better is THINK Pascal's method of having all variables immediately > available for examination.... I don't usually type my variables into the THINK C debugger -- it's easier to select them and type Cmd-D. Think Pascal shows all variables automatically, but that hides the few I care about among the many I don't. The numerous icons and subpanes in the LightsBug window are an additional distraction. It would be nice if the THINK C debugger could save and restore the state of the Data windows, but it works well enough that I usually don't have to walk through the code more than once or twice. My biggest gripe is that it doesn't save the Source and Data window positions, so I always have to rearrange them to get a good view of my source. Jim Matthews Dartmouth Software Development --
francis@daisy.uchicago.edu (Francis Stracke) (11/15/90)
In article <PHILS.90Nov14100504@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >In article <1990Nov13.223209.16268@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >If you select an expression in the data window (any expression that >doesn't have a function call), you can copy it to the data window by >using Command-D. Excuse me? Why copy it to the same window? Maybe I'm missing something--I haven't used this--but something seems a little off. (No offense, you understand. I expect you just misspoke, so to speak, so to speak...) [previous being a recursive joke; don't follow it through to the end, you'll get bored fast. :-) ] | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Non sequiturs make me eat lampshades | | francis@zaphod.uchicago.edu | |
mdtaylor@Apple.COM (Mark Taylor) (11/15/90)
In article <1990Nov14.220406.17241@midway.uchicago.edu> francis@daisy.uchicago.edu (Francis Stracke) writes: >In article <PHILS.90Nov14100504@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >>In article <1990Nov13.223209.16268@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >>If you select an expression in the data window (any expression that >>doesn't have a function call), you can copy it to the data window by >>using Command-D. > >Excuse me? Why copy it to the same window? Highlight the text of your expression in the source code window, then hit Command-d. The expression and its value will pop up in the Data window. Very helpful feature. What bugs me (so to speak) is that I always seem to need it displayed as a C string, rather than as a pointer. So I have to go over and click on the expression, then choose "C String" from the Data menu. Gets to be a pain after doing it a few hundred times. What would be great is if the debugger had a preferences section which would allow you to set an option to automatically have your variables displayed as both an address and a string. I don't care if I get garbage for non-strings. Short of that, the Data menu should affect the highlighted expression in the Data window even if the Data window isn't active. That way I could use Command-d to put the expression in the Data window, then go immediately to the Data menu and select the format without having to first click in the Data window. And command-key equivalents for the Data menu would also be great! - Mark
gft_robert@gsbacd.uchicago.edu (11/16/90)
----- Thanks to all who pointed out that command-D will copy the data to the data window. OK, here's my other main beef: since the THINK C debugger is a separate program, why must it exit -- thus losing all your breakpoints, variable windows you've set up, etc -- every time you stop running the program you're debugging? OK, I'm sure that there is a valid reason for this, so let me turn the question around: why isn't there a way to save project specific things such as breakpoints, variables you want shown, etc. from debug session to debug session? I'm sure this would be tricky since the source is going to change, but there must be some better way than setting everything up from scratch again. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/16/90)
In article <1990Nov14.220406.17241@midway.uchicago.edu> francis@daisy.uchicago.edu (Francis Stracke) writes: In article <PHILS.90Nov14100504@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >In article <1990Nov13.223209.16268@midway.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >If you select an expression in the data window (any expression that ^^^^^^^^^^^ >doesn't have a function call), you can copy it to the data window by >using Command-D. Excuse me? Why copy it to the same window? source window, sorry. -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu
vd09+@andrew.cmu.edu (Vincent M. Del Vecchio) (11/17/90)
> Excerpts from netnews.comp.sys.mac.programmer: 15-Nov-90 Re: THINK C > Debugger (was R.. gft_robert@gsbacd.uchica (1092) > OK, here's my other main beef: since the THINK C debugger is a separate > program, why must it exit -- thus losing all your breakpoints, variable > windows you've set up, etc -- every time you stop running the program > you're debugging? OK, I'm sure that there is a valid reason for this, so let me turn the > question around: why isn't there a way to save project specific things > such as breakpoints, variables you want shown, etc. from debug session > to debug session? I'm sure this would be tricky since the source is > going to change, but there must be some better way than setting > everything up from scratch again. Personally, I would be happy if you could just save the set of variable windows. As you noted, the source can change quite a bit. Maybe they could add something to the _editor_ to handle breakpoints, kind of like the way it's done in Think Pascal. Vince Del Vecchio vd09@andrew.cmu.edu
seibel@bbn.com (Fred Seibel) (01/01/91)
When using the Debugger, I am frustrated by not being able to see the values of expressions typed into the data window. The documentation says that values are calculated and displayed for expressions in the current context when the debugger stops. This seems to be true, however, new expressions that could be evaluated in the context are not displayed unless I press Step or Trace in the debugger window. The examples given in the tutorials imply that the values will be displayed. Is there some parameter that I am missing. I have set update windows under Options. Thanks Fred seibel@bbn.com
resnick@cogsci.uiuc.edu (Pete Resnick) (01/01/91)
seibel@bbn.com (Fred Seibel) writes: >When using the Debugger, I am frustrated by not being able to see the >values of expressions typed into the data window. After typing the name of the expression, hit return, not just the check box. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD