From: zxmsd01@studserv.zdv.uni-tuebingen.de (Gunther Schadow)
Subject: [386BSD] AKCL distribution with source is out now!
Summary: I put AKCL at agate.berkeley.edu
Keywords: AKCL Common LISP Kyoto Austin 386BSD
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Date: Wed, 16 Dec 1992 21:46:01 GMT


Hi all,

The time is ripe! We finally have a complete Common LISP for 386BSD:
Austin Kyoto Common LISP (currently based on 1.609). I just put it at
~/pub/incoming/akcl.386bsd.tar.Z:agate.berkeley.edu for the unpatient:
you can fetch it from there (remember it is unlistable directory).
Chris will hopefuly put it into 0.1-ports/lisp.

attached is the README file...

Enjoy!
((((Gunther)))) 

-------------------------------------------------------------------------
			       This is
		       Austin Kyoto Common LISP
				 for
				386BSD

				 +++

	      This software contains, to the best of my
	     knowledge, no proprietary, trade secret, or
	     otherwise encumbered code. I am making this
	  software available for incorporation into 386BSD,
		understanding that 386BSD is a freely
		redistributable and modifiable system.

				 +++

THE FINAL STEP is towards a distribution of Common LISP for 386BSD is
made! After my port of KCL, which didn't support full KCL functionality
(SAVE was missing), a lot of questions came by mail or usenet, whether
I would port AKCL too. Fortunately this work has already been done by
Alan W. Black, at least to quite an extend. It is now several months
that I was announcing the comming AKCL. I was waiting for Alan to
complete his work, however he seems to be too busy to make a
distribution out of it. After I had problems making AKCL, it does
compile completely now.
  This Port provides *full* functionality, including interpreter,
compiler, SAVE and FASLINK facility, of which the latter is said to be
highly unportable --- however it works with 386BSD! Thank's to Alan,
and of course again to Bill & Lynne Jolitz, who made this at all
possible! I'm just happy to bring all the patches in an easy-to-use
format and make it available to the public. I'd like to see LISP grow
on 386BSD!
  And even more! I contacted Taiichi Yuasa and Masami Hagiya, the
authors of KCL whether we may distribute binaries based on their code,
and we got OK from them! So here is the binary included. With the
FASLINK and SAVE facilities it is easy to add new default features, so
that it is not necessary to recompile the whole thing in order to add
few procs. Thanks to Taiichi Yuasa, Masami Hagiya and Bill Schelter
for making a powerful Common LISP available for free!


IMPORTANT NOTICE

As mentioned above, KCL is good stuff, and everyone can have it for
free, but you need a license from SIGLISP to copy KCL.

"(c) Copyright Taiichi Yuasa and Masami Hagiya, 1984.  All rights reserved.  
 Copying of this file is authorized to users who have executed the true and 
 proper "License Agreement for Kyoto Common LISP" with SIGLISP."

You already copied KCL while you read this, and that's OK. according
to the Authors (who are essentially SIGLISP). But please don't forget
to send the LICENSE form, if you are not yet registered to SIGLISP.
Print LICENSE, and send it filled to the address given therein. You
may FAX (#0532-45-0480) it but it needs to be a hard copy, so don't
E-Mail. You want a letter from Japan? Unfortunately they do not reply
with nice stamps :-).


WHAT IT CONTAINS

This archive contains the following stuff:

  LICENSE		the SIGLISP license agreement for KCL
  README		this file
  saved_kcl		the akcl binaries --- do not strip!
  bin/akcl		a script to run saved_kcl correctly
  bin/lc*		scripts to call the LISP compiler
  doc/			various documentation
  lisp/			some lisp code, collected rather randomly
  littleX/*		a rather simple (but small) graphics support for X11
  	./Xdemo.l	to use as a staring point
	./turtle.l  	a little turtle graphics implementation
  xakcl/		complete X11 interface for AKCL (RAM expensive!)
  src/386bsd.tar.Z	the patches to build the system
  src/akcl-1-609.tar.Z	Austin extensions by W. Schelter
  src/kcl.tar.Z		Kyoto Common LISP sources
  src/ftime.tar.Z	The ftime function for compatibility

The version of AKCL herein is 1.609


HOW TO START

1. Place the whole archive in /usr/local/lib/akcl

2. Install shell scripts in bin/ into /usr/local/bin. You can remove
   the bin directory here afterwards. Saved_kcl doesn't go to
   /usr/local/bin!

3. Make a link
 
	# ln /usr/local/bin/akcl /usr/local/bin/lisp

   Emacs wants to call "lisp" with run-lisp.

4. Now Type 

	# lisp 

   if you want to try it. It is useful to run lisp from within Emacs,
   so you can edit the command lines more comfortably. Do this whith
   the Emacs command "M-x run-lisp".

5. If you don't want to remake the system (actually you don't have to)
   you can delete all the *.tar.Z files. Otherwise move them to
   /usr/src/local


X11 SUPPORT

There is a nice little graphics support provided with AKCL. Try 

	>(LOAD "/usr/local/lib/akcl/littleX/Xdemo.l")

Of course you need to have X11 running for that. When you step across
the demo, you will see any provided function at least once. If you
want to see more about it see the file littleXlsp.lsp.
  Xdemo.l is also an example of the FASLINK feature provided with
AKCL. It is possible to dynamically link object code into a running
AKCL session. See Xdemo.l for how it works.
  I also made a simple turtle graphics tool called turtle.l. Turtle
graphics is nice in order to visualize recursive function processing
in an easy way. A logo interpreter would be nice to have too. I love
logo for the purpose of teaching how to program a computer (first
steps ... :-).

XAKCL is another, more complete X11 interface to Xlib and Xutil
libraries. I just had a quick look at it so far, and it seems like my
8MByte RAM are too few to handle X+AKCL+XAKCL all together. An
AKCL+XAKCL memory image is about 3MByte without any opened window.
Since I need to run Emacs for AKCL (command line editing is a must for
me) there is another 1.5MB. So I think there is few sense to run XAKCL
unless you have shared libraries installed (either the early version or
the one coming with 386BSD 0.2).


MAKING THE SYSTEM

Although you normally don't have to do it, the procedure to recompile
the system is simple:

1. Make the directories /usr/src/local/kcl /usr/src/local/akcl

2. Cd to /usr/src/local/kcl and unpack kcl.tar.Z there.

3. Cd to /usr/src/local/akcl and unpack akcl-1-609.tar.Z there.

4. Now remain in /usr/src/local/akcl and unpack 386bsd.tar.Z there.
   This will overwrite some files of the original akcl distribution,
   and will add some new.

5. Type 
	# add-defs 386bsd

   and AKCL will set up for 386bsd.

6. Type
	# make -f Smakefile

   to start the make process of AKCL.

PLEASE NOTE:
Make wants to be always called this way:

	# make -f Smakefile

and not just with "make", because there is a file called "makefile"
created, that is *not* used as the main makefile! Please remember my
words!

When you reach the point where saved_kcl is being built for the first
time the machine may stop with an error on numlib.lsp. Although I
couldn't proof this I bet this error occurs If you have the original
definition of MAX_DBL in /usr/include/float.h. This should be
corrected and the system recompiled. If you do not have an error just
forget about this.
  When you reach the point where saved_kcl was built successfuly for
the first time, Smakefile compiles lsp/*.lsp and cmpnew/*.lsp with
that version of saved_kcl. This will take some time (at least on a
i486/33), and even 8MByte of RAM space may be too few to prevent the
thing from swaping. You may want to kill the any other process runing
on your machine for this time.
  You should end up with a saved_kcl in the unixport directory. This
file is rather big, however do *not* strip it unless you want to lose
the FASLINK facility which needs the symbol table.


LISP WORK GROUP

We have the possibility to build a work group on LISP by the work
groups provided on ref.tfs.com. This is merely a mailing list. If you
are interested contact me.


CONTACT

For comments & complaints, send E-Mail to

	gunther@student.zdv.uni-tuebingen.de

Please note that this address is valid only up to spring 1993, if you
want to go safe use gunther@ref.tfs.com.

Enjoy,
-Gunther


BTW: I DISLIKE COMMON LISP SOMEHOW

Well here's my c0.02 opinion on Common LISP. While I love LISP for
being a functional language, where data and programs are the same
thing (where programs do not even exist they're functions), there is
something about Common LISP I do dislike. Why is the following not a
valid Common LISP term?

((list 'lambda '(x) '(car x)) '(a b c))

It is an invalid function, but in fact

(list 'lambda '(x) '(car x)) eval's to a legal lambda expression

(lambda (x) (car x))

I'm sad that the nice EXPRs, FEXPRs and SUBRs are more and more
obsolete now. Are these facilities given up for compilability
concerns? An other example, I used to define local functions in TLC
LISP on the fly like this:

(de myexp
  ((label local-power 
	(lambda (x y) 
  		(cond ((zerop x) 1)
		      (t (times x (local-power x (minus y 1))))))) 2.7183 x))

Now we have to take two steps to make a label definition and then call
by that label.

(defun myexp
  (labels local-power 
	(lambda (x y) 
  		(cond ((zerop x) 1)
		      (t (times x (local-power x (minus y 1)))))) 
   (local-power 2.7183 x)))

It is the same sense I dislike the let term, because it weakens the
lambda calculus for a gain of little convenience. OK the let term can
be replaced by a lambda term, but the label term cannot. Sigh...

-------------------------------------------------------------------------------
Gunther Schadow,	          e-mail: Gunther@studserv.ZDV.Uni-Tuebingen.DE
Sudetenstrasse 25,	          Phone:  (49) 7071/37527
7400 Tuebingen, Germany.__________Stop__________Horn Please!__________O.K. TATA
--
-------------------------------------------------------------------------------
Gunther Schadow,	          e-mail: Gunther@studserv.ZDV.Uni-Tuebingen.DE
Sudetenstrasse 25,	          Phone:  (49) 7071/37527
7400 Tuebingen, Germany.__________Stop__________Horn Please!__________O.K. TATA
Newsgroups: comp.unix.bsd