Hello,
I have played around with lisp in the past , and now I am looking again
to see what kind of nifty toys there are to play with. Are there any
free lisp implementations still in active development?
* Dave Wallace
|
| I have played around with lisp in the past , and now I am looking
| again to see what kind of nifty toys there are to play with. Are
| there any free lisp implementations still in active development?
<URL:http://www.elwood.com/alu/table/systems.htm>
--Lars M.
From: Dave Wallace
Subject: Re: Active lisps -- bootstrapping CMUCL with glibc2.1
Date:
Message-ID: <36F3BA88.17901733@netgsi.com>
Thanks guys, for the links. It is good to see that there is so much going in the
Lisp world. Even traffic on this list seems to be up. I now have CLIPS up and
running but unfortunately I cannot compile CMUCL since the binaries require the
symbol "setfpucw" to be defined, but it is now a macro call in my glibc2.1
library. Is there a way to bootstrap without a pre-compiled version? I tried
accessing the mail-archives, but they are available only through HTTP and the
transfer keeps stalling somewhere around mid 1998 :-(
Thanks again,
Dave.
Sam Steingold wrote:
> >>>> In message <·················@netgsi.com>
> >>>> On the subject of "Active lisps"
> >>>> Sent on Thu, 18 Mar 1999 22:20:51 -0500
> >>>> Honorable Dave Wallace <········@netgsi.com> writes:
> >>
> >> I have played around with lisp in the past , and now I am looking
> >> again to see what kind of nifty toys there are to play with. Are
> >> there any free lisp implementations still in active development?
>
> http://clisp.cons.org
> http://cmucl.cons.org
From: Raymond Toy
Subject: Re: Active lisps -- bootstrapping CMUCL with glibc2.1
Date:
Message-ID: <4n4sndiqpz.fsf@rtp.ericsson.se>
>>>>> "Dave" == Dave Wallace <········@netgsi.com> writes:
Dave> running but unfortunately I cannot compile CMUCL since the binaries require the
Dave> symbol "setfpucw" to be defined, but it is now a macro call in my glibc2.1
This problem (setfpucw) has been fixed in the most recent sources, I think.
Dave> library. Is there a way to bootstrap without a pre-compiled version? I tried
No. You must have an existing binary to build a new one.
Dave> accessing the mail-archives, but they are available only through HTTP and the
Dave> transfer keeps stalling somewhere around mid 1998 :-(
There's some problem with the router or something like that. It's
supposed to be fixed soon.
Ray
On Sat, 20 Mar 1999 10:11:04 -0500, Dave Wallace <········@netgsi.com> wrote:
>running but unfortunately I cannot compile CMUCL since the binaries require the
>symbol "setfpucw" to be defined, but it is now a macro call in my glibc2.1
>library.
I ran into the same problem with CMUCL in Debian Potato. There are a
couple of workarounds, although none really trivial:
1. My own hack: I had a backup of the libraries from glibc2.0 era in
/lib/bak. I made a copy of the old ld.so (even they aren't compatible,
grr) as /lib/ld-linhack.so, edited the binary so that it uses
LD_LINHACK_PATH instead of LD_LIBRARY_PATH, edited the CMUCL binary so
that it uses /lib/ld-linhack.so instead of /lib/ld-linux.so.2, and set
LD_LINHACK_PATH to /lib/bak. Not pretty, but works.
2. As suggested by Peter Van Eynde <········@debian.org>: Create a library
with nothing but __setfpucw and use LD_PRELOAD:
pvaneynd:~/tmp$ cat fpucw.c
void __setfpucw(cw)
{
printf("my fpucw \n");
asm("fldcw %0" : : "m" (cw));
}
pvaneynd:~/tmp$ gcc -fPIC -c fpucw.c ; gcc -shared \
-Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 fpucw.o
pvaneynd:~/tmp$ export LD_PRELOAD=./libfoo.so.1.0
pvaneynd:~/tmp$ lisp
The printf() is just for testing purposes and can be left out.
Petteri
From: Daniel R Barlow
Subject: Re: Active lisps -- bootstrapping CMUCL with glibc2.1
Date:
Message-ID: <7d7vuo$u2v@fishy.ox.compsoc.net>
In article <·······················@simpukka.saunalahti.fi>,
Petteri Kangaslampi <········@sci.fi> wrote:
>2. As suggested by Peter Van Eynde <········@debian.org>: Create a library
>with nothing but __setfpucw and use LD_PRELOAD:
We went through this fun yesterday here too. Note further that
(a) having this LD_PRELAOD set all the time will cause libc 5 applications
to segfault on startup
(b) so at least we can turn the /usr/bin/lisp into a shell wrapper, right?
#!/bin/sh
LD_PRELOAD=/lib/libkludgefpucw.so
export LD_PRELOAD
exec /usr/bin/lisp.real $*
Not like that you can't, no. /usr/sbin/cmuclconfig breaks. What you
actually want in that second line is
exec /usr/bin/lisp.real ······@"}
Hope this helps someone. Gah
-dan