Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site prism.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!mhuxn!mhuxm!sftig!sftri!sfmag!eagle!ulysses!allegra!mit-eddie!think!prism!matt
From: matt@prism.UUCP
Newsgroups: net.emacs
Subject: Re: Orphaned Response
Message-ID: <3300002@prism.UUCP>
Date: Wed, 29-May-85 14:33:00 EDT
Article-I.D.: prism.3300002
Posted: Wed May 29 14:33:00 1985
Date-Received: Sun, 2-Jun-85 04:24:02 EDT
References: <33800004@gypsy.UUCP>
Lines: 56
Nf-ID: #R:gypsy:33800004:prism:3300002:000:2983
Nf-From: prism!matt    May 29 14:33:00 1985


/**** prism:net.emacs / mirror!rs / 11:40 am  May 29, 1985 ****/
we just brough V2.01 up yesterday.  the only real problems so far
seem to have been because of outdated .mo (MLisp Object) files.
In particular, we're running both old and new emacs.  Old emacs
recompiles the new emacs mlisp files, because it knows they're
out of date.  New emacs doesn't seem to do this.  What problems have
you been having?
/* ---------- */

To clarify and expand on mirror!rs's comment, the .mo situation is
this:  Gosling's v264 will look at .mo files produced by Unipress
2.01, realize they are out of date, and (silently) recompile the
mlisp sources to produce old format .mo files.  When Unipress 2.01
tries to read the old format files, it does dump core.

This is actually a more subtle problem than it seems, if you have
users trying to use different versions of Emacs with overlapping
EPATHs.  Periodically, someone here will try to invoke the old (264)
Emacs for some reason, trashing many of the .mo files in the maclib
directory.  Then everyone else's new Emacs (Unipress) suddenly core
dumps the first time it tries to read a .mo that's been ambushed.
The situation is even worse if you have people using EACH OTHER's
private Emacs mlisp directories.

The moral is: don't even TRY for a smooth transition from one
version to another.  Just have one or two people beta test Unipress
2.01, then dump it on people, with adequate guidance for them to
change over in one fell swoop.

There are some other circumstances that will crash Unipress Emacs:
in particular, typing "Meta-X line-number" will cause it to hang.
Also, I have found that typing "Meta-X set error-message-format %f %l
Error [0-9]*:.*" (the error message format the Lattice C
cross-compiler, also from Unipress, happens to produce) followed by a
"Meta-X parse-error-messages-in-region"  will cause a core dump on a
Pyramid.

Another lesser gripe concerns the display code - Gosling's was smart
enough to use linefeed and reverse linefeed to scroll the screen up
or down by one line.  Unipress, for some reason, changed the display
logic so that scrolling by even one line causes the entire screen to
be repainted from the top down.  This is agonizingly slow and broken
behavior, but it seems possible to get around it by writing your own
compiled terminal description and linking it with Emacs.  What you
do if you don't have source, I do not know.

Overall, though, Emacs 2.01 seems to have some real improvements
over Gosling's v264.  The rewrite of process handling is especially
nice, as is the handling of error message formats.  (No more piping
lint output through sed to make next-error grok the messages.)

-----------------------------------------------------------------------------
 Matt Landau            {cca, datacube, ihnp4, inmet, mit-eddie, wjh12}...
 Mirror Systems, Inc.                                   ...mirror!prism!matt
-----------------------------------------------------------------------------