singer@endor.UUCP (01/01/70)
In article <6523@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes: >A couple of things I'd like to see in LightSpeed C (which I greatly enjoy): > >Macros can be tricky. It would sure be nice to have the compiler optionally >generate a file containing the output of the macro pre-processor. This >would help me catch lots of otherwise very obscure bugs. The problem here is that there's no preprocessor per se; macro handling is part of the compiler itself. >I get rather annoyed with C at times because it lets me do dumb things >without complaining. Prototypes help, but I think it would be nice to >have a Lint option that would check your project for dumb mistakes (and >machine-dependency, though Mac programmers don't usually worry about that >too much -- what machine are they going to port their programs to?). It >seems that with LSC's projects, a nice implementation of this could be done. >It wouldn't need to be fast, either, since it would probably only be used >after major revisions or when bug-exterminating. The trouble with Lint is that it's not a small project, and we don't have the resources to devote to a Lint at this time. Note that Lint doesn't require a project file to work; it'll work on any .c file. >Other ANSI extensions would be nice, such as allowing function definitions >to have the same format as prototypes (for easier copy/pasteing) and >string/name concatenation at compile time. I would guess, though, that >THINK plans on supporting ANSI in full if and when it is finalized. We're looking at these items, and some of them will be present in the next major release of LightspeedC. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). Richard M. Siegel Customer Support Representative THINK Technologies, Inc. Uucp: {decvax, ucbvax, sun}!harvard!endor!singer Internet/Arpanet: singer@harvard.harvard.edu No one writes programs that work right the first time. If they did, I'd be out of a job.
alen@cogen.UUCP (Alen Shapiro) (01/01/70)
The few things I'd like to see in LSC (given that a source code debugger will one day be forthcomming from Think) have to do more with the interface. I find it annoying that after a R(un command (and subsequent exit from my application) my carefully set up edit windows and cursor locations within them are lost (on return to LSC). Since I do multi-machine C development and transfer text files around the place, I would like a way to specify the default font that a TEXT file is opened in (I cram code and like a small 9point font). I have many C modules, each of which I have to EDIT/SET-FONT every time I move my files back to the mac. All in all I am very pleased with the LSC environment. It makes working in C on the mac a pleasure, almost as nice as one of the environment on one of the two other machines on which I must maintain the code. Of these other two machines and o/s's I give you the task of guessing which is the hardest to target for :- Sun/3 running UNIX PC-AT running DOS-3 (hint...cringe here) --alen the Lisa slayer (it's a long story) ...seismo!esosun!cogen!alen
eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (01/01/70)
In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes: >>I'd like to be able to put my header files on a small ramdisk, as reading >>them in seems to be the most time-consuming part of my compiles > >Why bother? Just crank up the RAM Cache on the control panel and you get >better than the same effect: the include files that are getting used a lot >right now, stay in the cache, and you don't have to worry about explicitly >moving files around. This certainly does give a nice speed increase, especially if you have 2 Meg or more to run around in. But I am hesitant to use RAM cache when I am debugging tricky code that is crashing a lot; I worry about losing source changes that have not been written from the cache out to disk. I asked one of the folks at Think whether LSC was smart enough to flush the cache before a project is started up from the "Run" command. He claimed that this was not the case, and that there was no way that LSC could tell whether the cache was enabled. He said that he did not trust the RAM cache well enough to use it for his own development work. Now I am wondering: would it be possible to have an item in the "Options" dialog so that the user could inform LSC that a cache was in use - and that a flush should be done before running a project? Or maybe a future version of LSC will be smart enough to implement its own caching mechanism, or other memory management schemes that take greater advantage of large memory environments. ("criminies," they must be saying at Think, "ain't it fast enough?). I also remember seeing a description of a cache flush FKEY some time ago. Would that do the trick? If so, could someone mail me a copy? -- Julian Vrieslander (607) 255-3594 Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853 UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj ARPA: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRY
mms@utgpu.UUCP (01/01/70)
In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: > In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes: > >I'd like to be able to put my header files on a small ramdisk, as reading > >them in seems to be the most time-consuming part of my compiles > > Why bother? Just crank up the RAM Cache on the control panel and you get > better than the same effect: the include files that are getting used a lot > right now, stay in the cache, and you don't have to worry about explicitly > moving files around. It's no trouble to move the files, since I can tell the ram disk program to do that automatically, and if I run LSC with a reasonable amount of space under switcher there doesn't seem to be enough memory left over to make the cache effective. -- john j. chew (v3.0) poslfit@gpu.utcs.toronto.edu +1 416 463 5403 (300/1200 bps) poslfit@utorgpu.bitnet {cbosgd,decvax,mnetor,utai,utcsri,{allegra,linus}!utzoo}!utgpu!poslfit "Script-G for open, sub-delta for durchschnitt"
gardner@prls.UUCP (10/01/87)
A couple of things I'd like to see in LightSpeed C (which I greatly enjoy): Macros can be tricky. It would sure be nice to have the compiler optionally generate a file containing the output of the macro pre-processor. This would help me catch lots of otherwise very obscure bugs. I get rather annoyed with C at times because it lets me do dumb things without complaining. Prototypes help, but I think it would be nice to have a Lint option that would check your project for dumb mistakes (and machine-dependency, though Mac programmers don't usually worry about that too much -- what machine are they going to port their programs to?). It seems that with LSC's projects, a nice implementation of this could be done. It wouldn't need to be fast, either, since it would probably only be used after major revisions or when bug-exterminating. Other ANSI extensions would be nice, such as allowing function definitions to have the same format as prototypes (for easier copy/pasteing) and string/name concatenation at compile time. I would guess, though, that THINK plans on supporting ANSI in full if and when it is finalized. Robert Gardner
whp@apr.UUCP (Wayne Pollock) (10/02/87)
One of the features I liked in AT&Ts newer cpp was that it warned you if a comment contained "/*" - that is, the start of a comment. This usually means you forgot to end a comment someplace. -Just another feature you can add to your list! Wayne
oster@dewey.soe.berkeley.edu.UUCP (10/02/87)
In article <367@cogen.UUCP> alen@cogen.UUCP (Alen Shapiro) writes: >I find it annoying that after a R(un command >(and subsequent exit from my application) my carefully set up >edit windows and cursor locations within them are lost (on return >to LSC). An easy way to do this is: 1.) if you have the recently posted WDEF 2 (multi-finder compatibility patch installed in your working copy of LightSpeed C, then throw it away and make a new copy of your master. 2.) Start Switcher (I use version 5.5, available from user's groups and APDA) 3.) Use Switcher's "Get Info" command to find out how much memory you've got. 4.) Use Switcher's "Configure and Install" command to configure LightSpeed C to use almost all the free memory (I give mine 750k on a 1 meg machine. Performance is improved by giving it at least a small RAM Cache (On the control panel.)) 5.) Now, when you run a program under test and exit it, LSC comes back much faster, with all your open files, scroll positions, and cursor positions intact. 6.) For conveninence, I create a "Switcher Set" document for each of my projects that when you double click on it: a.) Starts Switcher b.) starts LSC c.) opens the project. I double click on these instead of on the project documents. You can even examine the source code while the program is running. Remember though, you must open all the files you are going to want to look at before you hit the Run command. You can switch out of the running-program-under-test and back to LightSpeed C, but you must be careful not to open any more files until you quit the running-program-under-test. This flaw is because LSC gives up a little too much memory to the running-program-under-test. You get back to the program-under-test with <command>-R (the resume command.) If you write applications or DAs in LSC, this method of development is great for your edit-compile-test cycle. I use this scheme all the time under System 4.1. I test very frequently because it is so fast and I don't lose my place in my source code. --- David Phillip Oster --Thanks to THINK Inc. (now a subsidiary) Arpa: oster@dewey.soe.berkeley.edu --for a truly great product. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
wbell@utgpu.UUCP (10/05/87)
Lint would be nice, but I'd rather see a source-level debugger, a la 'dbx'.
Any chance of this in the near future?
Also, when can we expect to see the 'next major release' mentioned?
(just curious, not desperate..)
--
----
University of Toronto Computing Services Warren Bell
UUCP: {cbosgd,ihnp4,utai,utcsri,utzoo}!utgpu!wbell
Internet: wbell@gpu.utcs.toronto.edu
BITNET: wbell at utoronto, wbell at utorgpu
Disclaimer: the views expressed above are mine, and do not in any way reflect
the views of my employers.singer@endor.harvard.edu (Richard Siegel) (10/05/87)
In article <1987Oct4.173336.1783@gpu.utcs.toronto.edu> wbell@gpu.utcs.UUCP (Warren Bell) writes: > > >Lint would be nice, but I'd rather see a source-level debugger, a la 'dbx'. >Any chance of this in the near future? > >Also, when can we expect to see the 'next major release' mentioned? >(just curious, not desperate..) I don't want to tip my hand *too* much, but there is another major release planned, and it won't be too long from now, and will include a lot of "wish list" features. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *
mms@utgpu.UUCP (10/09/87)
How about being able to set the <> and "" paths to be used with #include?
I'd like to be able to put my header files on a small ramdisk, as reading
them in seems to be the most time-consuming part of my compiles (isn't that
a great thing to say about a compiler?)
--
john j. chew (v3.0) poslfit@gpu.utcs.toronto.edu
+1 416 463 5403 (300/1200 bps) poslfit@utorgpu.bitnet
{cbosgd,decvax,mnetor,utai,utcsri,{allegra,linus}!utzoo}!utgpu!poslfit
"Script-G for open, sub-delta for durchschnitt"singer@endor.harvard.edu (Richard Siegel) (10/09/87)
In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes: > > >How about being able to set the <> and "" paths to be used with #include? >I'd like to be able to put my header files on a small ramdisk, as reading A good idea; I'll submit it to Mike, and see if he hasn't already considered it. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *
oster@dewey.soe.berkeley.edu (David Phillip Oster) (10/12/87)
In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes: >I'd like to be able to put my header files on a small ramdisk, as reading >them in seems to be the most time-consuming part of my compiles Why bother? Just crank up the RAM Cache on the control panel and you get better than the same effect: the include files that are getting used a lot right now, stay in the cache, and you don't have to worry about explicitly moving files around.
fry@huma1.HARVARD.EDU (David Fry) (10/13/87)
In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: >In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >>Why bother? Just crank up the RAM Cache on the control panel and you get >>better than the same effect: the include files that are getting used a lot >>right now, stay in the cache, and you don't have to worry about explicitly >>moving files around. > >This certainly does give a nice speed increase, especially if you have >2 Meg or more to run around in. But I am hesitant to use RAM cache when >I am debugging tricky code that is crashing a lot; I worry about losing >source changes that have not been written from the cache out to disk. > >I asked one of the folks at Think whether LSC was smart enough to >flush the cache before a project is started up from the "Run" command. He >claimed that this was not the case, and that there was no way that LSC >could tell whether the cache was enabled. He said that he did not trust >the RAM cache well enough to use it for his own development work. Two funny things about this: first, it is certainly possible for LSC to determine if the cache is enabled. How does the Control Panel do it? Divine intervention? I wrote an FKEY to toggle the cache setting it is trivial to check for the cache. Second, I have used LSC plenty with the cache on and I have crashed it just as often and I have yet to lose a single character of source this way. Ever since Apple came up with the cache it has been given a constant bad rap, in my opinion. I think it's a safe, great idea. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@harvma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
singer@endor.harvard.edu (Richard Siegel) (10/13/87)
My personal preference is not to use a cache; crashing doesn't worry me
because I always save my source files before I run. What worries me is
that a bad pointer could possibly corrupt the cache without crashing the
machine, and cause garbage to be written out to disk when the cache is flushed.
I don't know if that's a valid worry, but I prefer not to use the cache.
The user can tell if the cache is turned on, and I suppose LightspeedC
could detect whether it's turned on, but it's impossible to know *where*
above BufPtr the cache is. Very often the cache isn't the only thing in
high memory.
It's an interesting idea, but it's not likely to get much consideration
at the moment...
--Rich
**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies, Inc).
* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer *
* Customer Support | singer@endor.harvard.edu *
* THINK Technologies, Inc. (No snappy quote) *olson@endor.harvard.edu (Eric K. Olson) (10/13/87)
In a recent article David Fry writes: >In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: >>I asked one of the folks at Think whether LSC was smart enough to >>flush the cache before a project is started up from the "Run" command. He >>claimed that this was not the case, and that there was no way that LSC >>could tell whether the cache was enabled. He said that he did not trust >>the RAM cache well enough to use it for his own development work. > >Two funny things about this: first, it is certainly possible >for LSC to determine if the cache is enabled. How does the >Control Panel do it? Divine intervention? I wrote an FKEY to >toggle the cache setting it is trivial to check for the cache. > >Second, I have used LSC plenty with the cache on and I have >crashed it just as often and I have yet to lose a single >character of source this way. > >Ever since Apple came up with the cache it has been given a >constant bad rap, in my opinion. I think it's a safe, great >idea. I have used the cache without a problem since it became available in the System. I think it is very safe to use with LSC, because LSC does a _FlushVol (in LSC CODE #10) prior to running the project. This (I assume) flushes the cache; it wouldn't be a very useful system call otherwise. The cache is also probably quite safe for general use also, since _InitApplZone also calls _FlushVol, and _InitApplZone is called at every Launch. (In fact, LSC does two _FlushVols because of this). If you're program crashes and use use one of the many techniques to invoke _ExitToShell (FKEYs, debuggers, or SM 0 a9f4 G 0 in the minidebugger in the 128K & 256K ROMs), then the Launch of the Finder will also call _FlushVol. Then again, if _FlushVol doesn't flush the cache, none of this is any good. But I'm quite sure it does. Anyone at Apple care to comment? -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
gardner@prls.UUCP (Robert Gardner) (10/13/87)
In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: >This certainly does give a nice speed increase, especially if you have >2 Meg or more to run around in. But I am hesitant to use RAM cache when >I am debugging tricky code that is crashing a lot; I worry about losing >source changes that have not been written from the cache out to disk. > The RAM cache sure gets a lot of bad 'press'. I have used it with LSC very happily for a LONG time and have survived MANY crashes with it with absolutely NO loss of data. There was a lot of scare about it for awhile because it's not write-thru. I don't have any official dope on this, but from what I have been able to discover (mostly by just watching disk activity), the cache is flushed to disk whenever FlushVol() is called. If this is true then the RAM cache is no less safe than any- thing else since the normal disk buffers are also only flushed when FlushVol is called. IM recommends that you call FlushVol whenever you close a file or after a Save, and I suspect LSC does this before Running your application. (I have LSC set up to do auto saves before a Run.) I believe ExitToShell and perhaps a few other routines also call FlushVol. In summary, I have yet to figure out why the RAM cache is more dangerous than the standard Mac disk-buffering. I have used it successfully for nearly a year now and have never lost data because of it, though I've crashed many, many times in many strange and interesting ways. Robert Gardner
oster@dewey.soe.berkeley.edu (David Phillip Oster) (10/13/87)
In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: > But I am hesitant to use RAM cache when >I am debugging tricky code that is crashing a lot; I worry about losing >source changes that have not been written from the cache out to disk. Well, you can stop worrying. LightSpeed C asks you, before you run a project "Save Changes before running?" just press the write button and it will write the changes to disk. Apple has always said that programs must call FlushVol() after writing a file so that the directory information will be updated. Apple designed the RAM cache so that calling FlushVol() flushes the cache and ensures that the write really gets put on the disk. Assuming that LightSpeed C's write routine plays by the rules, your changes are safe. This point is more fully described in my upcoming "How to Write a TEXT Editor, part II, Data File compatibility." --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
steele@unc.cs.unc.edu (Oliver Steele) (10/14/87)
singer@endor.UUCP (Richard Siegel) writes: >My personal preference is not to use a cache; crashing doesn't worry me >because I always save my source files before I run. What worries me is >that a bad pointer could possibly corrupt the cache without crashing the >machine, and cause garbage to be written out to disk when the cache is flushed. >I don't know if that's a valid worry, but I prefer not to use the cache. It is a valid worry, but only if the cache is unflushed when the rogue program writes into it. If LSC does a FlushVol before it runs a project, and it sounds like it does from the grinding it makes on a floppy, then the worst a rogue can do is fill the cache with random data which gets written over again anyway. Well, the worst it can do is mess up the directory for the cache so that the caching code thinks it needs to be flushed again and messes up your disk after all, but this is pretty hard to do and a rogue can always misfire into the memory mapped i/o or accidentally call the Sony driver anyway. >The user can tell if the cache is turned on, and I suppose LightspeedC >could detect whether it's turned on, but it's impossible to know *where* >above BufPtr the cache is. Very often the cache isn't the only thing in >high memory. TN81 tells how to turn it off, but it says that this is probably best left under user control and this sounds like a good idea. As far as LSC improvements, I would like to see: o Allow function declarations in prototype form, i.e. static void foo(int a, long *b) { ... } o Allow a function declaration to server as a prototype, i.e. static void bar(long l){...} main{ bar(123); /* gets coerced */} o Make 'pascal' a modifier with its own flavor, instead of a storage modifier, so I can say static int pascal xyzzy(); (this isn't very important, but it bothers my gestalt). o Allow the use of PC-relative addressing for globals within a code segment. Sure it's non-reentrant, but writing fancy INITs or code that installs itself as a permanant patch is very painful right now. o Maybe give users a way to have smaller default windows on a large screen. It's nice to be able to see more code, but it's also nice to be able to see more windows at once without having to resize them all first. Was it Alan Kay or Larry Tessler who said the Mac is the first computer worth criticizing? Lightspeed C is the first C worth nitpicking. My non-nit: oo How about Lightspeed C++? With MacApp, and a Browser written in C++, and an extensive class library, and... well, I'll settle for LSC++. Heck, I'll "settle" for LSC3.0, but I'll perform man-years of hard physical labor (this does translate into $$, but I'm not a real good physical laborer so it's not as much as it sounds) for LSC++. Please? ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "'As it were' means 'I think that I sound very erudite.' 'Per se' is Latin for 'as it were.' As it were."
singer@endor.harvard.edu (Richard Siegel) (10/14/87)
In article <1612@unc.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: >singer@endor.UUCP (Richard Siegel) writes: >As far as LSC improvements, I would like to see: > I will give your suggestions to Mike and see what he has to say, and I'll post his responses. >Was it Alan Kay or Larry Tessler who said the Mac is the first computer >worth criticizing? Lightspeed C is the first C worth nitpicking. My >non-nit: > >oo How about Lightspeed C++? With MacApp, and a Browser written in C++, Maybe, but don't hold your breath. Mike has a long list of things that he wants to do, and C++ support is down near the bottom... LSC 3.0 will be out in a while, and will have all kinds of goodies, but it's not likely to have C++ in it. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *
chuq%plaid@Sun.COM (Chuq Von Rospach) (10/14/87)
> Maybe, but don't hold your breath. Mike has a long list of things >that he wants to do, and C++ support is down near the bottom... LSC 3.0 >will be out in a while, and will have all kinds of goodies, but it's not >likely to have C++ in it. Um, this is a straight line I can't refuse. Now that you've piqued our interest, what will LSC 3.0 have in it? Source level debugging? Have you folks thought seriously about adopting TransSkel (by Paul Dubois) into the standard LSC environment, or are you going all the way to MacApp compatibility? C++ is nice, but I'm not sure it is THAT nice, unless you're an AT&T Unix hacker. My personal preferences for future LSC enhancements are: o give me the ability to take my TMON distribution floppies and feed them to my dog, something I would do happily if there were only a decent debugger for the Mac. (macNosy/Debugger doesn't count. If I wanted stuff at THAT low a level, I'd stick with Unix and ADB. I want something from THIS century, something that looks like it ought to exist on a Mac). o MacApp or some kind of object oriented programming, so that that Mac and the compiler do most of the programming grunt work. Hypercard is a GREAT example of how this works -- let IT worry about all thye structures and thigns, and let me click on the silly button... Anyway, that's what I want. What are we going to get? chuq Chuq Von Rospach chuq@sun.COM Editor, OtherRealms Delphi: CHUQ
steele@unc.cs.unc.edu (Oliver Steele) (10/15/87)
mms@gpu.utcs.UUCP (John J. Chew III) writes: >In article <21246@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >> In article <1987Oct9.001743.14846@gpu.utcs.toronto.edu> mms@gpu.utcs.UUCP (John J. Chew III) writes: >> >I'd like to be able to put my header files on a small ramdisk, as reading >> >them in seems to be the most time-consuming part of my compiles >> >> Why bother? Just crank up the RAM Cache on the control panel and you get >> better than the same effect: the include files that are getting used a lot >> right now, stay in the cache, and you don't have to worry about explicitly >> moving files around. > >It's no trouble to move the files, since I can tell the ram disk >program to do that automatically, and if I run LSC with a reasonable >amount of space under switcher there doesn't seem to be enough memory >left over to make the cache effective. I don't understand this last bit: if you reserve x amount of memory, you aren't going to be able to use it for anything else whether you've reserved it for a RAM disk or for a cache. Are you talking about the RAM cache built into the later system files, as Mr. Oster is, or about some third party software that reserves memory dynamically? In any case, the advantage of a cache over a RAM disk is that you probably won't need to load every include file for most projects, so you can get the same time savings with less memory for a cache since it loads only the applicable files, and dynamically changes its file selection if you move to another project. Curiously, I've found that if you only have one drive, this use (compiling files) is the *only* one for which a cache is superior ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "'As it were' means 'I think that I sound very erudite.' 'Per se' is Latin for 'as it were.' As it were."
lsr@apple.UUCP (Larry Rosenstein) (10/15/87)
In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: > >This certainly does give a nice speed increase, especially if you have >2 Meg or more to run around in. But I am hesitant to use RAM cache when >I am debugging tricky code that is crashing a lot; I worry about losing >source changes that have not been written from the cache out to disk. You should consult Tech Note #81 on caching. There is a way to disable caching if an application needs to do so. Also, the cache is flushed out when you call FlushVol. Application should *ALWAYS* call FlushVol when they finish writing out a file. If you turn off the cache in the Control Panel, the system still caches some directory information, which would not be written out until FlushVol was called. (This has always been true on the Macintosh, even for MFS volumes.) I always run with the disk cache on, and haven't lost anything except when I have failed to save a file. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
singer@endor.harvard.edu (Richard Siegel) (10/15/87)
In article <30912@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: >Um, this is a straight line I can't refuse. Now that you've piqued our >interest, what will LSC 3.0 have in it? Source level debugging? Have you The official line (quoted from Mike Kahl) is that "we are morally committed to providing symbolic debugging for LightspeedC." >folks thought seriously about adopting TransSkel (by Paul Dubois) into the >standard LSC environment, or are you going all the way to MacApp >compatibility? I honestly don't know the answer to that question. As I said, object orientation is of low priority compared to things like revisions to the code generations, MultiFinder compatibility, and a debugger. >o give me the ability to take my TMON distribution floppies and feed them > to my dog, something I would do happily if there were only a decent > debugger for the Mac. (macNosy/Debugger doesn't count. If I wanted This will happen. > stuff at THAT low a level, I'd stick with Unix and ADB. I want > something from THIS century, something that looks like it ought to > exist on a Mac). My sentiments exactly, and I've never heard it said better. >o MacApp or some kind of object oriented programming, so that that Mac and > the compiler do most of the programming grunt work. Hypercard is > a GREAT example of how this works -- let IT worry about all thye > structures and thigns, and let me click on the silly button... As I said, possible but not likely in the next release. >Anyway, that's what I want. What are we going to get? I don't know exactly what to promise, because I'm not familiar with the plans for the product. (Besides, I'm covered by a confidentiality agreement.) You can expect the obvious things, like a debugger and MultiFinder compatibility, however... >chuq >Chuq Von Rospach chuq@sun.COM >Editor, OtherRealms Delphi: CHUQ --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *
jww@sdcsvax.UCSD.EDU (Joel West) (10/15/87)
C++ is an excellent productivity tool for any C programmer,
not just UNIX refugees.
However, THINK's loose cannon-at-large, Andrew Singer, indicated
at a recent conference that he thought object-oriented programming
was oversold and THINK (now Symantec) would NOT be doing C++.
--
Joel West (c/o UCSD)
Palomar Software, Inc., P.O. Box 2635, Vista, CA 92083
{ucbvax,ihnp4}!sdcsvax!jww jww@sdcsvax.ucsd.edusmethers@psu-cs.UUCP (Paul Smethers) (10/16/87)
Let me add Key commands for editing to the list of improvements that would make LSC easier. This could come in any form, even weird option-key sequences like MS Word. Just as long as I don't have to reach for a mouse or inadiquate cursor keys. I'm leftover form the unix 'C' programmer error where we did all programming with text editors like VI or EMACS. Although I love graphical editors that use the mouse, I feel like they hamper my ability to quickly edit and modify programs efficiently (it can't be efficient to reach over for a mouse to back up the cursor one line of code). I think that we all must admit to having backspaced a word or two so that we could correct a typo earlier in the line of code. I would much rather press a option-shift-<insert your favorite key> to move to the beginning of the line or word, make the correction, and then press a option-shift- <insert your second favorite key> to jump back to the end of the line for further editing. What do you say? Am I outnumbered by the masses?
raylau@dasys1.UUCP (Raymond Lau) (10/17/87)
In LightspeedC, I would like to see something similar to Aztec's precompiled
headers - that is, some encoded version of .h files which the compiler can
read and process quickly.
And how about unlimited global/static space? I am sick of having to similate
large arrays through ptrs (or hndls)...if not doing it in a more efficient way,
then there should at least be a way to have the compiler handle this for you.
Finally, on the first compile, there tends to be many errors in one's prgm.
It wouldn't hurt to have an option to have LSC list out maybe 15-20 errors to a
window instead of stopping on each error.
(Of course,t here's Switcher type performance under MultiFinder, but customer
support has already promised such in an upcoming upgrade.)
--
Raymond Lau {allegra,philabs,cmcl2}!phri\
Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!raylau
New York, NY, USA {sun}!hoptoad/ gerrie@hpfclp.HP.COM (Gerrie Shults) (10/20/87)
AFTER the debugger, I'd like to put in another plug for C++, or maybe even Apple's Minimal C++. As long as we're wishing, I'd like to have complete support for MacApp when Apple releases their Minimal C++ version, and not have to be tied to MPW (my objection to MPW is nothing intrinsic, it has to do with money). Object-oriented programming may have been oversold, but based on limited personal experience and some number of success stories at OOPSLA (Object-Oriented Programming Systems, Languages and Applications) in Orlando, I believe there is something there of value. Lots of valuable things have been oversold in this world. It won't make your software problems go away, but it can help you solve some of them. Gerrie Shults Hewlett-Packard, 3404 E. Harmony Rd., Fort Collins, CO 80525-9599 hplabs!hpfcla!gerrie gerrie%hpfcla@hplabs.hp.com
clubmac@runx.ips.oz (Macintosh Users Group) (10/21/87)
In article <2985@husc6.UUCP> fry@huma1.UUCP (David Fry) writes: >Second, I have used LSC plenty with the cache on and I have >crashed it just as often and I have yet to lose a single >character of source this way. > Surely LightspeedC calls FlushVol() when saving sources before Running, which would flush the cache of written data? >Ever since Apple came up with the cache it has been given a >constant bad rap, in my opinion. I think it's a safe, great >idea. Agreed, I've had no problems with the cache whatsoever. Jason Haines, President Club Mac Macintosh Users Group, Sydney, Australia Phone Home: +61-02-73-4444 Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia ACSnet: clubmac@runx.ips.oz ARPA: clubmac%runx.ips.oz@seismo.css.gov UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!runx.ips.oz!clubmac
clive@drutx.ATT.COM (Clive Steward) (10/25/87)
in article <1612@unc.cs.unc.edu>, steele@unc.cs.unc.edu (Oliver Steele) says: > As far as LSC improvements, I would like to see: > > o Allow function declarations in prototype form, i.e. > static void foo(int a, long *b) > { > ... > } > > o Make 'pascal' a modifier with its own flavor, instead of a storage > modifier, so I can say > static int pascal xyzzy(); > (this isn't very important, but it bothers my gestalt). > Actually, these and a couple of other things would be very useful indeed. They would add similarity to/compatibility with the standard C++ pre-compiler, cfront (!). I'd add: o Allow 'static' in front of any function declarations. This is legal (and often used) C, and is something cfront inserts more or less arbitrarily. o Allow the equivalent of preprocessor output (what cpp would emit), in a file. o To tie it all together (might as well ask for the whole moon), provide a mechanism to allow filtering before and after preprocessing, as part of the Make cycle per file -- in other words, a minor form of scripting. These would allow automatic use of sed equivalents, cfront, etc. All this, unless of course there's to be a LightSpeed C++ soon -- now this, would be absolutely ideal. Tough, perhaps, though, to track the development of that language, in particular, the multiple inheritance we keep hearing rumors about, which will be very important to have. Maybe this filtering method, while admittedly slow and nasty, is a better way for now, since it allows third parties to market a suitably modified release of the current cfront. (Part of the conversion for LSC will have to be in concert with Lightspeed, anyway, due to the munch process). Or maybe LSC would be interested in doing the whole thing??? Clive Steward
eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (10/26/87)
Here are a few more suggestions for enhancements to the next release of
LSC. First a couple of easy ones:
A "Print Selection" menu item, as in MacTerminal, would be handy for those
cases when we need a hard copy of only a few lines of code.
The command-click operation that brings up the list of headers #included
in a source file could be extended to show the same pop-up when we
command-click on the file name in the project window.
Now the bigger requests. Someone may have already mentioned this one
(I'm having serious brain-fade tonight), but I'd like to see a compiler
option to dump assembler code interspersed with the source code lines that
it came from. Yah, I know this would slow the compiler down - that's why
I mentioned it as an option. Consulair C has that feature, and I found it
was a nice aid for debugging and optimizing. Of course, the source-level
debugger, if and when it shows up, will somewhat reduce the need for this
feature.
For those of us writing code targetted specifically for the Mac II, the
obvious request is for compiler flags to produce 68020 code (from C or
from asm{}) and in-line direct calls to the 68881, bypassing SANE. I'd
bet that these items are somewhere on the enhancement list already - just
thought I'd mention them in the hope that they get a higher priority than,
say, colorizing the "About.." display.
--
Julian Vrieslander (607) 255-3594
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853
UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!eacj
ARPA: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRYmilt@orstcs.CS.ORST.EDU (Milt Sagen) (10/28/87)
I would like to see LSC have the ability to print a file from the finder, i.e. I select the file then select print form the File menu. As it stands now (2.01) LSC starts up and then requires me to open an existing project or create a new one in order to print the file originally selected. Along this same line; I would also like to have the ability to double-click on a LSC document and have the program startup with the document and without the request for a project. There are actual times when I would like to view, or print, a file without being concerned about any particular project. Milt Sagen no comment
anson@elrond.CalComp.COM (Ed Anson) (10/28/87)
Here is another possible improvement to Lightspeed C, which by itself would be worth the cost of an upgrade to me: Provide some means (e.g., form-feed) to force a page break when printing a program listing. If such a capability exists, I've missed it. FF characters embedded in the file are ignored. (Better still, provide a print option which starts each procedure at the top of a new page.) -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
dlt@csun.UUCP (Dave Thompson) (10/29/87)
In article <750@orstcs.CS.ORST.EDU> milt@orstcs.CS.ORST.EDU.UUCP (Milt Sagen) writes: >Along this same line; I would also like to have the ability to double-click on >a LSC document and have the program startup with the document and without the >request for a project. I'd like to see this also! Especially as I occasionally use the LSC editor to munge non-LSC files that are too large to be accomodated within a da editor (or that doesn't have the functionality). I usually end up bringing up just any project and then open the file that I *really* want. Seems to me that LSP *doesn't* make you give it a project first. -- Dave Thompson uucp: {ihnp4|hplabs|psivax}!csun!dlt CSUN Computer Center phone: (818) 885-2790 18111 Nordhoff Street, Northridge, CA 91330
jteh@mulga.UUCP (10/30/87)
In article <1365@elrond.CalComp.COM>, anson@elrond.CalComp.COM (Ed Anson) writes: > Here is another possible improvement to Lightspeed C, which by itself > would be worth the cost of an upgrade to me: > Provide some means (e.g., form-feed) to force a page break when printing > a program listing. If such a capability exists, I've missed it. FF > characters embedded in the file are ignored. (Better still, provide a > print option which starts each procedure at the top of a new page.) Or even better still, have an option that will allow you to print all the source & header files. This would be really useful for printing out the source for posterity sake. Also, it would be nice to have an option to allow the starting page number to follow the last page number of the previous file printed. I don't think this would be too hard to do. > ===================================================================== > Ed Anson, Calcomp Display Products Division, Hudson NH 03051 > (603) 885-8712, anson@elrond.CalComp.COM One flame that a friend of mine has for LS_Cv2.11 is that it does not support MFS. He says it bombs without any messages on Finder 4.1 (MFS). Perhaps Richard Siegal may have something to say about that. --------------------------- J.T Teh "He is no fool who gives up what he cannot keep to gain what he cannot lose." - James Elliot =========================== UUCP: {seismo,mcvax,ukc,ubc-vision}!mulga!jteh ARPA: jteh%mulga.oz@seismo.css.gov CSNET: jteh%mulga.oz@australia
rudolph@uiucdcsm.UUCP (10/30/87)
I've wondered about putting page breaks in my programs too. I don't have LSC, but if anyone knows of a way to put page breaks in text files using editors such as Edit or the Turbo Pascal editor, I'd like to know about it. David Rudolph rudolph@a.cs.uiuc.edu (217) 398-3124
oster@dewey.soe.berkeley.edu (David Phillip Oster) (10/30/87)
In article <2354@mulga.oz> jteh@mulga.oz (J.T. Teh) writes: >One flame that a friend of mine has for LS_Cv2.11 is that it does not >support MFS. He says it bombs without any messages on Finder 4.1 (MFS). >Perhaps Richard Siegal may have something to say about that. The actual problem is bad, but not quite this bad. LSC V2.11 does support MFS, what it does not support is running a program: 1.) compiled with LSC V2.11 2.) running under a System file of version 2.0 or _older_ 3.) on a machine with 128K ROMs or newer The symptom: you get a system alert (the bomb) before your main() procedure even gets called. The cause: LSC inserts preamble code before your main procedure, that initializes your initialized data. It uses a memory manager call, HGetState() to determien whethe a handle is locked or not. On some macs this trap does not exit. Instead of directly comparing the trap address with that of the UnImplemented() trap, the preamble code looks at the version number of the ROM. If you are running on a 128K ROM or newer machine, it assumes the trap is there and calls it. In fact, if you are using old system software on a new machine, that trap is a direct branch to SystemAlert(). The fix: this would be easy to fix, just change that preamble code to make the correct check. The excuse: So far, each of my complaints has been answered with: "Apple does not recommend the use of System files older than version 3.2 on machines with 128k ROMs." This means that if you want to test your programs under the old, MFS only versions of Apple's system software, you must buy an old, unenhanced Mac to test on. (Natural this is a problem only for programmers trying to do high quality work. My standard testing procedure is to thoroughly test under _every_ version of Apple's system software, starting with the current version and working backwards.) Conclusion: LSC Version 2.11 does support MFS, and does support old, MFS only versions of Apple's system software, it just currently doesn't support old versions of system software running on new ROMs. I am annoyed about this because my customers don't care about these subtle distinctions, they expect my software _work_, no excuses. I hope LSC will be fixed in the next version. --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
fry@huma1.UUCP (10/30/87)
Since everyone seems to saying what they want to see in LSC, I thought I'd add my little request. On machines with the 128K ROM and up it is desirable to have all CODE resources, except the main segment, marked as unlocked and unprotected. The 128K ROM will then load them, put them at the top of the heap and lock them. This goes a long way to preventing heap fragmentation. But LSC locks and protects all CODE resources so I have to go in with ResEdit and undo that for about 15 resources. Perhaps THINK could include in the GetInfo box a place to mark what resource attributes the segment should have? I expect this would also be useful for writers of INITs, DAs, FKEYs, etc. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@harvma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
omh@nancy.UUCP (11/02/87)
In article <21529@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <2354@mulga.oz> jteh@mulga.oz (J.T. Teh) writes: >>One flame that a friend of mine has for LS_Cv2.11 is that it does not >>support MFS. He says it bombs without any messages on Finder 4.1 (MFS). >>Perhaps Richard Siegal may have something to say about that. > > >The actual problem is bad, but not quite this bad. LSC V2.11 does support >MFS, what it does not support is running a program: >1.) compiled with LSC V2.11 >2.) running under a System file of version 2.0 or _older_ >3.) on a machine with 128K ROMs or newer > Actually, the problem is pretty bad, if you're trying to ship a product. > >The cause: LSC inserts preamble code before your main procedure, that >initializes your initialized data. It uses a memory manager call, HGetState() >to determien whethe a handle is locked or not. On some macs this trap >does not exit. Instead of directly comparing the trap address with that of >the UnImplemented() trap, the preamble code looks at the version number of >the ROM. If you are running on a 128K ROM or newer machine, it assumes the >trap is there and calls it. In fact, if you are using old system software >on a new machine, that trap is a direct branch to SystemAlert(). > >The fix: this would be easy to fix, just change that preamble code to make >the correct check. > >The excuse: So far, each of my complaints has been answered with: >"Apple does not recommend the use of System files older than version 3.2 >on machines with 128k ROMs." > >This means that if you want to test your programs under the old, MFS only >versions of Apple's system software, you must buy an old, unenhanced Mac >to test on. (Natural this is a problem only for programmers trying to do >high quality work. My standard testing procedure is to thoroughly test under >_every_ version of Apple's system software, starting with the current >version and working backwards.) > > >--- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. >Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. >Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu I heartily echo David's sentiments (and predicament). An additional problem, What version of the System/Finder are you supposed to ship with? My software works on all versions (128K to II) of Macs. So, I ship with System2.0/Finder4.1. This breaks (as outlined above) on every machine with new Roms. My software program is educational software for pre-schoolers, which means I am going to get a lot of naive users as customers. (By naive, I mean people who don't regularly keep up with all the developments in the Mac world.) Think's response: Ship the program with no system. Great, now it won't even boot. I don't think a slip of paper shipped with the program saying "please copy over an appropriate system and finder from the disks you got when you bought your computer" would be an appropriate thing to do, not to mention Apple's penchant for preferring you to ship a bootable disk. (they like to have you under licensing!) When you write educational software, you really have to design the system to accomodate the most computer illiterate user. It is also against our Macintosh programmers unwritten philosophy of "write the software so that you don't have to read the manual first" to require System/Finder changes. I realize that Apple hasn't made it easy with all the System Finder changes. But this really seems to be an easy thing to catch. My solution: I ported over to MPW. Didn't like it, but I had to in order to support the full gamut of machines (128K to II). Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET omh%cs.brown.edu@relay.cs.net-relay.ARPA {ihnp4,allegra}!brunix!omh
clubmac@runx.ips.oz (Macintosh Users Group) (11/02/87)
In article <2354@mulga.oz> jteh@mulga.oz (J.T. Teh) writes: >Or even better still, have an option that will allow you to print all the >source & header files. This would be really useful for printing out the >source for posterity sake. Also, it would be nice to have an option to allow >the starting page number to follow the last page number of the previous file >printed. I don't think this would be too hard to do. > I totally agree, I am sure *EVERY* LSC user would like some enhancements to printing, such as Print All and page breaks between functions. > >One flame that a friend of mine has for LS_Cv2.11 is that it does not >support MFS. He says it bombs without any messages on Finder 4.1 (MFS). >Perhaps Richard Siegal may have something to say about that. > I have something to say about it - what the hell is someone flaming about anything not supporting MFS? MFS is officially *DEAD*. Anyone who hasn't ordered a ROM/Drive upgrade for their ol' 512K Mac is a candidate for the funny farm. Jason Haines, President Club Mac Macintosh Users Group, Sydney, Australia Phone Home: +61-02-73-4444 Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia ACSnet: clubmac@runx.ips.oz ARPA: clubmac%runx.ips.oz@uunet.css.gov UUCP:{enea,hplabs,mcvax,prlb2,uunet,ubc-vision,ukc}!munnari!runx.ips.oz!clubmac
smethers@psu-cs.UUCP (Paul Smethers) (11/02/87)
In article <8400005@uiucdcsm> rudolph@uiucdcsm.cs.uiuc.edu writes: > > >I've wondered about putting page breaks in my programs too. I don't have >LSC, but if anyone knows of a way to put page breaks in text files using >editors such as Edit or the Turbo Pascal editor, I'd like to know about it. > I have a simply solution that I have been using for printing with page breaks while using LSC. I inserted page breaks into my code a long time ago with Aztec C, and have been Cutting and Pasting them wherever I've needed them ever since. I print in MPW (I like their printing options, with good user-defined banners and font control), which understands page breaks. This may not sound great initially, but considering that most of the printing problems mentioned so far - including printing multiple files, all source code, or even program sub-routine names or comments only (try their regular expression pattern matching) - can be fixed with a MPW shellscript, MPW and LSC make a great combination programming environment (in fact, I almost asked that LSC put in more operating system tools, but now that Multifinder is almost out, it would seem silly for them to try to provide what MPW does already). I don't use MPW C anymore, but I love the shell. Here are my printing options from my UserStartup file for mpw (I use a GCC laserprinter): set PrintOptions "-h -b -lm 0.5 -t 4 -f courier -s 6 -hf 'Swiss Narrow' -hs 18 -l 120" If there is any interest, I'll post a sample shellscript that searches out sub-routine comments (if you use standard 'C' header comments) and prints them out. Paul Sm910ce s
gardner@prls.UUCP (Robert Gardner) (11/02/87)
In article <20092@brunix.UUCP> omh@nancy.UUCP (Owen M. Hartnett) writes: >In article <21529@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >>The actual problem is bad, but not quite this bad. LSC V2.11 does support >>MFS, what it does not support is running a program: >>1.) compiled with LSC V2.11 >>2.) running under a System file of version 2.0 or _older_ >>3.) on a machine with 128K ROMs or newer >I heartily echo David's sentiments (and predicament). An additional problem, >What version of the System/Finder are you supposed to ship with? >My solution: I ported over to MPW. Didn't like it, but I had to in order to >support the full gamut of machines (128K to II). Add one more frustrated LSC user to the list! My solution? Stick with LSC v2.0 and ignore the Mac II market! (I'm also looking at "computer illiterate users".) I'm hoping the THINK will fix the problem before the Mac II market (for my products) becomes big enough to worry about. (Actually, most of my stuff runs on the Mac II, you just have to be careful with low-level file io calls.) LSC v3.x had better NOT have this problem!!!!! Robert Gardner
singer@endor.harvard.edu (Richard Siegel) (11/03/87)
In article <7162@prls.UUCP> gardner@prls.UUCP (Robert Gardner) writes: > >looking at "computer illiterate users".) I'm hoping the THINK will fix >the problem before the Mac II market (for my products) becomes big >enough to worry about. (Actually, most of my stuff runs on the Mac II, >you just have to be careful with low-level file io calls.) LightspeedC version 2.11 (posted to sumex-aim, comp.binaries.mac, Delphi, Genie, and CompuServe, and from there to most of the civilized world. LSC 2.11 fixes the problems with cache violation and direct handle attribute maipulation. The problem with HGetState and HSetState is one that has been flamed about very much on this net, but there's really nothing that's going to be done; certainly, the startup code could be modified to check every possible machine/ROM/System file combination, but this is not going to be done. The simple fact is that running System 2.0 on a machine with the 128K (or later) ROM set will not work. This is what Apple says, and this is the way it is. If you want to test your software on old ROMs or with an old System, use System 3.2. If you must test with System 2.0, you'll have to get an old 512K machine to try it. The reason you get crashes using HGetState and HSetState with System 2.0 on a Mac Plus is because the trap dispatch table is different under System 2.0, and these two calls (among others) get mapped out. >LSC v3.x had better NOT have this problem!!!!! LSC 2.11 doesn't have it, LSC 3.x won't either. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
conybear@moncsbruce.oz (Roland Conybeare) (11/04/87)
Here are some improvements to LSC that I would appreciate:
* ctrl-D opens the file whose name is given by the current selection; this
is useful for looking up things in include files. I would like something
more sophisticated that looks up the definition of the selected function
name or global variable, a la vi's tag command.
* I find prototypes very useful. However a lot of my code has fields in
structures which are pointers to functions, and I cannot define a
prototype for these variables. I would like to be able to prototype these
as well; e.g.
typedef struct _x {
void *(*x_install_fn)( SET *s, int y );
int a, b, c;
} X;
* I find the restriction of one segment per file unpleasant at times.
For example, I have a lot of files (>40) with an "Initialisation part"
and a "Working part". The initialisation part contains code and
data which is called once or transformed in some way and never used
again. If each such initialisation part had its own segment, then
they would eventually get thrown away. At the moment, to achieve
such efficiencies I must put each initialisation section in its own
file which obscures the intent of my programs.
* Oh, please could there be some way to automatically run each
source file through another program before attempting to compile it?
This would allow me to gratify my desire to write tools rather than
applications; I could also overcome so many deficiencies of C. Let
me write that inline function expander, that initialiser of automatic
arrays/structs..
Some less important improvements.
* Could we have a zoom box in the project window? This would make the
window tall enough to display every file in its project. Hopefully a
zoom'd window would still be zoomed when returning from running a
program.
* For include files, I would like control-click in the title bar to
bring up a menu listing the files including the given file. I would
also like to be able to get this menu by clicking on a file in the
project window. I find these menus so useful that often I find myself
opening source files just so I can conveniently open an include file.
* I would *love* some sort of cross-reference on my source code, telling
me for each function where it is declared/called, and for each
global variable where it is declared/used.
Finally, thank you for an excellent C compiler that deserves improvement.
Roland Conybeare
(conybear@moncsbruce.oz)singer@endor.harvard.edu (Richard Siegel) (11/05/87)
In article <328@moncsbruce.oz> conybear@moncsbruce.oz (Roland Conybeare) writes: > >is useful for looking up things in include files. I would like something >more sophisticated that looks up the definition of the selected function >name or global variable, a la vi's tag command. Try option-double-click on a symbol. If it's declared somewhere, the file will be opened and the symbol declaration will be displayed. (This doesn't work for macros, of course...) A zoomed window won't be preserved after you return to LSC from running a project, unless you use LSC with MultiFinder. Incidentally... LSC version 2.15 (MultiFinder, complete ToolBox interfaces, and new AppleTalk glue) will be ready for delivery within a few days. I'm hoping to have it posted to sumex-aim and comp.binaries.mac either this weekend or early next week. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
lsr@apple.UUCP (Larry Rosenstein) (11/06/87)
In article <21529@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: > >The excuse: So far, each of my complaints has been answered with: >"Apple does not recommend the use of System files older than version 3.2 >on machines with 128k ROMs." I have to agree with Think Technologies on this one. Also, I suspect that Lightspeed C is not the only program that would exhibit this problem. Inside Macintosh volume 4 is the "specification" for a Mac Plus. It states that HGetState is part of the machine. It turns out, however, that the call is implemented by the patches in System 3.2 or later, and not in ROM. A similar situation would apply to the Mac II. A couple of the Color Quickdraw traps are implemented only in patches. If you ran a program that used one of these traps on a pre-4.1 System file, it would bomb as well. Rather than considering this a bug in LSC, it would be more accurate to say that this is a bug in the 128K ROM, which is fixed in System 3.2 or later. (Unlike most ROM bugs, it happens to be a fatal bug that is easy to run across.) It is always true that each ROM requires a certain System file or later, because inevitably there are bugs in the ROM that must be fixed. It is inadvisable to run the machine without these bug fixes. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
lsr@apple.UUCP (Larry Rosenstein) (11/06/87)
In article <20092@brunix.UUCP> omh@nancy.UUCP (Owen M. Hartnett) writes: > >I heartily echo David's sentiments (and predicament). An additional problem, >What version of the System/Finder are you supposed to ship with? > >My software works on all versions (128K to II) of Macs. So, I ship with >System2.0/Finder4.1. This breaks (as outlined above) on every machine >with new Roms. There probably is no good solution to this problem. The number of different ROMs means that a developer has a difficult time supporting all the machines. Here are some thigns to consider. First, System 2.0 is recommended only for machines with 128K of RAM. It seems foolish to configure a product for this machine, when it causes problems for the vast majority of users with 512K or more. The solution here might be to state that your program only runs on 512K machines and above. Such a statement doesn't exclude many users. The recommended configuration for all other machines is System 3.2 or later. (This is true even for 512K machines with old ROMs.) LSC programs will work fine on this System. If you expect a user to boot off your diskette and start working, then the only way to can cater to every machine is to ship the latest System file. The latest System file has the ROM bug fixes for every machine. Note that the latest System (4.2) will work fine on 512K machines with 64K or 128K ROMs. (I admit that I haven't tried this, but System 4.1 worked.) The size of the patches, however, reduces the amount of working RAM, so it is not recommended by Apple. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
stew@endor.harvard.edu (Stew Rubenstein) (11/06/87)
In article <6650@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >Note that the latest System (4.2) will work fine on 512K machines with 64K >or 128K ROMs. (I admit that I haven't tried this, but System 4.1 worked.) >The size of the patches, however, reduces the amount of working RAM, so it >is not recommended by Apple. Are you certain of this? I seem to remember noticing that PTCH 105 was NOT in system 4.2, although it is in 4.1. Stew Rubenstein Cambridge Scientific Computing, Inc. UUCPnet: seismo!harvard!rubenstein CompuServe: 76525,421 Internet: rubenstein@harvard.harvard.edu MCIMail: CSC
lsr@apple.UUCP (Larry Rosenstein) (11/07/87)
In article <3119@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes: > >Are you certain of this? I seem to remember noticing that PTCH 105 was >NOT in system 4.2, although it is in 4.1. Right you are. (I did say that I hadn't checked System 4.2 before making my comment.) Also, the patch for the Mac XL is not in System 4.1, but is in System 3.2. This means developers would have to ship System 4.1 if they wanted to support 512K machines with old ROMs as well as other machines. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
raylau@dasys1.UUCP (Raymond Lau) (11/08/87)
In article <6650@apple.UUCP>, lsr@apple.UUCP (Larry Rosenstein) writes: B > > First, System 2.0 is recommended only for machines with 128K of RAM. It > seems foolish to configure a product for this machine, when it causes > problems for the vast majority of users with 512K or more. The solution > here might be to state that your program only runs on 512K machines and > above. Such a statement doesn't exclude many users. > -- > Larry Rosenstein > > Object Specialist > Apple Computer That is not always true. I have had "bug reports" from 512k owners who use System 2.0. (I say "bug reports" bec. System 2.0 lacks List Mgr support) It appears than they either complain that System 3.2 doesn't work well on the 512...(though no one mentions exactly why) OR that they own the internal Hyperdrive 10. It seems that GCC has orphaned the Hyperdrive 10...leaving it without System past 2.0 support. ----------------------------------------------------------------------------- Raymond Lau {allegra,philabs,cmcl2}!phri\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!raylau New York, NY, USA {sun}!hoptoad/ GEnie:RayLau Delphi:RaymondLau CIS:76174,2617 "Take it and StuffIt."
omh@nancy (Owen M. Hartnett) (11/09/87)
In article <6650@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <20092@brunix.UUCP> omh@nancy.UUCP (Owen M. Hartnett) writes: >> >>I heartily echo David's sentiments (and predicament). An additional problem, >>What version of the System/Finder are you supposed to ship with? >> >>My software works on all versions (128K to II) of Macs. So, I ship with >>System2.0/Finder4.1. This breaks (as outlined above) on every machine >>with new Roms. > >There probably is no good solution to this problem. The number of different >ROMs means that a developer has a difficult time supporting all the >machines. Here are some thigns to consider. > >First, System 2.0 is recommended only for machines with 128K of RAM. It >seems foolish to configure a product for this machine, when it causes >problems for the vast majority of users with 512K or more. The solution >here might be to state that your program only runs on 512K machines and >above. Such a statement doesn't exclude many users. > Exactly what problems does it cause with other systems? Other than messing up their hard drives because it doesn't know scsi, I haven't run into any problems. This is not a problem either, because if someone is using a hard drive, they'll be booting from a hard drive, not from the system on the shipping disk. I haven't got it in my heart to turn away customers because they haven't upgraded yet. My market consists of home users of the Macintosh and so the number of 128Ks as a percentage of my market is around 5%. I haven't seen any figures that tell exactly how many 128s are out there, but my market figures are indicating otherwise. Of course, my market share isn't as big as Apple's. >The recommended configuration for all other machines is System 3.2 or later. >(This is true even for 512K machines with old ROMs.) LSC programs will work >fine on this System. > >If you expect a user to boot off your diskette and start working, then the >only way to can cater to every machine is to ship the latest System file. >The latest System file has the ROM bug fixes for every machine. > >Note that the latest System (4.2) will work fine on 512K machines with 64K >or 128K ROMs. (I admit that I haven't tried this, but System 4.1 worked.) >The size of the patches, however, reduces the amount of working RAM, so it >is not recommended by Apple. > The problem with using the newest systems is their size. You can't get one on a 400K disk and still have room for your application. However, MPW (and most other compilers) will generate working code on a MacPlus using System 2.0/Finder 4.1. The way I see it, most SE's and II's will have a hard disk, negating the System shipped anyway, and so you should cater to 128's, 512's, 512ke's, and Pluses in your system selection. Besides, SE owners and II owners have been adequately warned by Apple to use the correct System/Finder. Of course, this advice pertains only to people who want to ship to the entire Macintosh line. As Apple's goal is to sell as many computers as possible, we developers would like to sell as many programs as possible, thus I feel it would be foolish to eliminate any market share, no matter how small, if they can possibly be accomodated. I believe Think Technologies is making a mistake in not expending some effort to overcome this, (because I really like using their products!) but I realize they have a lot of things on their to-do list. Well, now I'm really dreaming... but maybe Apple will come up with a developer's version of System/Finder which can be shipped to run on any machine. Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET omh%cs.brown.edu@relay.cs.net-relay.ARPA {ihnp4,allegra}!brunix!omh
singer@endor.harvard.edu (Richard Siegel) (11/09/87)
In article <1923@dasys1.UUCP> raylau@dasys1.UUCP (Raymond Lau) writes: >Hyperdrive 10. It seems that GCC has orphaned the Hyperdrive 10...leaving it >without System past 2.0 support. > This is not at all true. We've been using HyperDrives running System 3.2 and System 4.0; the GCC software required is V3R1. I understand that there is a V3R2 for running System 4.1, but we haven't got it yet... --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
hammen@csd4.milw.wisc.edu (Robert Joseph Hammen) (11/09/87)
In article <6656@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <3119@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes: >> >>Are you certain of this? I seem to remember noticing that PTCH 105 was >>NOT in system 4.2, although it is in 4.1. > >Right you are. (I did say that I hadn't checked System 4.2 before making my >comment.) Also, the patch for the Mac XL is not in System 4.1, but is in >System 3.2. > >This means developers would have to ship System 4.1 if they wanted to >support 512K machines with old ROMs as well as other machines. This means that developers would have to ship System 4.0 if they wanted to support Lisas under MacWorks. System 4.0 does work fine on a Lisa, especially with the HFS upgrade now available from Sun Systems Remarketing. >Larry Rosenstein Robert Hammen Computer Applications, Inc. hammen@csd4.milw.wisc.edu Delphi: HAMMEN GEnie: R.Hammen
howard@cpocd2.UUCP (11/16/87)
In article <328@moncsbruce.oz> conybear@moncsbruce.oz (Roland Conybeare) writes: >I would like something more sophisticated that looks up the definition >of the selected function name or global variable, a la vi's tag command. In article <3112@husc6.UUCP> singer@endor.UUCP (Richard Siegel) writes: > Try option-double-click on a symbol. If it's declared somewhere, >the file will be opened and the symbol declaration will be displayed. >(This doesn't work for macros, of course...) Why "of course"? UNIX ctags works for both procedure names *and* macros, so it's clearly possible to handle macros correctly. Perhaps you just haven't thought about it enough yet. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET "Never had anything but a mother." - Mississippi John Hurt
singer@endor.UUCP (11/17/87)
In article <971@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >Why "of course"? UNIX ctags works for both procedure names *and* macros, >so it's clearly possible to handle macros correctly. Perhaps you just haven't >thought about it enough yet. > In the context of LightspeedC, you can't use option double-click to look up macros because macros aren't added to the linker tables when a source file is compiled. Of course, this is subject to change, but for now, that's the way it's done. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
steele@unc.cs.unc.edu (Oliver Steele) (11/18/87)
In article <328@moncsbruce.oz> conybear@moncsbruce.oz (Roland Conybeare) writes: >I would like something more sophisticated that looks up the definition >of the selected function name or global variable, a la vi's tag command. In article <3112@husc6.UUCP> singer@endor.UUCP (Richard Siegel) writes: > Try option-double-click on a symbol. If it's declared somewhere, >the file will be opened and the symbol declaration will be displayed. >(This doesn't work for macros, of course...) howard@cpocd2.UUCP (Howard A. Landman) writes: >Why "of course"? UNIX ctags works for both procedure names *and* macros, >so it's clearly possible to handle macros correctly. Perhaps you just haven't >thought about it enough yet. And maybe he has. UNIX ctags runs as a text-processing program separate from cpp, pcc, lint, and anything else that looks at PSGs. (Try running it on a strangely indented program to see how this can mess it up.) Since it's going to make a separate pass from the compiler through all the source files, there's no penalty for having it check for macros as well as function headers, as long as they're both defined as greps. LSC does any symbol lookup on the basis of information it has gathered in the compilation phase and stored in the project file. If it were to let you option-double-click on macros, it would need to compile a list of what macros were defined in what headers/files at compile-time, which is inner-loop in the LSC environment. It would also need to update this table in the project menu after each recompilation, and manage separate copies for each source file, since macro definitions are not global. (imagine having to wait for ctags after each recompilation). Updating the project file already takes a lot of time. Now, how about making opt-2-click look for the first occurrence of a word in the CURRENT file when the word isn't in the link information? This at least solves the problem for statics, and for macros that aren't in headers. Also, a cmd-D that widens the selection range to include surrounding text if the selection is just an insertion point would be convenient. ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "When you believe in a loving God, life appears to be very funny." -- Garrison Keillor