Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!ucsdhub!hp-sdd!hplabsy!hplabsz!mayer
From: mayer@hplabsz.HPL.HP.COM (Niels Mayer)
Newsgroups: comp.lang.lisp.x
Subject: Re: Xlisp 2.1
Message-ID: <4705@hplabsz.HPL.HP.COM>
Date: 23 Jan 90 06:16:20 GMT
References: <6670@tekgvs.LABS.TEK.COM> <4814@itivax.iti.org> <15658@boulder.Colorado.EDU> <730@visdc.UUCP>
Reply-To: mayer@hplabs.hp.com (Niels Mayer)
Organization: Hewlett-Packard Labs, Software Technology Lab, Palo Alto, CA.
Lines: 103
Summary:
Expires:
Sender:
Followup-To:

In article <730@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes:
>I obtained the winterp distribution from the Uunet archives,
>uunet!~/X/contrib/winterp.tar.Z, and dug out the xlisp material.  The
>file is 605837 bytes long, and xlisp is only a small part of it.  The
>winterp documentation looks to be of considerable value, even if you
>can't use the rest of winterp.  The winterp package is neat.

Thanks! Try it, you'll like it.... The Motif interface really makes XLISP
fun.

> There is
>lots of good object-oriented xlisp code; but you need GNU emacs, Motif,
>and X to make use of winterp.

Actually, WINTERP does not require GNUEMACS, but does need you to have the
Motif toolkit, Xwindows, and Unix. The WINTERP distribution contains an
emacs-lisp interface to gnuemacs which allows you to send the lisp
expression currently being edited to winterp's serverized lisp listener
without having to exit the editor. You are free to use any editor you want
with WINTERP, it's just that the gnuemacs interface is much easier to use.

(BTW, A while ago, I posted a emacs-lisp file called xlisp-mode.el that
modifies gnuemacs' "inferior-lisp" features in order to run XLISP as a
gnuemacs subprocessess ... this gives the same interface to raw XLISP as
you'd get through winterp's gnuemacs interface.)

>Lots of Unix stuff that didn't work before has been fixed.  The system
>command, for example, works fine now.  They have also added support for
>running xlisp from a pipe as part of the emacs interface.

Actually, I added a few primitives to XLISP for use with WINTERP. Since
they're also useful for raw XLISP, I didn't #ifdef them out of the code.
In file unixstuff.c, you'll find interfaces to popen(3s), pclose(3s),
system(3s), as well as the following kludgy interfaces to fscanf(3s):
FSCANF-FIXNUM, FSCANF-STRING, FSCANF-FLONUM.

The POPEN interface is especially useful, since it'll let you talk to
any other unix process and get that output back as if it were a file
stream:
        (defun ls (dirname) ;returns a list of filenames matching <dirname>
          (do* 
           ((fp (popen (strcat "/bin/ls -1 -r " dirname) :direction :input))
            (line (read-line fp) (read-line fp))
            (result (list line) (cons line result))
            )
           ((null line)
            (pclose fp)
            (cdr result))))

I also added some primitives to speed up certain ARRAY operations that I
need to use alot: COPY-ARRAY, ARRAY-INSERT-POS, ARRAY-DELETE-POS.

>There is a new Copyright notice that seems to say
>that you can use xlisp for commercial uses so long as you include the
>copyright notice.

The MIT X Consortium insists that all contributed software in X11r4 have no
copyright restrictions. In particular, they wouldn't allow David Betz's
"for noncommercial use only... all rights reserved" copyright. So I begged
and pleaded with Betz. Betz was extremely kind & reasonable -- he let me
change the copyright status for XLISP as included in the X11 release of
WINTERP. Betz also mentioned something about removing those restrictions
from future copies of XLISP as well.

>The makefile is now a HP-UX thing that I couldn't use.  The program
>is still easy to compile, however; and the System V defaults, ie
>cc -O -s -o xlisp *.c with no makefile, would probably work fine.
>All the msdos, Mac, and Atari stuff is gone; there are only Unix
>headers.

Sorry... I didn't really have time to spiff up the xlisp-only compilation
for my winterp release. Rule "lisp:" in
winterp/src-server/xlisp/Makefile.hpux should work for any unix
installation. Your make was complaining about the mkmf-generated dependency
information that is in that file. All you need to do is remove that
dependency information, either by editing, by rerunning 'mkmf', or by using
'makedepend'. (I believe 'mkmf' is a SYSVism, and 'makedepend' is available
on the X11r4 distribution in directory mit/utils...)

>The program runs pretty much the same.  There were only a few bytes
>less (room) when I fired it up.  Subjectively it didn't seem to have
>any less pep.

There shouldn't be any speed differences in executing XLISP2.1. 2.0 --> 2.1
only added the C-implemented defstruct primitives, fixed a few bugs (esp,
that nasty one in FORMAT), and added a few math functs:
{	"DEFSTRUCT",			F, xdefstruct		}, /* 285 */
{	"%STRUCT-TYPE-P",		S, xstrtypep		}, /* 286 */
{	"%MAKE-STRUCT",			S, xmkstruct		}, /* 287 */
{	"%COPY-STRUCT",			S, xcpystruct		}, /* 288 */
{	"%STRUCT-REF",			S, xstrref		}, /* 289 */
{	"%STRUCT-SET",			S, xstrset		}, /* 290 */
{	"ASIN",				S, xasin		}, /* 291 */
{	"ACOS",				S, xacos		}, /* 292 */
{	"ATAN",				S, xatan		}, /* 293 */


-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *