Building maxima / mailing lists / sym package

--- Martin RUBEY <rubey@labri.fr> wrote:
> > Regardless of the details, at the heart of this is an expression
> > of frustration that we should all take to heart. 
> 
> I do think so, too.

I agree, but remember that we are still at a developer release stage.  

 
> > Instructions like "build x lisp only from CVS with version n of gcc
> > but not version m before you build version z of maxima" etc. makes
> > me think we are moving in a way that's getting a little out of
> > hand.
> 
> > It's ok for the core developers (perhaps), 
> 
> Well, maybe I was very lucky, but I found CVS VERY simple to use and
> had no troubles building GCL nor Maxima, on the other hand I do
follow
> the list since quite some time now. (Still I'm certainly not a core
> developer...) Moreover, I'm not using xmaxima, and certainly not
> MSWindows.

I too have not had much trouble with CVS.  I think most problems
currently occur when gcc 2.96 is used, which is widely known to be
broken.  (I think we pretty much concluded his problems were related to
that - 2.96 has caused many such disasters.  I've had a few myself. 
That's why I know how to switch a machine to 2.95 - I had to do it when
compiling Berlin.)
 
Instructions like which versions of gcl, gcc and maxima work are
inevitable and quite essential - most open source projects will have
such limitations.  The thing to do is document them.  I don't think
it's an indication of a failure in the way we're doing things.  Anyone
who has ever compiled KDE apps knows what I mean - those are even more
picky about how things are done. 

> > Perhaps one of the problems is that we are miximg
> > intro/devleopers/math/GUI subjects into one mailing list: "Get x 
> > from CVS" should never appear on a
> > non-developer's list, IMHO, and when it does, the time has come to
> > break up the list.

My contention is that the point for breaking up the list should come
when the traffic gets to be too heavy to follow in one list.  The
exception, perhaps, could be a maxima-users vs. maxima-devel, which is
a common breakdown of lists, but at this point since there is no really
good stable release of Maxima, and traffic is relatively low, I'd say
we are better off (for now) where we are.  Most of what I've seen go by
has been legit developer discussion - there have been relatively few
people who have compiled Maxima, so new data points are valid developer
info.  When traffic gets very heavy, that would be the time to break up
the list.
 
> > I suggest something like
> > 	maxima-announce
> > 	maxima-users
> > 	maxima-developers
> > 	maxima-cvs
> > 	maxima-ui
> > as a breakup of this list. It can be broken up into the sourceforge
> > mailing lists which are now gatewayed both directions into
> > sourceforge
> > newsgroups. Newsgroups I find much easier to read.
> 
> I did suggest something similar, but still more detailed (probably
> too  detailed) some time ago.

We already have cvs and developers.  users and ui I don't think are
mature enough topics on the list to warrant their own lists yet. 
Announce might be a good idea.

Note about the ui list - I think the time to fork that into it's own
list will be after we have chosen a default UI to go with, and have it
working at least in a basic form.  Some significant changes to maxima
(particularly in the prompt and parsing departments) will likely be
needed before a really good ui can take off, and until those are
achieved it won't make much sense to split up the two subjects.  Once
the UI is functioning it might make more sense.

> http://www.ma.utexas.edu/pipermail/maxima/2001/001174.html
> 
> I'm not sure yet whether I will move to Axiom, but for my time with 
> Maxima I renew my offer to make a digest of the mail archive.
> (Provided that mail is more or less properly tagged) I find it VERY 
> annoying, that sometimes I remember some issue discussed on the list 
> and find my self spending quite some time before I find it again...

I'm not sure what you mean by tagged - descriptive subjects?  I've
often thought something like a Kernel Cousin for maxima would be
useful.  If I'm ever really bored silly on a Friday night I might look
into the format for KC and start going through the archives.

> Also I think that after release 5.9 we really should think about 
> changes that might be worth some effort, but might not be compatible
> with earlier versions. I'm thinking especially of the scoping issue
> described in the following threads:

[snip]

Not qualified to judge.  Probably 6.0/6.1 would be the more logical
place for that kind of split, since that's when will have official
stable and unstable branches. That sounds like something for the
unstable branch. Jim? What do you think?

> In a different vein, I offer to translate the (french) documentation
> of sym, if there is no translation yet and if there is somebody
> interested...

Yes!  Interested!

> (I do speak a little french, so I won't do it for myself!) In any
> case, sym1.mac should be replaced by the following, because of the
> restructured share directory... (note that there are two different 
> files permut.lisp, one in share/sym, another one in 
> share/combinatorics)

That would be GREAT!  I saw that stuff when I was working on share
directory reorganization, and wondered what to do about it.   A
translation would be a wonderful contribution.
 
> Most important however:
> Thanks for all the great work! I'm really really happy to be able to
> use a free cas by now!

If you do decide to jump ship for Axiom (traitor :-P) I will be
interested to see how you think the two compare.  I've heard Axiom has
some nice features but has a rather significant learning curve.

CY

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com