I see.
It would be ideal if you could provide a small test sample, so that we can
reproduce the bug :-)
--
Thibault Martin-Lagardette
On Nov 19, 2010, at 12:25, Alan Skipp wrote:
> Whoops, sorry about that. I find that I can get away without assigning to
> self in 'init' when doing a quick hack, but certainly not the recommended
> approach, especially when attempting to track down another bug.
> I've amended the initializer now and I still encounter the same problem.
>
> Al
>
> On 19 Nov 2010, at 10:53, Thibault Martin-Lagardette wrote:
>
>> Hi Alan,
>>
>> I didn't look in further details yet, but clearly your initWithBlock method
>> is wrong, it should be:
>>
>> - (id)initWithBlock:(void (^)())aBlock;
>> {
>> if ((self = [super init])) {
>> block = [aBlock copy];
>> NSLog(@"Block: %@", block);
>> block();
>> }
>> return self;
>> }
>>
>> You are not assigning `self` to be equal to what `[super init]` returns, and
>> this is, even without macruby or blocks, prone to crashes :-)
>>
>> Can you try to fix this and then tell us if it's still crashing?
>>
>> --
>> Thibault Martin-Lagardette
>>
>>
>>
>> On Nov 19, 2010, at 10:14, Alan Skipp wrote:
>>
>>> I've been attempting to get an objective-c framework to work with macruby
>>> and I believe I've found a bug in the way ruby Proc objects are copied when
>>> used as objective-c blocks.
>>> The copied block doesn't seem to persist correctly beyond the scope in
>>> which it was copied. It isn't deallocated, but calling it results in a
>>> crash. Typical error messages are:
>>> wrong type NSCFSet (expected Proc) (TypeError)
>>> wrong type NSRectSet (expected Proc) (TypeError)
>>> I'm guessing that there's a pointer to the wrong memory location?
>>>
>>> Here's the Objective-C implementation:
>>>
>>> @implementation TestBlock
>>>
>>> - (id)initWithBlock:(void (^)())aBlock;
>>> {
>>> [super init];
>>> block = [aBlock copy];
>>> NSLog(@"Block: %@", block);
>>> block();
>>> return self;
>>> }
>>>
>>> - (void)callBlock;
>>> {
>>> NSLog(@"block: %@", block);
>>> block();
>>> }
>>>
>>> @end
>>>
>>>
>>> Within 'initWithBlock:', the copied block can be invoked without error.
>>> Attempting to do so from 'callBlock', results in a crash. The test
>>> framework can be used without error when using objective-c.
>>>
>>> Here's the ruby controller code:
>>>
>>> @b = TestBlock.alloc.initWithBlock Proc.new { puts "hello from ruby"}
>>>
>>> # this next line is called from a different scope and causes the crash
>>> @b.callBlock
>>>
>>>
>>> 2010-11-19 08:41:06.620 CallObjectiveCBlocks[7046:a0f] Block:
>>> <__NSAutoBlock__: 0x200be74a0>
>>> hello from ruby
>>>
>>> 2010-11-19 08:41:20.011 CallObjectiveCBlocks[7046:a0f] block:
>>> <__NSAutoBlock__: 0x200be74a0>
>>> 2010-11-19 08:41:20.012 CallObjectiveCBlocks[7046:a0f]
>>> /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/Controller.rb:21:in
>>> `call:': wrong type Array (expected Proc) (TypeError)
>>> from
>>> /Users/alan/Documents/programming/macruby/CallObjectiveCBlocks/build/Debug/CallObjectiveCBlocks.app/Contents/Resources/rb_main.rb:23:in
>>> `<main>'
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel@lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel@lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
