January 2010 - MacRuby-devel - lists.macosforge.org

[MacRuby] #564: Scoping within nested classes is broken
by MacRuby 08 Feb '10

08 Feb '10

#564: Scoping within nested classes is broken ---------------------------------------+------------------------------------ Reporter: joshua.ballanco@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: module ---------------------------------------+------------------------------------ The following code throws an 'uninitialize constant: A::C::D::B' error, when it should actually just find the module "B" -- {{{ module A module B end class C end class C::D include B end end }}} Note: Removing the surrounding "module A" eliminates the lookup problem. -- Ticket URL: <http://www.macruby.org/trac/ticket/564> MacRuby <http://macruby.org/>

1 1

[MacRuby] #570: Some STDOUT write function doesn't handle spaces or tabs correctly or something
by MacRuby 08 Feb '10

08 Feb '10

#570: Some STDOUT write function doesn't handle spaces or tabs correctly or something ---------------------------------+------------------------------------------ Reporter: honglilai@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ How to reproduce: {{{ $ macgem help commands GEM commands are: buildBuild a gem from a gemspec ... }}} Notice the lack of spacing between "build" and "Build a gem ...". -- Ticket URL: <http://www.macruby.org/trac/ticket/570> MacRuby <http://macruby.org/>

1 1

[MacRuby] #576: It's possible to close STDOUT (and presumably other standard IO streams)
by MacRuby 08 Feb '10

08 Feb '10

#576: It's possible to close STDOUT (and presumably other standard IO streams) -----------------------------------+---------------------------------------- Reporter: matthew@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Run the following in irb, then macirb: {{{ STDOUT.close }}} '''Expected (Ruby 1.9.1):''' {{{ => nil }}} '''Actual (MacRuby 0.5 beta 2):''' {{{ (closes interpreter) }}} The expected behavior is to ignore close requests to standard IO streams. Ruby does this, but MacRuby does not. When using macirb, calling {{{STDOUT.close}}} simply closes the interpreter, whereas in Ruby it returns nil. This has important real-world implications when dealing with logging. Consider logging to STDOUT; Logger#close actually closes the STDOUT stream! -- Ticket URL: <http://www.macruby.org/trac/ticket/576> MacRuby <http://macruby.org/>

2 5

[MacRuby] #580: popen3 causes abort trap
by MacRuby 08 Feb '10

08 Feb '10

#580: popen3 causes abort trap -------------------------------+-------------------------------------------- Reporter: cwdinfo@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -------------------------------+-------------------------------------------- {{{ irb(main):003:0> require 'open3' => true irb(main):004:0> Open3.popen3('ls') { |stdin, stdout, stderr| puts stdout.read} Abort trap }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/580> MacRuby <http://macruby.org/>

1 1

[MacRuby] #582: Segmentation fault using ScriptingBridge
by MacRuby 08 Feb '10

08 Feb '10

#582: Segmentation fault using ScriptingBridge ---------------------------------+------------------------------------------ Reporter: martin@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ Using MacRuby 0.5 beta 2, on Mac OS 10.6.2, typing the following code in macirb crashes with a segmentation fault on the last line: {{{ framework 'Foundation' framework 'ScriptingBridge' mail_app = SBApplication.applicationWithBundleIdentifier("com.apple.mail") properties = NSDictionary.dictionaryWithObjectsAndKeys "Hello", "subject", "Hello world!", "content", nil msg = mail_app.classForScriptingClass("outgoing message").alloc.initWithProperties(properties) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/582> MacRuby <http://macruby.org/>

1 2

[MacRuby] #354: Bundling framework in SL release build will not run on Leopard
by MacRuby 04 Feb '10

04 Feb '10

#354: Bundling framework in SL release build will not run on Leopard ------------------------------+--------------------------------------------- Reporter: jtc331@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- I have an app that has the embed macruby target include when I do a release build (Xcode is set to release for 10.5) but the generated release will only work on SL machines not Leopard machines. Neither machine tested has macruby installed. It crashes with the following error in the console: 9/28/09 5:50:59 PM [0x0-0x22022].com.yourcompany.MacRuby-Sim8086[18769] dyld: Library not loaded: @executable_path/../Frameworks/MacRuby.framework/Versions/0.5/usr/lib/libmacruby.dylib 9/28/09 5:50:59 PM [0x0-0x22022].com.yourcompany.MacRuby-Sim8086[18769] Referenced from: /Volumes/UNTITLED/MacRuby-Sim8086.app/Contents/MacOS /MacRuby-Sim8086 9/28/09 5:50:59 PM [0x0-0x22022].com.yourcompany.MacRuby-Sim8086[18769] Reason: no suitable image found. Did find: 9/28/09 5:50:59 PM [0x0-0x22022].com.yourcompany.MacRuby-Sim8086[18769] /Volumes/UNTITLED/MacRuby- Sim8086.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.5/usr/lib/libmacruby.dylib: unknown required load command 0x80000022 9/28/09 5:50:59 PM [0x0-0x22022].com.yourcompany.MacRuby-Sim8086[18769] /Volumes/UNTITLED/MacRuby- Sim8086.app/Contents/MacOS/../Frameworks/MacRuby.framework/Versions/0.5/usr/lib/libmacruby.dylib: unknown required load command 0x80000022 9/28/09 5:50:59 PM com.apple.launchd[72] ([0x0-0x22022].com.yourcompany .MacRuby-Sim8086[18769]) Exited abnormally: Trace/BPT trap -- Ticket URL: <http://www.macruby.org/trac/ticket/354> MacRuby <http://macruby.org/>

2 5

[MacRuby] #548: The flip-flop operator
by MacRuby 03 Feb '10

03 Feb '10

#548: The flip-flop operator -------------------------------------+-------------------------------------- Reporter: eloy.de.enige@… | Owner: martinlagardette@… Type: defect | Status: new Priority: trivial | Milestone: Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- MRI supports the flip-flop operator, MacRuby doesn't yet compile it I've added a test_vm testcase here: http://github.com/masterkain/macruby/blob/master/test_vm/conditional.rb#L54 -- Ticket URL: <http://www.macruby.org/trac/ticket/548> MacRuby <http://macruby.org/>

1 2

[MacRuby] #378: Macruby 0.5 allows instantiation of a Module instance
by MacRuby 02 Feb '10

02 Feb '10

#378: Macruby 0.5 allows instantiation of a Module instance ---------------------------------------+------------------------------------ Reporter: keith.gautreaux@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ---------------------------------------+------------------------------------ It seems that MacRuby treats modules differently than Ruby 1.9. You shouldn't be able to instantiate a named module using the new method, i.e. {{{ A = Module.new do def meth1 "hello" end end }}} YARV: {{{ a = A.new => NoMethodError: undefined method `new' for A:Module }}} but it does in MacRuby returning an instance of A:Module which responds to the meth1 call: {{{ a.meth1 =>"hello" }}} I believe the proper behavior (based on the 1.9 pickaxe documentation) is to allow extending of an object with A's methods but not instantiation. {{{ a = NSObject.new a.extend(A) a.meth1 => "hello" }}} Once I figure out how to write specs I'll see if I can submit a failing one. -- Ticket URL: <http://www.macruby.org/trac/ticket/378> MacRuby <http://macruby.org/>

1 4

Packaging a HotCocoa application without the standard library
by isaac kearse 02 Feb '10

02 Feb '10

Hey Guys, Just wrote a few blog posts about a HotCocoa app I just released, and how I packaged it up: http://isaac.kearse.co.nz/2010/01/31/stopwatch/ http://isaac.kearse.co.nz/2010/02/01/packaging-hotcocoa/ Interested in getting feedback about the way I embedded MacRuby & HotCocoa in this app. (also feedback about the app is welcome) I was thinking about patching HotCocoa to enable this out of the box because at the moment it seems to copy across the MacRuby framework instead of using macruby_deploy. Cheers, Isaac

2 2

[MacRuby] #571: #respond_to? should return false for unimplemented methods
by MacRuby 01 Feb '10

01 Feb '10

#571: #respond_to? should return false for unimplemented methods ---------------------------------+------------------------------------------ Reporter: honglilai@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ MRI >= 1.9.2's #respond_to? method now returns false for unimplemented methods. By "unimplemented" I mean methods which are #defined as rb_f_notimplement in the MRI 1.9 source code. rb_f_notimplemented is a method which raises NotImplementedErrror. An example of this is Process.fork, implemented on MRI 1.9 as rb_f_fork. The #fork method is defined on all platforms, even on platforms where fork is not actually supported (i.e. rb_f_fork is #defined to rb_f_notimplemented). However Process.respond_to?(:fork) now returns false instead of true on these platforms. MacRuby should follow this behavior. -- Ticket URL: <http://www.macruby.org/trac/ticket/571> MacRuby <http://macruby.org/>

1 3