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.

SLSIA:

Welcome to Clozure Common Lisp Version 1.10-r16304M  (DarwinX8664)!
? (find-symbol "ARGS")
NIL
NIL
? (arglist 'setf)
(&REST ARGS)
:DECLARATION
? (find-symbol "ARGS")
ARGS
:INTERNAL

The problem occurs only when calling CCL::ARGLIST on macros, not functions.

I know it's not kosher to complain about the behavior of unexported functions, but swank uses this and it causes real problems. For example, trying to (use-package :cl-who) in a swank session fails because the symbol STR gets interned in cl-user during the swank startup process.

WITH-STANDARD-IO-SYNTAX is supposed to bind implementation-defined printer control variables to values that produce "standard" read/print behavior. There's at least some argument that binding CCL:*PRINT-ABBREVIATE-QUOTE* to T (as WITH-STANDARD-IO-SYNTAX currently does in CCL) is undesirable: the abbreviated syntax is certainly part of what CLHS calls "standard syntax", but if part of the purpose of WITH-STANDARD-IO-SYNTAX is to suppress implementation-dependent behavior, WITH-STANDARD-IO-SYNTAX should probably bind it to NIL instead.