Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.belwue.de!news.uni-tuebingen.de!studserv!zxmsd01 From: zxmsd01@studserv.zdv.uni-tuebingen.de (Gunther Schadow) Subject: [386BSD] AKCL distribution with source is out now! Message-ID: <zxmsd01.724542361@studserv> Summary: I put AKCL at agate.berkeley.edu Keywords: AKCL Common LISP Kyoto Austin 386BSD Sender: news@softserv.zdv.uni-tuebingen.de (News Operator) Organization: Comp. Center (ZDV) U of Tuebingen, FRG Date: Wed, 16 Dec 1992 21:46:01 GMT Lines: 273 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