Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!kolling
From: kolling@decwrl.UUCP (Karen Kolling)
Newsgroups: net.emacs
Subject: v2 of Unipress emacs
Message-ID: <2448@decwrl.UUCP>
Date: Mon, 3-Jun-85 19:10:28 EDT
Article-I.D.: decwrl.2448
Posted: Mon Jun  3 19:10:28 1985
Date-Received: Thu, 6-Jun-85 07:37:28 EDT
Organization: DEC Western Research Lab, Los Altos, CA
Lines: 25


>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.

This is the pits.  Thank goodness I'd already decided that the bug
level in v2 was so high that I'm not going to release it to our users.
We have to have two versions of emacs coexisting, Unipress emacs because
it (up to v2, anyway) is "better", and an old emacs (84? 85?) because
Unipress emacs wedges when our Modula2 users run multi-threaded programs
under emacs shells.  And, natch, both versions share our local hacked ml
files.  Just what I wanted, two copies of all the subsidiary libraries
and half the users having to edit their EPaths.  Why has the format
of the mo files changed, I'd like to know?  

Karen