Hi All,
Does anyone know of a Lisp that'll install quickly on an
Alpha running NetBSD 1.5.3?
clisp crashes after a build with few warning messages.
Steel-Bank CL has problems during "sh make.sh".
And I'm afraid to try building CMUCL myself. ;-)
(This here query you're reading is a final attempt to find
something I can get up & running quick, without having to
spend time porting.)
Thanks for your help.
gene
Gene Michael Stover <········@gte.net> writes:
> Hi All,
>
> Does anyone know of a Lisp that'll install quickly on an Alpha running
> NetBSD 1.5.3?
>
>
> clisp crashes after a build with few warning messages.
> Steel-Bank CL has problems during "sh make.sh".
> And I'm afraid to try building CMUCL myself. ;-)
>
> (This here query you're reading is a final attempt to find something I
> can get up & running quick, without having to spend time porting.)
>
>
> Thanks for your help.
> gene
Common Lisp on NetBSD is a pretty difficult endeavor. Even though
it's currently crashing, clisp is probably your best choice. CMUCL was
very recently ported to NetBSD by Pierre Mai, but it won't have any mileage
on it (I don't know what architecture he was using for development).
I spent some time trying to port SBCL to NetBSD x86, but ran into a
problem with NetBSD missing some signal handling calls found in OpenBSD
and FreeBSD (if you're interested in specifics, there's a page on cliki
explaining the problem I ran into). Overall, it wasn't an important
project for me (I did it on my own time), so I haven't worked on it
lately.
Good luck.
--Brad
From: Gene Michael Stover
Subject: Re: Lisp on NetBSD/Alpha
Date:
Message-ID: <3C749836.20203@gte.net>
Brad Knotwell wrote:
> Common Lisp on NetBSD is a pretty difficult endeavor. Even though
> it's currently crashing, clisp is probably your best choice. CMUCL was
> very recently ported to NetBSD by Pierre Mai, but it won't have any mileage
> on it (I don't know what architecture he was using for development).
>
> I spent some time trying to port SBCL to NetBSD x86, but ran into a
> problem with NetBSD missing some signal handling calls found in OpenBSD
> and FreeBSD (if you're interested in specifics, there's a page on cliki
> explaining the problem I ran into). Overall, it wasn't an important
> project for me (I did it on my own time), so I haven't worked on it
> lately.
>
> Good luck.
Hey, thanks Brad. That's helpful to know. (It sort of
releives a burden to know that it's officially a difficult
endeavour. ;-) I'll probably give clisp another whack; I
had a hunch (can't remember why, though) that it's problem
might be soluble with appropriate pointer-size typedefs & such.
Unfortunate, it is, that NetBSD is difficult to port to. Or
maybe it's not; maybe it's just a lack of demand.
gene
Brad Knotwell <········@ix.netcom.com> writes:
> Common Lisp on NetBSD is a pretty difficult endeavor. Even though
> it's currently crashing, clisp is probably your best choice. CMUCL was
> very recently ported to NetBSD by Pierre Mai, but it won't have any mileage
> on it (I don't know what architecture he was using for development).
The NetBSD port is for x86 only, I've not made any attempt to port the
alpha backend to NetBSD.
> I spent some time trying to port SBCL to NetBSD x86, but ran into a
> problem with NetBSD missing some signal handling calls found in OpenBSD
> and FreeBSD (if you're interested in specifics, there's a page on cliki
> explaining the problem I ran into). Overall, it wasn't an important
> project for me (I did it on my own time), so I haven't worked on it
> lately.
NetBSD seems to be in some sort of transition from BSD-style signal
handling functions to POSIX-style signal handling, and currently isn't
fully here nor there.
Furthermore NetBSD on x86 is missing support for getting at the page
fault memory address in SIGSEGV handlers, hence the generational GC
can't use a hardware write-barrier, and so runs suboptimally.
At least on SPARC, NetBSD doesn't seem to have that problem, so maybe
NetBSD/Alpha is also in the clear with this.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein