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

[MacRuby] #592: No such file to load -- ubygems (LoadError)
by MacRuby 04 Jun '10

04 Jun '10

#592: No such file to load -- ubygems (LoadError) -------------------------------------+-------------------------------------- Reporter: lasse.koskela@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: LoadError -------------------------------------+-------------------------------------- After a fresh install of MacRuby 0.5 (the zipped-up installer .pkg), the macruby binary fails to load 'ubygems' when printing out the version, as shown below: $ /usr/local/bin/macruby -v[[BR]] MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, x86_64][[BR]] no such file to load -- ubygems (LoadError)[[BR]] $ On the other hand, the following does not emit the same error: $ /usr/local/bin/macruby -e 'puts "hello"'[[BR]] hello[[BR]] $ -- Ticket URL: <http://www.macruby.org/trac/ticket/592> MacRuby <http://macruby.org/>

1 2

[MacRuby] #549: Class variables are not initialised properly.
by MacRuby 03 Jun '10

03 Jun '10

#549: Class variables are not initialised properly. -------------------------------------+-------------------------------------- Reporter: sorin.ionescu@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: class, instance -------------------------------------+-------------------------------------- The mime-types gem has a class and an instance interface. The class interface uses an instance of itself. However, it doesn’t work in MacRuby. It does not seem to be initialised properly. I have included in a sample code with the expected behaviour. Changing @__types__ to @@__types__ will not fix it. #!/usr/bin/env macruby class Test def initialize() @foo = true end def add(something) puts "Is foo nil: #{(a)foo.nil?}" end @__types__ = self.new() def self.add(something) @__types__.add(something) end end t = Test.new t.add(3) Test.add(4) Output (MacRuby 0.5) Is foo nil: false Is foo nil: true Expected (Ruby 1.9.1/1.8.7) Is foo nil: false Is foo nil: false -- Ticket URL: <http://www.macruby.org/trac/ticket/549> MacRuby <http://macruby.org/>

1 7

[MacRuby] #499: Order declaring class hierarchy gets MacRuby confused about instance variables
by MacRuby 03 Jun '10

03 Jun '10

#499: Order declaring class hierarchy gets MacRuby confused about instance variables ------------------------------+--------------------------------------------- Reporter: paul@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- The following code appears to misbehave in MacRuby. It defines a class hierarchy Alpha > Beta > Gamma, with methods to set and get instance variables. {{{ class Alpha end class Beta < Alpha def setAnotherVar @another_var = "Assigned to another_var in Beta" end end class Alpha def setVar=(var) @var = var end def var @var end end class Gamma < Beta def setAnotherVar @another_var = "Assigned to another_var in Gamma" end end a = Gamma.new a.setVar = "Assigned to var" puts a.var a.setAnotherVar puts a.var }}} Ruby 1.8.7 prints: Assigned to var[[BR]] Assigned to var Whereas MacRuby prints: Assigned to var[[BR]] Assigned to another_var in Gamma Ruby 1.8.7 would appear to be the correct behaviour. MacRuby is getting confused about instance variables. Setting the "another_var" instance variable wrongly changes the "var" instance variable. Declaring the classes strictly in the order of the hierarchy (i.e Alpha then Beta then Gamma) fixes the problem, but in a large project where classes are autoloaded, that may not happen. This is a simplified extraction from a larger project. It was a very elusive bug. Well, is it a bug? -- Ticket URL: <http://www.macruby.org/trac/ticket/499> MacRuby <http://macruby.org/>

2 5

[MacRuby] #415: Crash with "Call result #2 has unhandled type" trying to display a window
by MacRuby 01 Jun '10

01 Jun '10

#415: Crash with "Call result #2 has unhandled type" trying to display a window -----------------------------------+---------------------------------------- Reporter: trejkaz@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- I tried to run a trivial test application (straight from the MacRuby web page) and got a crash. I have narrowed down the cause in the Ruby code: {{{ require 'hotcocoa' include HotCocoa application do |app| win = window :size => [100,50] # commenting out this line makes it stay running end }}} I tried this on the 0.5 beta as well as the most recent nightly, getting the same result in both cases. Result of running this script: {{{ shard:test trejkaz$ macruby --version MacRuby version 0.5 (ruby 1.9.0) [universal-darwin10.0, i386] shard:test trejkaz$ macruby minimal.rb 2009-11-01 21:41:12.508 macruby[17009:903] *** -[NSLock unlock]: lock (<NSLock: 0x2214830> '(null)') unlocked when not locked 2009-11-01 21:41:12.512 macruby[17009:903] *** Break on _NSLockError() to debug. Call result #2 has unhandled type f32UNREACHABLE executed at CallingConvLower.cpp:148! Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@431' Abort trap }}} If this is really only happening to me, let me know what other information I can provide. -- Ticket URL: <http://www.macruby.org/trac/ticket/415> MacRuby <http://macruby.org/>

1 9

[MacRuby] #511: GCD crash with indirect method access
by MacRuby 01 Jun '10

01 Jun '10

#511: GCD crash with indirect method access ---------------------------------------+------------------------------------ Reporter: joshua.ballanco@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: GCD ---------------------------------------+------------------------------------ The following code will crash when I run it on my Mac Pro (8x2.26 GHz): {{{ #!/usr/local/bin/macruby class Foo def doit end end class Bar def initialize @foo = Foo.new end def step @foo.doit end end @bars = [] 1000.times { @bars << Bar.new } steps = Dispatch::Group.new @bars.each do |bar| Dispatch::Queue.concurrent.async(steps) { bar.step } end steps.wait }}} Commenting out the "@foo.doit" line prevents the crash. -- Ticket URL: <http://www.macruby.org/trac/ticket/511> MacRuby <http://macruby.org/>

1 8

[MacRuby] #539: "macrubyc --static" failing on SL 10.6, MacRuby 0.5 Beta 2
by MacRuby 01 Jun '10

01 Jun '10

#539: "macrubyc --static" failing on SL 10.6, MacRuby 0.5 Beta 2 --------------------------------+------------------------------------------- Reporter: mail@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: --------------------------------+------------------------------------------- When attempting to run the following command: {{{ macrubyc --static hello-world.rb -o hello }}} with MacRuby 0.5 Beta 2 on OS X 10.6, Mac Pro Early 2008, using the MacRuby 0.5 Beta 2 package installer from the downloads page, I receive the following error: {{{ Undefined symbols: "llvm::raw_fd_ostream::raw_fd_ostream(char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned int)", referenced from: _rb_vm_aot_compile in libmacruby-static.a(vm.o) "llvm::Value::printCustom(llvm::raw_ostream&) const", referenced from: vtable for llvm::CmpInstin libmacruby-static.a(bridgesupport.o) vtable for llvm::CmpInstin libmacruby-static.a(compiler.o) ld: symbol(s) not found collect2: ld returned 1 exit status Error when executing `/usr/bin/g++ -o hello -arch x86_64 -L/Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib -lmacruby- static -framework Foundation -lobjc -lauto -lxml2 -L/opt/local/lib -lpthread -lffi -lm -lLLVMBitWriter -lLLVMInterpreter -lLLVMX86CodeGen -lLLVMX86Info -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem /var/folders/QO/QOheC+M9HmWJZ+oGEZpjEE+++TI/-Tmp-/main.o ./hello-world.o' }}} The file hello-world.rb is simply: {{{ #!/usr/bin/env ruby -w puts 'Hello, world!' }}} Just in case it is at all relevant, I also have MacPorts installed and the LLVM port, the ruby port and the ruby1.9 port installed from there as well (though these should presumably not have any effect due to the package installer using its own libraries). In searching for similar problems mentioned by others, I haven't been able to find any and as such I have started a new ticket. -- Ticket URL: <http://www.macruby.org/trac/ticket/539> MacRuby <http://macruby.org/>

1 2

[MacRuby] #477: Need GCD wrapper for dispatch_once
by MacRuby 27 May '10

27 May '10

#477: Need GCD wrapper for dispatch_once ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- We need an API for dispatch_once: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… http://developer.apple.com/mac/library/documentation/Performance/Reference/… http://www.opensource.apple.com/source/libdispatch/libdispatch-84.5.1/src/o… http://www.opensource.apple.com/source/libdispatch/libdispatch-84.5.1/src/o… Ideally something as simple as: Dispatch::Once.new { run_this_once } The tricky part is that the "Once" would have to allocate (the equivalent of) a global or static dispatch_once_t (i.e., a long). Could that be done with class variables? -- Ticket URL: <http://www.macruby.org/trac/ticket/477> MacRuby <http://macruby.org/>

1 9

[MacRuby] #595: our YAML library does not honor #add_builtin_type
by MacRuby 27 May '10

27 May '10

#595: our YAML library does not honor #add_builtin_type -----------------------------------+---------------------------------------- Reporter: lsansonetti@… | Owner: neeracher@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- rails 3 uses the following code that does not work on macruby because the add_builtin_type method is not implemented: {{{ class OrderedHash #:nodoc: def to_yaml_type "!tag:yaml.org,2002:omap" end def to_yaml(opts = {}) YAML.quick_emit(self, opts) do |out| out.seq(taguri, to_yaml_style) do |seq| each do |k, v| seq.add(k => v) end end end end end YAML.add_builtin_type("omap") do |type, val| ActiveSupport::OrderedHash[val.map(&:to_a).map(&:first)] end }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/595> MacRuby <http://macruby.org/>

1 1

[MacRuby] #352: macirb does not eval UTF-String
by MacRuby 23 May '10

23 May '10

#352: macirb does not eval UTF-String ------------------------+--------------------------------------------------- Reporter: dev@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ------------------------+--------------------------------------------------- {{{ $ echo 'p "Rübe"' | macirb p "Rübe" SyntaxError: (irb):1: unterminated string meets end of file from core:in `eval:' from core:in `evaluate:' }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/352> MacRuby <http://macruby.org/>

1 5

[MacRuby] #562: Including a module into class Class or class Module
by MacRuby 14 May '10

14 May '10

#562: Including a module into class Class or class Module -------------------------------------+-------------------------------------- Reporter: eloy.de.enige@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: mocha -------------------------------------+-------------------------------------- I saw that when you open class Class and define a method, it's automatically defined as a class method on NSObject. My preliminary patch does this for both Class and Module. However, as the test in #3300 shows, using the two behaviors together still leads to a problem. -- Ticket URL: <http://www.macruby.org/trac/ticket/562> MacRuby <http://macruby.org/>

1 7