Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.

[John Jorgensen]

Or we could have a configure option "--with-clos" or something. I haven't
learned enough about the build system to offer a patch though...

Another option would be (maybe with their permission) to use the clos and
conditions from another project (ecls for instance).

J*
---------
> Greetings!  First, thanks all for the contributions!  I will commit
> this as soon as we get it into a rudimentary state.  Also would like
> feedback on its implications on image size, especially as it may
> affect maxima.  Should we have pcl .o files, separate from the main
> image, like tkl.o?
> 
> "Vadim V. Zhytnikov" <address@hidden> writes:
> 
> > John Jorgensen wrote:
> > 
> > > I have managed to inelegantly incorporate clcs (in the gcl source tree),
> > > and pcl-gcl (found at;
> > > http://www.ma.utexas.edu/users/wfs/pub/gcl/pcl-gcl-2.1.tgz) into a
> > > "unified" build. In case anyone is interested, here are the instructions;
> > >
> > > 1) Check out gcl from CVS. These instructions may work with the release,
> > >    but I haven't tested it.
> > > 2) Get pcl-gcl-2.1 at the link listed above and untar it into the gcl
> > >    tree.
> > > 3) In the GCL tree, either "mv pcl-gcl-2.1 pcl" or make a soft link.
> > > 4) In gcl/pcl, run "ln -s impl/gcl/makefile.gcl makefile"
> > > 5) From the parent of the gcl source root, apply the attached patch with;
> > >    "patch -p0 <pcl-clcs-gcl.patch". This modifies some makefiles to do
> > >    the build.
> > > 5) From the gcl source root, follow the normal build process.
> > >
> > > run;
> > >
> > > $ bin/gcl
> > > >(list-all-packages)
> > >
> > > to look for the presence of the new packages. I've only done a little
> > > testing on this build, but it's promising.
> > >
> > > Now I realize that the attached patch is the picture of ugliness, but it
> > > gets the job done. Is there any chance that at least the pcl-gcl package
> > > could get put into the CVS tree so that folks don't have to search for
> > > it? After that, maybe someone can clean up my small patch and submit it to
> > > the maintainer...
> 
> I'll try to go over the patch and commit equivalent soon.  Is pcl-2.1
> the latest?
> 
> > >
> > > BTW camm, thanks for maintaining this easy to build and fast CLISP.
> > >
> 
> Glad its useful for you and hopefully others!
> 
> > > J*
> > >
> > >
> > 
> > That is fine and I also confirms that PCL and CLCS (CONDITIONS) can
> > be easily compiled, loaded and resulting big GCL image saved.
> > But having PCL and CONDITIONS in the GCL image file is not enough.
> > External symbols of these packages must be _present_ in LISP (or rather
> > COMMON-LISP) and USER (COMMON-LISP-USER) package.
> > The following script should loosely do the trick. We create COMMON-LISP
> > package, import in it all required symbols from LISP, PCL and CONDITIONS
> > and make all these symbols (export) external in COMMON-LISP.
> 
> Vadim, do you have a suggestion for where this should go?  Assuming we
> save everything in the image, init_gcl.lisp?
> 
> > List clcs_shadow is borrowed rom clcs. The lisp_unexport list is taken
> > from lsp/stdlisp.lsp. These are the symbols which should not be present
> > in the resulting COMMON-LISP package.  Unfortunately these list seems
> > to be incomplete and resulting COMMON-LISP package still have some
> > extra unwanted symbols. But at present this is not a great problem
> > since the first thing which ansi-test verifies is the COMMON-LISP
> > contents.  It will tell us which symbols are missing and which ones are
> > superfluous.
> > 
> 
> Wonderful!
> 
> > BTW, notice that notorious INT in lisp_unexport.
> > Actually this is is the right way to do with it. At first I've tried to 
> > track
> > down
> > its origin and purpose but I failed (not surprisingly that C-code has too 
> > many
> > INT).
> > But we just we do not care vary much.  We just do not want to import it in
> > COMMON-LISP.
> > 
> 
> I too have tried and failed to find the symbol definition.  A todo for
> any would-be helper.  Can one entirely eliminate unwanted symbols in
> lisp via this export/inport functionality?  Then it truly might not
> matter. 
> 
> > -------------------------------------------------------------------------------
> > 
> > (setq clcs_shadow
> >  '(CONDITIONS::BREAK
> >    CONDITIONS::ERROR
> >    CONDITIONS::CERROR
> >    CONDITIONS::WARN
> >    CONDITIONS::CHECK-TYPE
> >    CONDITIONS::ASSERT
> >    CONDITIONS::ETYPECASE
> >    CONDITIONS::CTYPECASE
> >    CONDITIONS::ECASE
> >    CONDITIONS::CCASE ))
> > 
> > (setq lisp_unexport
> >  '(LISP::LAMBDA-BLOCK-CLOSURE
> >    LISP::BYE
> >    LISP::QUIT
> >    LISP::EXIT
> >    LISP::IEEE-FLOATING-POINT
> >    LISP::DEFENTRY
> >    LISP::VOID
> >    LISP::ALLOCATE-CONTIGUOUS-PAGES
> >    LISP::UNSIGNED-SHORT
> >    LISP::DOUBLE
> >    LISP::BY
> >    LISP::GBC
> >    LISP::DEFCFUN
> >    LISP::SAVE
> >    LISP::MAXIMUM-CONTIGUOUS-PAGES
> >    LISP::SPICE
> >    LISP::DEFLA
> >    LISP::ALLOCATED-PAGES
> >    LISP::SUN
> >    LISP::INT
> >    LISP::USE-FAST-LINKS
> >    LISP::CFUN
> >    LISP::UNSIGNED-CHAR
> >    LISP::HELP
> >    LISP::HELP*
> >    LISP::MACRO
> >    LISP::*BREAK-ENABLE*
> >    LISP::CLINES
> >    LISP::LAMBDA-CLOSURE
> >    LISP::OBJECT
> >    LISP::FAT-STRING
> >    LISP::SIGNED-SHORT
> >    LISP::MC68020
> >    LISP::LAMBDA-BLOCK
> >    LISP::TAG
> >    LISP::PROCLAMATION
> >    LISP::ALLOCATED-CONTIGUOUS-PAGES
> >    LISP::*EVAL-WHEN-COMPILE*
> >    LISP::SIGNED-CHAR
> >    LISP::*IGNORE-MAXIMUM-PAGES*
> >    LISP::*LINK-ARRAY*
> >    LISP::KCL
> >    LISP::BSD
> >    LISP::ALLOCATE-RELOCATABLE-PAGES
> >    LISP::ALLOCATE
> >    LISP::UNIX
> >    LISP::MAXIMUM-ALLOCATABLE-PAGES
> >    LISP::ALLOCATED-RELOCATABLE-PAGES
> >    LISP::SYSTEM
> >    LISP::KYOTO
> >    LISP::CCLOSURE))
> > 
> > (make-package "COMMON-LISP" :nicknames '("CL"))
> > 
> > (do-external-symbols (s "LISP")
> >   (if (not(member s lisp_unexport))
> >       (import s "COMMON-LISP")))
> > (import 'lisp:nil "COMMON-LISP")
> > 
> > (do-external-symbols (s "PCL")
> >   (import s "COMMON-LISP"))
> > 
> > (do-external-symbols (s "CONDITIONS")
> >   (if (member s clcs_shadow)
> >       (shadowing-import s "COMMON-LISP")
> >       (import s "COMMON-LISP")))
> > 
> > (do-symbols (s "COMMON-LISP")
> >   (export s "COMMON-LISP"))
> > ;;;(export 'common-lisp::nil "COMMON-LISP")
> > 
> > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") :use
> > '("COMMON-LISP"))
> > (import 'lisp:nil "COMMON-LISP-USER")
> > 
> > (in-package "CL-USER")
> > ----------------------------------------------------------------------
> > 
> > Unfortunately the above code doesn't work as expected (at least as
> > I expect it to work ;-). The problem is with NIL symbol.
> > And this is a bit strange. First trouble is that I export doesn't want
> > to make it external symbol of newly created COMMON-LISP package.
> > GCL executes the following code
> > 
> > (make-package "FOO")
> > (import 'lisp:nil "FOO")
> > (export 'foo::nil "FOO")
> > 
> > without any error or warning but external symbol foo:nil is
> > not created.  The same code (with lisp:nil replace by cl:nil)
> > works well on CLisp and fails on CMUCL like in GCL.
> > I'm not quite sure which way is correct since NIL is quite
> > special symbol but it seems to me that (export nil ...) is buggy in
> > both GCL and CMUCL.
> 
> I'm surprised that CMUCL would have a bug of this nature.  Are you
> sure that nil isn't some implied default in all packages or somesuch?
> Does the clocc test complain about a missing nil?
> 
> > 
> > The second trouble is once again with NIL but now with
> > respect to COMMON-LISP-USER package. Since NIL is not
> > external symbol in COMMON-LISP it is not imported into
> > COMMON-LISP-USER by make-package.  But the real trouble
> > is that subsequent
> > (import 'lisp:nil "COMMON-LISP-USER")
> > does not do the job either! Once again it executes
> > without visible error or warning NIL is not placed in
> > COMMON-LISP-USER!  Very strange since it worked
> > for COMMON-LISP earlier. Actually it is turned out that
> 
> I'm not sure if I follow.  You've imported nil into common-lisp, but
> cannot export, and cannot import into common-lisp-user to begin with?
> How do you know you've got it in common-lisp if you cannot export it? 
> 
> > 
> > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") )
> > (import 'lisp:nil "COMMON-LISP-USER")
> > 
> > works while
> 
> What is the sign of 'working' here?
> 
> > 
> > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") :use
> > '("COMMON-LISP"))
> > (import 'lisp:nil "COMMON-LISP-USER")
> > 
> > not.
> > 
> > I'm a bit puzzled :-(
> > 
> 
> You are doing great!  I think we're close.  In any case, you can
> probably run the clocc test with what you've got, no?  Any reasonable
> results? 
> 
> Take care,
> 
> > Vadim
> > 
> > --
> >      Vadim V. Zhytnikov
> > 
> >       <address@hidden>
> >     <address@hidden>
> >      <address@hidden>
> > 
> > 
> > 
> > 
> > 
> 
>