Re: [Axiom-developer] RE: cross-compiling Axiom

[Camm Maguire]

Greetings!

root <address@hidden> writes:

> > Nothing AFAICT in the existing build framework.  I just want to
> > mention that GCL unlike some other lisp systems supports both an
> > interpreter and a compiler.  This is primarily to aid in developing
> > and debugging the compiler, but also provides some means for platform
> > independent work.  The whole Axiom system should load and run
> > interpreted if desired, and if one has a massive amount of time on
> > one's hands :-).  The same holds for the GCL lisp files -- check out
> > the saved_pre_gcl image.
> 
> Axiom already does this. I use it for deep debugging.
> The debugsys image is automatically created in the OBJ/SYS directory.
> 
> > One item of medium term interest in GCL development is a just-in-time
> > byte-code compiler/interpreter for faster platform-independent
> > (i.e. non-native code) execution.  Few have expressed an interest in
> > this thus far.
> 
> CCL (part of the axiom pile) and CLISP both provide this ability.
> Both are portable but slow relative to GCL which was chosen for speed.
> There is also a byte-coded lisp that uses the Java VM. This is a solved
> problem so I wouldn't spend too much time on it.
> 

OK, but would be nice to have all in one place.

> CLISP provides a portable ANSI platform and is the one I'm using to test
> the ANSI port for Axiom. I'm unlikely to release Axiom on that platform
> but will wait use a compiled lisp (hopefully GCL when it is ready).
> 

2.7.0 is getting close.

> Instead of a byte-code effort I'd much rather see the ability to 
> portably construct a window in which I can draw colored lines from lisp.
> Such an effort will make it possible for the graphics to be ported.
> There is a lot of work going on in this area and I think it is important.
> 

Weren't we looking at gcltk last time?  I cleaned this up specifically
for this purpose.

If you can live with X emulation on Windows, etc., you should be able
to try xgcl now.  I.e. you should be able to remove --disable-xgcl
from the compile flags with current 2.6.8pre.  Just do (xgcl-demo) at
the prompt.

Likewise there was the browser/gcl http server idea.

Otherwise, I am at a loss as to what would constitute a good solution
here.  We could get an interface to wxwindows pretty easily, but what
will be definitive and stand the test of time?

> In general I'd take direction from the Java crowd about new functionality.
> Java is interesting only because you can portably do networking, graphics,
> database, etc. Lisp is missing the fundamental support hooks to build
> these libraries.
> 

Alas, that boat has already sailed.  I don't think it will ever be
possible to revise the ansi lisp standard to include graphics and
networking.  My own opinion is to bring lisp as close to C as possible
in regard to these missing items -- then we will be assured of some
longevity.  And I don't think we need to fret about the lack of
standardization here -- as long as we have one good open-source
compiler that will never go away and can be bent to our needs, that's
all we should ever want.  If I had to design all the C code I write to
work on gcc, icc, portland, .... my productivity would be destroyed --
gcc is good enough, and is not going away in my lifetime.  As far as
axiom goes, I'm far more interested in fixing math bugs and adding
math functionality, though clearly I haven't been contributing in this
area (yet).  I don't particularly care about SPAD vs. Aldor either --
as long as we have one language under our control that is open and
forever, I'm grateful.

Speaking of networking -- a Debian user just found a bug in our socket
code which has now been fixed in cvs, in case you want to update.

Take care,


> Just my opinion.
> 
> t
> 
> 
> 

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