Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!ml27192 From: ml27192@uxa.cso.uiuc.edu (Mark Lanett) Newsgroups: comp.sys.mac.programmer Subject: Re: MPW 3.3 Message-ID: <1991Jun24.190210.15044@ux1.cso.uiuc.edu> Date: 24 Jun 91 19:02:10 GMT References: <1991Jun24.184048.4050@waikato.ac.nz> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 64 ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >In short, with all the work that's being invested in this key binding >feature, I don't think it's likely to disappear all of a sudden. Let >the THINK users* worry about whether you could have an environment that's >too powerful to use; but if you want to be able to explore anywhere, build >anything, without your environment ever holding you back, MPW remains >the ultimate. Gee, just what I want, the ability to program my editor to do what THINK already does correctly. MPW's scripting ability would be a nice addition to a working compiler. The MPW team, however, seems to think that what I want is more features, rather than fewer bugs. It would be nice if I could spend less time working on MPW and more on my program. Some things I would like to see in MPW are: * An integrated linker. It's obscene that THINK's is both faster _and_ uses less memory. * A linker that either works or gives decent messages as to what's wrong. Here a message I just love: ### Link: Error: Module/EntryPoint has previous (conflicting) type: (Error 14) GELAPPLICATION_OPENOLD (5) ### Link: Error: Internal problem (or bad object file): (Error 91) a scope ID (5) referred to a non-scope object It would be asking too much, I suppose, for these numbers to be documented anywhere. Lawrence would probly say that it's great that I have the dumpobj tool so I can examine the output code to see what's gone wrong. I've in fact never used that tool for anything _but_ debugging the compiler and linker. If they worked I wouldn't need it, would I? * For the people working on the linker to talk to those working on the C++ compiler, because CFront quite often fails to generate all the Object Pascal strcture the linker needs. Then when the linker fails you have no clue as to which direction to proceed to solve the problem. What do you do about a "module _CLIVEEDIT missing" error? * For C to generate correct symbolic debugging symbols when I have lots of #include of other code. On of the ways to get decent performance from the C++ compiler is to #include all your .cp files into your one main .cp file, creating one huge compiler. Given the normal C++ overhead this is in fact faster than two little compiles. However, the symbolic info generated will be completely wrong. This problem seems to be caused by using load/dump, another way to try to speed up compiles. load/dump by itself doesn't work well either (it's the cause of the error printed above). I'm not aware of any problems with THINK's Precompiled Headers. When THINK releases a C++ compiler we are dumping MPW. We don't have the time or funds to debug Apple's tools. For the moment we're getting ETO. It's also ridiculous to have to pay to get beta software (we're Partners), but it seems to be the only way to get updates, in the hope that one might solve some problems. >Lawrence D'Oliveiro fone: +64-71-562-889 >Computer Services Dept fax: +64-71-384-066 >University of Waikato electric mail: ldo@waikato.ac.nz >Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 >Any opinions the author has expressed in this posting are sacred to >Epimetheus, the Greek god of hindsight. >*I should point out that I have nothing against THINK users. Some of my >best friends are THINK users. Honest. -- //----------------------------------------------------------------------------- Mark Lanett mlanett@uiuc.edu Software Tools Group, NCSA