March 2012 - macruby-tickets - lists.macosforge.org

[MacRuby] #1479: app not automagic-ly launching after build - xcode 4.3
by MacRuby 08 Mar '12

08 Mar '12

#1479: app not automagic-ly launching after build - xcode 4.3 --------------------------------+------------------------------------------- Reporter: g@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: --------------------------------+------------------------------------------- When building an app in Xcode 4.3 the "end product" App does not launch - forcing the user to locate the location of the App and manually launch This is not a major problem except for a beginner/noob who is learning Xcode and MacRuby at the same time.. (current behavior differs from Xcode and Macruby documentation) The normal (expected) behavior for Xcode is to launch a newly built App. I am running Macruby .12 nightly (as of march 3rd 2012) clean install of Xcode 4.3 (4E109) thx! -- Ticket URL: <http://www.macruby.org/trac/ticket/1479> MacRuby <http://macruby.org/>

1 2

[MacRuby] #1227: Xcode 4 templates are not installed properly if the install location is not on the system drive
by MacRuby 05 Mar '12

05 Mar '12

#1227: Xcode 4 templates are not installed properly if the install location is not on the system drive -------------------------------+-------------------------------------------- Reporter: shazron@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: xcode4 -------------------------------+-------------------------------------------- Right now the Xcode 4 template install location is based off "/Developer". If someone installed Xcode in another drive, or another folder in the system drive, it will not be installed properly. The proper way to detect the Xcode install location is by running `xcode- select -print-path` and using that value. -- Ticket URL: <http://www.macruby.org/trac/ticket/1227> MacRuby <http://macruby.org/>

1 2

[MacRuby] #1480: infinity loops occurs with RubySpec if compiled MacRuby with clang
by MacRuby 05 Mar '12

05 Mar '12

#1480: infinity loops occurs with RubySpec if compiled MacRuby with clang ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- In some Bignum and BigDecimal specs, it seems to occur the infinity loops when compiled with clang. {{{ $ CC=/usr/bin/clang CXX=/usr/bin/clang++ rake jobs=4 $ rake spec:rubyspec rm -rf rubyspec_temp ./mspec/bin/mspec ci -B ./spec/macruby.mspec :rubyspec MacRuby 0.12 (ruby 1.9.2) [universal-darwin11.0, x86_64] .......................................................................................................................................................................................................................................................^C Process aborted! rake aborted! Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...] Tasks: TOP => spec:rubyspec (See full trace by running task with --trace) }}} For passing the RubySpec, I needed some RubySpec Tags. https://gist.github.com/1978307 -- Ticket URL: <http://www.macruby.org/trac/ticket/1480> MacRuby <http://macruby.org/>

1 0

[MacRuby] #1382: GCC 4.2 not installed with Xcode 4.2
by MacRuby 04 Mar '12

04 Mar '12

#1382: GCC 4.2 not installed with Xcode 4.2 ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------------+--------------------------------------- The new Xcode no longer ships with gcc-4.2. It leaves an old binary around if you installed 4.1 or an earlier 4.2 beta, but as of beta 6 it is no longer present. New machines that install Xcode will not be able to compile C extensions since mkmf gets the compiler path from RbConfig. A symlink to llvm-gcc seems to work for now. -- Ticket URL: <http://www.macruby.org/trac/ticket/1382> MacRuby <http://macruby.org/>

1 10

[MacRuby] #1462: gem "Twitter4R" require fails
by MacRuby 03 Mar '12

03 Mar '12

#1462: gem "Twitter4R" require fails ---------------------------------+------------------------------------------ Reporter: cumomican@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby Later Component: MacRuby | Keywords: twitter4r ---------------------------------+------------------------------------------ {{{ $ macruby -v MacRuby 0.12 (ruby 1.9.2) [universal-darwin10.0, x86_64] $ macirb irb(main):001:0> require 'rubygems' => true irb(main):002:0> gem 'twitter4r' => true irb(main):003:0> require 'twitter' TypeError: JSON::Ext::Generator::GeneratorMethods::Object:Class is not a module /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/json-1.6.5/lib/json/ext.rb:14:in `block' /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/json-1.6.5/lib/json/ext.rb:12:in `block' /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/json-1.6.5/lib/json/ext.rb:9:in `<main>' /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/json-1.6.5/lib/json.rb:58:in `block' /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/json-1.6.5/lib/json.rb:54:in `<main>' /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/ruby/Gems/1.9.2/gems/twitter4r-0.7.0/lib/twitter.rb:23:in `<main>' irb(main):004:0> require 'twitter' Segmentation fault: 11 $ }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/1462> MacRuby <http://macruby.org/>

1 3

[MacRuby] #1478: Dispatch::Queue#barrier_{sync, async} should check OS version at runtime
by MacRuby 02 Mar '12

02 Mar '12

#1478: Dispatch::Queue#barrier_{sync, async} should check OS version at runtime ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- When runs MacRuby on OS X 10.6 which is built on OS X 10.7, Dispatch::Queue#barrier_{sync, async} cause crash. OS version check exists at compile-time. [[BR]] https://github.com/MacRuby/MacRuby/blob/master/gcd.c#L511-521 [[BR]] https://github.com/MacRuby/MacRuby/blob/master/gcd.c#L544-554 I think these methods also need to check at runtime. {{{ gcdq = Dispatch::Queue.concurrent('org.macruby.documentation') p gcdq.class @i = "" gcdq.barrier_sync { @i += 'c' } gcdq.barrier_async { @i += 'c' } }}} {{{ $ uname -a Darwin watson.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 $ macruby t.rb dyld: Symbol not found: __dispatch_queue_attr_concurrent Referenced from: /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/libmacruby.dylib Expected in: flat namespace in /Library/Frameworks/MacRuby.framework/Versions/0.12/usr/lib/libmacruby.dylib zsh: trace trap macruby t.rb }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/1478> MacRuby <http://macruby.org/>

1 0

[MacRuby] #1476: The dispatcher in the current master branch does not work reliable in a threaded env .
by MacRuby 02 Mar '12

02 Mar '12

#1476: The dispatcher in the current master branch does not work reliable in a threaded env . -------------------------------------+-------------------------------------- Reporter: eloy.de.enige@… | Owner: eloy.de.enige@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: regression dispatcher threads -------------------------------------+-------------------------------------- While working on a GCD version of MacBacon I noticed that on HEAD I get a lot of warnings about passing a block to an Objective-C method and segfaults. The warning clearly shows that these messages are being sent to the incorrect object, because the code sends it to pure Ruby objects, and the segfaults are a logical result from this. The problem does not exist in 0.10. I will have to do some git bisecting to get to the commit that introduced the regression and report back. -- Ticket URL: <http://www.macruby.org/trac/ticket/1476> MacRuby <http://macruby.org/>

1 6