Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!midway!ellis.uchicago.edu!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.icon
Subject: Re:  ansi routines
Message-ID: <1991Jun10.211145.23543@midway.uchicago.edu>
Date: 10 Jun 91 21:11:45 GMT
References: <9106101942.AA02715@eos.arc.nasa.gov>
Sender: news@midway.uchicago.edu (NewsMistress)
Distribution: inet
Organization: University of Chicago
Lines: 58

shafto@EOS.ARC.NASA.GOV (Michael Shafto) writes:
>
>Yes, and I would be interested in testing your new improved version.

I wasn't clear enough:  My version is expanded (in the sense that
the ANSI interface can be applied to non-ANSI terminals).  I'm not
sure that it really constitutes an improvement.  Anyway, I haven't
had enough requests to consider posting, so I reiterate the offer
of sending them to anyone who wants to use them.

It's really a good idea to used generalized I/O for any programs
written in Icon, since Icon runs on so many platforms.  These new
ANSI routines have the advantage of working as-is on DOS platforms
with the ansi.sys driver installed.  The escape codes are hard-
coded in.  If, however, you want to run a program written with
them on, say, a UNIX box, the routines are structured so that you
can just link in the Icon termlib-type routines I posted some time
ago here (and which I have copies of I'll gladly pass on; I use
them constantly, and can't seem to stop revising them).  There is
also a library of high-level routines I wrote for use in conjunc-
tion with the termlib-type library.  These can also be linked in
with the revised ANSI screen control library.  The routines in
the revised library sense what it is you've linked in, and make
use of whatever you've made available (if in fact they need any
additional help - which they don't in DOS environments).

The idea is to have a generalized library of screen functions
that DOS users can blindly use, which take up minimal space, are
fairly fast, and which can be augmented for Unix without having
to change a single line of code (and without requiring the user
to have to do worry about setting up any sort of database).  Ad-
mittedly, these routines are a bit more spartan than the iolib
routines I posted a while back.  They are a lot more hassle-free,
though, and they cover pretty much all the basic functions that
people doing visually oriented programs would need.

You know, speaking of screen control, I wrote a set of Icon-based
windowing routines some time ago.  They let you open up virtual
screens, move them around, create borders, overlap them, write to
any screen (aka window), and have the portion showing on the stan-
dard screen be correctly updated (if in fact any was showing).

The reason I didn't post them is quite simple:  Although they were
fast enough for most purposes, they ate up way, way too much mem-
ory.  I implemented the concept of a displayable area with the
Icon equivalent of a 2d array (a list of lists), and then tried
various ways of representing squares in that array (integers, rec-
ords, etc.).  The trouble was that I wanted them to be pointers
to window structures created by the user.  Not having this facility,
I had to use records, which used up just too much space.

It *almost* worked.  :-(  I guess I wish that Icon had some sort
of explicit pointer data type.

-- 

   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer