[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bypassing the Super User
To get around the /usr/include problem, we changed cmpmain.lsp
to pass an extra -I<system-directory>. This will work as long
as cmpinclude.h is kept in the same directory as saved_kcl,
without any extra work when you install kcl. The relevant
code looks like this:
(safe-system
(format nil
#-(or system-v e15 dgux)
#+buggy-cc
#+vax"cc ~@[~*-O ~]-S -I. -I~a -w ~a ; as -J -W -o ~A ~A"
#-vax"cc ~@[~*-O ~]-S -I. -I~a -w ~a ; as -J -o ~A ~A"
#-buggy-cc "cc ~@[~*-O ~]-c -I. -I~a -w ~a"
#+(or system-v e15 dgux) "cc ~@[~*-O ~]-c -I. -I~a ~a 2> /dev/null"
(if (or (= *speed* 2) (= *speed* 3)) t nil)
(namestring si:*system-directory*)
(namestring c-pathname)
#+buggy-cc (namestring o-pathname)
#+buggy-cc (namestring s-pathname)
))
Date: Mon, 5 Sep 88 15:48:43 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET>
To: kcl@CLI.COM
Subject: Re: KCL scoping bug?
Date: Mon, 5 Sept 88
Subject: Re: KCL scoping bug?
In order to make the KCL interpreter run in the same way as the compiled
code, delete all statements in file c/bind.c that contain the C local
variable "special_processed". In the master KCL source file at my hand,
there are 17 such statements:
bool special_processed;
special_processed = FALSE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
if (special_processed) continue;
special_processed = FALSE;
special_processed = TRUE;
if (special_processed) continue;
bool special_processed;
special_processed = FALSE;
special_processed = TRUE;
if (special_processed) continue;
-- Taiichi
From: drl@vuse.vanderbilt.edu (David R. Linn)
Message-Id: <8809051736.AA07905@backup.vuse.vanderbilt.edu>
To: kcl@cli.com, siglisp%kurims.kurims.kyoto-u.junet@utokyo-relay.csnet
Subject: KCL Version scheme (Open letter to the authors)
I have a request to make with respect to keeping track of
versions of KCL. So far as I have been able to tell, the only
version scheme currently used by KCL reflects the date that
the *local* version was produced. I would like to request that
you consider going to a <Major-Version-Number>.<Minor-Version-Number>
or perhaps even <Major>.<Minor>.<Local> as this will help keep
the KCLs in use at different sites in better sync.
I recently encountered this problem when trying to bring up AAAI PCL
in KCL. Gregor's note said that it should work in the "October 15, 1987"
KCL. My version was "August 15, 1987" and the version on CLI.COM
seems to be "June 3, 1987". I strongly suspect that these are all
the same version but have not yet checked.
David
David Linn, System Manager/Postmaster |INET:
Vanderbilt University School of Engineering| drl@vuse.vanderbilt.edu
Post Office Box 1824, Station B |Phone:
Nashville, TN, USA 37235 | [USA] 615-343-6164
From: Taiichi Yuasa <yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET>
To: kcl@CLI.COM
Subject: Re: KCL scoping bug?
Date: Mon, 5 Sept 88
Subject: Re: KCL scoping bug?
In order to make the KCL interpreter run in the same way as the compiled
code, delete all statements in file c/bind.c that contain the C local
variable "special_processed". In the master KCL source file at my hand,
there are 17 such statements:
bool special_processed;
special_processed = FALSE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
special_processed = TRUE;
if (special_processed) continue;
special_processed = FALSE;
special_processed = TRUE;
if (special_processed) continue;
bool special_processed;
special_processed = FALSE;
special_processed = TRUE;
if (special_processed) continue;
-- Taiichi