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 instruction


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.
Date: Wed, 05 Jun 2002 21:53:50 +0300

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...
>
> BTW camm, thanks for maintaining this easy to build and fast CLISP.
>
> 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.
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.

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.

-------------------------------------------------------------------------------

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

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

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

works while

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

not.

I'm a bit puzzled :-(

Vadim

--
     Vadim V. Zhytnikov

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






reply via email to

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