C Y wrote:
I have some familiarity with Maxima, in fact I was mixed up with the
original creation of that ebuild (although I was not responsible for
the last complex ebuild dependancy magic that finally made it work.) I
have played a minor role in the development of Maxima itself (some
documentation work and bug finding, primarily). I don't know nearly
enough about the details of ebuilds to offer comprehensive advice, but
I can say with confidence that the ebuilds for various lisps Maxima
uses are going to outpace the release schedule for Maxima, so either
someone needs to keep creating patches to Maxima or preserve the older
lisps with exact version dependancies for a static Maxima to keep
working. If the better idea is judged to be patch from cvs as needed,
I would advise waiting for 5.9.2 before starting that, since there are
a LOT of patches since 5.9.1. (As is, it would be simplier to just use
a cvs tarball instead.)
I used to be on the CMUCL and SBCL mailing lists because CMUCL is the
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.
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 ...
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. :)
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.
GCL is a tad faster on some benchmarks, and CLISP has "readline" built in.
I would also advise that some more focus be turned on Axiom, which is a
competitor to Maxima and a very powerful program indeed - in some
respects it is unique among computer algebra systems. It's design
lends some hope to the idea of systematically incorporating new
mathematical abilities into it, which is a big deal. It retains deep
awareness of things like mathematical types, and unlike Maxima is much
more fully documented :-/. A cvs ebuild exists and works, with some
edits of the final axiom script produced, but I would like to see a
stable one too.
I'm not sure there's a "stable" Axiom in the minds of the upstream
people just yet. 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. I've forgotten what the core symbol
crunching engine is -- IIRC it carries an older version of one of the
four open-source Lisps. In any event, I'll join the chorus of "let's
have as much support for Axiom as we can."
Unfortunately, I have no significant familiarity with Octave's build
process, having used it only once or twice for minor applications.
A few years ago at my "day job", I had the opportunity to pick an open
source numerical package to embed in some computer performance
monitoring and analysis code. At the time, we were doing the analysis
off line in Excel and Minitab, because they were cheaper. Most of the
"glue code" and data collection was written in Perl, so I considered
Perl Data Language (PDL) at first. One of the factors was that the codes
needed to be available in Red Hat RPM form, preferably from the Red Hat
distribution CDs. That pretty much reduced the contestants to Octave,
Lisp-Stat and R, which were available on the Red Hat "professional"
workstation" CDs.
I did look at Octave, but the two front runners were Luke Tierney's
Lisp-Stat and R. Lisp-Stat seemed to be frozen in time, and Tierney
himself was working on the R team. R won, hands down, and it's only
gotten better since then. Despite the fact that R (formerly known as GNU
S) is primarily used for high-end statistical processing, the underlying
numerical core and R language are elegant, powerful, extremely well
documented and I think *much* more vibrant and alive than GNU Octave.
Again, if the choice is where to allocate limited resources, I'd say
Octave (and Lisp-Stat) can be left alone and the focus put on R. If
someone wants to get ambitious, they could Gentoo-ize the CRAN and
Bioconductor package management systems. Dirk Eddelbuettel does this (by
hand!) for Debian and it's a thankless job. Even without that, Gentoo is
the best scientific workstation around.
Perhaps we could have a "support team" behind someone with official
Gentoo developer status - people could point out significant ebuilds
with most logic in place to the developer, help work out quirks in the
programs/ebuilds, and generally speed things up? Certainly the
developer would bear final responsibility but this way those of us with
five hours every month or so could help out too, particularly for
specialty packages. (BTY, if some genius could figure out brl-cad I
would be grateful - it's going to take me a year at this point :-/.)
I think we have that now ... anyone can join the mailing list and the
Bugzilla site and do whatever they can. I do this because I enjoy
learning new stuff -- like R, Maxima, Axiom, Common Music and soon, Ruby
and Ruby on Rails. Other folks are doing this for Xen, etc. We get a
world-class workstation out of it (at least those of us who can afford
an x86-64 :) ) for not a whole lot of money or even time.
There are a fair number of at least partial ebuilds for useful
scientific software stuck in bugzilla - brl-cad and acl2 come
immediately to mind, and I know there are others. Plus a fair number
that don't have ebuilds where it would be useful to have them. Gentoo
is alreay one of the best for scientific software, due to compiling
things being easy and our ebuild pool, but we could definitely do
better.
I don't know what brl-cad and acl2 are/do, so I can't help you there.
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. :)
My machine is probably a poor test machine - what gentoo environment
would we need to maintain?
Someday real soon now I'll buy an x86-64, but that's clearly the
"vibrant, alice and even chaotic choice".
--
M. Edward (Ed) Borasky
http://www.borasky-research.net/
http://borasky-research.blogspot.com/
http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com
--
[email protected] mailing list
