1 |
--- "M. Edward (Ed) Borasky" <znmeb@×××××××.net> wrote: |
2 |
|
3 |
> I used to be on the CMUCL and SBCL mailing lists because CMUCL is |
4 |
> tge best overall Lisp for my purposes and SBCL is the most actively |
5 |
> developed. In addition to Maxima, I use Lisp for algorithmic |
6 |
> composition, and right now CMUCL is the only one that fully supports |
7 |
> Rick Taube's Common Music. |
8 |
|
9 |
Cool! I didn't know Common Music was in active use. I should look at |
10 |
that more carefully. |
11 |
|
12 |
> I guess the fact that there are four "competing" open source Lisps |
13 |
> is a "problem", just as the fact that there are two competing open |
14 |
> source "emacs" packages is a "problem". Still, I think the various |
15 |
> compatibilities/standards/etc. between Maxima and the four |
16 |
> currently-existing Lisps are best suited by the current mechanism ... |
17 |
|
18 |
I guess it's a problem, but I like that there are so many different |
19 |
environments experimenting with different things. The biggest fly in |
20 |
the ointment right now is ANSI compatibility (*cough*gcl*cough*) - once |
21 |
an ANSI platform can be depended on on all 4 then people can start |
22 |
stretching the various features available on each, and maybe evolve |
23 |
what will become ANSI Common Lisp 2.0 :-) Maxima being able to run on |
24 |
all of them gives us a) a check that the underlying lisp isn't doing |
25 |
unexpected things to results b) assurance that if one lisp dies we have |
26 |
no trouble continuing on c) a good excuse to install lots of lisps ;-) |
27 |
and d) an extra way to shake bugs out of our code (not that we need any |
28 |
help right now, granted...) |
29 |
|
30 |
> they're all available in Portage in at least one "stable" form, |
31 |
> however ancient that might be, and available in "testing" |
32 |
> or "unstable" for us amateur beta testers. I don't have a problem |
33 |
> joining mailing lists for packages I use and filing bug reports |
34 |
> upstream -- ask the Texmacs, R, or Common Music and SBCL folks |
35 |
> about that. :) |
36 |
|
37 |
My main complaint is that, in many cases, the newer release of the |
38 |
lisp/CAS/scientific program in general is likely to contain many fixes, |
39 |
and in fact be more desirable to use generally than the older version. |
40 |
In fact, keeping the older, incorrect version around is an active |
41 |
disservice to people using it thinking it's correct. Perhaps in the |
42 |
case of the various lisps I can see waiting a bit (except for gcl ;-) |
43 |
but in the case of Maxima, when we DO put out a new release there tend |
44 |
to be fixes for mathematically incorrect behavior and other things that |
45 |
make no sense to wait on. It is improbable that Maxima will regress |
46 |
between versions - there's too much room for improvement. I would |
47 |
expect the same would hold for Axiom. Even if there WERE regression, |
48 |
it might not be caught for quite some time, since exercising the |
49 |
capabilities of a CAS is not trivial in and of itself. |
50 |
|
51 |
> Gentoo is about choice, right? If the choice, however, must be |
52 |
> where to allocate finite (or in some cases zero) volunteer |
53 |
> developer/maintainer time, I'd cast my vote for CMUCL as the Lisp |
54 |
> of choice, at least until SBCL hits 1.0 and gets the callback thing |
55 |
> worked out for Common Music. |
56 |
|
57 |
I would tend to agree, except I don't know how CMUCL does on non-x86 |
58 |
platforms. Clisp at least tends to run on ANYTHING, despite it's not |
59 |
being the performance choice. IIRC that's why Clisp was originally set |
60 |
as the no-choice-given default for Maxima, although that may have |
61 |
changed since. |
62 |
|
63 |
> GCL is a tad faster on some benchmarks, and CLISP has "readline" |
64 |
> built in. |
65 |
|
66 |
GCL can use readline too, at this point - not sure if it's in the |
67 |
ebuild by default. |
68 |
|
69 |
Oh, I recommend rlwrap for cmucl, by the way - assuming one is being |
70 |
foolish like me and not using SLIME ;-). Must learn SLIME, must learn |
71 |
SLIME... |
72 |
|
73 |
> I'm not sure there's a "stable" Axiom in the minds of the upstream |
74 |
> people just yet. |
75 |
|
76 |
Hmm, good question. |
77 |
|
78 |
> I had Axiom on my Debian systems when I was running Debian but |
79 |
> never had a chance to play with it. It takes several hours to |
80 |
> build from source on a fast machine. |
81 |
|
82 |
Yep - reminds me of acl2's build, or to a lesser extent brl-cad's :-). |
83 |
All the good stuff takes forever to build ;-). |
84 |
|
85 |
> I've forgotten what the core symbol crunching engine is -- IIRC it |
86 |
> carries an older version of one of the four open-source Lisps. |
87 |
|
88 |
GCL, although of late they have been staying relatively current. |
89 |
|
90 |
> In any event, I'll join the chorus of "let's have as much support |
91 |
> for Axiom as we can." |
92 |
|
93 |
:-) |
94 |
|
95 |
[snip - interesting about Octave vs. R - maybe the Octave interface |
96 |
should be bolted onto the R core!] |
97 |
|
98 |
> I don't know what brl-cad and acl2 are/do, so I can't help you there. |
99 |
|
100 |
Acl2 is... well, here's their own description: |
101 |
|
102 |
"ACL2 is both a programming language in which you can model computer |
103 |
systems and a tool to help you prove properties of those models." |
104 |
|
105 |
http://www.cs.utexas.edu/users/moore/acl2/ |
106 |
|
107 |
Here's one of its more famous uses: |
108 |
|
109 |
"Remember the Intel FDIV bug? The first Pentium [trademark, Intel, Inc] |
110 |
could not divide floating-point numbers correctly and it reportedly |
111 |
cost Intel $500 million to fix. At the time that was happening, we used |
112 |
ACL2 to verify that the floating point division microcode on AMD's |
113 |
competing microprocessor, the AMD-K5, was correct. AMD used ACL2 to |
114 |
verify the elementary floating-point operations for the recently |
115 |
released Athlon." |
116 |
|
117 |
This and HOL4 would be my first two candidates for proof systems to |
118 |
create ebuilds for. I took the bugzilla one for 2.8 and tried it on |
119 |
2.9 (the current version) - it seemed to build successfully, although |
120 |
I've not done any fancy testing with it yet. |
121 |
|
122 |
BRL-CAD (http://brlcad.org/) |
123 |
BRL stands for Ballistic Research Laboratory - this is a powerful |
124 |
constructive solid geometry (CSG) modeling package used by the army for |
125 |
decades to do real world simulation. It was recently released as open |
126 |
source software, and it has the potential to plug a major gap in the |
127 |
lineup of open source software solutions. Unfortunately, it's history |
128 |
is so long that it predates Linux and the library naming conventions |
129 |
that go with it, and uses tweaked versions of other standard libraries. |
130 |
The result is that an improper install will wreck havock on an |
131 |
unsuspecting Gentoo box :-/. I ultimately had to reinstall. What it |
132 |
needs is to have all relevant libraries in their own directory (say |
133 |
/usr/lib/brlcad/) and go from there, but I don't know how to make an |
134 |
ebuild that a) builds it with those targets and b) updates the system |
135 |
correctly so brl-cad doesn't try to use the wrong libraries (e.g. in |
136 |
/usr/lib) or not know about the ones in /usr/lib/brlcad. |
137 |
|
138 |
I'm a bit like you - I love to tinker. The odds I'll do any serious |
139 |
CAD work with BRL-CAD are remote, but I like the idea of it being |
140 |
available in case I DO hit something that makes it necessary/worthwhile |
141 |
to put in the time. So if you've got the itch, I recommend BRL-CAD |
142 |
:-). (incidently, the main interaction environment is not called |
143 |
brlcad - it's something I forget at the moment. But if typing brlcad |
144 |
doesn't do anything it's not unexpected.) |
145 |
|
146 |
> Where *I* would focus "gentoo-science" -- indeed, all of Gentoo -- |
147 |
> is on packages that are vibrant, alive and even chaotic upstream. |
148 |
> Right now, that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs, |
149 |
> NS/NAM, etc. |
150 |
> |
151 |
> ... the stuff that's on *my* hard drive. :) |
152 |
|
153 |
You definitely want to check out BRL-CAD - it's still actively used by |
154 |
quite a few people, IIRC. The project lead is Sean Morrison - very |
155 |
helpful guy. Even if you don't do CAD, worth a look as a potential |
156 |
assist to open source in general :-). I always make sure I've got |
157 |
Blender installed for the same reasons (or non-reasons :-P) even though |
158 |
you can fit my artistic talent in the head of a pin :-/. |
159 |
|
160 |
Cheers, |
161 |
CY |
162 |
|
163 |
|
164 |
|
165 |
____________________________________________________ |
166 |
Start your day with Yahoo! - make it your home page |
167 |
http://www.yahoo.com/r/hs |
168 |
|
169 |
-- |
170 |
gentoo-science@g.o mailing list |