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

[MacRuby] #216: fork subprocess exiting (normally) segfaults
by MacRuby 11 Feb '10

11 Feb '10

#216: fork subprocess exiting (normally) segfaults -------------------------------+-------------------------------------------- Reporter: celtic@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: fork process -------------------------------+-------------------------------------------- When '''fork''''s subprocess dies, it segfaults about 80% of the time (out of a sample of 10 runs): {{{ echo "fork {}" | macruby }}} Calling the non-block version alone like this seems to segfault less often, perhaps 50% of the time: {{{ echo fork | macruby }}} Note that it's only the subprocess that segfaults, and not the main process. This can be demonstrated: {{{ fork { } sleep 1 puts "soup" }}} This produces the segfault output, followed by 'soup' a moment later. Strangely, sleeping after the non-block call causes things to work: {{{ fork sleep 1 }}} (no segfault with the above code) -- Ticket URL: <http://www.macruby.org/trac/ticket/216> MacRuby <http://macruby.org/>

1 6

[MacRuby] #250: subclassing Array
by MacRuby 11 Feb '10

11 Feb '10

#250: subclassing Array -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: subclassing, Array -------------------------------------+-------------------------------------- {{{ class Board < Array def initialize(*args) super 0.upto(7) do self << (0..7).map{[]} end end end b = Board.new }}} {{{ ./miniruby -I./lib -e "class Board < Array; def initialize(*args); super; 0.upto(7) do; self << (0..7).map{[]}; end; end; end; p Board.new" # => [] }}} {{{ macruby -e "class Board < Array; def initialize(*args); super; 0.upto(7) do; self << (0..7).map{[]}; end; end; end; p Board.new" # => [] }}} {{{ ruby19 -e "class Board < Array; def initialize(*args); super; 0.upto(7) do; self << (0..7).map{[]}; end; end; end; p Board.new" # => [[[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []]] }}} {{{ ruby -e "class Board < Array; def initialize(*args); super; 0.upto(7) do; self << (0..7).map{[]}; end; end; end; p Board.new" # => [[[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []], [[], [], [], [], [], [], [], []]] }}} I think the problem is pretty obvious, let me know if you need more explanations. -- Ticket URL: <http://www.macruby.org/trac/ticket/250> MacRuby <http://macruby.org/>

1 1

[MacRuby] #159: "%d" with large integer argument gives conversion error
by MacRuby 11 Feb '10

11 Feb '10

#159: "%d" with large integer argument gives conversion error ---------------------------------+------------------------------------------ Reporter: jamis(a)37signals.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ The following script reproduces the error easily: {{{ N = 34363859232 p N p N.class puts "%d" % N }}} This results in the following exception: {{{ 01.rb:5:in `%': integer 34363859232 too big to convert to `int' (RangeError) }}} When run in ruby 1.9, the output shows that N is a Bignum. When run in macruby, the output shows that N is a fixnum. This appears to be due to bignum.c line 523: {{{ if (len <= (sizeof(long)*CHAR_BIT)) { }}} Apparently, in macruby, sizeof(long) is 8, which means bignums are only instantiated for integers larger than 64 bits or so, and in the above example, the integer is only 44 bits. Even though the bignums are only created based on sizeof(long), the rb_str_format function in sprintf.c uses FIX2LONG for converting the VALUE to a long int, and FIX2LONG uses INT_MIN and INT_MAX to check the bounds of the integer. I'm not sure what the safest way to fix this is. Should check_int (and others?) in numeric.c be comparing against larger boundary numbers, instead of INT_MIN/MAX? -- Ticket URL: <http://www.macruby.org/trac/ticket/159> MacRuby <http://macruby.org/>

1 13

[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] #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] #148: Trying to load the JSON library crashes
by MacRuby 08 Jan '10

08 Jan '10

#148: Trying to load the JSON library crashes ---------------------------------------+------------------------------------ Reporter: wootest+macruby(a)gmail.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ---------------------------------------+------------------------------------ Steps to reproduce: 1. In any .rb file in any MacRuby project, try to load the Ruby standard JSON library with "require 'json'". Notes:[[BR]] This happens in both 0.3 and the testing branch as of r671. Results: {{{ 2008-10-26 21:39:57.735 testmacruby[30789:10b] *** +[JSON module_function]: unrecognized selector sent to class 0x93effb0 /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/json/common.rb:106:in `module_function': NSInvalidArgumentException: *** +[JSON module_function]: unrecognized selector sent to class 0x93effb0 (RuntimeError) from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/json/common.rb:106:in `<module:JSON>' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/json/common.rb:3:in `<top (required)>' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/json.rb:1:in `require' from /Library/Frameworks/MacRuby.framework/Versions/0.3/usr/lib/ruby/1.9.0/json.rb:1:in `<top (required)>' from /Users/jesper/Desktop/testmacruby/build/Debug/testmacruby.app/Contents/Resources/rb_main.rb:13:in `require' from /Users/jesper/Desktop/testmacruby/build/Debug/testmacruby.app/Contents/Resources/rb_main.rb:13:in `<main>' }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/148> MacRuby <http://macruby.org/>

1 2