Custom Query (1030 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (691 - 693 of 1030)

Ticket Resolution Summary Owner Reporter
#51 fixed Include additional Cocoa-Bridge Databases (ApplicationServices, QuartzCore, Foundation) Gary Byers Brent Fulgham
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 Gary Byers gz
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 Gary Byers Andrew Shalit
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

; return something "equivalent" to its argument. ; (This is necessary when certain types of objects ; are referenced as constants in code compiled ; by COMPILE-FILE.)

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

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.