From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E7DPH-0005ZC-LC for garchives@archives.gentoo.org; Mon, 22 Aug 2005 14:36:12 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7MEYKWZ008014; Mon, 22 Aug 2005 14:34:20 GMT Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7MEYJhx025456 for ; Mon, 22 Aug 2005 14:34:19 GMT Received: from [67.169.201.4] (c-67-169-201-4.hsd1.or.comcast.net[67.169.201.4]) by comcast.net (sccrmhc14) with ESMTP id <2005082214345901400k3tjje>; Mon, 22 Aug 2005 14:34:59 +0000 Message-ID: <4309E28C.60707@cesmail.net> Date: Mon, 22 Aug 2005 07:34:52 -0700 From: "M. Edward (Ed) Borasky" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050812) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 To: gentoo-science@lists.gentoo.org Subject: Re: [gentoo-science] Re: Scientific herd leadership References: <20050822074856.77312.qmail@web31707.mail.mud.yahoo.com> In-Reply-To: <20050822074856.77312.qmail@web31707.mail.mud.yahoo.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: f160c892-de42-45c2-9e52-5193413d7c40 X-Archives-Hash: ca0fcdb5b4c92a5c858d8d4d706d5093 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@gentoo.org mailing list