Custom Query (1030 matches)

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.

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.

The Bosco HOWTO shows in a step-by-step fashion how to create a Cocoa application, using OpenMCL and Bosco. Bosco in its old form is now obsolete, and we could use an updated HOWTO that shows how to create a Cocoa application using current OpenMCL facilities.