From owner-freebsd-hackers Sun Apr 2 07:11:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA15343 for hackers-outgoing; Sun, 2 Apr 1995 07:11:17 -0700 Received: from snoopy.mv.com (snoopy.mv.com [199.125.64.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA15324 for ; Sun, 2 Apr 1995 07:11:13 -0700 Received: (from pw@localhost) by snoopy.mv.com (8.6.9/8.6.6) id KAA00621; Sun, 2 Apr 1995 10:08:45 -0400 Date: Sun, 2 Apr 1995 10:08:45 -0400 From: "Paul F. Werkowski" Message-Id: <199504021408.KAA00621@snoopy.mv.com> To: spaz@u.washington.edu Cc: hackers@FreeBSD.org In-reply-to: (message from John Utz on Sat, 1 Apr 1995 19:11:49 -0800 (PST)) Subject: Re: CLISP clarification, Was: New Snapshot...Good and Bad.... Sender: hackers-owner@FreeBSD.org Precedence: bulk >>>>> "John" == John Utz writes: John> Hokay; Allow me to clear up all of this confusion that i John> started... <...> John> @ncftp>more ANNOUNCE @This is CLISP, a Common Lisp John> implementation. John> @ CLISP is mostly CLtL1 compliant, with some CLtL2 John> additions, including a @ CLOS subset. Many features of CLtL2 John> or dpANS CL are currently not @ supported. John> @ The newest versions will always be available via anonymous John> ftp from @ ma2s2.mathematik.uni-karlsruhe.de [129.13.115.2], John> directory @ /pub/lisp/clisp/. @ Another ftp site carrying John> CLISP is @ ftp.cs.cmu.edu [128.2.206.173], directory John> user/ai/lang/lisp/impl/clisp/. ^^^^^^^^^^^^ Given the John> thread of this conversation I think this mirror is kind of John> significant. It would seem to me that if cmu wants to mirror John> this particular implementation that would indicate that they John> felt that it was a reasonable job that implements some John> significant feature not found in there original. Actually, The CMU site is a repository for lots of AI stuff, practically anything that ever made it out of the labs, I think. John> I would be willing to bet that significant feature is John> SIZE!!! John> @ Our Common Lisp CLISP @ * needs only 1.5 MB of memory John> ^^^^^^^^^^^^^^^^ Hmm, that beats GCL which starts life at 2.4 MB. Seems like it used to be smaller than that. Anyhow bear in mind that Lisp grows like a wart once it has to actually do anything. John> Did i read in someone else's posting that CMU CLISP John> wants 16M?!!! Anybodys Lisp wants lots of memory. GCL starts at 2.4 MB with basic features. Add CLOS, LOOP, Conditions, etc to get some of the CLtL2 functionality and it gets to 6.3 MB real quick. Toss in CLX for X support and we are pushing 8MB. Add in some application code, maybe a blackboard or rules system and we start to exceed the VM limits on a 16 MB box. From my experience, 16MB should be considered a minimal system for running Lisp. 32MB is pretty nice. I saw one post where a guy was running 192MB and was pretty happy. John> @ * implements 99% of the CLtL1 standard, as well as some John> extensions @ * can call your preferred editor @ * is freely John> distributable John> @ Get it via anonymous ftp from John> ma2s2.mathematik.uni-karlsruhe.de @ [129.13.115.2], @ John> directory /pub/lisp/clisp/, or contact @ Bruno Haible John> . John> If you are not hot and sweaty about getting the exact John> particular package then i would seriously look at this. It John> made right the heck up on 2.0R ( excepting __const char John> *__const sys_errlist, of course ). It might be an improvment John> to *have* this as opposed to *wondering* about the John> portability of the full on CMU version. Yeh, I might just check it out and see how it compares to GCL. The neat feature of CMU Lisp is that it is close to the new ANSI spec and has a native mode compiler rather than having to go the Lisp-to-C route. The bad news is that the i386 instruction set is not one of alpha, Sparc or SGI. Also, it turns out that there is assembly language hooks to the kernel for each implementation and one needs an operational CMU-Lisp just to build the .h file for the underlying C code. Looks like a challenge. John> As i said originally, it flops on the current snap. It John> compiles fine but seems to run out of room on my 8 meg 386 John> during the bytecompile stage ( this is a total wag , i infer John> this because the lisp environment gets created from the c John> code, executes, goes to work on a mess of *.lsp and dies in John> one called clos.lsp, but what i don't know about lisp defies Ah, but once you get to know it - you will either love it or hate it. Close to the being the worlds oldest computer language and one considered by many to be the worlds greatest systems programming language of all time! John> One of our vm gurus, i think it was DG but it might John> have been Bruce, mentioned something about needing snapshots John> to test out the current state of the vm code..so i would John> think that this might be an elliptic reference to the grief John> i was having. Building Lisp on a small box WILL beat the cr ^H^H^H^H mm, stress test any VM system. John> in case you are wondering why i am torturing myself John> with a language i can't comprehend,,, lisp is the lang of John> choice for symbolic computation and the guy that wrote this John> clisp has also done a gorgeous port of some classic symbolic John> computation code. Given the fact that i dont even know what John> the equivalent of printf is in lisp, it seemed logical to (format t "The number is ~d~%" 1) John> get his *environment* if i wanted to use his *port* with any John> chance of having a successfull compilation. Which, btw, John> turned out to be the case on 2.0R. John> obviously, i eagerly await the next snap, but i think John> i am stuck now until 2.1 because i dont see where i will John> have time to do this again until the quarter is over...it John> tooks three days of near continuous effort ( thank heaven my John> wife was out of town... :-) ) The GCL port ought to work fine on -current. Good luck. Paul