Hi Laurent,
The work around you suggested works.
Also, after a clean build the automatic loading of framework and bridgeSupport
file worked as well.
Thanks very much,
Alan
On 22 Nov 2010, at 02:55, Laurent Sansonetti wrote:
> Hi Alan,
>
> Thanks for reporting that problem in the tracker. In t
Hi Alan,
Thanks for reporting that problem in the tracker. In the meantime, keeping a
reference to the Proc object in the Ruby side might work around the problem (as
I suspect that the proc here is being garbage-collected prematurely).
@b = TestBlock.alloc.initWithBlock (@tmp ||= Proc.n
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
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 N
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();
