[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Babyl on OZ and XX are now synchronized

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.

What happened:

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.