🚀 go-pugleaf

Has anyone got emacs GNUS running on the NeXT?  What did you do?  I'm stuck.

THE PROBLEM.  I'm trying to install the most recent version (3.13) of gnus on
a NeXT running (the most recent) Release 2.1 and the most recent version
(18.57.1) Gnu Emacs.  But when I invoke emacs in /NextApps/Terminal and then
invoke gnus (M-x gnus) within emacs, gnus starts up, reads ~/.newsrc if it
exists, and starts reading /usr/lib/news/active; but if the active file is
over roughly 423 lines/groups (mine is 1231 lines), before gnus finishes
reading it or subscribing to its groups, it will fatally and brutally ``IOT
trap'' emacs during one of its ``Garbage collecting'' cycles (and csh will be
returned in an odd state in which it doesn't echo characters typed).

gnus 3.13 also crashes emacs 18.55.121, which comes preinstalled on NeXT R2.1;
that's why Marc Horowitz <marc@mit.edu>, knowing emacs 18.55 had garbage
collection bugs, suggested I install the most recent version of emacs, but
unfortunately that had no effect.  The crash always occurs during a ``Garbage
collecting...'' cycle; it doesn't generate a core file but should if I give
the Mach shell command ``unlimit core''.  As far as I can tell, emacs 18.57
and gnus 3.13 don't ever generate IOT signals, so the must call something
which does; but the only NeXT Mach function I can find which generates the IOT
signal is odd RPC library routine authunix_create_default() (see
/LocalLibrary/NextAnswers/Jan_91/sysadmin.467), and it only IOT signals when
the user is a member of 9 or more groups, which is not the case.  What is the
IOT signal used for?  I can find practically no docs on it.

In a few cases, however, gnus 3.13 DOES NOT crash emacs 18.57.1 and, in fact,
gnus seems to work normally.  This happens when Emacs 18.57.1 is invoked
though John.G.Myers@andrew.cmu.edu's GNU Emacs front end version 2.0 (to
obtain, ``mail archive-server@cc.purdue.edu -s send
next/2.0-release/source/Emacs-2.0.tar.Z''); unfortuantely, because the front
end invokes emacs directly, the setenv variables defined for gnus in ~/.login
are not set (though this doesn't appear to be why gnus works in this case).
And OCASSIONALLY and UNPREDICTABLY, gnus 3.13 also behaved normally and did
not crash emacs 18.57.1 when emacs was invoked from the csh of a dialup
session.

POSSIBLE PATCHES?  MIT SIPB's Matt Power heard about a gnus-coredumping-emacs
bug and suggested I look in Athena's emacs RCS version notes.  So I did so and
I found two changes emacs to support gnus; both changes were by jik@MIT.Edu
(Jonathan I. Kamens) to ``fix gnus coredumping''; one of the changes was a
patch from rms to emacs/src/editfns.c and the other was a somewhat conflicting
patch from jimb to emacs/src/eval.c.  Specifically:
 e40-008-8:/mit/mbparker% attach emacsdev
 e40-008-8:/mit/emacs/emacs-18.57/src/RCS% rlog *
 :
 =============================================================================
 
 RCS file:        editfns.c,v;   Working file:    editfns.c
 head:            1.2
 branch:
 locks:           ;  strict
 access list:
 symbolic names:
 comment leader:  " * "
 total revisions: 2;    selected revisions: 2
 description:
 ----------------------------
 revision 1.2
 date: 91/05/13 19:31:19;  author: jik;  state: Exp;  lines added/del: 25/12
 Changes from rms to possibly fix gnus coredumping:
 * Use new functions insert_from_string and insert_from_string_before_markers.
 * Turn off polling in inint_editfns.
 * Don't call getpwnam(0).
 * Clip_to_bounds: Not static.
 * VMS: use pwd.h from Emacs, not from system.
 * In_accessible_range deleted and replaced with other functions.
 ----------------------------
 :
 =============================================================================
 
 RCS file:        eval.c,v;   Working file:    eval.c
 head:            1.7
 branch:
 locks:           ;  strict
 access list:
 symbolic names:
 comment leader:  " * "
 total revisions: 7;    selected revisions: 7
 description:
 ----------------------------
 revision 1.6
 date: 91/05/21 07:30:44;  author: jik;  state: Exp;  lines added/del: 0/4
 Patch from jimb to fix gnus coredumping problem.
 Only part of his patch was applied, because some of it conflicted with rms'
 changes
 ----------------------------
 :

Are these patches to fix the problem I'm having?  Does the problem I'm having
sound familiar?  Do you know what could be causing the problem I'm having and
how I might fix it?  Or has anyone successfully installed gnus on the NeXT --
what did you do?

Thanks for your time and help, -Mike Parker
mbparker@mit.edu