Re: BOOL returned from Objective-C does not getted mapped properly (always true)
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)
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)
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)
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)
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
