On Aug 19, 2012, at 17:49, Pascal Costanza pc@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.ht...) so it will get a good long look soon.

Rudi

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@constantly.at wrote:

On Aug 19, 2012, at 17:49, Pascal Costanza pc@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@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

-- Pascal Costanza

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

On Aug 26, 2012, at 16:28, Pascal Costanza pc@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

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

On Aug 26, 2012, at 18:40, Pascal Costanza pc@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

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

On Aug 26, 2012, at 19:17, Pascal Costanza pc@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.

On 5 Sep 2012, at 12:33, Rudolf Schlatte rudi@constantly.at wrote:

On Aug 26, 2012, at 22:37, Pascal Costanza pc@p-cos.net wrote:

...

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

[etc]

Nice. For more fun and games, consider (setf (class-name *c1*) t) - instant universal superclass. Anyway, both issues are hopefully fixed now.

I wonder if this should be added to ansi-tests.

This would probably make sense.

On to the next bug:

CL-USER(1): (use-package :mop) T

CL-USER(2): (defclass my-class (standard-class) ()) #<STANDARD-CLASS MY-CLASS {5122152B}>

CL-USER(3): (defmethod slot-unbound ((class my-class) object slot) (print :foo) (call-next-method)) #<STANDARD-METHOD SLOT-UNBOUND (MY-CLASS T T) {149BE3AA}>

CL-USER(4): (defclass test () ((slot :accessor test-slot)) (:metaclass my-class)) #<MY-CLASS TEST {79BC8795}>

CL-USER(8): (make-instance 'test) #<TEST {21BF4C80}>

CL-USER(9): (slot-boundp * 'slot) T

CL-USER(10): (test-slot **)

:FOO #<THREAD "interpreter" {12EEA1E7}>: Debugger invoked on condition of type UNBOUND-SLOT The slot SLOT is unbound in the object #<TEST {21BF4C80}>. Restarts: 0: TOP-LEVEL Return to top level.

It seems that as soon as a method on slot-unbound is defined, slot-boundp returns t no matter whether the slot is bound or not. This should not be the case.

Another issue that I'm currently fighting with is initialization of class slots for classes for which I never create any instances:

(defclass test () ((slot :initform 42 :allocation :class)))

(slot-value (class-prototype (find-class 'test)) 'slot) will report an unbound slot. This is probably defensible based on the HyperSpec and the CLOS MOP specification, but I doubt its useful. I believe that class slots should be initialized in finalize-inheritance the latest, and not only in shared-initialize on instances, to be useful for such scenarios. (But it's fine if you disagree, then I have to live with that and find a different solution…)

Pascal

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

On Sep 9, 2012, at 18:46, Pascal Costanza pc@p-cos.net wrote:

[...]

On to the next bug:

CL-USER(1): (use-package :mop) T

CL-USER(2): (defclass my-class (standard-class) ()) #<STANDARD-CLASS MY-CLASS {5122152B}>

CL-USER(3): (defmethod slot-unbound ((class my-class) object slot) (print :foo) (call-next-method)) #<STANDARD-METHOD SLOT-UNBOUND (MY-CLASS T T) {149BE3AA}>

CL-USER(4): (defclass test () ((slot :accessor test-slot)) (:metaclass my-class)) #<MY-CLASS TEST {79BC8795}>

CL-USER(8): (make-instance 'test) #<TEST {21BF4C80}>

CL-USER(9): (slot-boundp * 'slot) T

CL-USER(10): (test-slot **)

:FOO #<THREAD "interpreter" {12EEA1E7}>: Debugger invoked on condition of type UNBOUND-SLOT The slot SLOT is unbound in the object #<TEST {21BF4C80}>. Restarts: 0: TOP-LEVEL Return to top level.

It seems that as soon as a method on slot-unbound is defined, slot-boundp returns t no matter whether the slot is bound or not. This should not be the case.

It's simpler than that - slot-boundp-using-class was just utterly broken for classes with non-standard metaclass. r14154 has the embarrassing details.

Rudi

[removing closer-devel, but feel free to re-add]

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

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…

The relevant sentence being: "The lambda list congruence rules require that each method accept all of the keyword arguments mentioned after &key in the generic function definition, by accepting them explicitly, by specifying&allow-other-keys, or by specifying &rest but not &key."

The mentioned style warnings occur when compiling a file containing, e.g.,

(defmethod foo ((x fixnum) &key y z) x)

I think I agree that these style warnings can be elided, since a typo in the arglist will lead to another style warning "Undefined variable A assumed special" anyway. Filed as bug #242.

Rudi