🚀 go-pugleaf

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   *
*********************************************************************