[MacRuby-devel] Stream of Consciousness Testing Log

Mon Mar 31 12:35:40 PDT 2008

On Mar 31, 2008, at 10:22 AM, Laurent Sansonetti wrote:
> Hi Pierce,
> On Mar 31, 2008, at 10:04 AM, Pierce T. Wetter III wrote:
>> Ok, so I have a rubycocoa application with source freely available.  
>> So lets try to bootstrap it into MacRuby and see what happens.
> That's courageous of you :-)

  Well, Frictionless seems kind of sluggish to me, and I'm expecting  
that MacRuby will make it kick ass. Of course, it could very will be  
coding stupidity on my part that makes it sluggish (a highly recursive  
data model can do that), but I couldn't quite figure out how to use  
Instruments/XRay to profile the ruby side. But I use bindings/CoreData  
everywhere, so it wouldn't surprise me if bridge crossings are killing  

>> [Session started at 2008-03-31 09:46:42 -0700.]
>> Assertion failed: (__auto_zone != NULL), function ruby_xmalloc,  
>> file gc.c, line 296.
>> The Debugger has exited due to signal 6 (SIGABRT).The Debugger has  
>> exited due to signal 6 (SIGABRT).
>> I'm guessing, but I bet that I have to turn GC on, because it has  
>> to be OFF for RubyCocoa, but ON for MacRuby. Someone should put a  
>> useful message on that assertion like "Hey dummy, turn on GC".
> Excellent suggestion, I will do that. Could you file an entry in the  
> tracker?

  Done, its #43

> It is my objective to provide a RubyCocoa compatible layer on top of  
> MacRuby, so that things like the OSX module or the underscore syntax  
> would be temporarily supported. But I don't think I will do that for  
> 0.2.
> At least I will provide more documentation in the wiki.
>> Ok, running... That seems to work. But now I get:
>> The Debugger has exited due to signal 6 (SIGABRT).The Debugger has  
>> exited due to signal 6 (SIGABRT).
> That is a weird crash. In theory this message should be print only  
> when you want to access a bridge support constant whose value hasn't  
> been cached by the parser (which is definitely a bug, because the  
> constant shouldn't be defined then). I suppose you're not accessing  
> CFBinaryHeapCompareContext directly in your code.

> Do you reproduce this all the time? If you could get a gdb backtrace  
> it would be very helpful, or, if it's possible, please send me a  
> copy of your project offlist and I will have a look at it.

  Yeah, it repeated itself twice when I did it, though XCode didn't  
stop appropriately, the debugger just quit. Oh, no wait, it did, I was  
just confused:

#0  0x942ce0ea in __kill ()
#1  0x942ce0dd in kill$UNIX2003 ()
#2  0x943453f2 in raise ()
#3  0x943549af in abort ()
#4  0x001d6120 in rb_bug (fmt=0x2c3e58 "unresolved bridgesupport  
constant `%s' not in cache") at error.c:226
#5  0x002acb0d in rb_objc_resolve_const_value (v=17353872,  
klass=16863952, id=10917) at objc.m:1587
#6  0x0027e8d7 in rb_const_get_0 (klass=16863952, id=13, exclude=0,  
recurse=2) at variable.c:1484
#7  0x001cd9e4 in <unknown function> [inlined] () at :0
#8  rb_define_class (name=0x9225280 "CFBinaryHeapCompareContext",  
super=17354096) at class.c:0
#9  0x002af0f4 in <unknown function> [inlined] () at :0
#10 bs_parse_cb (path=0xbfffb1ec "/System/Library/Frameworks/ 
CoreFoundation.bridgesupport", type=BS_ELEMENT_STRUCT, value=0x2aa5,  
ctx=0x0) at objc.m:0
#11 0x002b2f93 in _bs_parse (path=0xbfffb1ec "/System/Library/ 
CoreFoundation.bridgesupport", loaded_paths=0xbfffd770,  
options=BS_PARSE_DEFAULT, callback=0x2aece0 <bs_parse_cb>,  
context=0x0, error=0xbfffec00) at bs.c:1078
#12 0x002b2bcc in _bs_parse (path=0xbfffcf3c "/System/Library/ 
Foundation.bridgesupport", loaded_paths=0xbfffd770,  
options=BS_PARSE_DEFAULT, callback=0x2aece0 <bs_parse_cb>,  
context=0x0, error=0xbfffec00) at bs.c:484
#13 0x002b2bcc in _bs_parse (path=0xbfffe800 "/System/Library/ 
AddressBook.bridgesupport", loaded_paths=0xbfffd770,  
options=BS_PARSE_DEFAULT, callback=0x2aece0 <bs_parse_cb>,  
context=0x0, error=0xbfffec00) at bs.c:484
#14 0x002b5517 in bs_parse (path=0xbfffe800 "/System/Library/ 
AddressBook.bridgesupport", options=BS_PARSE_DEFAULT, callback=0,  
context=0x0, error=0x0) at bs.c:1101
#15 0x002a9f3a in rb_require_framework (argc=0, argv=0x0,  
recv=16893536) at objc.m:2158
#16 0x002927c5 in call_cfunc (func=0x2a99f0 <rb_require_framework>,  
recv=16893536, len=<value temporarily unavailable, due to  
optimizations>, argc=1, argv=0x370050) at vm_insnhelper.c:282
#17 0x002a0510 in vm_call_method (th=0x1013c70, cfp=0x3eff88, num=1,  
blockptr=0x1, flag=2145, id=9032, mn=0x107dde0, recv=16893536,  
klass=16893568) at vm_insnhelper.c:372
#18 0x00299d92 in vm_eval (th=0x1013c70, initial=0) at insns.def:1085
#19 0x0029f71c in vm_eval_body (th=0x1013c70) at vm.c:1149
#20 0x0029f9f1 in rb_iseq_eval (iseqval=17508880) at vm.c:1358
#21 0x001d9afa in ruby_exec_node (n=0x10b26b0, file=0x10b0e71 "/Users/ 
rb_main-mr.rb") at eval.c:237
#22 0x001df0df in ruby_run_node (n=0x10b26b0) at eval.c:265
#23 0x002aa8cb in macruby_main (path=0x31474 "rb_main-mr.rb", argc=3,  
argv=0x40f090) at objc.m:2753
#24 0x00002561 in main (argc=1, argv=0xbffff790) at /Users/pierce/ 

  I'll send you the project as well. Pass it along to whoever you like.

> Thanks for trying all of this, of course MacRuby is currently under  
> heavy development, and I hope all these problems will disappear when  
> we release a stable version.

   I'm hoping the more poking around I do, the faster it gets done. :-)

   Hell, maybe Frictionless can become one of the standard samples.


More information about the MacRuby-devel mailing list