Custom Query (1030 matches)
Results (790 - 792 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #928 | fixed | DEFINE-CONDITION allows non-condition parent conditions | ||
| Description |
Ethan H. Schwartz 2009-04-14 11:24:20 EDT On DEFINE-CONDITION, The CLHS says: parent-type---a symbol naming a condition type. If no parent-types are supplied, the parent-types default to (condition). With CCL Version 1.3-dev-r11854-working-0711 (LinuxX8664): (defclass a () ()) #<STANDARD-CLASS A> (define-condition foo (a) ()) FOO (error 'foo) #<STANDARD-CLASS FOO> is not a condition class It would be better if CCL complained at time of compilation of the condition that the parent-type argument is not a condition type. [was ITA bug 58450] |
|||
| #289 | fixed | DEFCLASS option processing | ||
| Description |
This was reported by Didier Verna on openmcl-devel a few times in the last week or so. Compiling a file that contains (defclass test-class (standard-class) ()) (defclass test () () (:metaclass test-class)) now errs at compile-time, apparently while doing a FIND-CLASS of TEST-CLASS while building the (new) class-keyvect. |
|||
| #2 | fixed | DEF-FOREIGN-TYPE, "auxiliary" foreign types, side-effects | ||
| Description |
In trying to fix some issues related to how DEF-FOREIGN-TYPE and PARSE-FOREIGN-TYPE deal with "auxiliary" foreign types (e.g., record types), I've introduced a bug wherein some of the target-specific foreign types defined via INSTALL-STANDARD-FOREIGN-TYPES are only defined at compile-time. One symptom of this is that it isn't possible to compile "lib/db-io.lisp" unless "lib/foreign-types.lisp" has been compiled in the same session; in other words, the load-time effect of defining things like (:STRUCT :CDB-DATUM) doesn't take place. The whole concept of "auxiliary" foreign types is questionable, and the current foreign type system code applies it too broadly. Something like: (DEF-FOREIGN-TYPE NIL (:STRUCT FOO (:X :INT))) should always globally define or redefine the structure-type :FOO, and in something like: (DEF-FOREIGN-TYPE NIL (:STRUCT :BAR (:A (:STRUCT :FOO)))) the inner reference to (not definition of) (:STRUCT :FOO) should be a (possibly forward-) reference to the globally visible structure type :FOO. In a third case (should check a C reference), it is possible that in: (DEF-FOREIGN-TYPE NIL (:STRUCT :BAZ (:A (:STRUCT :FOO (:X :DOUBLE)))) the internal definition of (:STRUCT :FOO) is local to the containing definition, in which case the FOREIGN-RECORD-TYPE for :BAZ would need to enumerate all such local ("auxiliary") structure and type definitions. The old CMUCL type-system code (as it's been hacked up over the years) seems to want to treat all structure type definitions and references as if they were somehow local (to something ...), and attempting to fix this has introduced other problems. |
|||
