--- "M. Edward (Ed) Borasky" <znmeb@...> wrote:
> I used to be on the CMUCL and SBCL mailing lists because CMUCL is
> tge best overall Lisp for my purposes and SBCL is the most actively
> developed. In addition to Maxima, I use Lisp for algorithmic
> composition, and right now CMUCL is the only one that fully supports
> Rick Taube's Common Music.
Cool! I didn't know Common Music was in active use. I should look at
that more carefully.
> I guess the fact that there are four "competing" open source Lisps
> is a "problem", just as the fact that there are two competing open
> source "emacs" packages is a "problem". Still, I think the various
> compatibilities/standards/etc. between Maxima and the four
> currently-existing Lisps are best suited by the current mechanism ...
I guess it's a problem, but I like that there are so many different
environments experimenting with different things. The biggest fly in
the ointment right now is ANSI compatibility (*cough*gcl*cough*) - once
an ANSI platform can be depended on on all 4 then people can start
stretching the various features available on each, and maybe evolve
what will become ANSI Common Lisp 2.0 :-) Maxima being able to run on
all of them gives us a) a check that the underlying lisp isn't doing
unexpected things to results b) assurance that if one lisp dies we have
no trouble continuing on c) a good excuse to install lots of lisps ;-)
and d) an extra way to shake bugs out of our code (not that we need any
help right now, granted...)
> they're all available in Portage in at least one "stable" form,
> however ancient that might be, and available in "testing"
> or "unstable" for us amateur beta testers. I don't have a problem
> joining mailing lists for packages I use and filing bug reports
> upstream -- ask the Texmacs, R, or Common Music and SBCL folks
> about that. :)
My main complaint is that, in many cases, the newer release of the
lisp/CAS/scientific program in general is likely to contain many fixes,
and in fact be more desirable to use generally than the older version.
In fact, keeping the older, incorrect version around is an active
disservice to people using it thinking it's correct. Perhaps in the
case of the various lisps I can see waiting a bit (except for gcl ;-)
but in the case of Maxima, when we DO put out a new release there tend
to be fixes for mathematically incorrect behavior and other things that
make no sense to wait on. It is improbable that Maxima will regress
between versions - there's too much room for improvement. I would
expect the same would hold for Axiom. Even if there WERE regression,
it might not be caught for quite some time, since exercising the
capabilities of a CAS is not trivial in and of itself.
> Gentoo is about choice, right? If the choice, however, must be
> where to allocate finite (or in some cases zero) volunteer
> developer/maintainer time, I'd cast my vote for CMUCL as the Lisp
> of choice, at least until SBCL hits 1.0 and gets the callback thing
> worked out for Common Music.
I would tend to agree, except I don't know how CMUCL does on non-x86
platforms. Clisp at least tends to run on ANYTHING, despite it's not
being the performance choice. IIRC that's why Clisp was originally set
as the no-choice-given default for Maxima, although that may have
> GCL is a tad faster on some benchmarks, and CLISP has "readline"
> built in.
GCL can use readline too, at this point - not sure if it's in the
ebuild by default.
Oh, I recommend rlwrap for cmucl, by the way - assuming one is being
foolish like me and not using SLIME ;-). Must learn SLIME, must learn
> I'm not sure there's a "stable" Axiom in the minds of the upstream
> people just yet.
Hmm, good question.
> I had Axiom on my Debian systems when I was running Debian but
> never had a chance to play with it. It takes several hours to
> build from source on a fast machine.
Yep - reminds me of acl2's build, or to a lesser extent brl-cad's :-).
All the good stuff takes forever to build ;-).
> I've forgotten what the core symbol crunching engine is -- IIRC it
> carries an older version of one of the four open-source Lisps.
GCL, although of late they have been staying relatively current.
> In any event, I'll join the chorus of "let's have as much support
> for Axiom as we can."
[snip - interesting about Octave vs. R - maybe the Octave interface
should be bolted onto the R core!]
> I don't know what brl-cad and acl2 are/do, so I can't help you there.
Acl2 is... well, here's their own description:
"ACL2 is both a programming language in which you can model computer
systems and a tool to help you prove properties of those models."
Here's one of its more famous uses:
"Remember the Intel FDIV bug? The first Pentium [trademark, Intel, Inc]
could not divide floating-point numbers correctly and it reportedly
cost Intel $500 million to fix. At the time that was happening, we used
ACL2 to verify that the floating point division microcode on AMD's
competing microprocessor, the AMD-K5, was correct. AMD used ACL2 to
verify the elementary floating-point operations for the recently
This and HOL4 would be my first two candidates for proof systems to
create ebuilds for. I took the bugzilla one for 2.8 and tried it on
2.9 (the current version) - it seemed to build successfully, although
I've not done any fancy testing with it yet.
BRL stands for Ballistic Research Laboratory - this is a powerful
constructive solid geometry (CSG) modeling package used by the army for
decades to do real world simulation. It was recently released as open
source software, and it has the potential to plug a major gap in the
lineup of open source software solutions. Unfortunately, it's history
is so long that it predates Linux and the library naming conventions
that go with it, and uses tweaked versions of other standard libraries.
The result is that an improper install will wreck havock on an
unsuspecting Gentoo box :-/. I ultimately had to reinstall. What it
needs is to have all relevant libraries in their own directory (say
/usr/lib/brlcad/) and go from there, but I don't know how to make an
ebuild that a) builds it with those targets and b) updates the system
correctly so brl-cad doesn't try to use the wrong libraries (e.g. in
/usr/lib) or not know about the ones in /usr/lib/brlcad.
I'm a bit like you - I love to tinker. The odds I'll do any serious
CAD work with BRL-CAD are remote, but I like the idea of it being
available in case I DO hit something that makes it necessary/worthwhile
to put in the time. So if you've got the itch, I recommend BRL-CAD
:-). (incidently, the main interaction environment is not called
brlcad - it's something I forget at the moment. But if typing brlcad
doesn't do anything it's not unexpected.)
> Where *I* would focus "gentoo-science" -- indeed, all of Gentoo --
> is on packages that are vibrant, alive and even chaotic upstream.
> Right now, that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs,
> NS/NAM, etc.
> ... the stuff that's on *my* hard drive. :)
You definitely want to check out BRL-CAD - it's still actively used by
quite a few people, IIRC. The project lead is Sean Morrison - very
helpful guy. Even if you don't do CAD, worth a look as a potential
assist to open source in general :-). I always make sure I've got
Blender installed for the same reasons (or non-reasons :-P) even though
you can fit my artistic talent in the head of a pin :-/.
Start your day with Yahoo! - make it your home page
email@example.com mailing list