November 2008 - MacRuby-devel - lists.macosforge.org

Re: [MacRuby-devel] NSNumber Numeric Patch
by Jonathan deWerd 29 Nov '08

29 Nov '08

> Thread about patch that adds Numeric methods directly to NSNumbers Just caught a "todo" as I was looking through the code. NSNumbers returned from objc methods are (sometimes not?) converted to ruby objects. That code would be unnecessary, since the conversion will happen automatically. In effect, my patch did the "TODO" item in the code :) This patch nukes the appropriate code (the tests and my app seem to be unaffected, which is a good sign). Needless to say, it probably won't work very well if applied before my other patch to numeric.c.

1 0

Re: [MacRuby-devel] NSNumber Numeric Patch
by Jonathan deWerd 29 Nov '08

29 Nov '08

> Hi Jonathan, > > On Nov 28, 2008, at 7:08 PM, Jonathan deWerd wrote: > >> Hi! >> I was tracking down a bug in my app that caused a crash, and I >> finally narrowed it down to the conversion between NSNumber and the >> Numeric types. I don't think that was the direct cause of the crash >> (the immediate cause was a longjmp to a nonexistant "thread"), but >> manually converting it via to_i made it work just fine. In the >> spirit of "if it's worth doing once, it's worth automating" I wrote >> some code that patches NSNumber itself to act more like a a Numeric. >> You can now mix it in just about anywhere, with bignums and floats >> and ints and it should all Just Work. >> >> This patch doesn't replace any ruby Numeric machinery, it just adds >> a bit of sugar to the bridge. >> <numeric.c.patch> >> >> I didn't write any formal test cases for it since I was hoping a >> greater ruby mind than I could figure out an easy way to subvert the >> Numeric test cases to my purposes :) >> I would love for anyone experienced with boundary conditions to take >> a look at it. I think I got just about everything, but an awful lot >> of hackery goes on with ruby's numeric types, so a second opinion >> would be most welcome. > > This is very interesting! In fact, I was planning to implement > something very similar in order to fix http://www.macruby.org/trac/ticket/112 > > My idea is to move the Numeric methods to NSNumber directly (very > similarly to what we currently do for NSString, NSArray and > NSDictionary), so that pure NSNumber objects can respond to #+, #- > etc... > > So your patch seems to already implement parts of this idea. The next > step would be to make sure these methods are created on NSNumber and > that this still works with Fixnums, which are as you might know > special types in the core. They are not real objects but masked > pointers, unless they got converted to a RFixnum structure in order to > be passed to Objective-C. (Eventually I would like to get rid of the > masked pointers and use RFixnum structures for every Fixnum, which > shouldn't turn that bad performance wise once we will JIT compile the > arithmetic code paths. I would investigate that later.) > > Would you be willing to adapt your patch to implement this idea? Sure, but I think we might want to make sure that's the best option before we go ahead and do it. Currently (as in after the patch) NSNumber interoperates almost perfectly with the existing ruby infrastructure: >> n = (NSNumber.numberWithInt(3)**NSNumber.numberWithInt(100000)) => Some amusingly large number >> n==(NSNumber.numberWithInt(3)**NSNumber.numberWithInt(100000)) => true >> n==(3**NSNumber.numberWithInt(100000)) => true >> n==(3**100000) => true >> n.to_s(10).length => 47713 >> 10[NSNumber.numberWithInt(3)] => 1 >> NSNumber.numberWithFloat(10.1)+NSNumber.numberWithInt(2)+1 => 13.1000003814697 >> NSNumber.numberWithFloat(10)+NSNumber.numberWithInt(2)-0.1 => 11.9 >> 1+NSNumber.numberWithInt(10)+NSNumber.numberWithInt(2) => 13 Basically, unless there is a very simple operation being done (with no sharp edge cases that I was uncertain about), it converts itself into a ruby object or pseudo-object and passes itself directly to the C implementations of the appropriate ruby methods. This probably performs better than keeping it as a CFNumber, since a CFNumber's value would need to be fetched and a new CFNumber would need to be reallocated for every operation (and I believe the ruby equivalents are quite a bit cheaper). Current ("ruby") solution: 1 CFNumber value fetch (2 C calls) for each OC->RB crossing (no double- dispatch penalty, it sends the new object right to the C functions) 1 RFixnum allocation for each RB->OC crossing Cheap numeric operations (no allocations in the good case, at worst it's probably the same as objc) Complete NSNumber conversion ("objc" solution): 1 CFNumber value fetch for each numeric operation 1 CFNumber allocation for each numeric operation Using FIXABLE() numbers, both solutions should approximately tie for 1- step arithmetic. But in every other case, the ruby solution should be faster, and it has the advantage of already being implemented :-) It just occurred to me that I left out method dispatch overhead. You're the expert on that, so you tell me how it weighs in here :) I would love to see something like FScript's operator methods ('+' maps to 'add:', and the like). Would using objc_msgSend make it worth the allocation overhead? For compatibility reasons, a complete overhaul of the FIXNUM system probably wouldn't be very practical: any "regular" ruby C API code would still use the FIXNUM interface, so you would have to keep it around even if you replaced it with something more elegant under the hood. Unless there are secret plans I don't know about :) > > >> Thanks to everyone here working on macruby, you've done an amazing >> job. It's a very worthy successor to rubycocoa :) > > I'm very glad you like it, and thanks for taking the time to hack on a > patch :-) > >> PS >> While you're applying patches, I've got another quick one in a >> ticket that deals with macruby_main and absolute paths: http://www.macruby.org/trac/ticket/163 > > I will look at this one, thanks for reminding me! Thanks for applying it :)

1 0

[MacRuby] #163: macruby_main forces a relative path
by MacRuby 29 Nov '08

29 Nov '08

#163: macruby_main forces a relative path ----------------------------------+----------------------------------------- Reporter: jjoonathan(a)gmail.com | Owner: lsansonetti(a)apple.com Type: enhancement | Status: new Priority: minor | Milestone: MacRuby 0.4 Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Sometimes it makes sense to load a script from a path external to the main bundle (say, inside an input manager or something), but macruby_main automatically prepends the main bundle's resource path, making the use of absolute paths (via ../../ etc) extremely hackish. My proposed solution is also hackish, but it works. Simply check to see if the path starts with a "/" and don't prepend the resource folder path if that's the case. '''objc.m:2819''' s/&p1[2]/(path[0] != '/') ? &p1[2] : "" -- Ticket URL: <http://www.macruby.org/trac/ticket/163> MacRuby <http://macruby.org/>

1 1

NSNumber Numeric Patch
by Jonathan deWerd 29 Nov '08

29 Nov '08

Hi! I was tracking down a bug in my app that caused a crash, and I finally narrowed it down to the conversion between NSNumber and the Numeric types. I don't think that was the direct cause of the crash (the immediate cause was a longjmp to a nonexistant "thread"), but manually converting it via to_i made it work just fine. In the spirit of "if it's worth doing once, it's worth automating" I wrote some code that patches NSNumber itself to act more like a a Numeric. You can now mix it in just about anywhere, with bignums and floats and ints and it should all Just Work. This patch doesn't replace any ruby Numeric machinery, it just adds a bit of sugar to the bridge. I didn't write any formal test cases for it since I was hoping a greater ruby mind than I could figure out an easy way to subvert the Numeric test cases to my purposes :) I would love for anyone experienced with boundary conditions to take a look at it. I think I got just about everything, but an awful lot of hackery goes on with ruby's numeric types, so a second opinion would be most welcome. Thanks to everyone here working on macruby, you've done an amazing job. It's a very worthy successor to rubycocoa :) PS While you're applying patches, I've got another quick one in a ticket that deals with macruby_main and absolute paths: http://www.macruby.org/trac/ticket/163

2 1

macruby or macirb bug
by Tim Rand 29 Nov '08

29 Nov '08

In macirb the following code crashes >> array = NSMutableArray.arrayWithObjects([1,2]) => [[1, 2], 1511869] >> array => [[1, 2], 1511869] >> array.length => 2 >> array2 = NSMutableArray.arrayWithObjects([1, 2, "this"]) Killed Using the more ruby friendly way of assigning a variable to an array works. >> array = [1,2,"this"] =>[1, 2, "this"]

3 2

[MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
by MacRuby 29 Nov '08

29 Nov '08

#164: MacRuby crashes Cocoa app with exception in CFEqual --------------------------------+------------------------------------------- Reporter: self(a)mattmower.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby | Keywords: crash,cfequal --------------------------------+------------------------------------------- Cocoa application built using MacRuby r746 on OS 10.5.5 with a Core 2 Duo MBP with 4GB of RAM. I am invoking a ruby proc using performRubySelector as follows: callSelector = @selector(call:); proc = [[MacRuby sharedRuntime] evaluateString:[NSString stringWithFormat:@"proc %@", source]]; return [proc performRubySelector:callSelector withArguments:_arg1_,_arg2_,nil]; in this case I am passing two Objective-C objects, part of my application data model, into the proc. The source of the proc is: do |generateTool,player| if rand < 0.5 generateTool.directionKnob.value = 1 else generateTool.directionKnob.value = 5 end end At some point the application crashes with the following stack trace: (gdb) thread apply all bt Thread 6 (process 59831 thread 0x6f17): #0 0x9063c68e in __semwait_signal () #1 0x90667986 in _pthread_cond_wait () #2 0x9066736d in pthread_cond_wait$UNIX2003 () #3 0x900db692 in -[NSCondition wait] () #4 0x9009402a in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] () #5 0x900e7648 in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] () #6 0x0001cf7e in -[ELTool run:] (self=0x22afa80, _cmd=0x96884ee0, _playhead_=0x0) at /Users/matt/Projects/LucidMac/Elysium/src/tools/ELTool.m:83 #7 0x000087bc in -[ELLayer pulse] (self=0x2246630, _cmd=0x2b27f) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:245 #8 0x00007f9f in -[ELLayer run] (self=0x2246630, _cmd=0x96884a24) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:155 #9 0x000081ca in -[ELLayer runLayer] (self=0x2246630, _cmd=0x2b203) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:177 #10 0x90093bad in -[NSThread main] () #11 0x90093754 in __NSThread__main__ () #12 0x906666f5 in _pthread_start () #13 0x906665b2 in thread_start () Thread 5 (process 59831 thread 0x5403): #0 0x9063c68e in __semwait_signal () #1 0x9063c50f in nanosleep$UNIX2003 () #2 0x002ec71e in thread_timer (dummy=0x0) at thread_pthread.c:571 #3 0x906666f5 in _pthread_start () #4 0x906665b2 in thread_start () Thread 4 (process 59831 thread 0x4d03): #0 0x906354a6 in mach_msg_trap () #1 0x9063cc9c in mach_msg () #2 0x00098f0f in XServerMachPort::ReceiveMessage () #3 0x0008b477 in MIDIInPortThread::Run () #4 0x0008f07d in XThread::RunHelper () #5 0x000999ee in CAPThread::Entry () #6 0x906666f5 in _pthread_start () #7 0x906665b2 in thread_start () Thread 3 (process 59831 thread 0x3d03): #0 0x906354a6 in mach_msg_trap () #1 0x9063cc9c in mach_msg () #2 0x011a7c39 in __ape_agent () #3 0x906666f5 in _pthread_start () #4 0x906665b2 in thread_start () Thread 2 (process 59831 thread 0x2a03): #0 0x9063c68e in __semwait_signal () #1 0x90667986 in _pthread_cond_wait () #2 0x9066736d in pthread_cond_wait$UNIX2003 () #3 0x93f36bcf in auto_collection_thread () #4 0x906666f5 in _pthread_start () #5 0x906665b2 in thread_start () Thread 1 (process 59831 thread 0x10b): #0 0x92fce036 in CFEqual () #1 0x900b917f in -[NSKeyValueUnnestedProperty _keyPathIfAffectedByValueForKey:exactMatch:] () #2 0x900b9015 in -[NSKeyValueUnnestedProperty keyPathIfAffectedByValueForKey:exactMatch:] () #3 0x9008fe81 in -[NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] () #4 0x9016c96d in _NSSetIntValueAndNotify () #5 0x903dc1dd in .LCFI1 () #6 0x903dc771 in ffi_call () #7 0x002fd3e0 in rb_objc_call2 (recv=36326752, klass=501521904, sel=0x1283530, imp=0x9016c8f0 <_NSSetIntValueAndNotify>, sig=0x202e630, bs_method=0x0, argc=1, argv=0x14e0058) at objc.m:1296 #8 0x002e64d3 in vm_call_method (th=0x203b6b0, cfp=0x155ff50, num=1, blockptr=0x0, flag=97, id=<value temporarily unavailable, due to optimizations>, recv=36326752, klass=501521904, mcache=0x202e620) at vm_insnhelper.c:662 #9 0x002d6759 in vm_eval (th=0x203b6b0, initial=<value temporarily unavailable, due to optimizations>) at insns.def:1067 #10 0x002e0f6b in vm_eval_body (th=0x203b6b0) at vm.c:1033 #11 0x002e14db in vm_invoke_proc (th=0x203b6b0, proc=0x22a3530, self=33777776, argc=1, argv=0xbfffe5b0, blockptr=0x0) at vm.c:449 #12 0x0020ab6f in proc_call (argc=1, argv=0x1, procval=1) at proc.c:506 #13 0x002cf035 in call_cfunc (func=0x20ab10 <proc_call>, recv=36301072, len=<value temporarily unavailable, due to optimizations>, argc=1, argv=0xbfffe5b0) at vm_insnhelper.c:289 #14 0x002e2539 in vm_call0 (th=0x203b6b0, klass=19322032, recv=36301072, id=128335, oid=4, argc=1, argv=0xbfffe5b0, body=0x2069c40, nosuper=0) at vm_eval.c:75 #15 0x002f4db8 in performRuby_safe (arg=1) at objc.m:3545 #16 0x002052a9 in rb_rescue2 (b_proc=0x2f4d60 <performRuby_safe>, data1=3221218812, r_proc=0x2f4dc0 <performRuby_rescue>, data2=0) at eval.c:662 #17 0x002f8f47 in -[NSObject(MacRubyAdditions) performRubySelector:withArguments:count:] (self=0x229e910, _cmd=0x30fd70, sel=0x2f1a0, argv=0xbfffe660, argc=1) at objc.m:3609 #18 0x002f4ea0 in -[NSObject(MacRubyAdditions) performRubySelector:withArguments:] (self=0x1, _cmd=0x30fd4c, sel=0x1, firstArg=0x22afa80) at objc.m:3649 #19 0x0001e42a in -[RubyBlock evalWithArg:arg:] (self=0x23b5ec0, _cmd=0x2ef72, _arg1_=0x22afa80, _arg2_=0x0) at /Users/matt/Projects/LucidMac/Elysium/src/scripting/RubyBlock.m:55 #20 0x0001d0bf in -[ELTool runWillRunScript:] (self=0x22afa80, _cmd=0x2effc, _playhead_=0x0) at /Users/matt/Projects/LucidMac/Elysium/src/tools/ELTool.m:104 #21 0x9009475c in __NSThreadPerformPerform () #22 0x92fcb615 in CFRunLoopRunSpecific () #23 0x92fcbcf8 in CFRunLoopRunInMode () #24 0x946a1480 in RunCurrentEventLoopInMode () #25 0x946a1299 in ReceiveNextEventCommon () #26 0x946a110d in BlockUntilNextEventMatchingListInMode () #27 0x927073ed in _DPSNextEvent () #28 0x92706ca0 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #29 0x926ffcdb in -[NSApplication run] () #30 0x926ccf14 in NSApplicationMain () #31 0x00002670 in main (argc=3, argv=0xbffff6ac) at /Users/matt/Projects/LucidMac/Elysium/main.m:13 (gdb) then crashed with an EXC_BAD_ACCESS signal. This problem is blocking the next release of my app which utilizes a lot of Ruby scripting. -- Ticket URL: <http://www.macruby.org/trac/ticket/164> MacRuby <http://macruby.org/>

1 6

Re: [MacRuby-devel] MacRuby-devel Digest, Vol 9, Issue 42
by Luke Evans 26 Nov '08

26 Nov '08

Excellent. Thanks for the pointer and the heads up about the sleeping dragons. On 26-Nov-08, at 7:00 AM, Laurent Sansonetti wrote: > MacRuby trunk ships an Objective-C API that you can use to communicate > with the interpreter. > Note that there are currently 2 known bugs about this "feature". These > will be fixed for 0.4 (the next release).

1 0

Using the MacRuby framework to embed ruby in Objective-C
by Luke Evans 25 Nov '08

25 Nov '08

Hi, Thanks for MacRuby, I'm going to follow its development closely. While I wouldn't use Ruby (without static typing) for large-scale development, IMHO, it is my favourite scripting language for those "little jobs", and I'm currently interested in it as an embedded language in my app. Given the interest, I thought I would try creating a mini obj-c project, including the MacRuby framework, to attempt some simple interactions with ruby from obj-c. Accordingly, I created some toy code: - (void)awakeFromNib { ruby_init(); rb_eval_string("puts 'hello world'"); ruby_finalize(); } Running my little app, results in a series of messages of the form" warning: Could not find object file "/private/tmp/trunk/xxxxx.o" - no debug information available for "xxxxx.c" where xxxxx are things like "array", "bignum", "class", "compar", ... etc. The app then crashes with a stack walk back containing a huge number of nested exceptions (it seems). Now, it's quite possible that I'm just not driving this right (to date I've always scripted in Ruby, and never attempted to drive it from C). Equally, I'd imagine that it's possible that the 0.3 version of the framework isn't up to this yet. If I can get past this point, I can see the objective-c interfacing functions in the header file, so things might be peachy from then on :-) Can anyone enlighten me? Cheers Luke

2 1

Can't build trunk
by Patrick Bennett 25 Nov '08

25 Nov '08

I'm at revision 749 of the trunk and can't seem to build the trunk (it's done this for several revisions). It seems like I'm alone here but I've done nothing but fetch the source and tried to build it. The only thing I can think of that 'might' be an issue is that before I ever downloaded the MacRuby code, I downloaded and installed one of the binary releases. Here's a snip of the tail of my build output: ... compiling json make: Nothing to be done for `all'. compiling json/ext/generator gcc -I. -I../../../../.ext/include/universal-darwin9.1 - I../../..//.././include -I../../..//.././ext/json/ext/generator - DRUBY_EXTCONF_H=\"extconf.h\" -fno-common -fno-common -pipe -Wall - arch i386 -arch x86_64 -o generator.o -c generator.c generator.c: In function ‘cState_configure’: generator.c:493: warning: implicit declaration of function ‘RHASH_TBL’ generator.c:493: warning: passing argument 1 of ‘st_lookup’ makes pointer from integer without a cast generator.c: In function ‘cState_configure’: generator.c:493: warning: implicit declaration of function ‘RHASH_TBL’ generator.c:493: warning: passing argument 1 of ‘st_lookup’ makes pointer from integer without a cast generator.c:501: warning: passing argument 1 of ‘st_lookup’ makes pointer from integer without a cast generator.c:501: warning: passing argument 1 of ‘st_lookup’ makes pointer from integer without a cast gcc -I. -I../../../../.ext/include/universal-darwin9.1 - I../../..//.././include -I../../..//.././ext/json/ext/generator - DRUBY_EXTCONF_H=\"extconf.h\" -fno-common -fno-common -pipe -Wall - arch i386 -arch x86_64 -o unicode.o -c unicode.c gcc -dynamic -bundle -undefined suppress -flat_namespace -arch i386 - arch x86_64 -o ../../../../.ext/universal-darwin9.1/json/ext/ generator.bundle generator.o unicode.o -L. -L../../../.. -arch i386 - arch x86_64 -lmacruby compiling json/ext/parser make: *** No targets. Stop. rake aborted! Command failed with status (1): [./miniruby -I./lib -I.ext/common - I./- -r....] /Users/patrickb/dev/MacRuby-trunk/rakefile:549 (See full trace by running task with --trace) Thanks... Patrick

4 10

[MacRuby] #168: NSNotFound is different from returned values
by MacRuby 25 Nov '08

25 Nov '08

#168: NSNotFound is different from returned values ---------------------------------+------------------------------------------ Reporter: psychs@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ Code: {{{ s = 'test' r = s.rangeOfString 'abc' puts r.location puts NSNotFound }}} Output: {{{ 9223372036854775807 2147483647 }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/168> MacRuby <http://macruby.org/>

1 1