Thread: [Camelbones-devel] Plan for today
Brought to you by:
shermpendley
From: Sherm P. <she...@gm...> - 2010-09-02 13:31:38
|
Getting ambitious now... Adding support for non-object properties and KVO. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Sherm P. <she...@gm...> - 2010-09-03 00:57:10
|
On Thu, Sep 2, 2010 at 9:30 AM, Sherm Pendley <she...@gm...> wrote: > Getting ambitious now... Adding support for non-object properties Turns out that rabbit hole goes pretty deep, and exposed an existing bug as well. When a Perl method is registered with the ObjC runtime, it's always with the same IMP (implementation function). That IMP is coded to examine the passed-in self & _cmd arguments, and dispatch to the required Perl method. So far so good, but that IMP is coded to return an id, which means that it doesn't handle return values properly if it's called by objc_msgSend_stret() or _fpret(). This bug was exposed by testing the getter methods generated by declaring non-object properties, but in fact it bites any Perl method that returns a struct type (on both ppc & intel), or a floating-point type (on Intel). sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Sherm P. <she...@gm...> - 2010-09-04 13:45:27
|
On Thu, Sep 2, 2010 at 8:57 PM, Sherm Pendley <she...@gm...> wrote: > On Thu, Sep 2, 2010 at 9:30 AM, Sherm Pendley <she...@gm...> wrote: > >> Getting ambitious now... Adding support for non-object properties > > Turns out that rabbit hole goes pretty deep, and exposed an existing > bug as well. > > When a Perl method is registered with the ObjC runtime, it's always > with the same IMP (implementation function). That IMP is coded to > examine the passed-in self & _cmd arguments, and dispatch to the > required Perl method. So far so good, but that IMP is coded to return > an id, which means that it doesn't handle return values properly if > it's called by objc_msgSend_stret() or _fpret(). > > This bug was exposed by testing the getter methods generated by > declaring non-object properties, but in fact it bites any Perl method > that returns a struct type (on both ppc & intel), or a floating-point > type (on Intel). Checked in support for non-object properties and new _stret() and fpret() IMP functions for Perl methods. The self-tests are giving strange results though. In t/21-Properties.t, there is test code that does stuff like the following: ok(20) if $tester->testObject_withRect($obj, { 'x' => 25.0, 'y' => 30.0, 'width' => 35.0, 'height' => 40.0 }); $obj has, among others, a property declared as type "{NSRect=ffff}". $tester is implemented in Objective-C, and uses the generated accessors to set the property value, then read it back and compare the result: - (BOOL)testObject:(id)target withRect:(NSRect)value { NSLog(@"Setting rect: %@", NSStringFromRect(value)); [target setRectcbtest:value]; NSRect newValue = [target rectcbtest]; NSLog(@"Retrieved rect: %@", NSStringFromRect(newValue)); return NSEqualRects(value, newValue); } What's strange is that the NSLog statements produce identical results, but NSEqualRects() still returns a negative result. I can't yet explain that. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Sherm P. <she...@gm...> - 2010-09-09 01:01:10
|
On Thu, Sep 2, 2010 at 9:30 AM, Sherm Pendley <she...@gm...> wrote: > Getting ambitious now... Adding support for non-object properties and KVO. Okay, turns out that's a little *too* ambitious for 1.1.1. It's a new feature, not a bug fix. So, it's going on the back burner for the time being, so I can focus on rolling a new release. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |