Custom Query (1030 matches)
Results (691 - 693 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #51 | fixed | Include additional Cocoa-Bridge Databases (ApplicationServices, QuartzCore, Foundation) | ||
| Description |
The ApplicationServices framework includes important image processing classes needed for mapping files to OpenGL textures. Likewise, QuartzCore and Foundation have useful routines for other graphical applications. I'm attaching the populate.sh files I used to generate the CDB files for my use. |
|||
| #60 | fixed | Thread-safe gf dispatch | ||
| Description |
It should be possible for gf dispatch to run simultaneously in multiple threads without introducing inconsistencies in CLOS internals (e.g. caches). FWIW, here's what sbcl does about this: http://lisp-ecoop07.bknr.net/pdf/31662. |
|||
| #61 | fixed | CCL::LOAD-RECORD should treat "pointer to VOID" the same way that CCL::PARSE-FOREIGN-TYPE does | ||
| Description |
Inconsistency creates bogus warnings, as discussed on OpenMCL-devel. ? (use-interface-dir :cocoa) #<INTERFACE-DIR ..> ? (ccl::load-record :objc_method) ; read the structure type from database #<FOREIGN-RECORD-TYPE (:STRUCT :OBJC_METHOD ...)> ? (make-load-form *) ; return a form that, when evaluated, will
(CCL::PARSE-FOREIGN-TYPE '(:STRUCT :OBJC_METHOD (:METHOD-NAME ...))) ? (eval *) ; try to reconstruct the foreign type object The fairly new (a few months old ...) typed-pointer mechanism (MAKE-RECORD, RLET ...) compiles into code which references foreign type objects as constants; when those type objects are saved to and loaded from FASL files, the result -should- be "equivalent" to the original; in this case, it should involve a harmless "equivalent" redefinition of the :OBJC_METHOD structure type. CCL::LOAD-RECORD and CCL::PARSE-FOREIGN-TYPE of a record type specifier should do about the same thing (and return "equivalent" results), but they do it in different ways. They differ in at least one way: when reading the encoded representation of "pointer to void"", CCL::LOAD-RECORD actually creates a pointer to NIL (which, somewhat confusingly, prints as "(:* :VOID)"). CCL::PARSE-FOREIGN-TYPE processes the (:* :VOID) and creates a pointer to ... :VOID. CCL::RECORD-FIELDS-MATCH notices this this difference and warns about it (but the difference isn't apparent in the printed representation of the field types in the warning message.) CCL::LOAD-RECORD should really treat "pointer to VOID" the same way that CCL::PARSE-FOREIGN-TYPE does. The fact that it doesn't isn't really significant in any way that I can think of, but the different representation is enough to generate the warning here. You're right in thinking that the warning is merely annoying in this case. |
|||
