[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Babyl on OZ and XX are now synchronized
- To: Rob Austein <SRA@XX.LCS.MIT.EDU>
- Subject: Babyl on OZ and XX are now synchronized
- From: "Leonard N. Foner" <FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
- Date: 27 Sep 1987 20:30 EDT (Sun)
- Cc: BUG-EMACS@AI.AI.MIT.EDU, Foner%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, "Patrick G. Sobalvarro" <PGS@AI.AI.MIT.EDU>, JBA%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.
o I haven't even looked at the ITSen to see what their state is.
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.
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.