Re: Install problem ontolingua 4.0James Rice <Rice@HPP.Stanford.EDU>
Date: Mon, 6 Jun 94 17:10:22 PDT
From: James Rice <Rice@HPP.Stanford.EDU>
To: firstname.lastname@example.org (Frank van Raalte)
Subject: Re: Install problem ontolingua 4.0
>> We have a problem installing Ontolingua v4.0 on our system,
>> and hope you can help us. We run Sun Common Lisp 4.0 on
>> a Sun Sparcstation 1 with SunOS4.1.1; The error message
>> will be included at the end.
>> Thanks in advance,
This is caused by some brain-death in the Lucid package
system with their version of defpackage not doing the
right thing in the compilation environment. Lucid
actually fixed this in later releases, so you might want
to get a better release. We're running 4.1.1.
As it happens, there are two ways out of this problem (both
of which we will be taking in our sources for future
releases). Your immediate lossage is being caused by
evaluating the form:
'(ek::<=> ek::=< ek::=> ek::DENOTATION ek::EXISTS ek::FORALL ek::NAME
in the file kernel/packages.lisp. It turns out that this
form is a piece of dead code that didn't get deleted after
a reworking of the Epikit back end. You can simply delete
this form and recompile and you should be ok. This form
will not be present in any new releases.
The second way to deal with the problem is in the
selection of the defpackage implementation to use.
Because we found that a number of implementations had
non-CLtL2 compliant defpackage implementations we provided
our own full version. This is switched off by default and
switched on for some of the older/less compliant
implementations. Switching it on/off is controlled by
#+(or TI ALLEGRO-V3.1 ALLEGRO-V3.2) t
#-(or TI ALLEGRO-V3.1 ALLEGRO-V3.2) nil
in the defsystem file. The reason why we don't use our
defpackage by default is because any implementation
specific hacks like source file recording don't happen in
our implementation. We've come to the conclusion that
there's really no point in trying to be so clever and
certainly no point in relying on Lisp implementations to
do the right thing in their defpackage implementations, so
we're going to make Ontolingua use our own defpackage code
unilaterally from now on, i.e. the defsystem file will
(defparameter oli::*onto-use-canned-defpackage* t
This won't affect anything else on your system. We don't
bash anything, so there shouldn't be any problems
resulting from this and Ontolingua's portability should be
For your immediate problem feel free to use either fix (or
> (load "defsystem")
;;; Loading source file "defsystem.lisp"
;;; 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"
>>Error: Package "EK" not found
(:INTERNAL READ 0):
Required arg 0 (STREAM): #<Stream OSI-BUFFERED-STREAM "/KbsWare/Kif-4/kernel/packages.lisp" C1E9BE>
Required arg 1 (EOF-ERROR-P): NIL
Required arg 2 (EOF-VALUE): #<Stream OSI-BUFFERED-STREAM "/KbsWare/Kif-4/kernel/packages.lisp" C1E9BE>
Required arg 3 (RECURSIVE-P): NIL
:C 0: Use the default package instead
1: Try compiling #P"/KbsWare/Kif-4/kernel/packages" again
:A 2: Abort to Lisp Top Level