From rudi at constantly.at  Mon Aug 13 11:46:57 2012
From: rudi at constantly.at (Rudi Schlatte)
Date: Mon, 13 Aug 2012 13:46:57 +0200
Subject: [closer-devel] Closer-mop support for ABCL
Message-ID: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>

Greetings,

ABCL 1.1, expected in 2-3 months from now, will have a mop implementation that passes the mop test suite without missing features.  The work is finished in svn and can be checked out at http://svn.common-lisp.net/armedbear/trunk/abcl/.

It would be great if we had closer-mop support by release time; attached is a naive patch (which assumes that abcl needs nothing in closer-mop-shared).  I also re-send the abcl patch for mop-feature-tests.  The closer-mop patch is written to give an error if :mop isn't on *features*, this feature is present in the mop-supporting svn version of abcl and will be in the released version as well, so if you decide to merge the patch, users of the old release will get a sensible error message.

Cheers,

Rudi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: closer-mop-abcl.patch
Type: application/octet-stream
Size: 1823 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20120813/79ed1806/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mop-feature-tests-abcl.patch
Type: application/octet-stream
Size: 745 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/closer-devel/attachments/20120813/79ed1806/attachment-0001.obj>
-------------- next part --------------



From pc at p-cos.net  Sun Aug 19 15:49:10 2012
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 19 Aug 2012 17:49:10 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
Message-ID: <CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>

Hi Rudi,

I'm currently looking into adding support for ABCL 1.1 to the Closer project. I'm not only adding the support for Closer to MOP itself, but I'm also testing whether the other packages work (like ContextL, etc.).

I found a bug with regard to the slot layout of metaobject classes. It seems that fixed slot positions are assumed where this shouldn't be the case. Here is a transcript that illustrates the problem:

CL-USER(6): (defclass my-effective-slot-definition (standard-effective-slot-definition)
              ((additional-information :initarg :additional-information)))
#<STANDARD-CLASS MY-EFFECTIVE-SLOT-DEFINITION {55FD7136}>

CL-USER(7): (defclass my-class (standard-class) ())
#<STANDARD-CLASS MY-CLASS {1A78B825}>

CL-USER(8): (defmethod effective-slot-definition-class ((class my-class) &rest initargs)
              (find-class 'my-effective-slot-definition))
#<STANDARD-METHOD EFFECTIVE-SLOT-DEFINITION-CLASS (MY-CLASS) {6B8192B6}>

CL-USER(9): (defclass person () 
              ((name :initarg :name))
              (:metaclass my-class))
#<MY-CLASS PERSON {5E1F5FC7}>

CL-USER(10): (make-instance 'person :name "test")
#<THREAD "interpreter" {69996E15}>: Debugger invoked on condition of type PROGRAM-ERROR
  Invalid initarg :NAME in call to MAKE-INSTANCE with arglist (#<PERSON {79B1A66B}> :NAME "test").
Restarts:
  0: TOP-LEVEL Return to top level.

[1] CL-USER(11): (class-slots (find-class 'person))
(#<MY-EFFECTIVE-SLOT-DEFINITION {7E24F937}>)
[1] CL-USER(12): (inspect (first *))
   0 LAYOUT -----------> #<LAYOUT {2D65CA94}>
   1 ADDITIONAL-INFORMATION -> #<UNBOUND>
   2 NAME -------------> NAME
   3 INITFUNCTION -----> NIL
   4 INITFORM ---------> NIL
   5 INITARGS ---------> (:NAME)
   6 READERS ----------> NIL
   7 WRITERS ----------> NIL
   8 ALLOCATION -------> :INSTANCE
   9 ALLOCATION-CLASS -> 0
  10 LOCATION ---------> NIL
  11 %TYPE ------------> T
  12 %DOCUMENTATION ---> NIL

Due to the additional slot that is added in my-effective-slot-definition, the ABCL MOP seems to get confused. The slot location for the 'name slot in the class 'person is stored in 'allocation-class instead of 'location. It seems that the index 9 is hard-wired for 'location in the ABCL MOP.

Can this still be fixed for ABCL 1.1?

It's probably better to add new slots in higher index positions instead of the low index positions, so the low index positions can indeed be hard-wired. But I'm not sure how easy it is to do this?

Best,
Pascal

On 13 Aug 2012, at 13:46, Rudi Schlatte <rudi at constantly.at> wrote:

> Greetings,
> 
> ABCL 1.1, expected in 2-3 months from now, will have a mop implementation that passes the mop test suite without missing features.  The work is finished in svn and can be checked out at http://svn.common-lisp.net/armedbear/trunk/abcl/.
> 
> It would be great if we had closer-mop support by release time; attached is a naive patch (which assumes that abcl needs nothing in closer-mop-shared).  I also re-send the abcl patch for mop-feature-tests.  The closer-mop patch is written to give an error if :mop isn't on *features*, this feature is present in the mop-supporting svn version of abcl and will be in the released version as well, so if you decide to merge the patch, users of the old release will get a sensible error message.
> 
> Cheers,
> 
> Rudi
> 
> <closer-mop-abcl.patch>
> <mop-feature-tests-abcl.patch>
> 
> _______________________________________________
> closer-devel mailing list
> closer-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

--
Pascal Costanza






From rudi at constantly.at  Sun Aug 19 20:21:22 2012
From: rudi at constantly.at (Rudolf Schlatte)
Date: Sun, 19 Aug 2012 22:21:22 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
Message-ID: <D389930B-23A1-4BD5-ADFF-1AC35A68016A@constantly.at>


On Aug 19, 2012, at 17:49, Pascal Costanza <pc at p-cos.net> wrote:

> Hi Rudi,
> 
> I'm currently looking into adding support for ABCL 1.1 to the Closer project. I'm not only adding the support for Closer to MOP itself, but I'm also testing whether the other packages work (like ContextL, etc.).

Hi Pascal, that excellent news!  Version 1.1 is a bit away still (current status: http://trac.common-lisp.net/armedbear/milestone/1.1.0), so now is an excellent time for bug reports.

> I found a bug with regard to the slot layout of metaobject classes. It seems that fixed slot positions are assumed where this shouldn't be the case. Here is a transcript that illustrates the problem:

[..]

The slot definition class is defined Java-side in funky ways and has other problems as well (http://lists.common-lisp.net/pipermail/armedbear-devel/2012-August/002567.html) so it will get a good long look soon.

Rudi




From rudi at constantly.at  Sat Aug 25 21:21:37 2012
From: rudi at constantly.at (Rudolf Schlatte)
Date: Sat, 25 Aug 2012 23:21:37 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
Message-ID: <9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>


On Aug 19, 2012, at 17:49, Pascal Costanza <pc at p-cos.net> wrote:

> Hi Rudi,
> 
> I'm currently looking into adding support for ABCL 1.1 to the Closer project. I'm not only adding the support for Closer to MOP itself, but I'm also testing whether the other packages work (like ContextL, etc.).
> 
> I found a bug with regard to the slot layout of metaobject classes. It seems that fixed slot positions are assumed where this shouldn't be the case. Here is a transcript that illustrates the problem:

Hi Pascal,

Thanks for the report and diagnosis!  This (and a related bug reported by Stas Boukarev) are hopefully fixed in svn.

Slot objects are allocated deep in Java-land (see SlotDefinition.java resp. clos.lisp:make-(direct|effective)-slot-definition for boring details) and the accessors defined in the SlotDefinition class used to believe they know everything about the layout of slot objects.  r14134 adds code paths for normal standard-object slot definitions.

Thanks again,

Rudi




From pc at p-cos.net  Sun Aug 26 14:28:40 2012
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 26 Aug 2012 16:28:40 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
Message-ID: <BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>

Hi Rudi,

I'm now seeing other bugs: There is a Java-level index-out-of-bounds error caused by a call to %set-standard-instance-access somewhere. However, it's pretty hard to figure out where and why that happens, because the Java error message doesn't tell me where in the Lisp code I am. Can you recommend any tricks how to localize errors better?

I could also make the Closer to MOP changes already available and tell you which test programs cause the problem, in case you would like to take a look at this yourself. Just let me know.

Just a minor thing: Sometimes, you have to declare keyword arguments in CLOS methods just to tell CLOS that a specific keyword argument is acceptable, even if it is not used (see 7.6.5 in the HyperSpec). ABCL gives style-warnings in such cases, but I don't think that should happen?

Best,
Pascal

On 25 Aug 2012, at 23:21, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Aug 19, 2012, at 17:49, Pascal Costanza <pc at p-cos.net> wrote:
> 
>> Hi Rudi,
>> 
>> I'm currently looking into adding support for ABCL 1.1 to the Closer project. I'm not only adding the support for Closer to MOP itself, but I'm also testing whether the other packages work (like ContextL, etc.).
>> 
>> I found a bug with regard to the slot layout of metaobject classes. It seems that fixed slot positions are assumed where this shouldn't be the case. Here is a transcript that illustrates the problem:
> 
> Hi Pascal,
> 
> Thanks for the report and diagnosis!  This (and a related bug reported by Stas Boukarev) are hopefully fixed in svn.
> 
> Slot objects are allocated deep in Java-land (see SlotDefinition.java resp. clos.lisp:make-(direct|effective)-slot-definition for boring details) and the accessors defined in the SlotDefinition class used to believe they know everything about the layout of slot objects.  r14134 adds code paths for normal standard-object slot definitions.
> 
> Thanks again,
> 
> Rudi
> 
> 
> _______________________________________________
> closer-devel mailing list
> closer-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

--
Pascal Costanza






From rudi at constantly.at  Sun Aug 26 15:14:43 2012
From: rudi at constantly.at (Rudolf Schlatte)
Date: Sun, 26 Aug 2012 17:14:43 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
Message-ID: <89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>


On Aug 26, 2012, at 16:28, Pascal Costanza <pc at p-cos.net> wrote:

> Hi Rudi,
> 
> I'm now seeing other bugs: There is a Java-level index-out-of-bounds error caused by a call to %set-standard-instance-access somewhere. However, it's pretty hard to figure out where and why that happens, because the Java error message doesn't tell me where in the Lisp code I am. Can you recommend any tricks how to localize errors better?

Thanks, r14135 catches that and throws a Lisp-side type error.  This should give you a more helpful backtrace.  I think in general Lisp code should never result in uncaught Java exceptions, so I'd be happy to fix any that you find.

Rudi





From pc at p-cos.net  Sun Aug 26 16:40:10 2012
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 26 Aug 2012 18:40:10 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
	<89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
Message-ID: <1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>


On 26 Aug 2012, at 17:14, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Aug 26, 2012, at 16:28, Pascal Costanza <pc at p-cos.net> wrote:
> 
>> Hi Rudi,
>> 
>> I'm now seeing other bugs: There is a Java-level index-out-of-bounds error caused by a call to %set-standard-instance-access somewhere. However, it's pretty hard to figure out where and why that happens, because the Java error message doesn't tell me where in the Lisp code I am. Can you recommend any tricks how to localize errors better?
> 
> Thanks, r14135 catches that and throws a Lisp-side type error.  This should give you a more helpful backtrace.  I think in general Lisp code should never result in uncaught Java exceptions, so I'd be happy to fix any that you find.


OK, thanks a lot! This works better now.

However, the error message doesn't seem to make any sense:

Error loading /Users/costanza/lisp/develop/closer/contextl/test/demo3.lisp at line 51 (offset 1410)
#<THREAD "interpreter" {3ADE1520}>: Debugger invoked on condition of type TYPE-ERROR
  The value 1 is not of type (INTEGER 0 1).
Restarts:
  0: TOP-LEVEL Return to top level.
[1] CX-USER(2): :bt

  0: (SYSTEM:BACKTRACE)
  1: (INVOKE-DEBUGGER #<TYPE-ERROR {4ADA1DC}>)
  2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
  3: org.armedbear.lisp.Lisp.type_error(Lisp.java:423)
  4: org.armedbear.lisp.StandardObject$pf__set_standard_instance_access.execute(StandardObject.java:489)
  5: org.armedbear.lisp.Symbol.execute(Symbol.java:825)
  6: org.armedbear.lisp.LispThread.execute(LispThread.java:666)
  7: org.armedbear.lisp.clos_671.execute(clos.lisp:3409)

The reason for the confusing error message seems to be that the error message gives instance.slots.length as an upper bound, but I think it should give instance.slots.length-1.

Now I need to figure out why the class has only exactly one slot...


Pascal

--
Pascal Costanza






From rudi at constantly.at  Sun Aug 26 16:58:10 2012
From: rudi at constantly.at (Rudolf Schlatte)
Date: Sun, 26 Aug 2012 18:58:10 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
	<89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
	<1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>
Message-ID: <9DF3873F-9C89-45A7-8D93-FA9BAAEF7266@constantly.at>


On Aug 26, 2012, at 18:40, Pascal Costanza <pc at p-cos.net> wrote:

[...]

> However, the error message doesn't seem to make any sense:
> 
> Error loading /Users/costanza/lisp/develop/closer/contextl/test/demo3.lisp at line 51 (offset 1410)
> #<THREAD "interpreter" {3ADE1520}>: Debugger invoked on condition of type TYPE-ERROR
>  The value 1 is not of type (INTEGER 0 1).

Ah, I copied the type-error-generating code from standard-instance-access which already implemented the bounds check, clearly the upper bound is mis-reported in both places.  Will fix.

> Restarts:
>  0: TOP-LEVEL Return to top level.
> [1] CX-USER(2): :bt
> 
>  0: (SYSTEM:BACKTRACE)
>  1: (INVOKE-DEBUGGER #<TYPE-ERROR {4ADA1DC}>)
>  2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
>  3: org.armedbear.lisp.Lisp.type_error(Lisp.java:423)
>  4: org.armedbear.lisp.StandardObject$pf__set_standard_instance_access.execute(StandardObject.java:489)
>  5: org.armedbear.lisp.Symbol.execute(Symbol.java:825)
>  6: org.armedbear.lisp.LispThread.execute(LispThread.java:666)
>  7: org.armedbear.lisp.clos_671.execute(clos.lisp:3409)

Frame 7 is from (setf slot-value-using-class); expanding the backtrace further will show where that one is called.

Rudi




From pc at p-cos.net  Sun Aug 26 17:17:32 2012
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 26 Aug 2012 19:17:32 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <9DF3873F-9C89-45A7-8D93-FA9BAAEF7266@constantly.at>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
	<89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
	<1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>
	<9DF3873F-9C89-45A7-8D93-FA9BAAEF7266@constantly.at>
Message-ID: <56959ADD-FFE5-418B-A95C-15C4B2C9F7DF@p-cos.net>


On 26 Aug 2012, at 18:58, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Aug 26, 2012, at 18:40, Pascal Costanza <pc at p-cos.net> wrote:
> 
> [...]
> 
>> However, the error message doesn't seem to make any sense:
>> 
>> Error loading /Users/costanza/lisp/develop/closer/contextl/test/demo3.lisp at line 51 (offset 1410)
>> #<THREAD "interpreter" {3ADE1520}>: Debugger invoked on condition of type TYPE-ERROR
>> The value 1 is not of type (INTEGER 0 1).
> 
> Ah, I copied the type-error-generating code from standard-instance-access which already implemented the bounds check, clearly the upper bound is mis-reported in both places.  Will fix.
> 
>> Restarts:
>> 0: TOP-LEVEL Return to top level.
>> [1] CX-USER(2): :bt
>> 
>> 0: (SYSTEM:BACKTRACE)
>> 1: (INVOKE-DEBUGGER #<TYPE-ERROR {4ADA1DC}>)
>> 2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
>> 3: org.armedbear.lisp.Lisp.type_error(Lisp.java:423)
>> 4: org.armedbear.lisp.StandardObject$pf__set_standard_instance_access.execute(StandardObject.java:489)
>> 5: org.armedbear.lisp.Symbol.execute(Symbol.java:825)
>> 6: org.armedbear.lisp.LispThread.execute(LispThread.java:666)
>> 7: org.armedbear.lisp.clos_671.execute(clos.lisp:3409)
> 
> Frame 7 is from (setf slot-value-using-class); expanding the backtrace further will show where that one is called.


OK, class redefinition doesn't trigger the obsolete instance structure protocol correctly, it seems. Here is a transcript:

CL-USER(1): (defclass person () (name))
#<STANDARD-CLASS PERSON {1E631646}>
CL-USER(2): (defparameter *p* (make-instance 'person))
*P*
CL-USER(3): (setf (slot-value *p* 'name) "name")
"name"
CL-USER(4): (defclass person () (name address))
#<STANDARD-CLASS PERSON {1E631646}>
CL-USER(5): (use-package :mop)
T
CL-USER(6): (class-slots (find-class 'person))
(#<SYSTEM:SLOT-DEFINITION NAME {1A60232C}> #<SYSTEM:SLOT-DEFINITION ADDRESS {37A0B39B}>)
CL-USER(7): (setf (slot-value-using-class (find-class 'person) *p* (second *)) "address")
#<THREAD "interpreter" {43F31EDC}>: Debugger invoked on condition of type TYPE-ERROR
  The value 1 is not of type (INTEGER 0 1).
Restarts:
  0: TOP-LEVEL Return to top level.

The problematic part seems to be the use of slot-value-using-class here. With just slot-value, this works fine...

Pascal

--
Pascal Costanza






From rudi at constantly.at  Sun Aug 26 19:26:13 2012
From: rudi at constantly.at (Rudolf Schlatte)
Date: Sun, 26 Aug 2012 21:26:13 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <56959ADD-FFE5-418B-A95C-15C4B2C9F7DF@p-cos.net>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
	<89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
	<1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>
	<9DF3873F-9C89-45A7-8D93-FA9BAAEF7266@constantly.at>
	<56959ADD-FFE5-418B-A95C-15C4B2C9F7DF@p-cos.net>
Message-ID: <326F705A-A940-4FCE-A264-69137AD68DB7@constantly.at>


On Aug 26, 2012, at 19:17, Pascal Costanza <pc at p-cos.net> wrote:

> OK, class redefinition doesn't trigger the obsolete instance structure protocol correctly, it seems. Here is a transcript:
> 
> CL-USER(1): (defclass person () (name))
> #<STANDARD-CLASS PERSON {1E631646}>
> CL-USER(2): (defparameter *p* (make-instance 'person))
> *P*
> CL-USER(3): (setf (slot-value *p* 'name) "name")
> "name"
> CL-USER(4): (defclass person () (name address))
> #<STANDARD-CLASS PERSON {1E631646}>
> CL-USER(5): (use-package :mop)
> T
> CL-USER(6): (class-slots (find-class 'person))
> (#<SYSTEM:SLOT-DEFINITION NAME {1A60232C}> #<SYSTEM:SLOT-DEFINITION ADDRESS {37A0B39B}>)
> CL-USER(7): (setf (slot-value-using-class (find-class 'person) *p* (second *)) "address")
> #<THREAD "interpreter" {43F31EDC}>: Debugger invoked on condition of type TYPE-ERROR
>  The value 1 is not of type (INTEGER 0 1).
> Restarts:
>  0: TOP-LEVEL Return to top level.
> 
> The problematic part seems to be the use of slot-value-using-class here. With just slot-value, this works fine...

(set-)standard-instance-access didn't check for invalid object layout, fixed in r14137.  Pure slot-value goes through a different code path for classes with metaclass standard-class, which did the check and update already.

Thanks for reporting!

Rudi




From pc at p-cos.net  Sun Aug 26 20:37:59 2012
From: pc at p-cos.net (Pascal Costanza)
Date: Sun, 26 Aug 2012 22:37:59 +0200
Subject: [closer-devel] Closer-mop support for ABCL
In-Reply-To: <326F705A-A940-4FCE-A264-69137AD68DB7@constantly.at>
References: <49D4C326-A8F4-4EFA-8FFE-CCAEE76838BD@constantly.at>
	<CBD729C5-5653-4443-9C22-AB626F58A8DD@p-cos.net>
	<9447CD68-89C1-40A5-855E-53E31198DAD3@constantly.at>
	<BE2A0710-880F-4F77-B51F-6DF0744E4609@p-cos.net>
	<89F50AB4-ECCC-4DA9-B1CC-4E8E99D63DD4@constantly.at>
	<1E0755AE-705E-4284-8202-A58915D37804@p-cos.net>
	<9DF3873F-9C89-45A7-8D93-FA9BAAEF7266@constantly.at>
	<56959ADD-FFE5-418B-A95C-15C4B2C9F7DF@p-cos.net>
	<326F705A-A940-4FCE-A264-69137AD68DB7@constantly.at>
Message-ID: <F61764B9-54E3-472F-B3A7-C7B03229836C@p-cos.net>


On 26 Aug 2012, at 21:26, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Aug 26, 2012, at 19:17, Pascal Costanza <pc at p-cos.net> wrote:
> 
>> OK, class redefinition doesn't trigger the obsolete instance structure protocol correctly, it seems. Here is a transcript:
>> 
>> CL-USER(1): (defclass person () (name))
>> #<STANDARD-CLASS PERSON {1E631646}>
>> CL-USER(2): (defparameter *p* (make-instance 'person))
>> *P*
>> CL-USER(3): (setf (slot-value *p* 'name) "name")
>> "name"
>> CL-USER(4): (defclass person () (name address))
>> #<STANDARD-CLASS PERSON {1E631646}>
>> CL-USER(5): (use-package :mop)
>> T
>> CL-USER(6): (class-slots (find-class 'person))
>> (#<SYSTEM:SLOT-DEFINITION NAME {1A60232C}> #<SYSTEM:SLOT-DEFINITION ADDRESS {37A0B39B}>)
>> CL-USER(7): (setf (slot-value-using-class (find-class 'person) *p* (second *)) "address")
>> #<THREAD "interpreter" {43F31EDC}>: Debugger invoked on condition of type TYPE-ERROR
>> The value 1 is not of type (INTEGER 0 1).
>> Restarts:
>> 0: TOP-LEVEL Return to top level.
>> 
>> The problematic part seems to be the use of slot-value-using-class here. With just slot-value, this works fine...
> 
> (set-)standard-instance-access didn't check for invalid object layout, fixed in r14137.  Pure slot-value goes through a different code path for classes with metaclass standard-class, which did the check and update already.


Perfect, these bug fixes come in very fast? :)

OK, on to the next bug: It seems that anonymous classes are always considered subtypes of other classes. This is not correct. Here is transcript:

CL-USER(1): (defparameter *c1* (make-instance 'standard-class))
*C1*
CL-USER(2): (defparameter *c2* (make-instance 'standard-class))
*C2*
CL-USER(3): (subtypep *c1* *c2*)
T
T
CL-USER(4): (defclass c1 () ())
#<STANDARD-CLASS C1 {4ABAD094}>
CL-USER(5): (defclass c2 () ())
#<STANDARD-CLASS C2 {2EC195E3}>
CL-USER(6): (subtypep 'c1 'c2)
NIL
T
CL-USER(7): (subtypep (find-class 'c1) (find-class 'c2))
NIL
T
CL-USER(8): (subtypep *c1* 'c1)
T
T
CL-USER(9): (subtypep 'c1 *c1*)
NIL
T

(The integration of types and classes is a bit complex. See 4.3.1 in the HyperSpec, especially the notion of "proper name", and 4.3.7.)

Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.