D/Objective-C 64bit

[Christian Schneider via Digitalmars-d-announce]

Speaking of drawing, I have a very serious problem wit NSView. I 
cannot call frame() nor bounds() on instances or subclasses and 
get a valid NSRect. (same goes for NSWindow frame()).

I had similar problems when working with NSAttributedString and 
NSRange, because NSRange from Chocolat was still 32 bit. After 
fixing this, it all worked perfectly. The parameter to drawRect, 
which is a NSRect as well contains correct values. So it seems to 
me that the NSRect struct declared as is should work just fine.

I am trying to implement drawRect in an NSView subclass (in the 
Portmidi example, KeyboardView). Everything works fine, 
NSBezierPath drawing methods etc., but I cannot call this.frame() 
nor this.bounds() from within that method without triggering a 
runtime segmentation fault.  Often I see this in the crash log as 
last "message":

misaligned_stack_error_entering_dyld_stub_binder

Sometimes there is other stuff, but always indicating a memory 
corruption.

I have not the slightest idea what could be the problem here, it 
most likely is not a threading issue, as drawRect is anyway 
called on the main thread, and usually one only has crashes if 
one tries to update widgets from background threads, which of 
course is not allowed in Cocoa, as the AppKit is not thread safe.

I just checked back, for any widget it fails. You can easily 
reproduce it by e.g. opening the SimpleWebBrowser example and add 
in applicationDidFinishLaunching (this is a good point, because 
all the UI element should be ready):

NSRect backButtonFrame = backButton.frame() ;
NSLog("frame %f %f %f %f", backButtonFrame.origin.x, 
backButtonFrame.origin.y, backButtonFrame.size.width, 
backButtonFrame.size.height) ;

For custom components, if this won't work, it is almost a deal 
breaker for using Cocoa through D. This is quite a setback, all 
the rest so far encountered is working so beautifully.