Closer-mop support for ABCL

Content preview: 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.). [...]

Content analysis details: (-102.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[217.70.178.89 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/338>

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

Post by Rudi Schlatte
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
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

--
Pascal Costanza

Rudolf Schlatte

2012-08-19 20:21:22 UTC

Content preview: On Aug 19, 2012, at 17:49, Pascal Costanza <pc-***@public.gmane.org>
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.). [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/339>

Post by Pascal Costanza
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.
[..]

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

Rudolf Schlatte

2012-08-25 21:21:37 UTC

Content preview: On Aug 19, 2012, at 17:49, Pascal Costanza <***@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: [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/340>

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

Pascal Costanza

2012-08-26 14:28:40 UTC

Content preview: 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? [...]

Content analysis details: (-102.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[217.70.178.89 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/341>

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

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
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/closer-devel

--
Pascal Costanza

Rudolf Schlatte

2012-08-26 15:14:43 UTC

Content preview: On Aug 26, 2012, at 16:28, Pascal Costanza <pc-***@public.gmane.org>
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? [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/342>

Post by Pascal Costanza
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

Pascal Costanza

2012-08-26 16:40:10 UTC

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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/343>

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

Rudolf Schlatte

2012-08-26 16:58:10 UTC

Post by Pascal Costanza
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).
[...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/344>

On Aug 26, 2012, at 18:40, Pascal Costanza <pc-***@public.gmane.org> wrote:

[...]

Post by Pascal Costanza
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.

Post by Pascal Costanza
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

Pascal Costanza

2012-08-26 17:17:32 UTC

Post by Pascal Costanza
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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[217.70.183.196 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/345>

Post by Rudolf Schlatte
[...]

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.

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

Rudolf Schlatte

2012-08-26 19:26:13 UTC

Content preview: On Aug 26, 2012, at 19:17, Pascal Costanza <***@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... [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/346>

Post by Pascal Costanza
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).
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

Pascal Costanza

2012-08-26 20:37:59 UTC

Post by Pascal Costanza
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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[217.70.183.196 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/347>

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).
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...

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.

Rudolf Schlatte

2012-09-05 10:33:29 UTC

Content preview: On Aug 26, 2012, at 22:37, Pascal Costanza <***@p-cos.net>
wrote: > OK, on to the next bug: It seems that anonymous classes are always

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 [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/348>

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.

Rudi

Pascal Costanza

2012-09-09 16:46:20 UTC

Post by Pascal Costanza
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. [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[217.70.183.195 listed in list.dnswl.org]
-100 USER_IN_WHITELIST From: address is in the user's white-list
Archived-At: <http://permalink.gmane.org/gmane.lisp.closer.devel/349>

Post by Pascal Costanza
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.

Rudolf Schlatte

2012-09-19 14:47:35 UTC

Post by Pascal Costanza
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…) [...]

Content analysis details: (-100.7 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
[88.151.129.22 listed in list.dnswl.org]
X-BeenThere: armedbear-devel-***@public.gmane.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <armedbear-devel.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/armedbear-devel>,
<mailto:armedbear-devel-request-***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/armedbear-devel>
List-Post: <mailto:armedbear-devel-***@public.gmane.org>
List-Help: <mailto:armedbear-devel-request-***@public.gmane.org?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel>,
<mailto:armedbear-devel-request-***@public.gmane.org?subject=subscribe>
Errors-To: armedbear-devel-bounces-***@public.gmane.org
X-Spam-Score: -100.7 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "tiger.common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Post by Pascal Costanza
Another issue that I'm currently fighting with is initialization of class

Post by Pascal Costanza
(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…)

I'm a bit slow with the fixes these days, but this should now be implemented in r14153.

Note that the related form

(defclass test ()
((slot :initarg :slot :allocation :class))
(:default-initargs :slot 42))

currently still has the old behavior (unbound slot until the first instance is created). Do you think this should be fixed as well?

Rudi

Rudolf Schlatte

2012-09-19 19:02:07 UTC

Content preview: On Sep 9, 2012, at 18:46, Pascal Costanza <***@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}>