[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Babyl on OZ and XX are now synchronized
- To: "Leonard N. Foner" <FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
- Subject: Babyl on OZ and XX are now synchronized
- From: Rob Austein <SRA@XX.LCS.MIT.EDU>
- Date: Mon, 28 Sep 1987 12:33 EDT
- Cc: BUG-EMACS@MC.LCS.MIT.EDU, BUG-BABYL@MC.LCS.MIT.EDU, JBA@OZ.AI.MIT.EDU, PGS@AI.AI.MIT.EDU
- In-reply-to: Msg of 27 Sep 1987 20:30-EDT from "Leonard N. Foner" <FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sunday, 27 September 1987 20:30-EDT
From: "Leonard N. Foner" <FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Hookay. I've finished synching OZ's Babyl to XX's. My wart on ECC's
original kluge has been transformed into something more palatable.
What isn't done:
o The EMACS 165/EMACS 169 issue.
I installed OZ:<EMACS>EMACS.INIT.50 on XX, seems to work.
o I haven't even looked at the ITSen to see what their state is.
Should be ok. You probably want to be very paranoid about installing
new stuff there, but I believe that things are in something
aproximating a consistant state.
o JBA, I haven't acted on the hack you mentioned to me. It won't
happen today (I'm waiting to see if I blew it somehow), but
probably later in the week.
I have installed the most recent versions of BABYL and BABYLM from XX.
There were some problems, but things appear to be working okay now.
First, the stuff in XX:PS:<EMACS>BABYL.OZ-INIT-KLUDGE doesn't quite
work. I'm reasonably sure it's a quoting issue: the ^]'s in the
string cause ?QNS errors (evaluation of q7 is probably happening too
early) if I try to set the variable that way, and using ^A in place
doesn't cause errors, but the ^A'd items don't seem to match any
strings. I haven't taken the time to figure this out; since the whole
thing is OZ-specific anyway, I've just substituted MIT-OZ (what would
have been in q7, the idea of the ^]7's) in place. That variable is
now in OZ's SITE.INIT.
Obviously a brain bubble on my part, I just moved the kludge code into
a new file and forgot about it. Using a literal MIT-OZ instead of ^]7
Second, it appears that the process of dumping a Babyl *never* reads
SITE.INIT, nor does the dumped Babyl read SITE.INIT when it comes up.
Hence, the variable setting in SITE.INIT will not take effect for
dumped Babyl's. (Use @SET TRAP FILE if you don't believe me... I
found it rather odd, too, since TECO.INIT *is* read, and it sets
*Initializations* to have the right pathname for SITE.INIT.
*Initializations* should get run on entry to ^R mode, and then
EMACS.INIT reads SITE.INIT, but this isn't happening for the
dumping-Babyl case because it never reads EMACS.INIT. I haven't
pursued this any further than that.)
What I did to fix that was to embed the variable in the
DUMP-BABYL.INIT file as well. This doesn't seem to me to be a great
idea, since I don't know if that file is sent in a distribution, and
furthermore it means that both locations have to be updated (there are
comments in each location that points at the other). I'm not sure if
instead maybe DUMP-BABYL.INIT should read the contents of SITE.INIT or
EMACS.INIT. That seems to be the best way to solve the problem, but
there might be a screw that I don't know about. If nobody can think
of one, I'll try that solution instead in a week or so.
The comments in DUMP-BABYL.INIT are wrong, EMACS.INIT isn't run by
TECO.INIT, what happens is that *Initialization* is set up to run
EMACS.INIT the first time ^R is entered. But standalone BABYL has its
own *Initialization* routine, which is set up in DUMP-BABYL.INIT and
overwrites the normal *Initialization*. DUMP-BABYL.INIT never enters
^R. Thus EMACS.INIT (and SITE.INIT) are never run. This last is
probably a bug.
The easiest thing would be to run EMACS.INIT explicitly from
DUMP-BABYL.INIT. If that causes problems, move the OZ specific stuff
to DUMP-BABYL.SITE-INIT and make everything else run that file.