d88-jwa@nada.kth.se (Jon W{tte) (03/23/90)
I've had this very long wish list for a while, and now I've completely mislaid it, so I'll just ramble on :-) 1. Compiler errors are accumulated in a separate window and may be stepped through _after_ compilation. (Like emacs, or even Turbo C on the (yukk) PC) 2. Some support for several different project/description files, and maybe cross-dependancy as well. 3. Some means of reading/saving the project layout into a text file (maybe read in a make(1) file and convert to a projcet ? 8-) 4. Grep in files with name matching <pattern> (not necessary in the project) 5. A class browser. 6. A means of setting various #define's globally. 7. Some way to set breakpoints in a source file other than the current, without using Debugger() (Or have I overlooked something ?) I'm sure I've wished for several other features during the last six months or so, but these seven things should be enough to make me pay the upgrade fee... (I do mac programming professionally, but still haven't the bucks for apple DTS, especially since it isn't quite the same here in Sweden... :-( ) h+
ech@cbnewsk.ATT.COM (ned.horvath) (03/24/90)
From article <3192@draken.nada.kth.se>, by d88-jwa@nada.kth.se (Jon W{tte):
>
> I've had this very long wish list for a while, and now I've
> completely mislaid it, so I'll just ramble on :-)
>
> 1. Compiler errors are accumulated in a separate window and may be
> stepped through _after_ compilation. (Like emacs, or even Turbo
> C on the (yukk) PC)
'Twould be nice. Especially as this would allow Warning diagnostics
in addition to the one-class of errors at present. But probably requires
Kahl and co. to rearchitect the compiler, so I guess I could live without
it.
> 2. Some support for several different project/description files,
> and maybe cross-dependancy as well.
I don't know what this means. You can include one project into another
now, and the dependencies get noted on make/use-disk; and you can Merge
the builds into a single result file. Make it ain't, but I've also
got Tempo...
> 3. Some means of reading/saving the project layout into a text
> file (maybe read in a make(1) file and convert to a projcet ? 8-)
I can't get excited about this one. When I begin a port, I have to
pound the "Add..." dialog a bunch. So what?
> 4. Grep in files with name matching <pattern> (not necessary in the
> project)
Same comment: yawn.
> 5. A class browser.
AHA! Now THIS one I NEED. I know Rich can't comment, but...PLEASE DO THIS!
> 6. A means of setting various #define's globally.
I'd like this one too. But then, most of my projects already have
a catch-all header for inclusion in every file, so...
> 7. Some way to set breakpoints in a source file other than the
> current, without using Debugger() (Or have I overlooked something ?)
I don't understand this one. I have Debugger() and DebugStr, and once a
debugging session is started, I can open any source file in TC4, and use
cmd-G to get it into the edit window of the debugger to set a breakpoint.
It MIGHT be nice to have a list of preset breakpoints, but given the speed
of the compiler, that's effectively what Debugger() provides.
To the above, let me add one more: permit me to do builds in background.
The compiler may be fast, but there are still times when I change one
thing in one header, and I don't really want to watch 50K lines compiled.
=Ned Horvath=d88-jwa@nada.kth.se (Jon Watte) (03/24/90)
In article <2274@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes: >From article <3192@draken.nada.kth.se>, by d88-jwa@nada.kth.se (Jon W{tte): >> 1. Compiler errors are accumulated in a separate window and may be >in addition to the one-class of errors at present. But probably requires >Kahl and co. to rearchitect the compiler, so I guess I could live without It would be _more_ than nice. Ever run gcc and gdb under gnu emacs ? Not that I'm a gnu fan, but they sure make some neat things... >> 2. Some support for several different project/description files, >> and maybe cross-dependancy as well. >I don't know what this means. You can include one project into another Yes, but to close one project and open another and switch back & forth isn't my view of user-friendliness (For example; NetHack has two support applications that needs to be run when you touch certain files) >> 3. Some means of reading/saving the project layout into a text >> file (maybe read in a make(1) file and convert to a projcet ? 8-) >I can't get excited about this one. When I begin a port, I have to >pound the "Add..." dialog a bunch. So what? Well. In the case of NetHack (again :-) it would save us the trouble of distributing a hqx-ed project file... Okay, it would be neat, but not essential. >> 4. Grep in files with name matching <pattern> (not necessary in the >> project) >Same comment: yawn. So do you have a grep that can scan through all files in a directiry ? I'd be very interested in it, in that case. (I _often_ use egrep "<some-expression>" f*.c or similar on unix boxes) >> 6. A means of setting various #define's globally. >I'd like this one too. But then, most of my projects already have >a catch-all header for inclusion in every file, so... A hitch: pre-compiled headers mustn't rely on these #defines... >> 7. Some way to set breakpoints in a source file other than the >> current, without using Debugger() (Or have I overlooked something ?) >I don't understand this one. I have Debugger() and DebugStr, and once a Well, maybe I want conditional breakpoints. I was mailed how to do this, I just hadn't seen it in the manual (Top of page 141) But then, I always "Set Aside" everything but the debugger and the project... >To the above, let me add one more: permit me to do builds in background. Yes ! Yes ! Yes ! Now, this is something I've wanted for years ! (Maybe as a check box under compilator flags, to avoid as much overhead as possible ?) Wishing for a white Christmas, h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
CXT105@psuvm.psu.edu (Christopher Tate) (03/25/90)
While we're coming up with a wish list, how about....
1) A way to toggle 6888x code generation within the source. It would make
it so easy to write programs that could be run with any coprocessor
configuration if you could do something like:
if (foundCoprocessor) {
#define _6888x_
/* use the coprocessor for this code */
#undef _6888x_
}
else {
/* do the same thing using SANE */
}
2) A way to search-and-replace in multiple files at once that are *not*
in the current project. I don't know how many times I've wanted to
do this....
3) A mechanism that would allow me to keep code in one library at a
time. It seems ludicrous to store the code for the ANSI library
in every project that I'm currently working on -- the disk space
really adds up, especially on floppies. Why can't the project just
contain the information about where to find the code, instead of
having to copy it into itself?
4) (This one is a pet peeve, since I got burned by it recently) The rules
that THINK C uses for finding the resource file associated with a
project are different from the rules it uses to find source files.
For example, you can put your source files into a folder called
(project_name), and the compiler will find them, but it will not find
the project_name.rsrc file if it's in that same folder. I'd like to
see C use the same rules for finding .rsrc files as it uses for finding
source code.
Rich, I hope you can pass some of these along. I realize that 1) is an
extension to C, and therefore suspect, but it'd make things awfully nice.
Another possibility would be for the compiler to generate code to detect the
coprocessor automatically at runtime, and then use the appropriate libraries.
Admittedly, it makes your code quite a bit bigger, but those of us who can't
handle 68881 programming might find it quite convenient....
-------
Christopher Tate | "Mr. Churchill, you're drunk!"
|
cxt105@psuvm.psu.edu | "Yes madam, and you are ugly. In the
{...}!psuvax1!psuvm.bitnet!cxt105 | morning, however, I shall be sober."
cxt105@psuvm.bitnet |rob@cs.mu.oz.au (Robert Wallen) (03/26/90)
In article <90083.132800CXT105@psuvm.psu.edu> cxt105@psuvm.psu.edu writes: >While we're coming up with a wish list, how about.... I suppose if you dont ask, you dont get so ... How about a #define that I can detect to determine the current project type. That way, my CDEF (etc) sources can contain code like pascal long #ifdef _APPLICATION_ /* change name to cdefmain to allow testbed */ cdefmain(...... #endif #ifdef _CODESEGMENT_ main(..... #endif and my (mostly) general purpose textedit routines can determine whether they are in _APPLICATION_ or _DESKACC_ (so I can refresh clikloop & workbreak routines only when they need it..., etc) And how about different names for the default pre-compiled MacHeaders files. That way, I can have the OOPS stuff precompiled for applications and desk accs and not worry for CDEFs or INITs. Maybe make it selectable from the 'Set Project Type' window. (Yeh, I know I can just turn it off in the options window and manually #include it. This is a wish list, isnt it)
nilesinc@well.sf.ca.us (Avi Rappoport) (03/28/90)
What I really need is a way to keep my breakpoints and variables between runs of the program. So annoying to have to keep resetting them. Also, standard command keys (I changed them with ResEdit, but hate to do that everytime I have a new version). Remembering window size and location: I have a portrait monitor, so I can't see all my code in the debug window, but the data window is often too big. If only I could reset the size, and have it stick... -- -- Help me justify my online bills: ask me EndNote questions, please! -- Avi Rappoport 2000 Hearst, Berkeley, CA 94709 nilesinc@well.sf.ca.us, 415-655-6666 Niles.Assoc on AppleLink fax: 415-649-8179
jonathan@itsgw.rpi.edu (Jonathan Fisher) (03/30/90)
In article <16903@well.sf.ca.us> nilesinc@well.UUCP (Avi Rappoport) writes: >What I really need is a way to keep my breakpoints and variables between >runs of the program. So annoying to have to keep resetting them. > Yes. That and a moveable or resizeable console window!! I use Think C for my Systems Programming Class, and we have to use a unix system. So I use Think C with the console window and the special command line (gasp) arguments function. But when using the debugger, I can't move the console window out of the way so that I could see the debugger windows. Every time that the program starts to run the console window comes to the front and hides the debugger windows. I am using a SE and no other screen. This renders auto-trace totally useless. If there is a way around this, someone please let me know! -- Jonathan Fisher jonathan@pawl.rpi.edu ITS Student Consultant or Rensselaer Polytechnic Institute userganu@rpitsmts.bitnet GO VIKINGS! Central Division Champs => NFC Champs => Superbowl XXV Champs
mjf@well.sf.ca.us (Marty Fried) (04/11/90)
In article <16903@well.sf.ca.us> nilesinc@well.UUCP (Avi Rappoport) writes: >What I really need is a way to keep my breakpoints and variables between >runs of the program. So annoying to have to keep resetting them. I too was frustrated with that aspect of the debugger. I have just discovered that you can use the "skip to here" function to re-run from any point, even from the beginning. If you select the first statement, then select skip to here, the program will start at that point. I haven't had a chance to fully test this out, but it seems to work. I have also used the console routines to resize and even rename to console window. (using stdin and stdout as the FILE *). I had to edit console.c to make it work, though. Hope these discoveries will help other programmers using ThinkC. Marty Fried * SlideTek, Inc. * Sausalito, California
denbeste@bgsuvax.UUCP (William C. DenBesten) (04/12/90)
In article <16903@well.sf.ca.us> nilesinc@well.UUCP (Avi Rappoport) writes: > What I really need is a way to keep my breakpoints and variables between > runs of the program. So annoying to have to keep resetting them. From article <17184@well.sf.ca.us>, by mjf@well.sf.ca.us (Marty Fried): > I too was frustrated with that aspect of the debugger. I have just discovered > that you can use the "skip to here" function to re-run from any point, even > from the beginning. Skip to here is neat, but keep in mind as you use it that the value of variables is NOT changed back to what it was at that point in the execution. For example, if you are stopped at c: and skip to a:, the value printed the second time is 9, not 7. x=7; a: printf("x is %d\n",a); x=9; c: It is not reasonable to expect the debugger to change the value of variables back since that would require keeping enormous amounts of state information. This does, however, mean that you can get really wierd results. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet
oster@well.sf.ca.us (David Phillip Oster) (04/13/90)
In article <17184@well.sf.ca.us> mjf@well.UUCP (Marty Fried) writes: _>In article <16903@well.sf.ca.us> nilesinc@well.UUCP (Avi Rappoport) writes: _>>What I really need is a way to keep my breakpoints and variables between _>>runs of the program. So annoying to have to keep resetting them. _>I have just discovered _>that you can use the "skip to here" function to re-run from any point, even _>from the beginning. If you select the first statement, then select skip to _>here, the program will start at that point. _>I have also used the console routines to resize and even rename to console _>window. (using stdin and stdout as the FILE *). I had to edit console.c to _>make it work, though. Unfortunately, if you write real Mac applications, which you apparently do not since you care about console i/o, you'll find that starting from the first statement is not the same as the initial start up in critical ways: 1.) You will be calling the ToolBox initialization routines in an environment where thay have already been called. 2.) any memory allocation routines you call will allocate new storage without ever freeing the old stuff from the previous run. (GetMenu, for example.) It is a nifty hack when it works, but don't expect it to work too well. -- -- David Phillip Oster - Note new address. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster
tim@hoptoad.uucp (Tim Maroney) (04/13/90)
In article <16903@well.sf.ca.us> nilesinc@well.UUCP (Avi Rappoport) writes: >>What I really need is a way to keep my breakpoints and variables between >>runs of the program. So annoying to have to keep resetting them. I've often thought this myself. Oh, Riiiich..... In article <17184@well.sf.ca.us> mjf@well.UUCP (Marty Fried) writes: >I too was frustrated with that aspect of the debugger. I have just discovered >that you can use the "skip to here" function to re-run from any point, even >from the beginning. If you select the first statement, then select skip to >here, the program will start at that point. I haven't had a chance to fully >test this out, but it seems to work. Except that your global data will not get reinitialized, so it's not the same as re-running the program. It could very well give misleading results; in fact, it's almost sure to, if you use any globals and count on C to initialize them to zero or to what your source code's initializers specify. I would recommend not using this strategy except possibly very early in the running of your program, or if you are using very little global data and not couting on its initialization. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Do what you wanna, do what you will; Just don't mess up your neighbor's thrill. And when you pay the bill, kindly leave a little tip To help the next poor sucker on his one-way trip." - Frank Zappa, "You Are What You Is"