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

[Vadim V. Zhytnikov]

Camm Maguire wrote:

> 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?

Please don't hurry with committing. We have to sort out new
basic CL package and check how Maxima works with
renewed GCL setup.

As for image it depends on what is our primary goal.
If we want ANSI compliance we must load PCL and CLCS
into GCL image.  Now some concrete figures for i586 with gcc 2.95.3
raw_gcl - 1912242, gcl - 3294522, gcl+pcl - 6939800,
gcl+pcl+clcs - 8070366.  Do we really care about image size
growth?  In my opinion not much. It seems to me that the only area
where such growth may be significant it is some handheld
computers.

Presently Maxima don't use PCL and CLCS but Maxima moves
toward CL compliance and we may need more various standard CL
features for the forthcoming Maxima releases. It already started to
happen with recent numerical Maxima updates.

Maybe the best way is to build full GCL with PCL, CLCS and
possible with other extensions by default and provide lightweight
old style GCL as special configure option.

>
>
> "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?

Yes all this package rearrangement must be done right before image is saved
or earlier.

>
>
> > 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.

We really do not know INT's purpose.  The simple fact that INT is
listed in lsp/stdlisp.lsp indicates that GCL authors were aware of it but they
did not removed it from GCL completely due to some reason.
So let it be in LISP package. LISP is no longer standard CL package
and may contain various nonstandard symbols like INT.
We just don't want it in COMMON-LISP and COMMON-LISP-USER.

>
>
> > -------------------------------------------------------------------------------
> >
> > (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?
>

Well when why CLISP and CMUCL behavior differs?  One of them must be wrong.
But I still don't quite understand what is the right behavior.
Tests stops due to unbound 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?
>

I have cl::nil (nil as internal symbol in common-lisp inherited from lisp)
but cl:nil (nil as external symbol in common-lisp) always gives error
inspite of (export ...).

>
> >
> > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") )
> > (import 'lisp:nil "COMMON-LISP-USER")
> >
> > works while
>
> What is the sign of 'working' here?
>

cl-user::nil is bound

>
> >
> > (make-package "COMMON-LISP-USER" :nicknames '("CL-USER") :use
> > '("COMMON-LISP"))
> > (import 'lisp:nil "COMMON-LISP-USER")
> >
> > not.
> >

cl-user::nil is unbound.
Actually I noticed some other peculiarities with NIL in GCL.
I'll report a bit later as soon as I'll be sure how all these
things must work in theory.

>
> > 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>
> >
> >
> >
> >
> >
>
> --
> Camm Maguire                                            address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

--
     Vadim V. Zhytnikov

      <address@hidden>
    <address@hidden>
     <address@hidden>