Re: [gentoo-science] Re: Scientific herd leadership

[M. Edward (Ed) Borasky]

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

-- 
gentoo-science@g.o mailing list