Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.sys.atari.st
Subject: Re: Laser C (Megamax 2.0)
Message-ID: <3221@batcomputer.tn.cornell.edu>
Date: 20 Dec 87 16:00:15 GMT
References: <515@usl-pc.UUCP> <854@uop.edu>
Reply-To: braner@tcgould.tn.cornell.edu (braner)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 28
Keywords: Megamax C, Laser C
Summary: sounds feasible

[]

I have just sent away for the Laser C upgrade, and will post when I get it.
But don't worry, Greg.  5 seconds for compile+link of a SMALL program is
certainly feasible WITHOUT tokenizing the source code.  The current Megamax
compiler (not linker) reads a text file off the RAMdisk and compiles it
in about 2 seconds _once_the_compiler_is_launched_.  The recent Megamax
flyer says something about their new (graphical) shell keeping multiple
programs (e.g., editor, compiler and linker) RESIDENT in RAM (not filed
in a RAMdisk), presumably saving a couple of seconds on the launching of each.

- Moshe Braner

PS: For those of you that had problems uudecoding IDLE:
          Remove the 'z' at the end of each line.
       (Sorry for that.  Source was sent to Turner)

PPS (literally): speaking about tokenizing, couldn't the Postscript page-
description language, which is known for its slowness, be substantially
speeded up through tokenizing?  That would also save on the communication
time (length of text sent to the printer) and disk space (if saved as
Postscript).  Printing an (Atari ST mono screen) bitmap on an Apple
Laserwriter (via 9600-baud serial line) takes a couple of minutes, and the
recent Cricket Draw for the Mac saves a typical graph on the disk as a
50-100K file!

PPPS: When, oh when, will we have compiler support for writing GEM metafiles,
      and a GEM-->Postscript translator? (Anybody looking for a project? :-)