Re: BOOL returned from Objective-C does not getted mapped properly (always true)

2010-09-19 Thread Sherm Pendley
On Sat, Sep 18, 2010 at 7:07 PM, Sherm Pendley sherm.pend...@gmail.com wrote:

 Found it! What's happening is that, for one- and two-byte return types
 (i.e., char and short), *four* bytes are being stored in a Perl
 variable. Since only one or two bytes were actually returned from the
 method, the other two or three bytes of the value being returned to
 Perl are essentially random.

The question is, why didn't the self-tests catch this? From the NSNumber.t test:

  my $testNumber = NSNumber-numberWithChar(5);
  if (defined $testNumber) {
  ok(1);
  } else {
  ok(0);
  }

  # It should be able to return a bool, a char, a short, and a long
  if ($testNumber-boolValue()) {
  ok(2);
  } else {
  ok(0);
  }

  if ($testNumber-charValue() == 5) {
  ok(3);
  } else {
  ok(0);
  }

I can see why boolValue() would pass when it shouldn't - when this bug
bites, BOOL return values are always nonzero. But the charValue() test
verifies a specific value, not just nonzero. And, there are other
tests in this file, that use various numberWith*() methods to create
NSNumber instances, and *Value() methods to test them. They all pass.

Hmm. None of the *Value() methods take arguments, but isEqual() does.
Maybe the random values corrupting the return value from isEqual()
were left over from the argument that was passed in? I tried adding a
couple of tests to check this theory:

  # Compare it with another number
  my $compNumber = NSNumber-numberWithLong(5);
  if ($compNumber-isEqual($testNumber)) {
  ok(22);
  } else {
  ok(0);
  }

  $compNumber = NSNumber-numberWithLong(50);
  if (!$compNumber-isEqual($testNumber)) {
  ok(23);
  } else {
  ok(0);
  }

These tests both use isEqual(), and the second one expects it to
return zero. Both tests pass!

I've verified the bug, and verified that it's been fixed in
Subversion. But that was with a GUI app that duplicates the conditions
exactly - using isEqual() to compare $sender to an outlet in an
IBAction method. Obviously those conditions tickle this bug in a way
that the self-tests don't. :-(

sherm--

-- 
Cocoa programming in Perl:
http://camelbones.sourceforge.net


Re: BOOL returned from Objective-C does not getted mapped properly (always true)

2010-09-18 Thread Thilo Planz
Hi, I have updated to the new CamelBones, but I am still having the problem
of NSObject-isEqual not working properly.

To recap the thread below, I am calling -isEqual on cocoa components
(I think NSButtons), and it returns values, which do not work as
booleans in Perl (maybe a memory address).

real code is here:
http://bitbucket.org/thiloplanz/perlpad/src/tip/MyWindowController.pm#cl-229

$sender-isEqual($self-{PerlInputButton}) returns something like 44858369

This used to work back in the old days...

Any idea on how I can fix or workaround this issue?

Thanks,

Thilo






 Have you tried -isEqual: for other classes? NSApplication is a
 singleton, and Apple may not have anticipated anyone comparing it with
 itself, or with random strings of text. :-)
 
 My real code does not call -isEqual: on NSApplication.
 This was just test code for the sake of the bug report.
 
 I real life, I am calling it on UI components, I think NSButtons:
 
 http://bitbucket.org/thiloplanz/perlpad/src/tip/MyWindowController.pm#cl-229
 
 
 Thilo
 

 I'll add some -isEqual: cases to the test suite, in any event. One
 can't have too many test cases.

 sherm--

 On Sat, Dec 5, 2009 at 9:59 PM, Thilo Planz thilopl...@googlemail.com 
 wrote:
 Hi there,

 For a long time, PerlPad has been segfaulting on recent Camelbones
 versions, and it seems that is caused BOOL return values no longer being
 mapped properly into Perl.

 It seems that functions such as NSObject-isEqual that return a BOOL
 return some kind of memory index to Perl.


 my $x = NSApplication-sharedApplication;
   print $x-isEqual($x);
   print \n;
 should return YES, prints 44858369

   print $x-isEqual(random string);
   print \n;
 should return NO, prints 42636800

   print true\n if $x-isEqual(random string);
 should evaluate to false in boolean context, but evaluates as true.


 I think in previous versions (of CB) this worked better.

 Is there any way I can rewrite my code to make at least
 isEqual work for now?

 Thanks,

 Thilo




 



Re: BOOL returned from Objective-C does not getted mapped properly (always true)

2010-09-18 Thread Sherm Pendley
On Sat, Sep 18, 2010 at 3:32 AM, Thilo Planz thilopl...@googlemail.com wrote:
 Hi, I have updated to the new CamelBones, but I am still having the problem
 of NSObject-isEqual not working properly.

 To recap the thread below, I am calling -isEqual on cocoa components
 (I think NSButtons), and it returns values, which do not work as
 booleans in Perl (maybe a memory address).

Found it! What's happening is that, for one- and two-byte return types
(i.e., char and short), *four* bytes are being stored in a Perl
variable. Since only one or two bytes were actually returned from the
method, the other two or three bytes of the value being returned to
Perl are essentially random.

 This used to work back in the old days...

It's probably a holdover from the old FFCall library. Comments in the
code indicated that it promoted such return types to 32 bits.
Apparently libffi doesn't do that. I've fixed the bug and checked the
change into Subversion, and I'll roll a new release as soon as I've
verified that it applies to both PPC  Intel, and for all of the
supported Mac OS X versions.

 Any idea on how I can fix or workaround this issue?

One workaround is to assign a tag to the relevant controls in
Interface Builder, and compare it like this:

  if ($sender-tag() == $self-{'thisButton'}-tag()) {
...
  }

Tags are 32-bit values, so this bug doesn't bite them.

sherm--

-- 
Cocoa programming in Perl:
http://camelbones.sourceforge.net


Re: BOOL returned from Objective-C does not getted mapped properly (always true)

2010-09-18 Thread Sherm Pendley
On Sat, Sep 18, 2010 at 7:07 PM, Sherm Pendley sherm.pend...@gmail.com wrote:
 On Sat, Sep 18, 2010 at 3:32 AM, Thilo Planz thilopl...@googlemail.com 
 wrote:

 Any idea on how I can fix or workaround this issue?

 One workaround is to assign a tag to the relevant controls in
 Interface Builder, and compare it like this:

  if ($sender-tag() == $self-{'thisButton'}-tag()) {
    ...
  }

 Tags are 32-bit values, so this bug doesn't bite them.

Another possibility is to use a bit mask to ignore the additional bytes:

  if ($sender-isEqual($self-{'thisButton'})  0xf) {
...
  }

sherm--

-- 
Cocoa programming in Perl:
http://camelbones.sourceforge.net


Re: BOOL returned from Objective-C does not getted mapped properly (always true)

2009-12-10 Thread Sherm Pendley
Hmm... BOOL values should be fine - they're covered in the self-tests, and pass.

Have you tried -isEqual: for other classes? NSApplication is a
singleton, and Apple may not have anticipated anyone comparing it with
itself, or with random strings of text. :-)

I'll add some -isEqual: cases to the test suite, in any event. One
can't have too many test cases.

sherm--

On Sat, Dec 5, 2009 at 9:59 PM, Thilo Planz thilopl...@googlemail.com wrote:
 Hi there,

 For a long time, PerlPad has been segfaulting on recent Camelbones
 versions, and it seems that is caused BOOL return values no longer being
 mapped properly into Perl.

 It seems that functions such as NSObject-isEqual that return a BOOL
 return some kind of memory index to Perl.


 my $x = NSApplication-sharedApplication;
       print $x-isEqual($x);
       print \n;

 should return YES, prints 44858369

       print $x-isEqual(random string);
       print \n;

 should return NO, prints 42636800

       print true\n if $x-isEqual(random string);

 should evaluate to false in boolean context, but evaluates as true.


 I think in previous versions (of CB) this worked better.

 Is there any way I can rewrite my code to make at least
 isEqual work for now?

 Thanks,

 Thilo




-- 
Cocoa programming in Perl:
http://www.camelbones.org


BOOL returned from Objective-C does not getted mapped properly (always true)

2009-12-06 Thread Thilo Planz
Hi there,

For a long time, PerlPad has been segfaulting on recent Camelbones
versions, and it seems that is caused BOOL return values no longer being
mapped properly into Perl.

It seems that functions such as NSObject-isEqual that return a BOOL
return some kind of memory index to Perl.


 my $x = NSApplication-sharedApplication;
   print $x-isEqual($x);
   print \n;

should return YES, prints 44858369

   print $x-isEqual(random string);
   print \n;

should return NO, prints 42636800

   print true\n if $x-isEqual(random string);

should evaluate to false in boolean context, but evaluates as true.


I think in previous versions (of CB) this worked better.

Is there any way I can rewrite my code to make at least
isEqual work for now?

Thanks,

Thilo