Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!dartvax!earleh From: earleh@dartvax.UUCP (Earle R. Horton) Newsgroups: comp.sys.mac Subject: Re: display bug in MacKermit 0.8(xx) Message-ID: <7508@dartvax.UUCP> Date: Wed, 28-Oct-87 13:37:13 EST Article-I.D.: dartvax.7508 Posted: Wed Oct 28 13:37:13 1987 Date-Received: Sat, 31-Oct-87 14:58:43 EST References: <7486@dartvax.UUCP> Organization: disorganized Lines: 58 Keywords: C compiler gripe Summary: Why not use sumacc compiler? In article <7486@dartvax.UUCP>, earleh@dartvax.UUCP (Earle R. Horton) writes: > There is a bug in the display code for MacKermit 0.8(xx) versions, and it's an > obscure one, at that. I have fixed it for 0.8(43A) (where do they get these ... > Aside: I appreciate the effort that went into porting MacKermit to Megamax, > and I think it was definitely a worthwhile thing to do. The source code for > xkmker 0.8(35) no longer will compile under summac, however. The guy who runs the VMS machine at the engineering school here wants a good vt100 emulator for the Mac which he can distribute for reasonable or no cost. So far, he considers MacKermit to be the only acceptable alternative, especially if it can be made to work properly with the editors which he has on the VMS machine. (I am not especially fond of VMS, but I have to admit their editors do a real good job of using the display abilities of a vt100.) I have the latest (?) version of the sources, 0.8(35) from June 1987, but I can't or won't compile them because they are in Megamax. (Apparently, 0.8(35) is a later version than 0.8(43A).) The sources which I have, that I can compile, are in sumacc but are about a year older than the latest version. I would like to incorporate the changes in the new version with my bug fix which allows MacKermit to work with the "Extensible VAX Editor (EVE)". I was toying with the idea of porting it to LightspeedC, until I looked at the header file which now contains preprocessor directions for both sumacc and Megamax. I would like to get something running here in a finite amount of time. ************************************************************************** Excuse me, Mr. C compiler developer, why didn't you all use the same data structure declarations? It's harder to make a Megamax program work with LightspeedC than it is to make a 4.3 BSD program work! ************************************************************************** Can anyone think of a reason why I shouldn't fix up the latest sources so they actually work with sumacc, then apply our local bug fixes and modifications? I haven't heard much about the sumacc compiler lately, but I really like it myself. Aside from some weird idiosyncrasies, it has some very endearing features: You can specify "-O" on the command line, and I'll bet it does something. (Optimizes things.) It uses /lib/cpp, which has predictable behavior. (This point can be argued, but I am used to it.) I can compile the sources IN THE BACKGROUND. None of this fake MultiFinder stuff, my C compiles run as completely detached processes on a VAX running real vmunix. (Apple, are you there yet?) It seems to produce a fairly compact final executable, probably as good as LightspeedC. Perhaps someone would care to enlighten me as to why the sumacc compiler has apparently fallen into disuse. Is it solely the inconvenience of having to download the compiled program (I can live with that) or is there something wrong with it? Cheers. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************