gleicher@duke.cs.duke.edu (Michael Gleicher) (01/14/88)
I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the net upgrades), and I must say it is one of the poorest products that I have seen for a computer. 1) The documentation is awful. In general, I have not seen a well documented product on the Mac (I'm used to the PC world). Most of the time it isn't too important as Mac programs are easy to use. Not so with something as complex as a C development system. All the lightspeed manual does is say how great the compiler is, how it is the ultimate environment, how much better it ill make programmers. The library reference is incomplete, and doesn't say little things like which headers & libraries you must include. 2) The editor sucks and you're stuck with it. The editor is so bad it isn't worth mentioning. Little things like a key to go to the end of a line, clear to end of line. When writing code, I need my hands for typing, not to do everything with the mouse. I thought that under Multi-Finder I'd have MicroEmacs 3.8m (a good editor with the mac interface) or some other thing running side-by-side. But this won't work because lightspeed keeps everything in memory. 3) The system is extremely limited by memory constraints. If I wanted to be limited to small code/data segments I'd have saved $3000 dollars and bought a 386 PC. But I want to be able to run Big programs on my Mac 2. I don't want to see Code Segment too large, although this is bearable considering the Mac loader. What isn't acceptable is seeing "Data Segment too Big". 4) The system doesn't really handle Multi-Finder. Under multifinder, I keep getting "Out Of Memory" when I try to compile programs (the program is about 2800 lines long in one file). Big programs won't run either. 5) The system doesn't support the 68881 No gripe here. I knew that I was getting this when I bought it. 6) I'm not sure how robust the compiler is. The compiler seems to choke on some simple syntax things. for example: unsigned Book[][50]; doesn't work or extern unsigned Book[][50]; Book = (void *) malloc(...) gives a bizzare error 7) The error messages are useless. The compiler stops on the first error. It gives this obnoxious box to click in. The messages aren't too useful. It doesn't show you exactly where the error is. Admittedly, I don't know the alternatives. I'm used to working on the PC, but comparing lightspeed to TurboC (turboC costs half as much), we're not talking the same league in product quality. Also, what I've been trying to do is to take a UNIX/MSDOS program (GnuChess) and get it to run on the Macintosh. This is probably not what lightspeed was meant for. But GnuChess should be easy compared to the next on I want to try. I don't at all regret making the jump into the 20th century and buying a Mac ][. I do regret wasting the $95 bucks on LightSpeed C. Michael Lee Gleicher (-: If it looks like I'm wandering Duke University (-: around like I'm lost . . . E-Mail: gleicher@cs.duke.edu)(or uucp (-: Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am!
steele@thorin.cs.unc.edu (Oliver Steele) (01/15/88)
gleicher@duke.cs.duke.edu (Michael Gleicher) writes: >I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the >net upgrades), and I must say it is one of the poorest products that I >have seen for a computer. Mr. Gleicher has posted a number of objections that I suspect a few people share. Since some don't matter, and there are work-arounds to some, I've posted rather than mailed my response. >1) The documentation is awful. There isn't a lot of documentation, but there wasn't anything I had trouble with even though I'd never seen anyone use the package before so I don't think there's too little. > In general, I have not seen a well documented > product on the Mac (I'm used to the PC world). Most of the time > it isn't too important as Mac programs are easy to use. Not so > with something as complex as a C development system. What's so complex about a C development system? I've had far more trouble with word processors on the Mac. Assuming you know C, of course, and that's not what the manual for a particular implementation of a language is supposed to teach you. > All the lightspeed manual does is say how great the compiler is, > how it is the ultimate environment, how much better it ill make > programmers. > The library reference is incomplete, and doesn't say little things > like which headers & libraries you must include. The boldface word in parentheses below the function name at the top of the page is the library. If there's an include file, it'll be listed as '#include <foo.h>' before the function declaration. Aside from that, you're right. > >2) The editor sucks and you're stuck with it. > The editor is so bad it isn't worth mentioning. Little things > like a key to go to the end of a line, clear to end of line. You are stuck with it (in fact, that's one of the advantages of LSC as a development system). If you don't like the editor, you really would have been better off buying any other system except perhaps MPW. By the way, option-right-arrow goes to the end of a line, and if you really need keys to clear to EOL, try return;shift-down-arrow;clover-X. However, ... > When writing code, I need my hands for typing, not to do everything > with the mouse. So get QuicKeys or Tempo. This is a point where you don't work well with the Mac user interface, so you need something that fits between you and the user interface, not a set of criticisms about each application. > I thought that under Multi-Finder I'd have MicroEmacs 3.8m (a > good editor with the mac interface) or some other thing running > side-by-side. But this won't work because lightspeed keeps everything > in memory. Run LSC and uEmacs. Edit a file in Emacs, save it, click on its name in the Project window, and press clover-K. If a window pops open in LSC, go to the same place in your Emacs window and close the LSC one. This is still simpler than vi and make on a Sun, and easier to figure out than emacs on a unix machine. >3) The system is extremely limited by memory constraints. > If I wanted to be limited to small code/data segments I'd have > saved $3000 dollars and bought a 386 PC. But I want to be able to > run Big programs on my Mac 2. I don't want to see Code Segment > too large, although this is bearable considering the Mac loader. > What isn't acceptable is seeing "Data Segment too Big". This is a flaw, but it's really hard to write 32K of data. If you just need it for arrays, just malloc or NewPtr() them and your object file will be smaller too. Sure, the compiler should be able to do this for you, but this isn't the major difference between a II and a 386 PC. >4) The system doesn't really handle Multi-Finder. [You mean MF doesn't really handle the system :-] > Under multifinder, I keep getting "Out Of Memory" when I try to > compile programs (the program is about 2800 lines long in one > file). Big programs won't run either. If you have more than a megabyte of memory, give LSC a bigger minimum size. If you don't, most other large programs won't run either and you probably shouldn't be running MF. I don't, so I don't. >5) The system doesn't support the 68881 > No gripe here. I knew that I was getting this when I bought it. > >6) I'm not sure how robust the compiler is. > The compiler seems to choke on some simple syntax things. > for example: > unsigned Book[][50]; doesn't work > or > extern unsigned Book[][50]; > Book = (void *) malloc(...) gives a bizzare error Do you mean unsigned Book[50][]; ? What you've written isn't valid C, and should have given an error on the PC; if it didn't, that's a PC compiler incompability, not an LSC one. >7) The error messages are useless. > The compiler stops on the first error. It gives this obnoxious > box to click in. The messages aren't too useful. It doesn't show you > exactly where the error is. The messages are more useful than cc gets me on Suns/Vaxen, and cc just gives a line too. They're less specific than tcc, so they aren't all they could be. However, they're better than cascading error messages (I can usually only use the first error from compilers that give me several), and porting code is the one area where they're really obnoxious. And if you like the keyboard better, just press 'return' instead of clicking. >Admittedly, I don't know the alternatives. I'm used to working on the PC, >but comparing lightspeed to TurboC (turboC costs half as much), we're not >talking the same league in product quality. > >Also, what I've been trying to do is to take a UNIX/MSDOS program >(GnuChess) and get it to run on the Macintosh. This is probably not >what lightspeed was meant for. It's probably a lot easier if you have the 2.15 stdio library. Earlier ones gave me a lot of problems with things like sscanf(stdin,...); I'm not sure how much better this has gotten. >But GnuChess should be easy compared to the next on I want to try. > >I don't at all regret making the jump into the 20th century and buying a >Mac ][. I do regret wasting the $95 bucks on LightSpeed C. > >Michael Lee Gleicher (-: If it looks like I'm wandering > Duke University (-: around like I'm lost . . . >E-Mail: gleicher@cs.duke.edu)(or uucp (-: >Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am! ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele UNC-CH LING Senior steele@cs.unc.edu Life is a negative-sum game.
steele@thorin.cs.unc.edu (Oliver Steele) (01/15/88)
gleicher@duke.cs.duke.edu (Michael Gleicher) writes: } unsigned Book[][50]; doesn't work } or } extern unsigned Book[][50]; } Book = (void *) malloc(...) gives a bizzare error steele@thorin.UUCP (Some Dyslexic Idiot) writes: >Do you mean unsigned Book[50][]; ? What you've written isn't >valid C, and should have given an error on the PC; if it didn't, that's >a PC compiler incompability, not an LSC one. Of course, Book[50][] is worse. unsigned Book[][50] is valid only as a former parameter or an extern, and works in LSC as such. It isn't valid as a global or local variable declaration, since the compiler can't figure out how much storage to allocate, and doesn't work in these situations. Book1[][50] isn't the same as (*Book4)[50] except as a formal parameter declaration, although both Books can be used the same way in an expression. unsigned Book1[][50]; tells the compiler that Book1 is an array to be allocated in the data segment, but it doesn't tell the compiler how big the array is, so the compiler can't allocate it. unsigned Book2[10][50]; tells the compiler how big the array is, too, but you knew that. extern unsigned Book3[][50]; tells the compiler that Book3 is an array which is defined in another file, so the compiler doesn't have to allocate Book3 when it hits the declaration but it knows what to do with Book3 when it sees it in an expression (plug in a constant reference off of A5, if the data segment is stored in a place relative to A5). Since Book3 acts like a constant here, any attempt to assign to it, such as Book3 = (void *) malloc(...); should "give a bizzare error". unsigned (*Book4)[50]; declares a pointer to an array of unsigned, which can be used in expressions synonymously with Book2 and Book3 just like str0 and str1 in 'char *str0, str1[50]' can be used synonymously, but which can be assigned to, just like str0 but unlike str1. The syntax for assignment is Book4 = (int (*)[50]) malloc(...); of course :-). And then you can say stuff like Book4[10][20] = 1234, just as if Book4 were a real array. ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele UNC-CH LING Senior steele@cs.unc.edu Life is a negative-sum game.
dorner@uxc.cso.uiuc.edu (01/15/88)
>I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the >net upgrades), and I must say it is one of the poorest products that I >have seen for a computer. Them's fightin' words, partner :-). Seriously, I think Lightspeed C is a super product--just not for you. I'm sure you would be much happier with MPW, as it can be used much more like an MS-DOS or Unix programming environment. >Michael Lee Gleicher (-: If it looks like I'm wandering > Duke University (-: around like I'm lost . . . >E-Mail: gleicher@cs.duke.edu)(or uucp (-: >Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am! ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: ihnp4!uiucuxc!dorner IfUMust: (217) 333-3339
holland@mips.csc.ti.com (Fred Hollander) (01/16/88)
In article <696@thorin.cs.unc.edu> steele@thorin.UUCP (Oliver Steele) writes: >gleicher@duke.cs.duke.edu (Michael Gleicher) writes: >> The editor is so bad it isn't worth mentioning. Little things >> like a key to go to the end of a line, clear to end of line. > >You are stuck with it (in fact, that's one of the advantages of LSC >as a development system). If you don't like the editor, you really >would have been better off buying any other system except perhaps MPW. Please elaborate on your gripes with MPW. I was considering this and would like to know about any problems or deficiencies that you are aware of. Thanks, Fred Hollander Computer Science Center Texas Instruments, Inc. The above statements are my own and not representative of Texas Instruments.
tedj@hpcilzb.HP.COM (Ted Johnson) (01/16/88)
I *LIKE* LSC a lot, but I can empathize (sp?) with your complaints. >[complaints about documentation, and how much better it is for IBM PC products] Learning to program the Mac is a mega-huge bootstrapping process. It reminded me of my first year at MIT. :-) The version of that manual I have says that they assume you ALREADY KNOW: (1) how to write in C, and (2) how to program the Mac Toolbox. The best book on how to use the ToolBox with C that I have ever seen is "Programming the Mac ToolBox with C", written by 3 guys from BMUG. Unfortunately, it is out of print. It also uses another C compiler (==> slightly different syntax), but this wasn't a major problem. I also found it EXTREMELY helpful to order a dozen or so back issues of MacTutor from a year or so ago. There were lots of examples of how to program with LSC. >[Complaints about the editor] I *LIKE* the editor because it is blindingly fast with huge files. I use it almost daily when I have to edit the header statements out of downloaded BinHex files. Beats using MacWrite by several orders of magnitude. Some more command key equivalents for cursor control would be nice though. My main complaint about LSC is its lack of a symbolic debugger, and the bugs with the stdio routines (which are used if you want to port a Unix command line interface program to your Mac). -Ted ----------------------------------------------------- Ted C. Johnson Hewlett-Packard Design Technology Center
olson@endor.harvard.edu (Eric K. Olson) (01/16/88)
In a recent article Michael Gleicher writes: >I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the >net upgrades), and I must say it is one of the poorest products that I >have seen for a computer. > >1) The documentation is awful. [...] I didn't notice, but then again, I didn't read it. >2) The editor sucks and you're stuck with it. > The editor is so bad it isn't worth mentioning. Little things > like a key to go to the end of a line, clear to end of line. Top, bottom of file: option-uparrow, option-downarrow Left, right of line: option-leftarrow, option-rightarrow To make any of the above "select from cursor to {top,bottom,left,right}" hold down the shift key also. To do "delete from cursor to {top,bottom,left,right}" do option-shift-arrow followed by delete. By extension: Find from cursor is Cmd-F, find from top of file is option-uparrow Cmd-F. If you start in the middle and can't find your string, hit option-uparrow Cmd-A to wrap the search to the top (and all the way to the bottom again). > I thought that under Multi-Finder I'd have MicroEmacs 3.8m (a > good editor with the mac interface) or some other thing running > side-by-side. But this won't work because lightspeed keeps everything > in memory. True. If you don't like LSC's editor, you have no real alternatives. >3) The system is extremely limited by memory constraints. > If I wanted to be limited to small code/data segments I'd have > saved $3000 dollars and bought a 386 PC. But I want to be able to > run Big programs on my Mac 2. I don't want to see Code Segment > too large, although this is bearable considering the Mac loader. > What isn't acceptable is seeing "Data Segment too Big". I like to use dynamic memory allocation in the spirit of the Macintosh. (I'd like to use Handles all the time, but I'm too lazy). I realize that this is a difficult concept for people used to virtual memory, but it makes sense in a non-VM environment. Try: char c[] = NewPtr(32000*sizeof(char)); instead of char c[32000] as suggested in a recent posting. I believe this limitation exists in most development environments for the Macintosh. Last time I used MPW C it had the same problem; this may have been fixed. If it is fixed, it's probably just by doing the above for you. You certainly don't want 32K of uninitialized data in your Application file! >4) The system doesn't really handle Multi-Finder. > Under multifinder, I keep getting "Out Of Memory" when I try to > compile programs (the program is about 2800 lines long in one > file). Big programs won't run either. Increase the partition of LSC by doing a Get Info in the Finder while LSC is not running. You can also increase the partition of the Project when run from LSC by putting a SIZE resource in the _Project_ file (not the Project.rsrc file). SIZE -1 is the default setting, SIZE 0 is the setting in the Get Info Box. I'm not sure which LSC uses, you might as well set both. These have to be put in using ResEdit (which has a template for SIZE resources), the Finder will only do applications. You should also put SIZE resources in your Project.rsrc file. These will be used only when you actually build the application into a file. >7) The error messages are useless. > The compiler stops on the first error. It gives this obnoxious > box to click in. The messages aren't too useful. It doesn't show you > exactly where the error is. It shows you the beginning of the logical line in which the error was flagged. It can be confusing if the problem is a missing ; or mismatched {}. I wish the error box would go away with a click anywhere, but have gotten used to hitting return (which makes the box go away) after hearing the beep because I moused outside of the error box. Then the mouse is still in position, and I just click it again. >Also, what I've been trying to do is to take a UNIX/MSDOS program >(GnuChess) and get it to run on the Macintosh. This is probably not >what lightspeed was meant for. Porting code for the PC or Unix is difficult because of the one-dimensional nature of unix (and the PC). They expect to communicate to the user with a stream of characters, and get data via a stream of characters. The Mac, on the other hand, communicates via a two-dimensional drawing, and gets most of its input via a two-dimensional pointing device. I've noticed that programs that try to use a character-oriented window running a character-oriented i/o scheme on the Mac are not accepted by the user community. Witness the AdvSys package and the anagram generator (Ars Magna), which I've never seen anyone else use [notable exceptions: Describe, because it was so useful and brief, and MPW, because it is so nicely done, and not overly one-dimensional]. It sounds like you should be using MPW (which even has a GreenHill C compiler), or A/UX if you want to run Unix. LSC is (in my opinion) ideal for programming Macintosh software. I never use the C libraries (I use Macintosh calls and C syntax essentially), cetainly not the Unix simulation libraries. I use P-strings exclusively, and have written my own string library. This is a very powerful environment, and since I can use ResEdit at the same time under MultiFinder, I use resources extensively with vitually no pain. -Eric (defun maybe (x) (maybe (not x))) Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
clubmac@runx.ips.oz (Macintosh Users Group) (01/17/88)
In article <10928@duke.cs.duke.edu> gleicher@duke.cs.duke.edu (Michael Gleicher) writes: >I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the >net upgrades), and I must say it is one of the poorest products that I >have seen for a computer. > You're in a VERY small minority, because EVERY person I've shown it to, all experienced programmers, have been very impressed with it's ease of use. The project concept in LSC is very nice to work with. Also, people like Aldus and Adobe obviously found LSC suitable - PageMaker and Illustrator are both written in LSC. >1) The documentation is awful. In general, I have not seen a well documented > product on the Mac (I'm used to the PC world). Most of the time > it isn't too important as Mac programs are easy to use. Not so > with something as complex as a C development system. > All the lightspeed manual does is say how great the compiler is, > how it is the ultimate environment, how much better it ill make > programmers. > The library reference is incomplete, and doesn't say little things > like which headers & libraries you must include. > I find the documentation more than adequate, I only look up library manual entries. Something as complex as a C development system? Is a C development system supposed to be so lacking of user-friendliness that we need 700 page manuals? You're the first person I've seen on the net who has found the documentation insufficient. However, since your used to the PC world, you expect huge manuals. As for the library reference, the non-MacTraps library references all indicate the headers needed. But do you REALLY need to have the same thing for the Mac Toolbox stuff? Don't you read Inside Mac? >2) The editor sucks and you're stuck with it. > The editor is so bad it isn't worth mentioning. Little things > like a key to go to the end of a line, clear to end of line. > When writing code, I need my hands for typing, not to do everything > with the mouse. Oh! We mustn't use the mouse (oh yeah, I mean pointing device..:-)) for things must we? Yeah, I guess one could use the arrow keys more. I think CAPPS offers this, so I would expect to see some key shortcuts in LSC 3.0. > I thought that under Multi-Finder I'd have MicroEmacs 3.8m (a > good editor with the mac interface) or some other thing running > side-by-side. But this won't work because lightspeed keeps everything > in memory. > MicroEmacs is a good editor with some semblance of a (not THE) Mac interface. >3) The system is extremely limited by memory constraints. > If I wanted to be limited to small code/data segments I'd have > saved $3000 dollars and bought a 386 PC. But I want to be able to > run Big programs on my Mac 2. I don't want to see Code Segment > too large, although this is bearable considering the Mac loader. > What isn't acceptable is seeing "Data Segment too Big". > You complain about the documentation, but the above paragraph indicates that didn't read Chapter 5 thoroughly. Look at page 5-3, which shows you how to segment your project. The above paragraph also is damning evidence that you haven't got stuck into reading Inside Macintosh. You are limited to 32K Code segments, but any dev. system will allow you to create LOTS of CODE segments. It's quite easy to get around the 32K Data segment limit by allocating your own blocks of memory for large structures/arrays. >4) The system doesn't really handle Multi-Finder. > Under multifinder, I keep getting "Out Of Memory" when I try to > compile programs (the program is about 2800 lines long in one > file). Big programs won't run either. > Now this one is a REAL GEM! It's been a long time since I have read something that has had me fall off my chair and send me into fits of laughter.. LSC doesn't 'handle' Multi-Finder? The SIZE resource shows 512K as a partition size, which I find too small. Christ, you can't do much with MF on a 1 meg Macintosh. Mind you, on a 2-meg Mac, I allocate 784K for LSC and it works like a charm. I also find a cache of 192-256K worthwhile for all the header files - speeds things up. >5) The system doesn't support the 68881 > No gripe here. I knew that I was getting this when I bought it. > If it wasn't a gripe, what was it? 68881 support is RSN. >6) I'm not sure how robust the compiler is. > The compiler seems to choke on some simple syntax things. > for example: > unsigned Book[][50]; doesn't work > or > extern unsigned Book[][50]; > Book = (void *) malloc(...) gives a bizzare error > Read Appendix D. >7) The error messages are useless. > The compiler stops on the first error. It gives this obnoxious > box to click in. The messages aren't too useful. It doesn't show you > exactly where the error is. > Yeah, let's go back to listing 20,000 errors at one go, with 99% of them relating to the first error! Lightspeed is so fast, one error at a time isn't a problem (at least when you have a HD, and some memory (1 meg is OK). The 'obnoxious' dialog box doesn't need to be clicked in - try enter or return. >Admittedly, I don't know the alternatives. I'm used to working on the PC, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SAY NO MORE! SAY NO MORE! :-) > >Also, what I've been trying to do is to take a UNIX/MSDOS program >(GnuChess) and get it to run on the Macintosh. This is probably not >what lightspeed was meant for. >But GnuChess should be easy compared to the next on I want to try. > Well, both rogue and hack were ported using LSC - maybe if you read the manual... >I don't at all regret making the jump into the 20th century and buying a >Mac ][. I do regret wasting the $95 bucks on LightSpeed C. Good on you for buying a Mac II, and buy MPW C - you'll be right at home :-) > >Michael Lee Gleicher (-: If it looks like I'm wandering > Duke University (-: around like I'm lost . . . >E-Mail: gleicher@cs.duke.edu)(or uucp (-: >Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Never a truer word written! :-) Jason Haines Club Mac Macintosh Users Group, Sydney, Australia Phone Home: +61-2-73-4444 Snail: Box 213, Holme Building, Sydney University, NSW, 2006, Australia ACSnet: clubmac@runx.ips.oz ARPA: clubmac%runx.ips.oz@uunet.uu.net UUCP:{enea,hplabs,mcvax,prlb2,uunet,ubc-vision,ukc}!munnari!runx.ips.oz!clubmac
rs4u+@andrew.cmu.edu.UUCP (01/17/88)
This is in response to your varied and miscellaneous gripes about LightspeedC. Before I begin responding to your specific complaints, first allow me to say that I am a user of LightspeedC (and to a much greater extent its sister product Lightspeed Pascal). It is not a perfect application. It comes damn close, but it's not perfect. But I have *never* seen a perfect application, on *any* computer. You say that it "is one of the poorest products [you] have ever seen for a computer." But by comparison to what? The least you can do is tell us what you're used to. Or what you've found to be better. One caveat: A main reason that I am defending LightspeedC is because I like the program. It is a fact (know my most of the readers of this news group) that I worked for THINK Technologies (the producers of LightspeedC). But I am answering this message as a satisfied owner and user of LightspeedC. Whether the reader believes this or not is of little consequence to me. I simply am relating the facts as they are. Now, in response to your numbered points: 1a) "The documentation is awful." The function of a program's documentation is to tell you how to use the program. For a programming environment, you need to know the basics: how to use the editor, how to use the compiler, how to use the linker, and so forth. I've been a user of LightspeedC since I first took up the C language, and I found the manual well geared towards someone who didn't know how to use the package. The manual does assume a certain basic amount of Macintosh knowledge, and a certain amount of C knowledge, but this is stated in the manual's introduction. Also, it's worth noting that Macintosh documentation is more sparse than PC (or other) documentation, because there's less to learn. An important part of using any programming language system is knowing the language you're trying to program in. 1b) "The library reference is incomplete, and doesn't say little things like which headers & libraries you must include." Horsefeathers. Chapter 13 of the User's Guide gives (on each page) a library function, along with a prototype of the function's declaration, and #include directives for the necessary include files.
rs4u+@andrew.cmu.edu.UUCP (01/17/88)
This is in response to your varied and miscellaneous gripes about LightspeedC.
Before I begin responding to your specific complaints, first allow me to say
that I am a user of LightspeedC (and to a much greater extent its sister
product Lightspeed Pascal). It is not a perfect application. It comes damn
close, but it's not perfect. But I have *never* seen a perfect application, on
*any* computer.
You say that it "is one of the poorest products [you] have ever seen for a
computer." But by comparison to what? The least you can do is tell us what
you're used to. Or what you've found to be better.
One caveat: A main reason that I am defending LightspeedC is because I like
the program. It is a fact (know my most of the readers of this news group)
that I worked for THINK Technologies (the producers of LightspeedC). But I am
answering this message as a satisfied owner and user of LightspeedC. Whether
the reader believes this or not is of little consequence to me. I simply am
relating the facts as they are.
Now, in response to your numbered points:
1a) "The documentation is awful."
The function of a program's documentation is to tell you how to use the
program. For a programming environment, you need to know the basics: how to
use the editor, how to use the compiler, how to use the linker, and so forth.
I've been a user of LightspeedC since I first took up the C language, and I
found the manual well geared towards someone who didn't know how to use the
package. The manual does assume a certain basic amount of Macintosh knowledge,
and a certain amount of C knowledge, but this is stated in the manual's
introduction.
Also, it's worth noting that Macintosh documentation is more sparse than PC
(or other) documentation, because there's less to learn.
An important part of using any programming language system is knowing the
language you're trying to program in.
1b) "The library reference is incomplete, and doesn't say little things like
which headers & libraries you must include."
Horsefeathers. Chapter 13 of the User's Guide gives (on each page) a library
function, along with a prototype of the function's declaration, and #include
directives for the necessary include files.
2) "The editor sucks and you're stuck with it."
I may be just a poor stupid Macintosh user, but I've found the editor to be
completely serviceable. There's no limit to the size of a source file I can
edit, and the editor is uniformly fast no matter huge the source file is. I
have used the editor to massage a 350K BinHex file, with no problems. The
search/replace is fast and reliable, and has pattern-matching and multi-file
search if I want to use it. I can also use the Option, Shift, and Command keys
if I want to pull tricks with long-distance selections and position jumps.
2a) "The editor is so bad it isn't worth mentioning."
It's no worse than any other Macintosh-based text editor. "Good" or "Bad" is
a matter of personal taste, at any rate.
3) "The system is extremely limited by memory constraints."
At best, this is wrong. You can run programs of unlimited size on your
computer, be it Mac 128K, 512K, Plus, SE, or II. The segmentation is easy and
painless. It is true that the Macintosh imposes a global-space limitation of
32K, but this is due to the A5-relative referencing of globals. To work around
the limit, use pointers instead of large static arrays. This and other methods
of getting around the limit have been discussed time and time again in this
newsgroup.
The 32K limitation can't be so awful -- many popular (and large!) programs
have been written using LightspeedC; for example, Aldus PageMaker, Adobe
Illustrator, Quark XPress, and LightspeedC itself.
4) "The system doesn't really handle Multi-Finder."
It doesn't? If you get an "Out of Memory" message, the next step is to see
how to increase the memory available to LightspeedC. If you only have one
megabyte of memory, you're screwed, but the LightspeedC update notes for 2.13
do note that you'll need two megabytes to run all but the smallest programs.
You can increase the allocation by choosing "Get Info" in the Finder, and
bumping up LightspeedC's application memory size to a larger size, if you can
afford the space. On a two-megabyte machine I use either 640 or 768K,
depending on what else I want to have resident.
5) "The system doesn't support the 68881."
This will change.
6) "I'm not sure how robust the compiler is."
I'm not a C expert, so I can't comment on your specific example. But I will
say this: in every case I've seen where the compiler has flagged an error, and
there's been doubt as to the robustness of the compiler, the compiler has been
right, and I've been wrong.
7) "The error messages are useless."
They're error messages. They give a description of the error. What else can
you ask for? I've always found them to be helpful. Maybe a bit terse at times,
but if I get confused, there's an appendix in the manual that gives a listing
or each message, followed by a fairly detailed description of the possible
causes of that error. I've never been misled by a LightspeedC error message.
7a) "The compiler stops on the first error."
I much prefer this to a cascade of error messages. I've hated cascades since
the day a Unix C compiler gave me 140 messages, all stemming from the fact
that I'd misspelled the name of a global and used the correctly spelled name
in the references to it. All I need is the first error message to clue me in
to the problem.
7b) "It gives this obnoxious box to click in."
What's the alternative? Insert the messages into the source file? Write the
messages into a separate file? The first clutters my source file, the second
takes longer to deal with than simply reading the message, then pressing
"Return" or "Enter" to dismiss the box.
7c) "The messages aren't too useful."
You already said this.
7d) "It doesn't show you exactly where the error is."
The cursor gets placed at the beginning of the offending line, and between
the error message, the cursor placement, the source context, and a little
parenthesis-matching, I have no problem finding the error.
I do not expect the C compiler to bottle-feed me. C doesn't work that way.
"Admittedly, I don't know the alternatives."
You should try them. After you have tried them, you may find that LightspeedC
is infinitely easier and quicker to work with.
"Also, what I've been trying to do is to take a UNIX/MSDOS program (GnuChess)
and get it to run on the Macintosh. This is probably not what lightspeed was
meant for. "
This is correct. LightspeedC is not a Unix C compiler that happens to be
running on the Macintosh; it is a C compiler that's useful for writing
Macintosh applications, drivers, and desk accessories in C. The Unix libraries
are there, but they're simplistic, and shouldn't be used for writing
Unix-style applications to run on the Macintosh. The Macintosh isn't a Unix
machine, and no amount of library support is going to make it one.
"I don't at all regret making the jump into the 20th century and buying a
Mac ][. I do regret wasting the $95 bucks on LightSpeed C."
As a Macintosh enthusast I admire your choice of computer. As an enthusiastic
Lightspeed Pascal and LightspeedC user, I admire your choice of language
environment. As I said previously, after trying the alternatives, you may find
LightspeedC to be your C compiler of choice on the Macintosh.
"Michael Lee Gleicher"
"Duke University"
--Rich
===================================================================
Richard Siegel
THINK Technologies, QA Technician (on leave)
Carnegie-Mellon University, Confused Physics Major
Arpa: rs4u@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u
==================================================================olson@endor.harvard.edu (Eric K. Olson) (01/17/88)
In a recent article Fred Hollander writes [not responding to me]: >Please elaborate on your gripes with MPW. I was considering this and >would like to know about any problems or deficiencies that you are aware >of. The last time I used MPW C it translated strings in Trap Calls silently from C to Pascal and back. I couldn't deal with that at all. Does it still do this, or has that been made optional? -Eric (defun maybe (x) (maybe (not x))) Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
hallett@hamlet.steinmetz (Jeff A. Hallett) (01/20/88)
In article <10928@duke.cs.duke.edu> gleicher@duke.cs.duke.edu (Michael Gleicher) writes: >I recently purchased LightSpeed C (2.11, upgraded to 2.15 from over the >net upgrades), and I must say it is one of the poorest products that I >have seen for a computer. >> >2) The editor sucks and you're stuck with it. > The editor is so bad it isn't worth mentioning. Little things > like a key to go to the end of a line, clear to end of line. > When writing code, I need my hands for typing, not to do everything > with the mouse. Granted, this is a limitation. I've never tried it, but I would think that importing a TEXT file would be standard. > >3) The system is extremely limited by memory constraints. > If I wanted to be limited to small code/data segments I'd have > saved $3000 dollars and bought a 386 PC. But I want to be able to > run Big programs on my Mac 2. I don't want to see Code Segment > too large, although this is bearable considering the Mac loader. > What isn't acceptable is seeing "Data Segment too Big". > I guess this is/was a limitation of the Mac itself for a while. To the best of my knowledge, it has been removed, so LSC should remove it as well in the next real release. >4) The system doesn't really handle Multi-Finder. > Under multifinder, I keep getting "Out Of Memory" when I try to > compile programs (the program is about 2800 lines long in one > file). Big programs won't run either. Not surprising considering the amount of overhead involved. You should get more memory for your machine. Again, I don't feel that this is LSC's fault; considering all that it does, it will need lots of memory. Remember, it compiles really quickly. > >6) I'm not sure how robust the compiler is. > The compiler seems to choke on some simple syntax things. > for example: > unsigned Book[][50]; doesn't work > or > extern unsigned Book[][50]; > Book = (void *) malloc(...) gives a bizzare error This isn't a problem considering the extremely non-standard C you are using here. First off, when you declare an array, you must define the subscripts in order. My Sun C compiler gives at least a warning on the extern one and an error on the first one. Also, the statement (void *)malloc(...) is also completely wrong. Why would you want to declare space and return a pointer to nothing? If you want a variable array, you should use: unsigned **Book; Book = (unsigned **)malloc(...); > BTW, it is a great idea to port GnuChess to the Mac. It will be a really neato achievment. The best of luck to you. Jeffrey A. Hallett | ARPA: hallett@ge-crd.arpa Software Technology Program | UUCP: desdemona!hallett@steinmetz.uucp GE Corporate Research and Development | (518) 387-5654 +--------------------------------------+--------------------------------------+ | Credo Quia Absurdum Est | +-----------------------------------------------------------------------------+
steele@unc.cs.unc.edu (Oliver Steele) (01/21/88)
Subject: Returned mail: User unknown From: Oliver Steele <ames!ucbcad!rutgers.edu!mcnc!dopey!steele> To: mips!holland@rutgers.edu >In article <696@thorin.cs.unc.edu> steele@thorin.UUCP (Oliver Steele) writes: >>gleicher@duke.cs.duke.edu (Michael Gleicher) writes: >>> The editor is so bad it isn't worth mentioning. Little things >>> like a key to go to the end of a line, clear to end of line. >> >>You are stuck with it (in fact, that's one of the advantages of LSC >>as a development system). If you don't like the editor, you really >>would have been better off buying any other system except perhaps MPW. > >Please elaborate on your gripes with MPW. I was considering this and >would like to know about any problems or deficiencies that you are aware >of. It wasn't a categorical gripe; it's just that MPW also has an integrated editor and it's easier to use that editor than another if you're using MPW (MultiFinder will probably change this, but no more than it has changed it for LSC). Since Mr. Gleicher objected to the integration of the editor with LSC, since MPW has an editor that is just as integrated, and since MPW doesn't have even as many cmd-key equivalents as the LSC editor does, I didn't think that he would find it preferrable. I don't really have any gripes with MPW. It's slower than LSC and doesn't do as much for you automatically, but then I don't think it could be better in either respect given that it's a more unix-type environment. When I program on Suns and Vaxen I wish I had LSC on them for C programming, but I wish I had more MPW-style editing in the shell. I couldn't see recommending another C environment besides LSC and MPW, but I think it's just a question of personal taste between the two. ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele@cs.unc.edu "I thought your class was at nine." "It is, but I have to buy the books so I can do the reading." "Oh yeah, I forget your modus operandi."
howard@cpocd2.UUCP (Howard A. Landman) (01/22/88)
In article <4Vw6hny00WAK5w00JJ@andrew.cmu.edu> rs4u+@andrew.cmu.edu (Richard Siegel) writes: >3) "The system is extremely limited by memory constraints." > > At best, this is wrong. You can run programs of unlimited size on your >computer, be it Mac 128K, 512K, Plus, SE, or II. The segmentation is easy and >painless. It is true that the Macintosh imposes a global-space limitation of >32K, but this is due to the A5-relative referencing of globals. To work around >the limit, use pointers instead of large static arrays. This and other methods >of getting around the limit have been discussed time and time again in this >newsgroup. > > The 32K limitation can't be so awful -- many popular (and large!) programs >have been written using LightspeedC; for example, Aldus PageMaker, Adobe >Illustrator, Quark XPress, and LightspeedC itself. I can't agree with this at all. That's like saying that there was nothing wrong with only having 8 KB of memory on a TRS-80, because people could write programs that ran in that space. I have a fairly simple UNIX application that I was hoping to port to the Mac. Unfortunately, the system architecture is such that the program's database is kept in (virtual) memory, in a couple of 2 MB arrays (will need to increase size soon, as that is almost all used). Under a true VM system like UNIX, the program has a working set of about 160 KB - most of the database is not needed at any given instant, so it is automatically paged out to disk. I can easily run the program on a machine with only 1 MB RAM, even though the program virtual image is about 4.5 MB (and growing), and the UNIX kernel (which is locked in core) eats up over 250 KB. Am I wrong in stating that this program simply cannot be made to run in 1 MB on a Mac without major recoding? I like my Mac, but (because of stuff like this) don't plan to program on it until AUX is available on a system I can afford. This isn't LSC's fault, but defending it as perfectly acceptable seems rather misguided. > This is correct. LightspeedC is not a Unix C compiler that happens to be >running on the Macintosh; it is a C compiler that's useful for writing >Macintosh applications, drivers, and desk accessories in C. The Unix libraries >are there, but they're simplistic, and shouldn't be used for writing >Unix-style applications to run on the Macintosh. Thanks for the warning. That's almost enough to make me never consider it. >The Macintosh isn't a Unix >machine, and no amount of library support is going to make it one. Fortunately, Apple thinks otherwise, at least with regard to the Mac II. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET One hand clapping sounds a lot like two hands clapping, only quieter.
edmoy@violet.berkeley.edu (;;;;YF37) (01/23/88)
In article <1072@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >I have a fairly simple UNIX application that I was hoping to port to the Mac. >Unfortunately, the system architecture is such that the program's database is >kept in (virtual) memory, in a couple of 2 MB arrays (will need to increase size >soon, as that is almost all used). Under a true VM system like UNIX, the >program has a working set of about 160 KB - most of the database is not needed >at any given instant, so it is automatically paged out to disk. I can easily >run the program on a machine with only 1 MB RAM, even though the program >virtual image is about 4.5 MB (and growing), and the UNIX kernel (which is >locked in core) eats up over 250 KB. > >Am I wrong in stating that this program simply cannot be made to run in 1 MB >on a Mac without major recoding? I like my Mac, but (because of stuff like >this) don't plan to program on it until AUX is available on a system I can >afford. The only way to do this is to implement your own "virtual memory". I remember having to maintain a program on a 4BSD VAX Unix system (has 32 bit virtual memory) and on a version 7 unix system on a PDP (has only 16 bit virtual memory). I have #ifdef's in many places, depending on whether I could index into the array directly (on the VAX) or whether I had to read a piece of the array from a disk file before indexing (on the PDP). Fun, fun, fun :-) Edward Moy Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy