Greetings, Jon -

My experience is that printer errors are particularly nasty - often
you get into situations where the error message can't be printed
because the error wants to print the thing that doesn't work, and
you end up in a recursive mess. Actually, I think ACL has gotten
quite a bit better about this since version 4.0. I can remember
getting into unrecoverable loops with printer errors. I also
remember them being very hard to debug.

In other words, I suspect what you are seeing is a manifestation
of what the Franz folks have done to avoid this problem. The printer
wants to say something like "Error printing <the zzz instance>" but
it knows that won't work because it's already in the middle of
trying to print a zzz instance. So it punts. Sure, they might
be able to do more analysis and figure out what the error is at
the next level, but I don't see this as a bug.

John Collins
-------------------------------------------
Dyte, Jon wrote:
> 
> Hi
> I'm using ACL4.3/Linux at home I think I have found a bug..
> 
> Here goes ;
> 
> (defstruct (zzz (:conc-name nil)
>                 (:print-function print-zzz))
>  (anything 23));; anything is just a meaningless slot
> 
> (defun print-zzz (obj stream level)
>   (write-string "[ " stream)
>   ;; next-lines to deliberatley throw an error
>   (let ((element (car t)))
>     (write element :stream stream))
>   (write-string " ]" stream))
> 
> in the listener on ACL Linux 4.3
> 
> > (setq test (make-zzz))
> > [ #<Printer Error @ #x5654321>#
>                       ^^^^^^^^^^;; this varies
> Note the right " ]" does not get printed
> 
> It seems that the print-zzz should really
> stop with the same error as if (car t) which
> is always an error is typed in the top level.
> 
> Is this a documented error?. I have all the patches
> from the website.
> 
> Jon