gcl-devel
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.
Date: 05 Jun 2002 17:41:01 -0400

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

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

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