eby@pegasus.ATT.COM (Robert P. Eby) (07/26/90)
A favorite hobby of people here in comp.sys.mac.programmer seems to be making suggestions for improvements to THINK C. Here are two things I would like to see: 1) When doing text selection in the editor, TC should use the user's selected highlight color on a color monitor (rather than white on black, yecch!) This shouldn't be that hard to do; just a matter of adding HiliteMode &= ~(1 << hiliteBit); in a few places. 2) There ought to be a "Cancel" or "Stop Compiling" button on the compilation dialog. Many's the time that I've hit propeller-R and THEN remembered that I needed to update the .rsrc file (for example). I can't imagine that this should be hard either (it could finish compiling the "current file" before it stopped). So whaddaya say? In 4.0.3 maybe? Of course, 2.1 level C++ would be nice also, but I can wait a little longer for that. Robert P. Eby UUCP: att!pegasus!eby AT&T Bell Laboratories Domain: eby@pegasus.ATT.COM
weyand@csli.Stanford.EDU (Chris Weyand) (07/29/90)
In <4930@pegasus.ATT.COM> eby@pegasus.ATT.COM (Robert P. Eby) writes: >A favorite hobby of people here in comp.sys.mac.programmer seems to be >making suggestions for improvements to THINK C. Here are two things I would >like to see: >1) When doing text selection in the editor, TC should use the user's >selected highlight color on a color monitor (rather than white on black, That would be nice! >2) There ought to be a "Cancel" or "Stop Compiling" button on the >compilation dialog. Many's the time that I've hit propeller-R and THEN >remembered that I needed to update the .rsrc file (for example). I can't >imagine that this should be hard either (it could finish compiling the >"current file" before it stopped). Try command-period. It works very well. Chris Weyand weyand@csli.Stanford.edu
d88-jwa@nada.kth.se (Jon W{tte) (07/29/90)
In article <4930@pegasus.ATT.COM>, eby@pegasus.ATT.COM (Robert P. Eby) writes: |> 1) When doing text selection in the editor, TC should use the user's |> selected highlight color on a color monitor (rather than white on black, Yes, I have also wanted this... |> 2) There ought to be a "Cancel" or "Stop Compiling" button on the |> compilation dialog. Many's the time that I've hit propeller-R and THEN Cmd-dot works fine for me. What's your problem ? Now, MARKS in the editor, and option-doubleclick that found the RIGHT definition of a function, and the use of scrolling keys, and saving all compilation errors in a window instead of stopping at the first would be a good start for 5.0... Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
mkelly@cs.uoregon.edu (Michael A. Kelly) (07/30/90)
|> 1) When doing text selection in the editor, TC should use the user's |> selected highlight color on a color monitor (rather than white on black, Try the 'ThC, Hilite!' init, found (I believe) in the sumex archives. (If not there, probably America Online.) It provides a temporary (we hope!) solution. Mike. -- Michael A. Kelly mkelly@cs.uoregon.edu
mdavis@pro-sol.cts.com (Morgan Davis) (07/31/90)
In-Reply-To: message from eby@pegasus.ATT.COM
> 2) There ought to be a "Cancel" button on the compilation dialog.
Just press Command-Period to cancel a compilation.
UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol
ARPA: crash!pnet01!pro-sol!mdavis@nosc.mil MCI Mail: 137-6036
INET: mdavis@pro-sol.cts.com America Online, BIX: mdavislippin@ragu.berkeley.edu (The Apathist) (08/01/90)
Recently mdavis@pro-sol.cts.com (Morgan Davis) wrote: >In-Reply-To: message from eby@pegasus.ATT.COM >> 2) There ought to be a "Cancel" button on the compilation dialog. >Just press Command-Period to cancel a compilation. Some of us would *still* like a button, however. (While you're at it, how about making it a movable modal so we can switch out and do something else?) --Tom Lippincott lippin@math.berkeley.edu "Hell is like a supermarket in other ways, too -- there's an express lane for ten sins or less, and they won't let you take the carts out to the parking lot." --Mister Boffo
purcell@sciences.tmc.edu (Guy B. Purcell) (08/02/90)
In article <1990Jul31.224245.24110@agate.berkeley.edu> lippin@math.berkeley.edu writes: >Recently mdavis@pro-sol.cts.com (Morgan Davis) wrote: >>In-Reply-To: message from eby@pegasus.ATT.COM >>> 2) There ought to be a "Cancel" button on the compilation dialog. >>Just press Command-Period to cancel a compilation. > >Some of us would *still* like a button, however. > >(While you're at it, how about making it a movable modal so we can >switch out and do something else?) > > --Tom Lippincott > lippin@math.berkeley.edu > If this were done, compiling would be *much* slower. Maybe later when multitasking is handled better this will be worth it, but not currently. I mean can you imagine putting in 'wait' statement in a compiler just to allow other tasks some CPU time? The OS should handle allocating CPU resources, not the various applications. Apple is working toward this -- we just have to be patient. Guy (purcell@zeus.sdsu.edu)
omh@cs.brown.edu (Owen M. Hartnett) (08/02/90)
This is really a suggestion for Think Pascal, but it probably applies to Think C as well: Have an option so that files will be saved *before* compilation starts. Many times the compiler has crashed during compilation (undoubtedly due to some gaffe of mine the previous compilation), but the changes don't get saved until *after* the compilation finishes. This doesn't happen often, but when it does, it's aggravating. -Owen Owen Hartnett omh@cs.brown.edu.CSNET Brown University Computer Science omh@cs.brown.edu uunet!brunix!omh "Don't wait up for me tonight because I won't be home for a month."
minich@d.cs.okstate.edu (Robert Minich) (08/02/90)
lippin@math.berkeley.edu writes: |#> 2) There ought to be a "Cancel" button on the compilation dialog. |#Just press Command-Period to cancel a compilation. | |Some of us would *still* like a button, however. | |(While you're at it, how about making it a movable modal so we can |switch out and do something else?) by purcell@sciences.tmc.edu (Guy B. Purcell): | If this were done, compiling would be *much* slower. Maybe later when | multitasking is handled better this will be worth it, but not currently. | I mean can you imagine putting in 'wait' statement in a compiler just | to allow other tasks some CPU time? The OS should handle allocating | CPU resources, not the various applications. Apple is working toward | this -- we just have to be patient. I agree an OS should deal with CPU scheduling, but I don't think that it would be prohibitively difficult to support background compilation. Judging how often to yield CPU time might entail a little bit of work, but it seems obvious to me that they are already checking for events, since they catch cmd-'.' to interrupt compiling. I s'pose the main difficulty would be ensuring the foreground process regular CPU bursts. However, I think it would be relatively simple to add some code around the are that provides status updates ("xxx lines") that looks at the current number of ticks and calls WNE() after a reasonable amount have gone by. There are two reasons I see to provide this feature: (1) you can read the netnews while you compile :-), and (2) you can start fixing the errors that are showing up in the "compile errors" window. :-> -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| There are no heroes -- |=(___)= | minich@a.cs.okstate.edu | We all wear gray hats. | U | - Ackphtth |
jackiw@cs.swarthmore.edu (Nick Jackiw) (08/02/90)
minich@d.cs.okstate.edu (Robert Minich) writes: > I agree an OS should deal with CPU scheduling, but I don't think that > it would be prohibitively difficult to support background compilation. > Judging how often to yield CPU time might entail a little bit of work, > but it seems obvious to me that they are already checking for events, > since they catch cmd-'.' to interrupt compiling. > I s'pose the main difficulty would be ensuring the foreground process > regular CPU bursts. However, I think it would be relatively simple to > add some code around the are that provides status updates ("xxx lines") > that looks at the current number of ticks and calls WNE() after a > reasonable amount have gone by. My project (THINK Pascal 3.0, but the argument's equivalent) takes a good 10 minutes to compile on an SE/30, locking up my machine entirely. Thus I frequently have time to ruminate about these issues. In that apple's not going to come up with user-based OS task scheduling soon, I frequently dream about my more sophisticated and time-consuming utilities (e. g. my compilers) allowing me at least to schedule their individual behavior. Some sort of meter in the Compile Options dialog could represent a percent of CPU time I desire to allocate to the compilation. It would default to 100--never switch out, never call WNE. (This is what it does now, I assume--it checks for cmd-. by consulting the keymap, not the event queue.) However, if I set it to 75%, I would expect my compile to take 13 minutes, but I'd have enough spare cycles to watch me tap the space bar in netnews. Alternately, I could allot it only 20%, have it take an hour, and work on my documentation with a fairly-good response time in the word processor. This sort of self-scheduling can never be better than approximative, in that you can't force tasks to return to you at a given time, but 5 minutes worth of scattered timeouts is still far more desirable than the 10 minute total lockup now confronting me every time I change a trans-project header. -- ------------------------ Nick Jackiw jackiw@cs.swarthmore.edu "We are what we think, Visual Geometry Project jackiw@swarthmr.bitnet having become what we
pete@titan.rice.edu (Pete Keleher) (08/02/90)
jackiw@cs.swarthmore.edu (Nick Jackiw) writes: > going to come up with user-based OS task scheduling soon, I frequently > dream about my more sophisticated and time-consuming utilities (e. g. my > compilers) allowing me at least to schedule their individual behavior. > Some sort of meter in the Compile Options dialog could represent a percent > of CPU time I desire to allocate to the compilation. It would default to > 100--never switch out, never call WNE. (This is what it does now, I > assume--it checks for cmd-. by consulting the keymap, not the event queue.) Although I haven't actually checked w/ MacNosy, I would guess that it does use the event queue, not the keymap. Command equivalents that are typed during compilation are lost, although as soon as linking starts, keyboard events can be entered which take you though the debugger and quite far into the application that you are working on. Many of the comments in this thread have dealt with how the compiler can decide that it has had enough cpu so that it can let the foreground processcrank for a bit time. In reality, the problem is that there are many applications out there that still don't use WaitNextEvent, which would prevent the compiler (the background applicataion) from getting any time at all. -- ============================================================================= Pete Keleher pete@titan.rice.edu The Alpha Editor is available from 'rascal.ics.utexas.edu' (128.83.144.1). =============================================================================
gft_robert@gsbacd.uchicago.edu (08/02/90)
----- In article <PETE.90Aug2104554@titan.rice.edu>, pete@titan.rice.edu (Pete Keleher) writes... [...] >Many of the comments in this thread have dealt with how the compiler can >decide that it has had enough cpu so that it can let the foreground >processcrank for a bit time. In reality, the problem is that there are many >applications out there that still don't use WaitNextEvent, which would >prevent the compiler (the background applicataion) from getting any time at >all. I'm not too sure about this. I wrote an app a couple of weeks ago which didn't use WaitNextEvent (I know, shame, shame). I can get VersaTerm to download files and stuff even when my GetNextEvent-app is in the foreground. Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================