[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More on making AKCL
More on making KCL re. wfs's re.
I did not wish to imply that KCL was unreliable. I have found no serious
bugs. My suggestion is simply about how the system could be constructed
so that someone like myself who has limited time to study the details
and certainly not to read the V/ files could work with it more easily.
Currently the system seems to run like this:-
1) Merge OldKCL into AKCL, including compiler .c files
2) Make AKCL with the OLD KCL compiler
3) Compile the new compiler with the old one
4) Make AKCL.
This has then been heavily modified because the old compiler .c files
are no longer compatible with the new AKCL data structures, not surpisingly.
My first suggestion is simply to remove the dependancies on the old KCL
INTERMEDIATE files as follows:-
1) Copy the OldKCL SOURCES into AKCL, excluding the compiler .c files.
(The oldKCL files can now be archived).
2) Merge in the Source changes.
3) Compile an interpretive version of AKCL, directly from sources.
This will be slow.
4) Make the Compiled AKCL.
When Bill S. or others wish to change AKCL they could simply repeat
step 4 using a reliable version to produce the next debug version.
This would be fast. When a new distribution is loaded KCL could compile
itself twice, once interpreted and once compiled, the results should be
identical. My point is please don't try to optimise step 3 with such tricks
as loading the .o files as you go.
My other, less important point is that it would be nice if the makes
were so organised as to not rely on dynamic linking or save-system, so
that it would easy to port a usefull subset of AKCL to other machines.
The main restriction of this lazy port would be that when new routines
were compiled KCL would have to be stopped and relinked with the new code
in the conventional C way, which is fine if the new machine is not one that
is being used for development.
Other General Notes:-
1) The source of my problems with SCO Unix is that it produces an
error with file names longer than 14 chars, other version fives
seem to simply truncate silently. (I then got into hot water trying
to modify the make procedures). They also seem to have 'fixed' other
things eg. ps only shows processes in your terminal group.
2) My problem with the four basic .lsp files was simply the loop in the
dependancies -- neither evalmacros or defmacro can be loaded before
the other has been because of the DefVar!
Simply calling si::*Make-Special instead from defmacro fixes this.
3) My comments on the C Stack GBC where illconsidered and wrong.
I had forgotten that savejump could be used to force a register save.
I spent many enjoyable hours fixing a similar bug on a mickey mouse
Lisp several years ago.
4) Most AKCL shell scripts already have #!/bin/sh in them, which I think
is fine. I cannot imagine a Unix sytem working without a bourne shell
in /bin. However why not put SHELL= in the make file before the
.defs is merged so that it can be overwritten. The .def files should
be kept as small as possible.
5) My comment on make/include was a complaint against AT&T not AKCL
obvioulsy AKCL must use the lowest common denominator of tools.
6) If the makes need a list of CMP modules to link or load for interpretation
couldn't you continue to use code like
echo $(CMPNEW) | sed ... > load.lsp
7) To avoid people editing sys_kcl.c to include extra modules of
their own why not introduce a dummy rouine init_user that is
in a stub file sys_user.c. This routine could be called after
other KCL initialization and be safly modified by others.
(The init_or_load macro could be placed in a .h file).
A nasty hack to get around the problem in the mean time is to
provide a dummy init_cmpspecial() rouine that calls
init_cmpspec(). I am not recomending this.
People who edited sys_kcl will be in trouble anyway if extra
modules are added.
None of the above changes would affect the product end Lisp users
would see, just what people like myself would see if the automatic
make procedures need any slight modifications.