axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: building wh-sandbox on Windows


From: Waldek Hebisch
Subject: [Axiom-developer] Re: building wh-sandbox on Windows
Date: Sun, 29 Apr 2007 20:14:41 +0200 (CEST)

Bill Page wrote:
> On April 28, 2007 5:11 PM Waldek Hebisch wrote:
> > Note that compilation is part of user interface.  We
> > can choose crippled interface (say only names in current
> > directory), accept inconsincy between Lisps or we resolve
> > this problem in general (for arbitrary paths).  I feel
> > that we should resolve the problem.
> > 
> 
> I do not think that resolving this problem for multiple
> Lisp targets needs to be much of a priority for Axiom
> right now. From my point of view it is enough that we
> now have a version of the Axiom source that compiles
> using GCL in ANSI mode. Being able also to compile
> Axiom using other common lisps like SBCL and CLisp is
> interesting but if their behaviour differs a little
> because of implementation differences allowed by the
> standard, I don't think that is such a big deal.
> 
> Perhaps you can convince me otherwise.
> 

First, Axiom works with ANSI GCL largely due to work with other
lisps -- cmucl port by Jurgen Weiss, Greg Vanuxem sbcl work,
Gaby changes to Shoe translator.  I took subset of patches
developed for sbcl and basicaly it worked -- sbcl catched all
or almost all problems which affected ANSI GCL.

For me sbcl port is of high priority.  Some reasons:

 - Seems to work better then gcl on some targets (like Mac OSX
   or Windows)
 - There is mature code which runs on sbcl but has problems
   on gcl (like web servers)
 - sbcl compiler is much more picky then gcl so we have chance to
   clean our code
 - sbcl seem to catch more errors at runtime than gcl
 - sbcl profiler works for me, but I was unable to use gcl
   profiler
 - performance with sbcl seem to be better

For delivery on Windows I besides using gcl I consider sbcl, clisp
(may be slow but supposedly is quite stable on Windows), Poplog clisp
(the compiler does not optimize as well as sbcl, but compiles very
quickly, compiled code should beat interprters and it works on Windows),
corman (not free but licence seem to allow non-commercial binary
redistribution).

I do not give high priority to other ports (besides sbcl), but once
we have things working in sbcl it should be relatively little extra
work to support other Lisps.  And now is a logical time to do this.

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]