Return-Path: glass@postgres.Berkeley.EDU 
Delivery-Date: Wed, 31 Mar 93 14:54:58 -0800
Return-Path: glass@postgres.Berkeley.EDU
Received: from erewhon.CS.Berkeley.EDU by postgres.Berkeley.EDU (5.61/1.29)
	id AA12797; Wed, 31 Mar 93 14:54:40 -0800
Received: by erewhon.CS.Berkeley.EDU (5.57/Ultrix3.0-C) id AA28481; Wed, 31 Mar 93 14:54:49 -0800
Message-Id: <9303312254.AA28481@erewhon.CS.Berkeley.EDU>
To: aoki@postgres.berkeley.edu (Paul M. Aoki)
Subject: Re: [aoki@postgres.berkeley.edu: death] 
In-Reply-To: Your message of Wed, 31 Mar 93 14:51:52 PST.
             <9303312251.AA23791@faerie.CS.Berkeley.EDU> 
Date: Wed, 31 Mar 93 14:54:48 -0800
From: glass@postgres.Berkeley.EDU
X-Mts: smtp

> > this rewrite rule should loop, but would get shut down due to the
> > number of loop invocations (i don't remember if i built in code to
> > give up on extreme numbers of rule invocations)
> 
> hmm, now that i think about it, this doesn't look like it's
> looping like you suggest (ie replace event -> replace event -> 
> replace event -> ...) the stack trace suggests that a single 
> invokation is going deep, like there's a loop in a structure
> somewhere that lispCopy is dying on.
> 
> not that i've looked at the code yet.
> --
>   Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
>                 |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

hmm... my guess is the recursive rule is causing it headaches.  I'd be
surprised if the problem being exhibited isn't the result of either
'event-qualifier' or 'recursive-rule'.  i think the trace is just a
symptom of something barfing because of the above.  but yeah, i agree
with you, i'd prefer to see a long trace of 'replace event....'.

later,
Adam
