Re: installation v. 3.2.0
James Rice <Rice@KSL.Stanford.Edu>
Full-Name: James Rice
Message-id: <2946660291-12965165@KSL-EXP-35>
Sender: RICE@KSL-EXP-35.stanford.edu
Date: Mon, 17 May 93 13:44:51 PDT
From: James Rice <Rice@KSL.Stanford.Edu>
To: vraalte@cs.utwente.nl (Frank van Raalte), ontolingua@KSL.Stanford.Edu
Subject: Re: installation v. 3.2.0
In-reply-to: Msg of Mon, 17 May 93 14:13:39 +0200 from vraalte@cs.utwente.nl (Frank van Raalte)
>> duvel% lisp
>> ;;; Sun Common Lisp, Development Environment 4.0.0 , 6 July 1990
>> ;;; Sun-4 Version for SunOS 4.0.x and sunOS 4.1
>> ;;;
>> ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990
>> ;;; by Sun Microsystems, Inc., All Rights Reserved
>> ;;; Copyright (c) 1985, 1986, 1987, 1988, 1989, 1990
>> ;;; by Lucid, Inc., All Rights Reserved
>> ;;; This software product contains confidential and trade secret
>> ;;; information belonging to Sun Microsystems, Inc. It may not be copied
>> ;;; for any reason other than for archival and backup purposes.
>> ;;;
>> ;;; Sun, Sun-4, and Sun Common Lisp are trademarks of Sun Microsystems Inc.
>> ;;; Loading source file "/home/kbs/vraalte/lisp-init.lisp"
>> ;;; Loading source file "/home/kbs/vraalte/.lisp"
>> > (load "defsystem")
>> ;;; Loading source file "defsystem.lisp"
>> #P"/KbsWare/Kif/defsystem.lisp"
>> > (COMPILE-LOAD-ONTOLINGUA)
>> ;;; You are using the compiler in development mode (compilation-speed = 3)
>> ;;; If you want faster code at the expense of longer compile time,
>> ;;; you should use the production mode of the compiler, which can be obtained
>> ;;; by evaluating (proclaim '(optimize (compilation-speed 0)))
>> ;;; Generation of full safety checking code is enabled (safety = 3)
>> ;;; Optimization of tail calls is disabled (speed = 2)
>> ;;; Reading source file "kernel/defpackage.lisp"
>> ;;; Writing binary file "kernel/defpackage.sbin"
>> ;;; Loading binary file "kernel/defpackage.sbin"
>> ;;; Reading source file "kernel/packages.lisp"
>> ;;; Writing binary file "kernel/packages.sbin"
>> ;;; Loading binary file "kernel/packages.sbin"
>> >>Error: No packages named ("COMMON-LISP") exist,
>> but a call to DEFPACKAGE is trying to "use" them.
>> LUCID-RUNTIME-SUPPORT:DO-DEFPACKAGE:
>> Required arg 0 (PACKAGE-NAME): "EPIKIT"
>> Required arg 1 (NICKNAMES): ("EK")
>> Required arg 2 (USES): ("COMMON-LISP")
>> Required arg 3 (SHADOWS): NIL
>> Required arg 4 (IMPORT-SHADOWS): NIL
>> Required arg 5 (IMPORTS): NIL
>> Required arg 6 (EXTERNALS): ("SAVE" "INCLUDES" "EMPTY" "=>" "<=" "<=>" "NOT" "PROVABLE" "<-" "DENOTATION" ...)
>> Required arg 7 (INTERNALS): ("=<" "=" "EXISTS" "FORALL" "LISP" "SETOF" "TRUE" "INDVARP" "SEQVARP")
>> Required arg 8 (SIZE): NIL
>> Optional arg 9 (ADD-USE-DEFAULTS-P): NIL
>> :C 0: Forget about using the packages ("COMMON-LISP")
>> 1: Try loading #P"/KbsWare/Kif/kernel/packages" again
>> :A 2: Abort to Lisp Top Level
>> ->
This looks like you're running an old version of Lucid
common lisp. The current version is 4.1. Lucid has a
certain reputation for nonconfirmant packages.
Although I don't know for sure (I didn't hack on this
bit), I believe that the problem was caused by the
introduction of stub package definitions for the Epikit
and Loom packages to allow you to do OL translations into
these targets without either of them being actually
loaded. I think this change happened after we moved over
to Lucid 4.1, so that would explain why we are not bitten
by this problem.
We no longer have an active version of this Lisp, so
perhaps you can perform a little test for me:
Change the reference to the "COMMON-LISP" packages in the
kernel/packages.lisp file into "LISP" in the defpackage
forms for Epikit and Loom as follows.
(:use #+TI "LISP" #-TI "COMMON-LISP")
goes to
(:use #+(or LCL4.0 ALLEGRO-V3.1 ALLEGRO-V3.2 TI) "LISP"
#-(or LCL4.0 ALLEGRO-V3.1 ALLEGRO-V3.2 TI) "COMMON-LISP")
(:use "COMMON-LISP")
goes to
(:use #+(or LCL4.0 ALLEGRO-V3.1 ALLEGRO-V3.2) "LISP"
#-(or LCL4.0 ALLEGRO-V3.1 ALLEGRO-V3.2) "COMMON-LISP")
If this works for you I can make a proper patch.
Hope this works,
Rice.