--- James Amundson <amundson@fnal.gov> wrote:
> On Tue, 2001-12-04 at 13:15, C Y wrote:
> > By the way, is it the plan to integrate
> > the new build system before or after 5.9?
>
> Definitely before. I would like to release 5.9.0 as soon as we've
> decided how the file should be (re)arranged and the build system is
> ready. The latter is getting close. When it gets a little closer I
> will put it in cvs in a separate directory.
Awesome!
> For the former (rearranging the files), I have a half-written script
> that moves and renames files from maxima-pre59 to the new maxima
> module. It also creates a script to do the reverse. Currently they
> are called "migrate" and "unmigrate". I was toying with calling them
> "emigrate" and "repatriate," but I thought that was a little too
> opaque. Suggestions are welcome.
You know you should never tell me that ;-) How are you renaming them?
Is this to standardize the extensions? Here's my food for thought on
the directory problem - these are just ideas, so feel free to tear them
up, ignore them, whatever...
Scrap the share1, share2, etc. system and instead have three
directories - systemextensions, externalpackages, and nonworking.
System extensions would be things like the vect package, which are not
loaded by default but are considered part of the "main" system and we
expect to maintain ourselves. externalpackages would be for things we
aren't maintaining as part of the core maxima effort, but feel are
worth including by default. This will probably have more topic
specific packages. (For example, if Feyncalc, a high energy
Mathematica package, were ported over to maxima, it could go in there.
Few would have use for it, but it would IMHO be a worthwhile
inclusion.) Hopefully as time goes by we will get more of this type of
thing. It'll probably be a bit of a judgement call in some cases as to
where things should go, but at least it would make a little more sense.
Nonworking could hold things like the other vect package, which
apparently isn't working too well right now but we don't want to get
rid of - basically for unmaintained stuff which isn't stable or usable.
That'll mean we have to sort through that mess, but I suspect we have
to do that no matter what.
As for documentation, move everything into a top level directory called
doc, and from there have directories for referencemanual, usermanual,
and whatever else we feel we should include.
We might want to establish a couple standards, such as any module
accepted into systemextensions must be documented in the reference
manual, and figure out some general standard for external packages.
Unfortunately, the documentation for 5.9 won't be much beyond where it
is right now - I haven't had time to put in writing more stuff, and
although Paulo has done some excellent work, we are still a LONG way
from a complete manual. If you like, once we get some technical stuff
straightened out with the TeX, we can take what we've got and include
it with the 5.9 release.
The good news is, Jay has done incredible work with the emaxima mode
and it's almost ready for prime time. He's been incorporating features
form imaxima and batlatex, with niiicce results. Once the bugs are
ironed out I'll announce a standard way to insert examples in the
manual, using emaxima. For those with a postscript viewer, you can get
a preview of what's to come here:
http://maxima.sourceforge.net/basicschapteremacs.ps (This most likely
won't be the final look, but it is the idea.) Most of it uses TeX -
there is also one ascii example, so those of you who are looking for an
ascii manual can get an idea, too. It should be simple to produce all
TeX or all ascii manuals, so everyone (hopefully) will be happy.
CY
__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com