Axiom is free software, available under a BSD like license. For more details, please have a look in the licences available in the CVS repository.

## What is the future of Axiom?

Tim Daly is Lead Axiom Developer. He has a fairly detailed agenda for Axiom.

## What is Axiom size?

Axiom is:
• 92 MB of source code
• about 56 MB once compiled
• 403591 lines for the interpreted in 220 files
• 255790 lines of algebra in 371 files

## On which system is known to run Axiom?

People have compiled and run Axiom on:
• Debian GNU/Linux 3.0, on i386, Sparc64. On PowerPC architecture, Axiom will not build because it requires gcc-3.3 (which supports -mlong-calls option, supporting relocs of more tha 24 bits).
• Debian GNU/Linux sid, on mipsel, ia64, i386, ppc, alpha, and sparc (and more to come!)
• RedHat Linux 7.3 and 9.0 on i386
• Slackware Linux 8.0.01 on Intel ProLiant ML530 2@800MHz
• Red Hat Linux 8.0 on Intel ProLiant ML530 2@1.0GHz -- Red Hat Enterprise Linux ES release 2.1 (Panama)
• SuSE Linux Ent Svr 8.0 on Intel ProLiant DL360 G2 2@1.4GHz
• Red Flag Linux 4.0
• Microsoft Windows

## How do I submit a patch?

In general a patch file is of the form

cd the.dir
diff -Naur file.pamphlet file.pamphlet.new >the.dir.file.pamphlet.patch
send the patch to the Axiom mailing list
<axiom-developer@nongngu.org> or
Tim Daly <daly@axiom-developer.org>

this has several features:
* it tells me where the patch is being applied
* the Naur options give me context
* I can see the impact of a change to multiple files

I read the patches before applying them so be sure to document the
reasons for the change in the pamphlet file. It may seem trivial
but remember that I didn't do the initial analysis so I, and others,
will have to understand after the fact.

In most cases in a pamphlet file if you're changing a few lines
of code or a whole function it should be documented thus:

...

(defun foo ()
(list
"this is ok code"
"this is broken code"
"this is also broken"
"this is ok"
)
)

turns into

\subsection{foo list fix}
\begin{verbatim}
"this is broken code"
"this is also broken"
\end{verbatim}
but clearly the elements of the list are wrong. We are going to
print this list for the user so we don't want them to know anything
is broken. Thus we have wonderful new code that will inspire confidence.
This list is printed with the [[printlist]] function.
<<foo list fix>>=
"this is great code"
"this inspires confidence"
@

...

(defun foo ()
(list
"this is ok code"
<<foo list fix>>
"this is ok"
)
)

and, yes, I do know that this is tedious.

In general, it is also useful to update the pamphlet files with
documentation-only changes as you understand what a block of code
is intended to do. Most of this information has been lost to history
and the world can leverage your efforts at understanding if you take
the time to document it. In many ways this is as important as fixing
the code.