Opened 10 years ago

Closed 10 years ago

#447 closed defect (invalid)

CCL1.3 darwins problem with delegate object calls, not problem in CCL1.2

Reported by: Arthur Owned by: gb
Priority: normal Milestone:
Component: Objective-C Bridge Version:
Keywords: delegate windowShouldClose: Cc:

Description

The essence seems to me to be that when Cocoa #/performClose: calls upon #/windowShouldClose: for the delegate of a instance of a subclassed window, the callout is unsupported by something in CCL v1.3. It works fine in CCL v1.2. The problem was first spotted when testing on a darwinx8664 machine, but that turns out to be a red herring. On Powerbook G4, with OS 10.5.6, with cocoa-application required in both cases, there is a difference between CCL1.2/CCL1.3.

Attached code file gives more explanation.

Attachments (1)

easygui-miniviews9.lisp (6.9 KB) - added by Arthur 10 years ago.
Lisp code file, Easygui package, normal in CCL1.2, error in CCL1.3

Download all attachments as: .zip

Change History (3)

Changed 10 years ago by Arthur

Lisp code file, Easygui package, normal in CCL1.2, error in CCL1.3

comment:1 Changed 10 years ago by gb

  • Owner set to gb
  • Status changed from new to assigned

The relevant difference between 1.2 and 1.3 is likely that:

? (defun foo (x) 
    (declare (optimize (safety 3)))
    (the fixnum x))
FOO
? (foo 'a)

signals a TYPE-ERROR in 1.3 and doesn't in 1.2.

You mentioned on openmcl-devel that something was complaining that (@METACLASS FOO) was an unknown type-specifier and I suggested that it be defined to return OBJC:OBJ-METACLASS until someone had time to look at it more carefully. It's possible that that was incorrect, and that the workaround would be to define it to return OBJC:OBJC-CLASS.

If you're compiling your code with (OPTIMIZE (SAFETY 3)) in effect, you might want to consider not doing so; the declaration is wrong (and not particularly useful), and SAFETY 3 is (as it should be) being picky about something that really doesn't matter.

(There -is- a bug here, but it's the bogus type assertion in the @class macro. 1.3 detects that in code compiled at high safety; 1.2 didn't. I don't think that it's likely that this has anything to do with delegate object calls.)

comment:2 Changed 10 years ago by rme

  • Resolution set to invalid
  • Status changed from assigned to closed

I created new ticket:467 for the @class issue.

Note: See TracTickets for help on using tickets.