David,
Thanks for your suggestions to Tampieri. I certainly agree that a new
contributor should subscribe to the mailing list and study the source. Some
will want to work from the bug list, others will have their own ideas of
areas they want to develop. Another suggestion I'd make is that if the
contributor is thinking of doing something major which will touch many parts
of the system (e.g. add numeric intervals as first-class objects), it would
probably be a good idea to first discuss on the mailing list.
But I don't understand why you suggest "build maxima from cvs source using
at least two different lisps." That seems like an unnecessary burden on
*any* developer, let alone a new developer -- I NEVER do that, and I've been
working on Maxima for 40 years.
What is the point of either the building part or the two Lisps part?
Someone can be very good at math and at writing Lisp code without mastering
the build system and the ins and outs of the various Lisp systems around.
One of the beauties of Maxima (and Lisp-based systems in general) is that
it is easy to add code (interpreted or compiled) dynamically, without the
heavy burden of rebuilding the whole system as in static languages like C.
Yes, before the code goes to production, it should be tested on all the
Lisps we support in case of obscure incompatibilities (which shouldn't arise
with normal math code, but may arise with I/O etc.), but I don't think any
individual developer is in a position to do that.
A new contributor can work on new Maxima or Lisp code, or revise existing
Maxima or Lisp code and in either case simply load it in using load(
<filename> ) with none of the time and trouble of rebuilding the whole
system. That is certainly what I do, starting with the Windows
binaries. There may be parts of the system that have weird dependencies on
load order or whatever, but I'd hope that most math-oriented code (as
opposed to systemsy stuff) is not affected by that.
-s