From bab at entricom.com  Thu Nov 18 21:51:40 2004
From: bab at entricom.com (Bruce Butterfield)
Date: Thu, 18 Nov 2004 13:51:40 -0800
Subject: [cl-prevalence-devel] compile problem with sbcl
Message-ID: <419D196C.90902@entricom.com>

 From today's CVS snapshot of cl-prevalence in SBCL 0.8.16:

* (require 'cl-prevalence)

; loading system definition from #P"/home/bab/.sbcl/systems/s-xml.asd" into
; #<PACKAGE "ASDF3835">
; registering #<SYSTEM :S-XML {93D1AB1}> as S-XML

debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR in thread 14043:
   Execution of a form compiled with errors.
Form:
   (DEFGENERIC FIND-OBJECT-WITH-SLOT
             (SYSTEM CLASS SLOT VALUE &OPTIONAL (TEST #'EQUALP))
             (DOCUMENTATION
              Find and return the object in system of class with slot 
equal to value, null if not found))
Compile-time-error:
   (during macroexpansion of (DEFGENERIC FIND-OBJECT-WITH-SLOT ...))
invalid (TEST #'EQUALP)
in the generic function lambda list (SYSTEM CLASS
                                             SLOT
                                             VALUE
                                             &OPTIONAL
                                             (TEST #'EQUALP))
See also:
   The ANSI Standard, Section 3.4.2



From scaekenberghe at common-lisp.net  Sat Nov 27 08:18:46 2004
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Sat, 27 Nov 2004 09:18:46 +0100
Subject: [cl-prevalence-devel] Re: cl-prevalence bug and patch
In-Reply-To: <5bd1017b04112618583e244d85@mail.gmail.com>
References: <5bd1017b04112618583e244d85@mail.gmail.com>
Message-ID: <F5CDF619-404C-11D9-820F-000A95B3E0D2@common-lisp.net>

James,

Thanks for the feedback. Here is a first reaction, without looking at 
your code.

On 27 Nov 2004, at 03:58, James Wright wrote:

> The first bug is pretty minor: An attempt to serialize a
> standard-object will fail if any of its slots are unbound.

This is probably fixed in the CVS version (among other things) - have a 
look at the mailing list(s).

> The second bug is somewhat mystifying.  Attempting to serialize an
> object that points to another object that points ... to another object
> that points to nothing will fail with a stack overflow if the length
> of the "chain" is any longer than about 1300.  I'm using Lispworks
> with a stack size of 64000.

I never tried chains that long. But yes there might be a problem here: 
the serializer tracks every object it encounters, and is itself a 
recursive process. Although 1300 doesn't seem that large a number. I am 
using LW myself, and sometimes you have to expand the stack a couple of 
times for very recursive code to succeed.

I will have a look at your example later on.

Sven