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

Ruby 1.9 Performance
by John-Paul Bader 06 Nov '09

06 Nov '09

Hey, don't know if this applies to MacRuby but its interesting non the less: A Japanese Teenage Boy Improved Ruby 1.9 Performance Up to 63% / Avarage: 8% http://yokolet.blogspot.com/2009/11/japanese-teenage-boy-improved-ruby-19.h… Kind regards, John

1 0

spotlight - MDItemRef
by Alan Skipp 04 Nov '09

04 Nov '09

Would anyone be able to give me a hint on how to get the following objective-c code working with macruby. The code uses spotlight to extract metadata from a file. MDItemRef inspectedRef = MDItemCreate(kCFAllocatorDefault,(CFStringRef)path); CFArrayRef attributeNames = MDItemCopyAttributeNames(inspectedRef); NSLog(@"%@", (NSArray*)attributeNames); I was hoping that including the 'CoreServices' framework would work, but no joy. >> framework 'CoreServices' => true >> item = MDItemCreate(KCFAllocatorDefault, '/Users/alan/Desktop/test.jpg') NameError: uninitialized constant KCFAllocatorDefault from core:in `const_missing:' from (irb):2:in `<main>' from core:in `eval:' from core:in `evaluate:' -- Alan Skipp al_skipp(a)fastmail.fm -- http://www.fastmail.fm - IMAP accessible web-mail

9 18

rSpec for MacRuby
by s.ross 04 Nov '09

04 Nov '09

When installing the gem using macgem, a shebang line is written pointing to macruby. The "spec" binary copied into /usr/bin forever after (or until manually edited or reinstalled) contains that shebang. Until MacRuby is close to parity with MRI (say... when MRI can run Rails), this may make less difference. Now, however, the single- location binary can cause a problem. I'm not sure what a sensible solution is to this, but thought since rSpec is getting some attention, I'd bring this up. -s

8 13

[MacRuby] #422: Kernel#caller compatibilty
by MacRuby 04 Nov '09

04 Nov '09

#422: Kernel#caller compatibilty -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- In a file: {{{ class Foo def self.bar puts caller(1) end end Foo.bar }}} macruby: {{{ core:in `caller:' simple_caller.rb:3:in `bar' simple_caller.rb:7:in `<main>' }}} ruby1.9: {{{ simple_caller.rb:7:in `<main>' }}} A tiny bit more advanced example: {{{ class Foo def self.bar baz do puts caller(1) end end def self.baz(&block) block.call end end Foo.bar }}} macruby: {{{ core:in `caller:' caller_proc.rb:9:in `baz' caller_proc.rb:3:in `bar' caller_proc.rb:13:in `<main>' }}} ruby1.9: {{{ caller_proc.rb:9:in `call' caller_proc.rb:9:in `baz' caller_proc.rb:3:in `bar' caller_proc.rb:13:in `<main> }}} Files attached. -- Ticket URL: <http://www.macruby.org/trac/ticket/422> MacRuby <http://macruby.org/>

1 0

[MacRuby] #421: MacGem reports wrong executable directory
by MacRuby 04 Nov '09

04 Nov '09

#421: MacGem reports wrong executable directory --------------------------------+------------------------------------------- Reporter: conradwt@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: beta 1 --------------------------------+------------------------------------------- `macgem environment` reports that the executable directory is - RUBY EXECUTABLE: /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/bin/macruby - EXECUTABLE DIRECTORY: /usr/bin Shouldn't the executable directory be the parent directory of the MacRuby executable? For example, I was thinking that it should be one of the following: /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/bin or /Library/Frameworks/MacRuby.framework/Versions/Current/usr/bin -- Ticket URL: <http://www.macruby.org/trac/ticket/421> MacRuby <http://macruby.org/>

1 0

[MacRuby] #254: Let void-returning ObjC calls return the receiver.
by MacRuby 03 Nov '09

03 Nov '09

#254: Let void-returning ObjC calls return the receiver. --------------------------------+------------------------------------------- Reporter: mikael@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- A lot of Objective-C methods return void, especially within Cocoa. This makes a lot of sense for a language like ObjC, but not nearly as much for Ruby, since all methods have a return value. Since method chaining is one of the things that make Ruby so elegant, I propose that all ObjC methods that are declared to return void actually return the receiver instead. This will allow for method chaining such as {{{ if someNSTask.launch.waitUntilExit.terminationStatus == 0 # … end }}} which would otherwise have to be written as {{{ someNSTask.waitUntilExit someNSTask.launch if someNSTask.terminationStatus == 0 # … end }}} . -- Ticket URL: <http://www.macruby.org/trac/ticket/254> MacRuby <http://macruby.org/>

1 1

Building LLVM 82747 on Snow Leopard with MacPorts ocaml installed
by Antony Blakey 03 Nov '09

03 Nov '09

I've just discovered that there is an interaction between the LLVM build process and OCaml - if OCaml is installed then LLVM 82747 will try and build OCaml bindings, which for me at least stops the LLVM build. The trick is to configure LLVM with: ./configure --enable-bindings=none Given the requirement to stick to a particular LLVM version, maybe this should be added to the README? Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Some defeats are instalments to victory. -- Jacob Riis

2 1

[MacRuby] #303: Method :open from 'open-uri' gives 'stack level too deep'
by MacRuby 03 Nov '09

03 Nov '09

#303: Method :open from 'open-uri' gives 'stack level too deep' ----------------------------+----------------------------------------------- Reporter: wijet@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.4 Component: MacRuby | Keywords: open-uri stdlib ----------------------------+----------------------------------------------- There seems to be a problem with method 'open' in open-uri lib. Following command: {{{ macruby -r 'open-uri' -e 'open "http://ruby-lang.org"' }}} produces {{{ /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?': stack level too deep (SystemStackError) from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/delegate.rb:150:in `respond_to?' ... 2922 levels... from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /open-uri.rb:146:in `open_uri' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /open-uri.rb:669:in `open' from /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /open-uri.rb:33:in `open' from -e:1:in `<main>' }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/303> MacRuby <http://macruby.org/>

1 3

[MacRuby] #199: Calling super from #respond_to? causes SystemStackError
by MacRuby 03 Nov '09

03 Nov '09

#199: Calling super from #respond_to? causes SystemStackError -------------------------------------+-------------------------------------- Reporter: eloy.de.enige@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- The following code results in a stack level too deep problem. I have added this as a test case to known_bugs.rb in r778. {{{ class Foo def respond_to?(method, hidden = false) super end end Foo.new.respond_to?(:object_id) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/199> MacRuby <http://macruby.org/>

1 2

[macruby] #108: Exception parsing XML file using REXML
by macruby 03 Nov '09

03 Nov '09

#108: Exception parsing XML file using REXML ----------------------------------+----------------------------------------- Reporter: jon.lipsky(a)gmail.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Hi, I am getting a "Can't modify immutable string" exception when trying to parse an XML document using the streaming parser included with REXML. I have created a sample script and sample XML file to reproduce the problem: {{{ require "rexml/document" require "rexml/streamlistener" include REXML class Reader include StreamListener def tag_start(a_name, a_attributes) puts(a_name + " - " + a_attributes.to_s) end end reader = Reader.new file = File.open("test.xml",File::RDONLY) Document.parse_stream(file, reader) }}} {{{ <?xml version="1.0" encoding="UTF-8"?> <test> </test> }}} Here is the stack trace that is generated: {{{ /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/rexml/parsers/baseparser.rb:260:in `force_encoding': can't modify immutable string (RuntimeError) from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/rexml/parsers/baseparser.rb:260:in `pull' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/rexml/parsers/streamparser.rb:16:in `parse' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/rexml/document.rb:200:in `parse_stream' from /Development/personal/ruby/rbface/src/rb/rexml_test.rb:16:in `<main>' }}} Thanks and best regards, Jon... -- Ticket URL: <https://www.macruby.org/trac/ticket/108> macruby <http://macruby.org/>

2 2