Re: Axiom & internal/external GCL (was: Re: [Axiom-developer] Axiom cvs 040624 build error)

[Camm Maguire]

Greetings!

First of all, regarding the general question of whether gcl source
should be bundled with axiom, I personally feel that whatever Tim
feels is best should prevail here.  

There seem to be a few misconceptions about what can be achieved with
a generic non-source gcl installation however.  I thought I'd clarify
these in case the bundling decision might pivot around them.

root <address@hidden> writes:

> >  - it is possible to build Axiom with an external GCL. In fact, Camm
> >    Maguire, lead GCL developer and debian packager of gcl, axiom, maxima
> >    and other software, is doing exactly that for the axiom debian
> >    package. I don't know however if the machinery has been included in
> >    current sources of Axiom.
> 
> that's not strictly correct. Axiom will not fully run on an external GCL.
> depending on what you are doing it will fail. in particular, axiom adds
> special socket handling code to GCL which will be used by the newly added
> graph capabilities. further, axiom has special build-time flags (documented
> in the top level Makefile) that need to be set to your particular version
> of GCL. If you are not using the same version that is included with the
> Axiom CVS you need to change these flags and rebuild your local version.

I believe that every GCL patch/add-on currently utilized by axiom can
be incorporated without reference to the gcl source, rather simply
having gcl installed in binary form.

To link in C code from C source, one can

1) Put (clines ".....") in a .lsp file, add any lisp interfaces needed
   with (defentry...), compile-file, load, and save-system.

or

2) (compiler::link '("compiled_lisp_modules.o" "if_any.o") "new_image"
   "any_interpreted_init_code_to_be_run_in_the_new_image" "c_module.o
   -lclib.a")

   This also works for dynamic, shared libraries.  The resulting
   new_image will link against any such named in the command above via
   the system's linker loader "ld.so" at runtime.  Check it out with
   ldd. 

Most of the other items if I recall can be effected by setting special
compiler variables (e.g. suppressing warnings and the like).  If we
are deficient in this area and you wish to pursue this, please let me
know.  I want GCL to be as useful to axiom as possible.

> 
> in addition to sockets Axiom is adding code to do machine-level numeric
> support. i have a local version (not yet documented, tested, and checked in)
> which contains support for BLAS (Basic Linear Algebra Subroutines). These
> are built into the GCL image at system build time. Axiom's numerics will
> depend on these routines as well as additional routines that are in the
> queue to add. There has been some discussion about pushing the numerics
> support into GCL as Camm is also the BLAS maintainer. Since Axiom is
> currently the only user it is not clear that GCL wants or needs them.
> 

Here again, you can take your friendly external gcl, run a
compiler::link, and voila, you have your new image.  I hope shortly to
make this even easier.

What's more, if you use -lblas -lg2c in compiler::link, rather that
...libblas.a, you will dynamically link against blas, and I can
guarantee you transparent speedups of a factor of 5 to 10 depending on
the running cpu without recompilation!

> A third package is also in my local version that is going to be added
> which requires GCL changes. I've been working with ltk. This is a 
> lisp TK toolkit that runs on almost every lisp (except, it seems, GCL).
> The current GCL/TK package is broken as far as I can tell. I can get it
> to work but it promptly crashes. We're working on a new Axiom GUI to

I'd be very grateful for a reproducible example so I can fix it :-).

> replace the lost techexplorer and it is being developed using TCL/TK.
> Since the current GCL/TK doesn't work and ltk is almost all native
> common lisp we're going to use it going forward. Hopefully once it
> runs I can convince Camm to support it also but, again, since Axiom is
> the only user it is not clear that it is worth adding it to GCL.
> 

We'd like to support everything, but I feel we have a scalability
problem with the conventional scenario in which lisp add-ons are
linked in.  I.e. special build options or patches/forks for every
xgcl, blasgcl, mpigcl, blasmpixgcl, etc. would rightly appear quite
ludicrous to one used to C development.  GCL is primarily a compiler
and runtime 'libc' -- one should be able to just grab it and compile
whatever code linking against whatever externally supplied libraries
one wants to.  This is clearly a much more modular approach.  And I
don't think we are that far away.  We can doubtlessly make things
easier -- this is something I'd like to work on.

> so it is unlikely, going forward, that Axiom will run on your installed
> version of GCL.
> 

Take care,

> Tim
> 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah