🚀 go-pugleaf

[]

The early version of Laser C (1.0) always spun drive A: for a second
but then DID go and load everything from the hard disk (assuming you
set all the paths and tool locations, under the OPTIONS menu, to drive
C:, and then clicked on "SAVE CONFIGURATION".)  The newer release
(1.01, I got it in the mail together with the manual) seems to have
fixed that bug altogether.

There IS a problem with running some TOS programs from inside Laser C's
STDIO window.  I never figured out when it is safe to just type the
program's name, and when you have to precede it with "tos" (giving it
the whole screen but loosing the ability to capture the output in the
STDIO window, which is back-scrollable and cut-and-pasteable).  By
"not safe" I mean that the output rolls off the window.  There is also
a problem with TTP programs.  Some (e.g. my MORE utility) do not get
the command-line arguments correctly.  TTP programs compiled with
Laser C work fine.  MORE was written in AL and it looks in the
base page for the unaltered command line.  I havn't had the time to
figure out what exactly happens when you invoke it from the STDIO window
but it does not get the command line right, probably gets a garbage
filename to print, and ends up with a "TOS error" message.

As for speed: yesterday I timed Laser C (on a 1040 + SH204) doing a complete
recompile of GNOME (190K source code in 13 files, 53K output binary).
It took just over 3 minutes.  Not bad at all, although Turbo C on a rather
fast IBM-AT clone with a much faster HD (but no caching of any sort!) did
it in 90 seconds.

Execution speed?  An optimized C version of the Fast Hartley Transform
(see April BYTE) transformed a 512-point data set on my ST in 1.7 seconds,
everything in double precision software FP.  (1.2 seconds for repeated calls
with the same N, keeping the work arrays in-between!).  Compare that with the
27 seconds quoted in the BYTE article for the Pascal version (on a Macintosh,
i.e. similar CPU power, although it might have used (in)SANE...).

- Moshe Braner
69 Ringwood Rd., Freeville, NY 13068
(607) 347-4573	(Home)
(607) 255-9401	(Work)
<braner@tcgould.tn.cornell.edu>		(ARPANET)
<braner@crnlthry> or <braner@crnlcam>	(BITNET)

PS: GNOME 2.2 is almost ready, and it comes in a DA flavor too.  Should
I post it?  How much memory should the DA hog?  (It must allocate a large
text buffer upon boot since DA's are not supposed to call Malloc() later.
My current setup uses a 90K buffer (the program uses another 50K) and
one can only edit about 50K of text in there due to both malloc- and
data-structure overhead.  The plus is that the text stays in it between
separate openings of the DA.)  Warnings to users of GNOME 2.1: do not
press ^C to try and abort numeric-prefix-entry mode, and do not press
the up or down arrows when choosing a buffer to go to if there is no
other buffer.  (These and other bugs are fixed in 2.2.)  If you know of
any other bugs in GNOME 2.1, _PLEASE_ tell me soon.  Thanks.