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

[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] #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

[MacRuby] #372: Error while requiring rss module
by MacRuby 01 Feb '10

01 Feb '10

#372: Error while requiring rss module ------------------------------+--------------------------------------------- Reporter: dmlary@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: rss, macruby 0.5 beta 1 ------------------------------+--------------------------------------------- Using macruby 0.5 beta 1, {{{ ~> macruby --version MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64] ~> cat rss.rb require 'rss' ~> macruby rss.rb rss.rb:1:in `<main>': undefined method `split' for nil:NilClass (NoMethodError) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/372> MacRuby <http://macruby.org/>

1 2

[MacRuby] #290: Hashes do NOT stay ordered
by MacRuby 31 Jan '10

31 Jan '10

#290: Hashes do NOT stay ordered -----------------------------------+---------------------------------------- Reporter: martin.ploeger@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: Hash order -----------------------------------+---------------------------------------- Hashes in Ruby 1.9 keep their order. In MacRuby (macirb): {:aa=>1, :a=>1} => {:a =>1, :aa=>1} According to Ruby 1.9 the result should be in the input-order: => {:aa =>1, :a=>1} The same is true for methods on a Hash like Hash#keys: The should return the keys in the input-order. -- Ticket URL: <http://www.macruby.org/trac/ticket/290> MacRuby <http://macruby.org/>

1 9

[MacRuby] #523: require of 'rss/2.0' fails.
by MacRuby 30 Jan '10

30 Jan '10

#523: require of 'rss/2.0' fails. -----------------------------+---------------------------------------------- Reporter: rob@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------+---------------------------------------------- robert-gleesons-iMac:~ robertgleeson$ macirb irb(main):001:0> require 'rss/2.0' NoMethodError: undefined method `get_file_and_line_from_caller' for RSS::Rss:Class from (irb):1:in `<main>' from core:in `eval:' from core:in `evaluate:' The same error is reported with require 'rss/1.0' Thanks Rob -- Ticket URL: <http://www.macruby.org/trac/ticket/523> MacRuby <http://macruby.org/>

1 3

[MacRuby] #493: signals cannot be intercepted
by MacRuby 26 Jan '10

26 Jan '10

#493: signals cannot be intercepted -----------------------------------+---------------------------------------- Reporter: lsansonetti@… | Owner: martinlagardette@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Currently MacRuby doesn't allow you to catch signals (via the Kernel#trap method). This should be implemented in the final 0.5 release. -- Ticket URL: <http://www.macruby.org/trac/ticket/493> MacRuby <http://macruby.org/>

1 3

[MacRuby] #513: MacRuby gets confused about inheritance under certain conditions
by MacRuby 25 Jan '10

25 Jan '10

#513: MacRuby gets confused about inheritance under certain conditions -----------------------------------+---------------------------------------- Reporter: matthew@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Given the following code, {{{ module Foo module Baz def initialize(a, b) end end end module Foo module Bar module Baz include Foo::Baz def initialize(a, b, c, d) super(a, b) end end end end module Foo module Bar module Quux include Baz end end end module Foo module Bar module Baz class Bat include Foo::Bar::Baz include Foo::Bar::Quux end end end end }}} There are two related errors associated with this piece of code. 1. {{{Foo::Bar::Baz::Bat.new}}} '''Expected result (Ruby 1.9.1)''' ArgumentError: wrong number of arguments (0 for 4) '''Actual result (MacRuby 0.5b2)''' => #<Foo::Bar::Baz::Bat:0x200252380> Note the difference in response from #512! 2. {{{Foo::Bar::Baz::Bat.new(nil, nil, nil, nil)}}} '''Expected result (Ruby 1.9.1)''' => #<Foo::Bar::Baz::Bat:0x913598> '''Actual result (MacRuby 0.5b2)''' ArgumentError: wrong number of arguments (4 for 2) It seems that MacRuby is becoming confused. Here are a few ways to make it understand that Foo::Bar::Baz::Bat#initialize should accept 4 arguments. - Comment out Foo::Bar::Baz::Bat's second include statement (line 33)[[BR]] - Comment out Foo::Bar::Quux's include statement (line 23)[[BR]] - Comment out Foo::Bar::Baz's include statement (line 11) and Foo::Bar::Baz#initialize's super call (line 14) Of course, for my application I need the original functionality, so none of those will work for me. :-) If you find a workaround while investigating, please let me know. -- Ticket URL: <http://www.macruby.org/trac/ticket/513> MacRuby <http://macruby.org/>

1 1

[MacRuby] #193: exec() does not work on MacRuby
by MacRuby 23 Jan '10

23 Jan '10

#193: exec() does not work on MacRuby ----------------------------------------+----------------------------------- Reporter: vincent.isambart@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- {{{ ~% macirb >> exec('ls') Errno::E045: Operation not supported - ls from (irb):1:in `exec' from (irb):1 from /usr/local/bin/macirb:12:in `<main>' >> }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/193> MacRuby <http://macruby.org/>

1 3

[MacRuby] #218: including a module which defines functions can mask functions of the same name in the including class
by MacRuby 20 Jan '10

20 Jan '10

#218: including a module which defines functions can mask functions of the same name in the including class -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: -------------------------------+-------------------------------------------- Simple explanation: classes A and B both define methods `foo', as does module M. A includes M before defining its own `foo', whereas B includes M afterwards. Given that A and B both call `super' in their `foo', it turns out that only A's `foo' ends up calling M's, whereas B's does not. Conclusion: including the module which defines the method after defining ones own causes it to be lost. I believe this is causes the problem first referred to in #215. Attaching a test case which verifies this behaviour. -- Ticket URL: <http://www.macruby.org/trac/ticket/218> MacRuby <http://macruby.org/>

1 3

[MacRuby] #489: Need a top-level Dispatch Object
by MacRuby 13 Jan '10

13 Jan '10

#489: Need a top-level Dispatch Object ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- GCD sources and queues both support: - suspend/resume - context data - finalizers It seems worthwhile to create a Dispatch::Base object which handles that, as well as retain/release, and have ::Queue and ::Source inherit from it. Even if we don't implement context data yet (and may never need finalizers), having the correct hierarchy now might save trouble later. -- Ticket URL: <http://www.macruby.org/trac/ticket/489> MacRuby <http://macruby.org/>

1 2