1 |
C Y wrote: |
2 |
|
3 |
>I have some familiarity with Maxima, in fact I was mixed up with the |
4 |
>original creation of that ebuild (although I was not responsible for |
5 |
>the last complex ebuild dependancy magic that finally made it work.) I |
6 |
>have played a minor role in the development of Maxima itself (some |
7 |
>documentation work and bug finding, primarily). I don't know nearly |
8 |
>enough about the details of ebuilds to offer comprehensive advice, but |
9 |
>I can say with confidence that the ebuilds for various lisps Maxima |
10 |
>uses are going to outpace the release schedule for Maxima, so either |
11 |
>someone needs to keep creating patches to Maxima or preserve the older |
12 |
>lisps with exact version dependancies for a static Maxima to keep |
13 |
>working. If the better idea is judged to be patch from cvs as needed, |
14 |
>I would advise waiting for 5.9.2 before starting that, since there are |
15 |
>a LOT of patches since 5.9.1. (As is, it would be simplier to just use |
16 |
>a cvs tarball instead.) |
17 |
> |
18 |
> |
19 |
I used to be on the CMUCL and SBCL mailing lists because CMUCL is the |
20 |
best overall Lisp for my purposes and SBCL is the most actively |
21 |
developed. In addition to Maxima, I use Lisp for algorithmic |
22 |
composition, and right now CMUCL is the only one that fully supports |
23 |
Rick Taube's Common Music. |
24 |
|
25 |
I guess the fact that there are four "competing" open source Lisps is a |
26 |
"problem", just as the fact that there are two competing open source |
27 |
"emacs" packages is a "problem". Still, I think the various |
28 |
compatibilities/standards/etc. between Maxima and the four |
29 |
currently-existing Lisps are best suited by the current mechanism ... |
30 |
they're all available in Portage in at least one "stable" form, however |
31 |
ancient that might be, and available in "testing" or "unstable" for us |
32 |
amateur beta testers. I don't have a problem joining mailing lists for |
33 |
packages I use and filing bug reports upstream -- ask the Texmacs, R, or |
34 |
Common Music and SBCL folks about that. :) |
35 |
|
36 |
Gentoo is about choice, right? If the choice, however, must be where to |
37 |
allocate finite (or in some cases zero) volunteer developer/maintainer |
38 |
time, I'd cast my vote for CMUCL as the Lisp of choice, at least until |
39 |
SBCL hits 1.0 and gets the callback thing worked out for Common Music. |
40 |
GCL is a tad faster on some benchmarks, and CLISP has "readline" built in. |
41 |
|
42 |
>I would also advise that some more focus be turned on Axiom, which is a |
43 |
>competitor to Maxima and a very powerful program indeed - in some |
44 |
>respects it is unique among computer algebra systems. It's design |
45 |
>lends some hope to the idea of systematically incorporating new |
46 |
>mathematical abilities into it, which is a big deal. It retains deep |
47 |
>awareness of things like mathematical types, and unlike Maxima is much |
48 |
>more fully documented :-/. A cvs ebuild exists and works, with some |
49 |
>edits of the final axiom script produced, but I would like to see a |
50 |
>stable one too. |
51 |
> |
52 |
> |
53 |
I'm not sure there's a "stable" Axiom in the minds of the upstream |
54 |
people just yet. I had Axiom on my Debian systems when I was running |
55 |
Debian but never had a chance to play with it. It takes several hours to |
56 |
build from source on a fast machine. I've forgotten what the core symbol |
57 |
crunching engine is -- IIRC it carries an older version of one of the |
58 |
four open-source Lisps. In any event, I'll join the chorus of "let's |
59 |
have as much support for Axiom as we can." |
60 |
|
61 |
>Unfortunately, I have no significant familiarity with Octave's build |
62 |
>process, having used it only once or twice for minor applications. |
63 |
> |
64 |
> |
65 |
A few years ago at my "day job", I had the opportunity to pick an open |
66 |
source numerical package to embed in some computer performance |
67 |
monitoring and analysis code. At the time, we were doing the analysis |
68 |
off line in Excel and Minitab, because they were cheaper. Most of the |
69 |
"glue code" and data collection was written in Perl, so I considered |
70 |
Perl Data Language (PDL) at first. One of the factors was that the codes |
71 |
needed to be available in Red Hat RPM form, preferably from the Red Hat |
72 |
distribution CDs. That pretty much reduced the contestants to Octave, |
73 |
Lisp-Stat and R, which were available on the Red Hat "professional" |
74 |
workstation" CDs. |
75 |
|
76 |
I did look at Octave, but the two front runners were Luke Tierney's |
77 |
Lisp-Stat and R. Lisp-Stat seemed to be frozen in time, and Tierney |
78 |
himself was working on the R team. R won, hands down, and it's only |
79 |
gotten better since then. Despite the fact that R (formerly known as GNU |
80 |
S) is primarily used for high-end statistical processing, the underlying |
81 |
numerical core and R language are elegant, powerful, extremely well |
82 |
documented and I think *much* more vibrant and alive than GNU Octave. |
83 |
|
84 |
Again, if the choice is where to allocate limited resources, I'd say |
85 |
Octave (and Lisp-Stat) can be left alone and the focus put on R. If |
86 |
someone wants to get ambitious, they could Gentoo-ize the CRAN and |
87 |
Bioconductor package management systems. Dirk Eddelbuettel does this (by |
88 |
hand!) for Debian and it's a thankless job. Even without that, Gentoo is |
89 |
the best scientific workstation around. |
90 |
|
91 |
>Perhaps we could have a "support team" behind someone with official |
92 |
>Gentoo developer status - people could point out significant ebuilds |
93 |
>with most logic in place to the developer, help work out quirks in the |
94 |
>programs/ebuilds, and generally speed things up? Certainly the |
95 |
>developer would bear final responsibility but this way those of us with |
96 |
>five hours every month or so could help out too, particularly for |
97 |
>specialty packages. (BTY, if some genius could figure out brl-cad I |
98 |
>would be grateful - it's going to take me a year at this point :-/.) |
99 |
> |
100 |
> |
101 |
I think we have that now ... anyone can join the mailing list and the |
102 |
Bugzilla site and do whatever they can. I do this because I enjoy |
103 |
learning new stuff -- like R, Maxima, Axiom, Common Music and soon, Ruby |
104 |
and Ruby on Rails. Other folks are doing this for Xen, etc. We get a |
105 |
world-class workstation out of it (at least those of us who can afford |
106 |
an x86-64 :) ) for not a whole lot of money or even time. |
107 |
|
108 |
>There are a fair number of at least partial ebuilds for useful |
109 |
>scientific software stuck in bugzilla - brl-cad and acl2 come |
110 |
>immediately to mind, and I know there are others. Plus a fair number |
111 |
>that don't have ebuilds where it would be useful to have them. Gentoo |
112 |
>is alreay one of the best for scientific software, due to compiling |
113 |
>things being easy and our ebuild pool, but we could definitely do |
114 |
>better. |
115 |
> |
116 |
> |
117 |
I don't know what brl-cad and acl2 are/do, so I can't help you there. |
118 |
Where *I* would focus "gentoo-science" -- indeed, all of Gentoo -- is on |
119 |
packages that are vibrant, alive and even chaotic upstream. Right now, |
120 |
that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs, NS/NAM, etc. |
121 |
... the stuff that's on *my* hard drive. :) |
122 |
|
123 |
>My machine is probably a poor test machine - what gentoo environment |
124 |
>would we need to maintain? |
125 |
> |
126 |
Someday real soon now I'll buy an x86-64, but that's clearly the |
127 |
"vibrant, alice and even chaotic choice". |
128 |
|
129 |
-- |
130 |
M. Edward (Ed) Borasky |
131 |
|
132 |
http://www.borasky-research.net/ |
133 |
http://borasky-research.blogspot.com/ |
134 |
|
135 |
http://pdxneurosemantics.com |
136 |
http://pdx-sales-coach.com |
137 |
http://algocompsynth.com |
138 |
|
139 |
-- |
140 |
gentoo-science@g.o mailing list |