Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.emacs
Subject: Re: 'load' bug
Message-ID: <994@umcp-cs.UUCP>
Date: Sun, 11-Nov-84 14:33:06 EST
Article-I.D.: umcp-cs.994
Posted: Sun Nov 11 14:33:06 1984
Date-Received: Tue, 13-Nov-84 01:17:07 EST
References: <198@flame.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 22

This problem [core dump from Emacs #264 when loading functions that
load other functions, and when loading via ESC-ESC (load "foo")] is
due to a rather silly oversight:  the code that runs ``compiled''
MLisp tries to save space by freeing any memory used if no ``defun''s
are executed.  Unfortunately, it uses a single global variable to
control this.  When load is invoked recursively (reentrantly?), it
doesn't save and restore this global.

This can be (has been) fixed in my local Emacs.  You actually need
to save 3 variables (ExecutedDefun, code, and codesize, or something
like that).  This needs to be done in two places, too, I think (in
ExecuteMLispFile in compile.c, and in ExecuteMLispLine in the same
file).  UniPress has these changes; dunno when they'll get them out
to other people.

The problem of one file recursively loading itself is more difficult.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland