Multi Font Files and Release 6-7

["David D. Loeffler" <Loeffler@MCC.COM>]

Thanks to this note from Bob I have been able to fix the multi-font
problems I mentioned in a previous message.

    Date: Sat, 15 Nov 86 17:34 EST
    From: RWK@YUKON.SCRC.Symbolics.COM

    0)  Files written under Rel-7 and rel-6-7 are not 1supposed
0	to be readable under Release 6.1.  The whole point is
	that you're supposed to load it into 1all0 of your Rel-6
	systems to avoid compatibility problems.

    1)  We have been using Rel-6-7 in-house for a year now.
	That doesn't mean there can't be a bug, but it isn't
	so broken that I don't think your message likely did
	more harm than good.  The risk certainly justifies
	quick investigation, but I think it's better to take
	the time and investigate what the problem really is,
	rather than have several thousand people who've already
	loaded it wondering "oh, no, what have I done?".

	Obviously, that's not how it appeared to you at the
	time, of course, and it's a judgement call no matter
	how you look at it.  It's quite possible that after we
	get this figured out, I'll come to the opposite conclusion,
	I just think it is rather 1improbable0.

    2)  Symbolics software *NEVER* writes *'s.  That's something
	written by Explorer and LMI software.

This bit of information allowed me to isolate the problem and make a fix
to the LMI software that seems to be working.  The problem is that the
* is written by LMI's (we are running release 3) in place of the 0.
Note: it is not a one-to-one mapping which is interesting.  Then when a
Symbolics would read the file it would not interpret the * in the same
way an LMI would.  The problem was difficult to pin down because the
Symbolics would correctly interpret the *'s until there got to be too
many of them.  The odd thing is that the problem never surfaced in
release 6.1 until rel-6-7 was loaded. But since Symbolics never really
supported * it was only a matter of time before their interpretation
and LMI's would diverge.

    3)  Rel-6-7 does not patch the code which 1generates0 the epsilon
	codes; it only patches the code which 1interprets0 them.
	(Don't be faked out by the fact that it patches a 2:tyo
0	 method.  That's used as part of interpreting the input,
	 not as part of generating the output.  Weird, eh?  A holdover
	 from the MIT days of long ago).

This helped too.

    4)  You don't say what what happens when it fails to read properly.

What would happen is when a file was read with too many *'s was read?
Well, the *'s would be put in by the LMI's (in places I could not
determine the reason for) and then when reading the Symbolics would
interpret it as a shift to fontN where N could be any one of the fonts
for the file then it seemed like 1 would use the next font in the font
map and so you can image the strange looking file that would result from
these semi random font changes.

    5)  You don't say that you observed that when you had it in the
	machine with rel-6-7 that it appeared correctly there.  (I.e.,
	did you verify that it isn't a problem with 1reading0 files in
	rel-6-7 instead of a problem with 1writing0 them?)

The problem came from reading the files in but I could not isolate the
problem to whether the LMI was putting in * in the wrong places or if
the Symbolics was interpreting them differently.  I just forced the
LMI's to use 0 instead of * and now all seems to work correctly.

    The evidence you cite contradicts # 2 and 3 above.  This apparent
    contradiction would seem to be the primary focus for investigation.
    Possibilities that come to mind which would also explain #1 are
    that rel-6-7 is misinterpreting a file written by Explorers, or
    that you have a private patch that relates to Explorer files.

Actually we have been editing multi-font files for some time on both
LMIs and Symbolics.  It was only after rel-6-7 was loaded that the font
information got skewed.

    What's really needed is a file which when read into Rel-6-7 and
    written back out again, fails in the manner described.  Surely,
    if you've observed it, you have such files lying around?

The failure was not that Rel-6-7 could not write out and then read in a
file.  It was just that the file was alternately edited on a Symbolics
and LMI.  After the number of font changes grow to large then the file's
font information would get skewed.

	Date: Wed, 5 Nov 86 08:49 CST
	From: David D. Loeffler <Loeffler@MCC.COM>

	    Date: Tue, 4 Nov 86 06:38 CST
	    From: David D. Loeffler <Loeffler@MCC.COM>

	    In Symbolics 3645 3Release 7 Problems0 in Genera 7.0, Mailer 5.2,
	    IP-TCP 52.0, microcode 3645-FPA-MIC 394, FEP 127,
	    fep0:>v127-lisp.flod(44), fep0:>v127-loaders.flod(44),
	    fep0:>v127-debug.flod(31), fep0:>v127-info.flod(44),
	    Machine serial number 4864,
	    h:>loeffler>patches>release-7>mcc-electric-lisp-mode.lisp, on Dave's HAL 9000:

	    We are having 4SERIOUS0 problems with Release 6-7 and multi font files.
	    Our group has 51 Symbolics machines.  2 are running release 7 and the
	    rest are running release 6.1 with Rel-6-7 loaded.  All of our code
	    development uses multi font files and now we have found that the systems
	    running Rel-6-7 have their own way of writting out multi font files so
	    that they can not be read correctly from Release 6 or Release 7.  These
	    files can be read correctly only from other machines running release 6.1
	    with rel-6-7 loaded.  


I retract this statement.  If you have multi-font files and are moving
them between LMI's, TI's and Symbolics then be forwarned that the *'s
may cause serious problems.  I seem to have fixed the problem by forcing
the LMI's here to use 0 instead of *.


  -- Dave