lisp implementations?
mikee
I am experimenting with a genetic programming system and the books talk
about multiple methods of extending the gp systems through automatically
defining functions, variables, recursion, etc. The current system I have
is in c and think I should move to a lisp system. Toward that end what
lisp system might be best for speed, memory use, extendability, and
overall use. I'm looking at running 1000-10000 individuals per generation
and 100-500 generations so the processing needs to be quick. I'm on a
linux/unix system and can compile anything I need. I know of gcl, and
emacs. Each have their advantages.
Thoughts?
Mike
Adam Warner
The two main free software ANSI Common Lisp implementations are CLISP
(http://clisp.cons.org/) and CMUCL (http://www.cons.org/cmucl/). Both are
high quality and can produce fast results. CLISP is typically faster when
interpreted and CMUCL is typically faster when compiled (because it
produces native code on the only supported x86 platform).
A number of performance benchmarks are available from here (for compiled
code):
http://ww.telent.net/cliki/Performance%20Benchmarks
When working from the command line CLISP is a pleasure to use because of
its GNU Readline integration (it's also the reason that CLISP is GPLed).
But this doesn't significantly handicap CMUCL because Emacs and ILISP
provide a great environment to work in (for CLISP, CMUCL and a number of
other environments refer http://sourceforge.net/projects/ilisp).
If you are not creating implementation specific code you will be able to
switch between the compilers with ease.
Anyway that's a start. A lot of useful links are here:
http://www.lisp.org/table/contents.htm
Regards,
Adam
Fred Gilham
You definitely want CMU Lisp (if you want a free system).
It's got a compiler that produces code comparable, and sometimes
superior, to commercial Lisp systems.
CLISP, for example, compiles to byte code and ordinarily runs much
slower than CMU Lisp.
It's got a fairly large memory footprint but most lisps are just like
that.
I wouldn't use Emacs as your compute engine because it, too, compiles
to byte code. (You can use the combination of Emacs, Ilisp and CMU
Lisp as an interactive Lisp development environment that will be
pretty good.)
CMU Lisp can be installed on Linux as a binary distribution. It's
fairly straightforward to build from source (once you've done the
binary install) but that's not usually considered necessary, and some
people never seem to get the hang of it. :-)
GCL is OK but I don't think it's as fast as CMU Lisp or as up-to-date.
--
Fred Gilham gil...@csl.sri.com
When an economist criticizes any human institution because it has
failed to convey to mankind an incommunicable attribute of God, we can
safely dismiss that economist. The trouble is, there remains a market
for these economists in academia. I regard this fact as one more piece
of evidence for the failure of tax-subsidized education. -- Gary North
Raymond Toy
Adam> The two main free software ANSI Common Lisp implementations are CLISP
Adam> (http://clisp.cons.org/) and CMUCL (http://www.cons.org/cmucl/). Both are
Adam> high quality and can produce fast results. CLISP is typically faster when
Adam> interpreted and CMUCL is typically faster when compiled (because it
Adam> produces native code on the only supported x86 platform).
How did you come to the conclusion that x86 is the only supported
platform for CMUCL? Please don't lie.
Ray
Sam Steingold
> * On the subject of "lisp implementations?"
> * Sent on Wed, 12 Jun 2002 14:58:24 -0000
> * Honorable mi...@mikee.myip.org (mikee) writes:
>
> current system I have is in c and think I should move to a lisp
try CLISP <http://clisp.cons.org> _and_ CMUCL <http://cmucl.cons.org>.
both have advantages and drawbacks.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
MS: Brain off-line, please wait.
Bradley J Lucier
mikee <mi...@mikee.myip.org> wrote:
>I am experimenting with a genetic programming system and the books talk
>about multiple methods of extending the gp systems through automatically
>defining functions, variables, recursion, etc. The current system I have
>is in c and think I should move to a lisp system. Toward that end what
>lisp system might be best for speed, memory use, extendability, and
>overall use. I'm looking at running 1000-10000 individuals per generation
>and 100-500 generations so the processing needs to be quick.
I used Gambit-C, a Scheme system, for this purpose. The application was
genetic programming applied to image processing, edge detection, that
sort of thing. I was running 2,000 programs/generation on 512 by 512
images, and it was taking on the order of 12 machine cycles/pixel overhead
(error checking, accumulation of results, loop overhead, etc.) with about
another 20 cycles/pixel to evaluate the functions. Note that each of the
2,000 individuals is run 262,144 (512 x 512) times each generation per image.
An older paper describing some of the ideas is available at
http://www.math.purdue.edu/~lucier/lucier-gp98.pdf
Brad Lucier
Christopher Browne
>> I am experimenting with a genetic programming system and the books talk
>> about multiple methods of extending the gp systems through automatically
>> defining functions, variables, recursion, etc. The current system I have
>> is in c and think I should move to a lisp system. Toward that end what
>> lisp system might be best for speed, memory use, extendability, and
>> overall use. I'm looking at running 1000-10000 individuals per
>> generation and 100-500 generations so the processing needs to be quick.
>> I'm on a linux/unix system and can compile anything I need. I know of
>> gcl, and emacs. Each have their advantages.
>
> The two main free software ANSI Common Lisp implementations are CLISP
> (http://clisp.cons.org/) and CMUCL (http://www.cons.org/cmucl/). Both are
> high quality and can produce fast results. CLISP is typically faster when
> interpreted and CMUCL is typically faster when compiled (because it
> produces native code on the only supported x86 platform).
CMUCL also supports some other platforms; PPC is probably the
most-used one, with the "general rule" being that you have to select
OS/Architecture combinations pretty precisely. (I don't think it runs
on Linux/Alpha, for instance, though Alpha is theoretically a
supported architecture.)
The list of "free software" implementations is also pretty
incomplete. Other options include:
-> SBCL, an "easier-to-bootstrap" CL originally based on the CMUCL
code base;
-> Several descendents of Kyoto CL, notably ECLS, ECoLisp, GCL.
CMUCL and CLISP are probably more widely used than these, but they're
worth considering, to be sure...
> When working from the command line CLISP is a pleasure to use because of
> its GNU Readline integration (it's also the reason that CLISP is GPLed).
> But this doesn't significantly handicap CMUCL because Emacs and ILISP
> provide a great environment to work in (for CLISP, CMUCL and a number of
> other environments refer http://sourceforge.net/projects/ilisp).
There's a package that implements a Readline-like environment in CMUCL
if you really need it.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.cbbrowne.com/info/sgml.html
"My experience as a member of the APB (Accounting Principles Board)
taught me many lessons. A major one was that most of us have a
natural tendency and an incredible talent for processing new facts in
such a way that our prior conclusions remain intact."
-- Charles Horngren
Christophe Rhodes
> Quoth Adam Warner <use...@consulting.net.nz>:
> >> I am experimenting with a genetic programming system and the books talk
> >> about multiple methods of extending the gp systems through automatically
> >> defining functions, variables, recursion, etc. The current system I have
> >> is in c and think I should move to a lisp system. Toward that end what
> >> lisp system might be best for speed, memory use, extendability, and
> >> overall use. I'm looking at running 1000-10000 individuals per
> >> generation and 100-500 generations so the processing needs to be quick.
> >> I'm on a linux/unix system and can compile anything I need. I know of
> >> gcl, and emacs. Each have their advantages.
> >
> > The two main free software ANSI Common Lisp implementations are CLISP
> > (http://clisp.cons.org/) and CMUCL (http://www.cons.org/cmucl/). Both are
> > high quality and can produce fast results. CLISP is typically faster when
> > interpreted and CMUCL is typically faster when compiled (because it
> > produces native code on the only supported x86 platform).
>
> CMUCL also supports some other platforms; PPC is probably the
> most-used one, with the "general rule" being that you have to select
> OS/Architecture combinations pretty precisely. (I don't think it runs
> on Linux/Alpha, for instance, though Alpha is theoretically a
> supported architecture.)
(with-hat-of-sbcl-implementor
Hmm. I don't think so, though I suppose it's possible I could have
missed some news. I believe that the supported combinations as of
CMUCL 18d are x86/{linux,openbsd,freebsd} and sparc/solaris. Some
platforms, such as Alpha/Tru64 and MIPS/IRIX, would be fairly easy
to bring up to 18d, as they have working 18b binaries, making it a
simple bootstrap issue. I don't think that CMUCL on the PowerPC's
ever worked except once, though it has been worked on recently. I
wouldn't hold my breath there, though; if you're on PPC and "Free"
is in your requirements, use OpenMCL (OS X/Linux) or SBCL (Linux).
I'll just mention that the SBCL situation is slightly rosier,
because there is no bootstrap issue, simple or otherwise. :-)
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Raymond Toy
Christophe> Christopher Browne <cbbr...@acm.org> writes:
>> Quoth Adam Warner <use...@consulting.net.nz>:
>> CMUCL also supports some other platforms; PPC is probably the
>> most-used one, with the "general rule" being that you have to select
>> OS/Architecture combinations pretty precisely. (I don't think it runs
>> on Linux/Alpha, for instance, though Alpha is theoretically a
>> supported architecture.)
Christophe> (with-hat-of-sbcl-implementor
Christophe> Hmm. I don't think so, though I suppose it's possible I could have
Christophe> missed some news. I believe that the supported combinations as of
As far as I know, CMUCL on PPC doesn't work yet. But since SBCL runs
on PPC/Linux, CMUCL on PPC should be doable. I wouldn't mind having
CMUCL/SBCL on my iMac at home. I just don't know enough to actually
do it.
Christophe> CMUCL 18d are x86/{linux,openbsd,freebsd} and sparc/solaris. Some
Christophe> platforms, such as Alpha/Tru64 and MIPS/IRIX, would be fairly easy
Christophe> to bring up to 18d, as they have working 18b binaries, making it a
I think MIPS/IRIX is difficult because the latest OS is quite a bit
different from earlier ones.
Christophe> simple bootstrap issue. I don't think that CMUCL on the PowerPC's
Yes, it's unfortunate that CMUCL only runs on a couple of platforms
now, but what can you do when none of the main developers has access
to the other platforms anymore?
So here's a way to get your 15 minutes of fame and learn quite a lot
about how Lisp works at a low level and the nitty-gritty details of
machine architecture: revive one of the older ports. :-)
Ray
Adam Warner
> How did you come to the conclusion that x86 is the only supported
> platform for CMUCL? Please don't lie.
Whoops. Thank you for correcting that. But no thanks for implying that I
lied. A lie implies that I intended to deceive.
It is willful deceit that makes a lie. A man may act a lie, as by
pointing his finger in a wrong direction when a traveler inquires of
him his road.
--Paley (courtesy dict.org:2628)
I attempted to help someone, made a mistake within that reply and learned
something new. Seems like a bargain. By the follow up replies am I right
in understanding that CMUCL only runs on x86 on the free software
architectures? For example is Linux on the SPARC supported?
Regards,
Adam
Herb Martin
(I don't care about anyone's opinion of such platforms
in the context of THIS question, just that there are a lot
of them out there and CLisp does run on WinNT/2000
quite nicely.)
Am I correct that CMUCL only runs on X86 with Linux?
Herb Martin
Try ADDS for great Weather too:
http://adds.aviationweather.noaa.gov/projects/adds
"Raymond Toy" <t...@rtp.ericsson.se> wrote in message
news:4n4rg8j...@edgedsp4.rtp.ericsson.se...
Tim Moore
>Isn't it true that only CLisp runs on MS platforms?
>
>(I don't care about anyone's opinion of such platforms
>in the context of THIS question, just that there are a lot
>of them out there and CLisp does run on WinNT/2000
>quite nicely.)
>
>Am I correct that CMUCL only runs on X86 with Linux?
No, as Christophe said, it runs on FreeBSD, OpenBSD, and NetBSD as
well.
Tim
Christopher Browne
> Isn't it true that only CLisp runs on MS platforms?
No, it isn't true. CLISP runs on just about any platform with
sufficient "POSIXy" properties. That includes the "desktop" MS
platforms (e.g. - anything at least as new as Windows 95, aside from
Wince/PocketPC). That includes just about anything resembling Unix,
which now includes MacOS-X.
> (I don't care about anyone's opinion of such platforms in the
> context of THIS question, just that there are a lot of them out
> there and CLisp does run on WinNT/2000 quite nicely.)
>
> Am I correct that CMUCL only runs on X86 with Linux?
No, not correct. CMUCL runs on IA-32 on Linux, and most of the BSDs.
(OpenBSD has been a bit troubled, but I think the problems got dealt
with.)
It runs on Digital Unix, on Alpha.
It runs on _some_ Unix-like platforms on PPC and MIPS architectures.
(I don't think that includes Linux; the main traditional PPC platform
of interest would be AIX, in any case.)
It runs on Solaris, on SPARC.
Running on (Linux|NetBSD|OpenBSD) on Alpha/SPARC/MIPS/PPC seems rather
more of a challenge; your milage may vary considerably as you diverge
from the "common" combinations.
There can't be too vastly many people specializing in deploying Common
Lisp on Sun SPARC boxes running Linux; that strikes me as something
you do in order to prove that it's possible, not something you do
because it's a particularly wonderful idea. (And I say that as
someone who runs Linux pretty exclusively!)
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.cbbrowne.com/info/wp.html
Signs of a Klingon Programmer - 8. "Debugging? Klingons do not
debug. Our software does not coddle the weak. Bugs are good for
building character in the user."
James A. Crippen
> There can't be too vastly many people specializing in deploying Common
> Lisp on Sun SPARC boxes running Linux; that strikes me as something
> you do in order to prove that it's possible, not something you do
> because it's a particularly wonderful idea. (And I say that as
> someone who runs Linux pretty exclusively!)
I still really want to do this, but for purely personal reasons. I
have an Ultra 5 that I use as my main server for UnLambda. It's an
excellent combination of OS and architecture for security because
*nobody* has a r00t kit for Linux on SPARC. Certainly something for
Linux on x86, and maybe even on Alpha. Certainly something for
Solaris on [Ultra]SPARC. But not for Linux on [Ultra]SPARC. It's
pretty much impenetrable, even with the major services wide open.
It's really fun to see entries in syslog like:
Jun 12 22:00:06 kappa ftpd: FTP LOGIN FAILED from 1.2.3.4, user
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@#!/bin/sh
Sorry, the stack's in a different place here buddy.
For light duty the system can't be beat. It's cheap, it's a non-x86
architecture, it uses PCI, and it's well supported under Linux.
Except that Linux/UltraSPARC has a screwed up implementation of
something in the kernel (I've forgotten what) that makes porting CMUCL
to it very difficult. It's like Linux in every other way except for
this, which is completely inconsistent. Anyone remember what the
struct is in the kernel that's weird? I know someone worked on
solving the same problem for SBCL...
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Herb Martin
CMUCL does NOT run on MS systems; when it
runs on an X86 system it must run on a Unix variant.
CLisp runs on non-MS systems AND on MS systems.
--
Eric Marsden
cbb> [CMUCL] runs on _some_ Unix-like platforms on PPC and MIPS
cbb> architectures. (I don't think that includes Linux; the main
cbb> traditional PPC platform of interest would be AIX, in any
cbb> case.)
Christopher, your article references Raymond Toy's article where he
states that CMUCL doesn't work on PowerPC, yet you go on to say that
is _does_ work on PowerPC?
To know what platforms CMUCL runs on, please see
<URL:http://www.cons.org/cmucl/platforms.html>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Christophe Rhodes
> Except that Linux/UltraSPARC has a screwed up implementation of
> something in the kernel (I've forgotten what) that makes porting CMUCL
> to it very difficult. It's like Linux in every other way except for
> this, which is completely inconsistent. Anyone remember what the
> struct is in the kernel that's weird? I know someone worked on
> solving the same problem for SBCL...
It's got a completely broken implementation of SA_SIGINFO signal
handling, yes. The gory details, (probably slightly wrong, feel free
to correct them) are at
<URL:http://ww.telent.net/sbcl-internals/SPARC>.
SBCL is supported on SPARC/Linux, at least until I stop understanding
about the issues and it breaks completely. Binaries are available from
the Debian project (or mail me).
Christophe Rhodes
> I attempted to help someone, made a mistake within that reply and learned
> something new. Seems like a bargain.
... for you. Maybe you've confused someone else -- is that then a net
soceital gain?
> By the follow up replies am I right
> in understanding that CMUCL only runs on x86 on the free software
> architectures? For example is Linux on the SPARC supported?
If anyone cared, they could port sbcl's support for sparc/linux back
to cmucl. Since sparc/linux is such a minority platform, it's unlikely
that any cmucl developer cares sufficiently. Incentives welcome :-)
Adam Warner
> Adam Warner <use...@consulting.net.nz> writes:
>
>> I attempted to help someone, made a mistake within that reply and
>> learned something new. Seems like a bargain.
>
> ... for you. Maybe you've confused someone else -- is that then a net
> soceital gain?
Well tell me. Read my original reply and let me know whether in your
humble opinion I caused net harm to the rest of society.
Regards,
Adam
James A. Crippen
> Adam Warner <use...@consulting.net.nz> writes:
>
> > By the follow up replies am I right
> > in understanding that CMUCL only runs on x86 on the free software
> > architectures? For example is Linux on the SPARC supported?
>
> If anyone cared, they could port sbcl's support for sparc/linux back
> to cmucl. Since sparc/linux is such a minority platform, it's unlikely
> that any cmucl developer cares sufficiently. Incentives welcome :-)
I'm still musing on it. I'd really like to get CMUCL working on my
box, as said before. But it's not like I don't already have other
projects I ought to spend my time working on...
Thien-Thi Nguyen
> Well tell me. Read my original reply and let me know whether in your
> humble opinion I caused net harm to the rest of society.
society will tell you in the long run; you cannot judge this for yourself.
to repeat a non-truth helps it live, regardless of intent.
thi
Andreas Hinze
>
> There's a package that implements a Readline-like environment in CMUCL
> if you really need it.
>
Where can i find that package ?
Best
AHz
Michael Hudson
> I think you (are continuing to or) missing the point.
>
> CMUCL does NOT run on MS systems; when it
> runs on an X86 system it must run on a Unix variant.
Then you phrased your question badly; you said "linux" specifically.
But I think you're correct, though rumours of a windows port for CMUCL
float around every now and again.
> CLisp runs on non-MS systems AND on MS systems.
Indeed.
Cheers,
M.
--
Windows installation day one. Getting rid of the old windows
was easy - they fell apart quite happily, and certainly wont
be re-installable anywhere else. -- http://www.linux.org.uk/diary/
(not *that* sort of windows...)
Raymond Toy
Christophe> If anyone cared, they could port sbcl's support for
Christophe> sparc/linux back to cmucl. Since sparc/linux is such a
Christophe> minority platform, it's unlikely that any cmucl
Christophe> developer cares sufficiently.
Sorry, not me. The only sparc machines I have access to are at work.
And there is not way I'd ever get to put Linux on it. I also fail to
see why I'd want that anyway. :-)
Ray
Raymond Toy
Adam> Hi Raymond Toy,
>> How did you come to the conclusion that x86 is the only supported
>> platform for CMUCL? Please don't lie.
Adam> Whoops. Thank you for correcting that. But no thanks for implying that I
Adam> lied. A lie implies that I intended to deceive.
Perhaps "lie" was too harsh, for which I apologize. But with just
printed words, it's very hard to tell. The way you phrased the answer
made it sound authoritative.
Ray
Erik Naggum
| Whoops. Thank you for correcting that. But no thanks for implying that I
| lied. A lie implies that I intended to deceive.
|
| It is willful deceit that makes a lie. A man may act a lie, as by
| pointing his finger in a wrong direction when a traveler inquires of
| him his road.
| --Paley (courtesy dict.org:2628)
Very useful. However, repeatedly signaling to someone that he generally
needs to acquire clues before posting means that failure to do so is no
longer accidental, but intentional.
But it is your kind that is taking over USENET, making it useless for
those of who already have a bunch of clues and who would have liked to
discuss things that only confound the newbie, and most of us tend to
think that leaving blatant disinformation stand is not acceptable, and
that corrective information should be posted. This may be why we got
onto USENET in the first place, why we learn instead of answer when the
topic at hand is new to us (and there always are such), and how we became
knowledgeable because we _listen_.
Therefore, I suggest that you mark your replies "CLUELESS NEWBIE ANSWER"
so people who find that kind of thing useful can read it and those who do
not do not have to respond to it, either.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Christopher Browne
> Christopher Browne wrote:
>> There's a package that implements a Readline-like environment in CMUCL
>> if you really need it.
> Where can i find that package ?
It's supposed to be at:
<http://emu.res.cmu.edu/~mrd/line-reader/>
The site seems dead. I've got a copy of version 0.5; could let it out
if need be...
--
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/linuxxian.html
Rules of the Evil Overlord #124. "Prior to kidnapping an older male
scientist and forcing him to work for me, I will investigate his
offspring and make sure that he has neither a beautiful but naive
daughter who is willing to risk anything to get him back, nor an
estranged son who works in the same field but had a falling-out with
his father many years ago." <http://www.eviloverlord.com/>
Herb Martin
> so people who find that kind of thing useful can read it and those who
do
> not do not have to respond to it, either.
Get a life -- his answers are more useful than
your carping.
You might also mark you messages as clueless
and irrelevant.
Herb Martin
Try ADDS for great Weather too:
http://adds.aviationweather.noaa.gov/projects/adds
"Erik Naggum" <er...@naggum.net> wrote in message
news:32329639...@naggum.net...
> * Adam Warner
> | Whoops. Thank you for correcting that. But no thanks for implying that I
> | lied. A lie implies that I intended to deceive.
> |
> | It is willful deceit that makes a lie. A man may act a lie, as by
> | pointing his finger in a wrong direction when a traveler inquires of
> | him his road.
> | --Paley (courtesy dict.org:2628)
>
> Very useful. However, repeatedly signaling to someone that he generally
> needs to acquire clues before posting means that failure to do so is no
> longer accidental, but intentional.
>
> But it is your kind that is taking over USENET, making it useless for
> those of who already have a bunch of clues and who would have liked to
> discuss things that only confound the newbie, and most of us tend to
> think that leaving blatant disinformation stand is not acceptable, and
> that corrective information should be posted. This may be why we got
> onto USENET in the first place, why we learn instead of answer when the
> topic at hand is new to us (and there always are such), and how we
became
> knowledgeable because we _listen_.
>
Herb Martin
> But I think you're correct, though rumours of a windows port for CMUCL
> float around every now and again.
I guess it was my first line that confused you, to wit:
> Isn't it true that only CLisp runs on MS platforms?
--
Herb Martin
Try ADDS for great Weather too:
http://adds.aviationweather.noaa.gov/projects/adds
"Michael Hudson" <m...@python.net> wrote in message
news:lk3cvrn...@pc150.maths.bris.ac.uk...
Michael Hudson
> > Then you phrased your question badly; you said "linux" specifically.
> > But I think you're correct, though rumours of a windows port for CMUCL
> > float around every now and again.
>
> I guess it was my first line that confused you, to wit:
>
> > Isn't it true that only CLisp runs on MS platforms?
No, it was this line:
> Am I correct that CMUCL only runs on X86 with Linux?
A little thing. I'll stop now.
--
My hat is lined with tinfoil for protection in the unlikely event
that the droid gets his PowerPoint presentation working.
-- Alan W. Frame, alt.sysadmin.recovery
James Amundson
> Quoth Andreas Hinze <a...@smi.de>:
>> Christopher Browne wrote:
>>> There's a package that implements a Readline-like environment in CMUCL if
>>> you really need it.
>
>> Where can i find that package ?
>
> It's supposed to be at:
> <http://emu.res.cmu.edu/~mrd/line-reader/>
>
> The site seems dead. I've got a copy of version 0.5; could let it out if need
> be...
I would be very interested in a readline package for CMUCL for use in Maxima. I
would appreciate a copy.
Thanks,
Jim Amundson
Christopher Browne
Take a look at the URL below. (Beware: My web hosting provider is
Under Reorganization, so access may be imperfect today...)
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/downloads/
"La Cicciolina [...] Electing her was an interesting contrast to the
situation in the UK: In Italy they elect a representative from the sex
industry. In the UK, they elect their clients." -- Peter Gutmann
Daniel Barlow
> Get a life -- his answers are more useful than
> your carping.
A wrong answer is more useful than no answer?
You seem to have got lost on the way to comp.lang.c. Don't let us
detain you.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Matthew Danish
> In the last exciting episode, James Amundson <amun...@fnal.gov> wrote::
> > On Thu, 13 Jun 2002 08:44:50 -0500, Christopher Browne wrote:
> >
> >> Quoth Andreas Hinze <a...@smi.de>:
> >>> Christopher Browne wrote:
> >>>> There's a package that implements a Readline-like environment in CMUCL if
> >>>> you really need it.
> >>
> >>> Where can i find that package ?
> >>
> >> It's supposed to be at:
> >> <http://emu.res.cmu.edu/~mrd/line-reader/>
> >>
> >> The site seems dead. I've got a copy of version 0.5; could let it out if need
> >> be...
> >
> > I would be very interested in a readline package for CMUCL for use in Maxima. I
> > would appreciate a copy.
>
> Take a look at the URL below. (Beware: My web hosting provider is
> Under Reorganization, so access may be imperfect today...)
If someone has a more permanent location for it, that would be appreciated.
Admittedly the package needs some better packaging work done on it. Perhaps
I'll asdf'ify it sometime when I have a chance.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Andreas Hinze
>
> If someone has a more permanent location for it, that would be appreciated.
> Admittedly the package needs some better packaging work done on it. Perhaps
> I'll asdf'ify it sometime when I have a chance.
>
Best regards
AHz
Neil Schemenauer
most programs.
Neil
synthespian
> Hi Raymond Toy,
>
>> How did you come to the conclusion that x86 is the only supported
>> platform for CMUCL? Please don't lie.
>
> Whoops. Thank you for correcting that. But no thanks for implying that I
> lied. A lie implies that I intended to deceive.
>
> It is willful deceit that makes a lie. A man may act a lie, as by
> pointing his finger in a wrong direction when a traveler inquires of
> him his road.
> --Paley (courtesy dict.org:2628)
>
> I attempted to help someone, made a mistake within that reply and
> learned something new. Seems like a bargain. By the follow up replies am
> I right in understanding that CMUCL only runs on x86 on the free
> software architectures? For example is Linux on the SPARC supported?
>
> Regards,
> Adam
Debian supports SPARC (it supports 11 platforms, BTW)
Regs
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
synth...@debian-rs.org
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
synthespian
>> * In message <slrnageocb...@kensho.eggtech.com> * On the subject
>> of "lisp implementations?" * Sent on Wed, 12 Jun 2002 14:58:24 -0000 *
>> Honorable mi...@mikee.myip.org (mikee) writes:
>>
>> current system I have is in c and think I should move to a lisp
>
> try CLISP <http://clisp.cons.org> _and_ CMUCL <http://cmucl.cons.org>.
> both have advantages and drawbacks.
>
I didn't see any of you guys mention the French xvbl.
They have some neat graphics stuff built in, but I don't know what the
*license* is. And I don't know if it's ANSI, too.
Christopher Browne
> Debian supports SPARC (it supports 11 platforms, BTW)
That's well and nice; it does not appear that CMUCL will run on
Linux/SPARC, though. The only CPU architecture that seems supported
for Linux is x86.
It's not much good, after all, if you can install Linux on the
platform, but then can't find a suitable install of CMUCL...
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/multiplexor.html
"Well, it's assembly language, you know. You don't want to have too much
taste..." -- Dave Moon
Christopher Browne
> On Wed, 12 Jun 2002 13:18:30 -0300, Sam Steingold wrote:
>
>>> * In message <slrnageocb...@kensho.eggtech.com> * On the subject
>>> of "lisp implementations?" * Sent on Wed, 12 Jun 2002 14:58:24 -0000 *
>>> Honorable mi...@mikee.myip.org (mikee) writes:
>>>
>>> current system I have is in c and think I should move to a lisp
>>
>> try CLISP <http://clisp.cons.org> _and_ CMUCL <http://cmucl.cons.org>.
>> both have advantages and drawbacks.
>>
>
> I didn't see any of you guys mention the French xvbl.
>
> They have some neat graphics stuff built in, but I don't know what the
> *license* is. And I don't know if it's ANSI, too.
I can't make out what variety of Lisp it is.
It's not Common Lisp; it's not Scheme; it's really not evident what it
is.
I'd even recommend Scheme before xbvlisp, even though the sheer
mention of Scheme would cause #Erik pain.
With Scheme, you have a minimal standard, and some quasi-standard
SRFI's to add some useful functionality. With CL you have a sizable
standard.
With xbvlisp, you get _zero_ documentation, some source code, mostly
in French, and _no_ textbooks, _no_ third party references, _no_ third
party libraries, no CLOCC, ...
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://cbbrowne.com/info/emacs.html
Windows and Icons and Mice, OH MY!
Adam Warner
> On Wed, 12 Jun 2002 19:49:33 -0300, Adam Warner wrote:
>
>> Hi Raymond Toy,
>>
>>> How did you come to the conclusion that x86 is the only supported
>>> platform for CMUCL? Please don't lie.
>>
>> Whoops. Thank you for correcting that. But no thanks for implying that
>> I lied. A lie implies that I intended to deceive.
>>
>> It is willful deceit that makes a lie. A man may act a lie, as by
>> pointing his finger in a wrong direction when a traveler inquires of
>> him his road.
>> --Paley (courtesy dict.org:2628)
>>
>> I attempted to help someone, made a mistake within that reply and
>> learned something new. Seems like a bargain. By the follow up replies
>> am I right in understanding that CMUCL only runs on x86 on the free
>> software architectures? For example is Linux on the SPARC supported?
>>
>> Regards,
>> Adam
>
> Debian supports SPARC (it supports 11 platforms, BTW)
It sure does (+/- http://www.debian.org/doc/FAQ/ch-compat.html,
http://www.debian.org/ports/). That doesn't mean the developers are able
to achieve 100% package availability for all platforms though. CMUCL
appears to be one of these exceptions.
Here is the list of packages available for Woody on i386:
ftp://ftp.debian.org/debian/dists/woody/main/binary-i386/
Here is the list of packages available for SPARC:
ftp://ftp.debian.org/debian/dists/woody/main/binary-sparc/
wget ftp://ftp.debian.org/debian/dists/woody/main/binary-i386/Packages.gz
cat Packages.gz | gunzip | grep -i 'package: cmucl'
Package: cmucl
Package: cmucl-clm
Package: cmucl-normal
Package: cmucl-safe
Package: cmucl-small
Package: cmucl-source
wget ftp://ftp.debian.org/debian/dists/woody/main/binary-sparc/Packages.gz
Package: cmucl-source
Notice how the binaries are not available and the cmucl-source package
states "Note that to recompile CMUCL you need a working CMUCL system :-("
Regards,
Adam
Adam Warner
> Notice how the binaries are not available and the cmucl-source package
> states "Note that to recompile CMUCL you need a working CMUCL system :-("
BTW I just checked and SBCL is available for Debian SPARC:
Package: sbcl
Priority: optional
Section: devel
Installed-Size: 22072
Maintainer: Jonathan Hseu <vom...@debian.org>
Architecture: sparc
Version: 0.7.2-1
Provides: lisp-compiler
Depends: libc6 (>= 2.2.4-4)
Pre-Depends: common-lisp-controller (>> 2.0)
Suggests: ilisp
Filename: pool/main/s/sbcl/sbcl_0.7.2-1_sparc.deb
Size: 6395314
MD5sum: 1cd43032ea4ab28daa2b0901221e9d91
Description: Steel Bank Common Lisp, a fork from CMUCL
SBCL is a Common Lisp compiler with a transparent build process, that
aims for correctness and ANSI compliance.
Regards,
Adam
Adam Warner
> Notice how the binaries are not available and the cmucl-source package
> states "Note that to recompile CMUCL you need a working CMUCL system :-("
BTW I just checked and SBCL is available for Debian SPARC:
Adam Warner
>> Debian supports SPARC (it supports 11 platforms, BTW)
>
> It sure does (+/- http://www.debian.org/doc/FAQ/ch-compat.html,
> http://www.debian.org/ports/). That doesn't mean the developers are able
> to achieve 100% package availability for all platforms though. CMUCL
> appears to be one of these exceptions.
Lastly, this URL shows what percentage of source packages build for each
platform: http://buildd.debian.org/stats/
Over time the support for all the additional architectures has improved to
the point where more than 92% of all packages build on non-i386
architectures. Some packages are just not relevant on other architectures
such as x86info which displays diagnostic information about i386 CPUs.
Regards,
Adam
Adam Warner
>> Debian supports SPARC (it supports 11 platforms, BTW)
>
> It sure does (+/- http://www.debian.org/doc/FAQ/ch-compat.html,
> http://www.debian.org/ports/). That doesn't mean the developers are able
> to achieve 100% package availability for all platforms though. CMUCL
> appears to be one of these exceptions.
Lastly, this URL shows what percentage of source packages build for each
Adam Warner
>> Debian supports SPARC (it supports 11 platforms, BTW)
>
> It sure does (+/- http://www.debian.org/doc/FAQ/ch-compat.html,
> http://www.debian.org/ports/). That doesn't mean the developers are able
> to achieve 100% package availability for all platforms though. CMUCL
> appears to be one of these exceptions.
Lastly, this URL shows what percentage of source packages build for each
Adam Warner
>> Debian supports SPARC (it supports 11 platforms, BTW)
>
> It sure does (+/- http://www.debian.org/doc/FAQ/ch-compat.html,
> http://www.debian.org/ports/). That doesn't mean the developers are able
> to achieve 100% package availability for all platforms though. CMUCL
> appears to be one of these exceptions.
Lastly, this URL shows what percentage of source packages build for each
Adam Warner
news client was supposedly unable to send the last message. So I had to
"send pending messages" multiple times. Unfortunately it appears three of
the final posts succeeded (even though I had to do the same thing with the
penultimate reply and it only got through once).
Regards,
Adam
Andie Wolbrink
>"Herb Martin" <He...@LearnQuick.Com> writes:
>
>> Get a life -- his answers are more useful than
>> your carping.
>
>A wrong answer is more useful than no answer?
No.
A wrong answer is more useful than an abusive answer.
-----------------------------------------------------
Kelvin is LORD!
All praise the Lord Kelvin!
Only The One, True Lord KELVIN Can Conserve You From Entropy!
Herb Martin
> No.
> A wrong answer is more useful than an abusive answer.
Ageeing with you....
Actually the more useful, original answer was
at least partially correct and the abusive response
was perhaps only correct through a misunderstanding.
Correcting an error made here should require neither
an apology nor abuse.
Just stating the facts works.
Herb Martin
Try ADDS for great Weather too:
http://adds.aviationweather.noaa.gov/projects/adds
news:ienjguc3pvilvdmks...@4ax.com...
James A. Crippen
> I'd even recommend Scheme before xbvlisp, even though the sheer
> mention of Scheme would cause #Erik pain.
This is band 42 of T300 #11. (60.44 Hz)
System 105.23
ZMail 42.0
Remote-File 5.0
LMFILE-Remote 5.0
Microcode -4.68e23
Frobozz Magic Lisp Machine Twenty-Three, with associated machine AI.
Eval: #Erik
>>Trap: Reader error on #<INPUT-STREAM 2000725571>:
No reader dispatch function defied for #\E
Cannot defy reader's expectations.
While in the function SI:%HARASS-READTABLE-MAYBE <- SI:%READ <- SI:READ <- SI:LISP-TOP-LEVEL
SI:%READ:
Arg 0 (STREAM): #<INPUT-STREAM 2000725571>
<Resume>: Supply a value to use this time as the value of
#<INPUT-STREAM 2000725571>
<Abort>: Return to Lisp Top Level
<Luser>: Help for lusers like you
<Escape>: Not possible
<Network>: Open File INET|USENET:rec.abortion instead
<End>: End user
->
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
Thomas F. Burdick
> Christopher Browne <cbbr...@acm.org> writes:
>
> > There can't be too vastly many people specializing in deploying Common
> > Lisp on Sun SPARC boxes running Linux; that strikes me as something
> > you do in order to prove that it's possible, not something you do
> > because it's a particularly wonderful idea. (And I say that as
> > someone who runs Linux pretty exclusively!)
>
> I still really want to do this, but for purely personal reasons. I
> have an Ultra 5 that I use as my main server for UnLambda.
Well, since I'm pretty sure that Christophe is the only CMUCL or SBCL
hacker who share's your love of Linux/SPARC, I think you've got three
options; port the SBCL support back to CMUCL yourself, hire someone to
do it for you, or run SBCL. Depending on your free time and available
money, the last option might well be the best. SBCL isn't
anti-feature, it's anti-features-in-the-core-that-don't-need-to-be, so
you'll probably get support trying to port whatever CMUCL thing you're
missing into SBCL userland.
[Warning: smarmy, misleading editing follows]
> It's an excellent combination of OS and architecture
[...]
> Except that Linux/UltraSPARC has a screwed up implementation of
> something in the kernel (I've forgotten what) that makes porting CMUCL
> to it very difficult. It's like Linux in every other way except for
> this, which is completely inconsistent.
Hmm...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> Centuries ago, Nostradamus foresaw when synthespian <synth...@debian-rs.org> would write:
> > On Wed, 12 Jun 2002 13:18:30 -0300, Sam Steingold wrote:
> >
> >>> * In message <slrnageocb...@kensho.eggtech.com> * On the subject
> >>> of "lisp implementations?" * Sent on Wed, 12 Jun 2002 14:58:24 -0000 *
> >>> Honorable mi...@mikee.myip.org (mikee) writes:
> >>>
> >>> current system I have is in c and think I should move to a lisp
> >>
> >> try CLISP <http://clisp.cons.org> _and_ CMUCL <http://cmucl.cons.org>.
> >> both have advantages and drawbacks.
> >>
> >
> > I didn't see any of you guys mention the French xvbl.
> >
> > They have some neat graphics stuff built in, but I don't know what the
> > *license* is. And I don't know if it's ANSI, too.
>
> I can't make out what variety of Lisp it is.
>
> It's not Common Lisp; it's not Scheme; it's really not evident what it
> is.
It seems to be a MACLISP-like dialect that predates CL, developed at
the AI Lab at Univ. Paris 8, and still (?) used in classes. Yow. The
dialect is bVLISP, with the X having been added when it got its X11
interface.
> I'd even recommend Scheme before xbvlisp, even though the sheer
> mention of Scheme would cause #Erik pain.
>
> With Scheme, you have a minimal standard, and some quasi-standard
> SRFI's to add some useful functionality. With CL you have a sizable
> standard.
>
> With xbvlisp, you get _zero_ documentation, some source code, mostly
> in French, and _no_ textbooks, _no_ third party references, _no_ third
> party libraries, no CLOCC, ...
No, you actually get a fair amount of stuff, including a manual, and
an old textbook that was later rewritten to use Common Lisp. Of
course, it's all in French, but that's not a problem for me :)
[the fact that it's a weird dialect that Univ Paris 8 is still keeping
alive for some weird reason, however, is a problem for me].
If you're curious, here's its homepage, in French:
<http://www.ai.univ-paris8.fr/Xbvl/xbvl-home-fr.html>
and (less complete) in English:
<http://www.ai.univ-paris8.fr/Xbvl/xbvl-home-en.html>
Erik Naggum
> I'd even recommend Scheme before xbvlisp, even though the sheer
> mention of Scheme would cause #Erik pain.
* James A. Crippen
| This is band 42 of T300 #11. (60.44 Hz)
| System 105.23
| ZMail 42.0
| Remote-File 5.0
| LMFILE-Remote 5.0
| Microcode -4.68e23
| Frobozz Magic Lisp Machine Twenty-Three, with associated machine AI.
|
| Eval: #Erik
People constantly spell my real name wrong, too. I used to sign off with
#\Erik or #:Erik. The former is at least self-quoting, while the
uninterned symbol results in an unbound variable error unless quoted.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Christophe Rhodes
> ja...@unlambda.com (James A. Crippen) writes:
>
> > Christopher Browne <cbbr...@acm.org> writes:
> >
> > > There can't be too vastly many people specializing in deploying Common
> > > Lisp on Sun SPARC boxes running Linux; that strikes me as something
> > > you do in order to prove that it's possible, not something you do
> > > because it's a particularly wonderful idea. (And I say that as
> > > someone who runs Linux pretty exclusively!)
> >
> > I still really want to do this, but for purely personal reasons. I
> > have an Ultra 5 that I use as my main server for UnLambda.
>
> Well, since I'm pretty sure that Christophe is the only CMUCL or SBCL
> hacker who share's your love of Linux/SPARC,
Ahem.
Having experienced the pain of it, I have to say that I have no love
for Linux/SPARC. Don't go there. You have been warned.
Christophe "give me Solaris any day... wait, what am I saying?"
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
synthespian
This is the kind of thing that's frustrating...Instead of adding to
Common LISP they fork to some weird dialect.
Now, I might be wrong, but this looked like the easiest X11 interface.
Am I?
This kind of attitude (forking into weird stuff) is actually _bad_ for
Common LISP (and, hmmm,
actually good for the xvblisp guys ;-))
It's just like one of those things...Like XLISPSTAT had a greater
potential for statistics, but now everybody uses R...
BTW, does anybody have a _clue_ as to _when_ a new ANSI standard will
(probably) come out? (How _do_ theses things come about, anyway?)
Regs,
Christopher Browne
> This is the kind of thing that's frustrating...Instead of adding to
> Common LISP they fork to some weird dialect.
I think you didn't read the posting, and somehow missed the phrase
"that predates CL."
> Now, I might be wrong, but this looked like the easiest X11
> interface. Am I?
It may be one of the _simplest_ X11 interfaces around. Unfortunately,
things can be too simple to be flexible enough to be properly useful.
> It's just like one of those things...Like XLISPSTAT had a greater
> potential for statistics, but now everybody uses R...
Different communities generate different tools. XLispStat apparently
saw _zero_ attention for a very long time, and the fact that it has
neither been updated in a long time nor ported to CL indicates that
nobody cared very much.
In contrast, apparently a bunch of people cared about S, so a free
version got created.
> BTW, does anybody have a _clue_ as to _when_ a new ANSI standard
> will (probably) come out? (How _do_ theses things come about,
> anyway?)
They come about when the ANSI committee has usable revision proposals
to look at.
No such proposals are currently outstanding, so there is nothing for
the committee to meet on.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/lisp.html
Rules of the Evil Overlord #75. "I will instruct my Legions of Terror
to attack the hero en masse, instead of standing around waiting while
members break off and attack one or two at a time."
<http://www.eviloverlord.com/>
James A. Crippen
> * Christopher Browne
> > I'd even recommend Scheme before xbvlisp, even though the sheer
> > mention of Scheme would cause #Erik pain.
>
> * James A. Crippen
> | This is band 42 of T300 #11. (60.44 Hz)
> | System 105.23
> | ZMail 42.0
> | Remote-File 5.0
> | LMFILE-Remote 5.0
> | Microcode -4.68e23
> | Frobozz Magic Lisp Machine Twenty-Three, with associated machine AI.
> |
> | Eval: #Erik
>
> People constantly spell my real name wrong, too. I used to sign off with
> #\Erik or #:Erik. The former is at least self-quoting, while the
> uninterned symbol results in an unbound variable error unless quoted.
I used to sign off with `,james and had similar problems. I switched
to 'james and now nobody has problems with my name since it always
evaluates to me. Except of course if people try to evaluate it twice.
James A. Crippen
> t...@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ja...@unlambda.com (James A. Crippen) writes:
> >
> > > Christopher Browne <cbbr...@acm.org> writes:
> > >
> > > > There can't be too vastly many people specializing in deploying Common
> > > > Lisp on Sun SPARC boxes running Linux; that strikes me as something
> > > > you do in order to prove that it's possible, not something you do
> > > > because it's a particularly wonderful idea. (And I say that as
> > > > someone who runs Linux pretty exclusively!)
> > >
> > > I still really want to do this, but for purely personal reasons. I
> > > have an Ultra 5 that I use as my main server for UnLambda.
> >
> > Well, since I'm pretty sure that Christophe is the only CMUCL or SBCL
> > hacker who share's your love of Linux/SPARC,
>
> Ahem.
>
> Having experienced the pain of it, I have to say that I have no love
> for Linux/SPARC. Don't go there. You have been warned.
>
> Christophe "give me Solaris any day... wait, what am I saying?"
Yah, it's not like the two choices are particularly appealing. I like
Sun hardware, but their OS blows chunks. And Linux on SPARC isn't
much better...
The major problem with Linux/UltraSPARC is that GCC doesn't (even
today) handle all of the 64-bit ops available in UltraSPARC
processors. Basically the only program on a Linux/UltraSPARC box that
can actually be 64-bit is the kernel. Everything else runs in 32-bit
vanilla SPARC v8 mode. Someday I suppose GCC will finally support all
of the UltraSPARC architecture, and then we can rejoice in
well-supported cheap 64-bit hardware. Older UltraSPARC hardware is
cheap. My Ultra5 cost me less than $500 bucks or so, IIRC, and over a
year ago at that. Older UltraSPARCs are not too fast, but cheap, and
can still handle stupid amounts of memory. And yes, older Alphas are
cheap too but they're not terribly well supported by their
manufacturer anymore...
Bradley J Lucier
James A. Crippen <ja...@unlambda.com> wrote:
>The major problem with Linux/UltraSPARC is that GCC doesn't (even
>today) handle all of the 64-bit ops available in UltraSPARC
>processors.
GCC 3.1 allows you to compile 64 applications on ultrasparc; I have no
problems with it, use '-mcpu=ultrasparc -m64'.
This didn't work reliably until this past February or so.
Brad
James A. Crippen
Does it compile glibc 2.2.x without problems? That's the really
important thing. If so then a *real* 64-bit Linux is available. If
you still have to use a 32-bit glibc then you're still stuck in
emulation mode.
Bradley J Lucier
James A. Crippen <ja...@unlambda.com> wrote:
>b...@cs.purdue.edu (Bradley J Lucier) writes:
>> GCC 3.1 allows you to compile 64 applications on ultrasparc; I have no
>> problems with it, use '-mcpu=ultrasparc -m64'.
>>
>> This didn't work reliably until this past February or so.
>
>Does it compile glibc 2.2.x without problems?
Well, as far as I know, it does. But you can ask the people on the
glibc mail lists if you really want to know; I suggest Jakub Jelinek.
Brad Lucier
Paolo Amoroso
> Yes, it's unfortunate that CMUCL only runs on a couple of platforms
> now, but what can you do when none of the main developers has access
> to the other platforms anymore?
Have you checked the SourceForge compile farm?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Raymond Toy
Paolo> On 12 Jun 2002 17:47:46 -0400, Raymond Toy <t...@rtp.ericsson.se> wrote:
>> Yes, it's unfortunate that CMUCL only runs on a couple of platforms
>> now, but what can you do when none of the main developers has access
>> to the other platforms anymore?
Paolo> Have you checked the SourceForge compile farm?
Not lately. Last time I did, it only had x86 flavors, Solaris/Sparc,
and maybe an Alpha.
I guess I should have also mentioned that coupled with the lack of
access is, perhaps more importantly, the possible lack of desire. :-)
It's a lot of work, and sometimes you have to dig really deep into the
OS. I tried to bring 18c to the HPPA 10.x. Many system internals
changed from the 18a version, and I eventually got tired of trying to
figure out what structure really corresponded to what and all the
macros that went with them, when I didn't have an old system to look
at for comparison.
Ray
Daniel Barlow
> On 12 Jun 2002 17:47:46 -0400, Raymond Toy <t...@rtp.ericsson.se> wrote:
>
>> Yes, it's unfortunate that CMUCL only runs on a couple of platforms
>> now, but what can you do when none of the main developers has access
>> to the other platforms anymore?
>
> Have you checked the SourceForge compile farm?
Yes, it's a bloody pain in the arse (american: ass). The chief
problem is that it's a major hassle to get files to and from it.
I've had a lot more success with the Testdrive facility from
Digital^WCompaq^WHP, which has made it possible to do things like fix
SBCL for ev6 Alphas, and port it to Tru64 (will be in 0.7.5). At
least it's possible to use Emacs Tramp to talk to those machines.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
synthespian
> Hi mikee,
>
>>
> When working from the command line CLISP is a pleasure to use because of
> its GNU Readline integration (it's also the reason that CLISP is
GPLed).
Hello-
What is "Gnu Readline integratin"?
Forgive my iGNUrance.
Henry
synth...@debian-rs.org
synthespian
>
> -> SBCL, an "easier-to-bootstrap" CL originally based on the CMUCL
> code base;
>
Hi-
I've read before about "bootstrapping".
What does it mean?
Thnak you
Friedrich Dominicus
> On Wed, 12 Jun 2002 13:01:59 -0300, Adam Warner wrote:
>
> > Hi mikee,
> >
> >>
> > When working from the command line CLISP is a pleasure to use because of
> > its GNU Readline integration (it's also the reason that CLISP is
> GPLed).
Sorry what's the problem with readline support under CMUCL?
I have installed cle here which one can use to add readline support
for programs attached to a tty.
Regards
Friedrich
Joel Ray Holveck
>> code base;
> What does it mean?
Building from source without an already-built Lisp.
My understanding is that SBCL requires some Common Lisp, but not SBCL.
However, to build CMUCL, you need an earlier version of CMUCL.
joelh