RE: [Axiom-developer] sbcl and Axiom

[C Y]

--- "Page, Bill" <address@hidden> wrote:
 
> Anyway, such is the difficulty that is cut out for you in this
> task... :) I hope you can attract the help of others more
> knowledgeable.

It sounds like Tim is on top of the situation.  
 
> > I can load the boot-strap lisp files in boot (after some
> > tweaking) but I have not as yet attempted to repeat the cycle
> > by loading the clisp files produced from that process.  For
> > that cycle to work automatically, changes at the boot->lisp
> > level are necessary.
> 
> Could you give some examples of the "tweaking"?

Sure.  Package names needed to be fixed, for example:

"LISP" -> :cl
"USER" -> :cl-user
"SYSTEM" -> for cases where it is needed in sbcl, like getenv,
:sb-posix
"COMPILER" -> no match found yet in sbcl

(in-package 'BOOTTRAN) type entries -> (in-package :BOOTTRAN)

Logic like (make-package "FOO") (in-package "FOO") <use other packages>
was replaced with a single defpackage statement.

I could dig up a couple more I think, but I think with Tim translating
and cleaning up this code having me work on it is a bit like running
Windows 3.1 to back up a Unix server.

Maybe an idea would be to have Tim post a "files to be cleaned up" list
so we could go to work on the ones he hasn't already delt or is dealing
with - at least clean up the code so it loads elsewhere, even if we
don't know what exactly it's doing.  Although given some of that
autogenerated code, I think the refactoring will be major enough that a
lot of those changes will be of minimal utilty anyway :-/.

> > Since I'm not familiar with make as a tool, I'm trying to keep
> > everything as much as possible in lisp.
> 
> Good luck! make is fundamental to almost all open source (with
> some lisp code and some python code as the only exceptions that
> I know about). I really recommend taking a look at the gnu make
> documentation.

I guess I should.
 
> > Theoretically the build order is the key point, at least once
> > I figure out the technical reason for using multiple images.
> > Also, once the changes needed to run in sbcl are made, those
> > pamphlet files should just plug right into the make process.
> 
> Could you explain a little more about how you see this working?
> It seems to me that more than build order is important.

I think Tim covered it, but basically with lisp files the trick is to
make sure for each file you load and compile any definitions it uses
from other files are already loaded.  That's most of what asdf does -
manange those inter-connections.

> > During development though, I find asdf a bit more convenient
> > for lisp loading - I can easily load, for example, the boot
> > subsystem defined in the boot dir without the rest of the
> > compile proceeding, then incrementally attempt loading each
> > file from the next step. 
> 
> I suppose it is possible to integrate asdf into parts of the
> current build process. You will end up using both make and
> asdf.

Currently, yes.

> > (Currently I'm a bit stalled on interp/sys-pkg.lisp - VMLISP
> > and BOOT exports appear to be causing a bit of confusion,
> > although it may be I haven't sorted out what's really going
> > on yet.)
> 
> Are you trying to build interp starting with the boot image?
> I think that is not the way the current build works. Even the
> axiom_cmu Makefile builds two separate images (depsys and
> interpsys).

Yes, but I don't like the necessity of that.  Tim seems to agree that
the eventual goal is a single pass with a lisp system, although how far
away we are from that being workable I couldn't say.

> > I'm using both the Makefiles and debugsys.lisp for file orders,
> > so they're definitely playing a role, and the files themselves
> > should just plug back into their old spots, once they're working.
> 
> We are here to try to help ... :)

Thanks! :-).  I'm more or less poking around where more skilled folks
are busy, but since most of the new lisp goodies around (CFFI, McCLIM,
scigraph, cl-plplot, etc. etc.) don't run on GCL I was kind of hoping I
could wedge it into sbcl.  However, after having looked at some of the
code I can safely say just getting it on sbcl won't do much.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com