Recursive printing errors

[Andrew.Mickish@A.GP.CS.CMU.EDU]

Have you had any other complaints about "recursive printing errors" in MCL?
While I was developing Garnet in MCL, I would get these horrible errors
scrolling infinitely in my listener frequently.  I would usually get them
whenever I tried to load a library file or execute a trap instruction.
Now our users of Garnet are getting them.

I sent a bug report in about this last spring, but was never able to put
together a small example.  Before I spend more time on this, I wanted to
ask if you had any advice about it.

Thanks,

--Andrew Mickish


-------------------------------- forwarded message -------------------------

Date: Fri, 16 Dec 1994 11:14:42 +0500
To: garnet-bugs@cs.cmu.edu
From: tsl1@cornell.edu (Timothy S. Larkin)
Subject: Garnet 3.0 and MCL
Status: RO

This message follows up on my earlier one about the failure of Garnet to
load in MCL 2.01. It appears that Lisp is broken by this package
definition:

(defpackage :COMMON-LISP-USER (:use :COMMON-LISP #+apple :CCL
                                    :KR :KR-DEBUG :GARNET-DEBUG)

As evidence, I find that I can evaluate

          (ccl::require-interface 'types)

before evaluating the defpackage, whereas after the defpackage, the
require-interface form produces

> Error: There is no package named "NIL" .
> While executing: #<error printing #<Recursive printing error> #x156334A>
;  NOTE:
> Error: There is no package named "NIL" .
> While executing: #<error printing #<Recursive printing error> #x156334A>

until the stack overflows.

I haven't yet figured out why the package definition produces this disaster.


Cordially,

timothy larkin
tsl1@cornell.edu