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

[MacRuby] #731: uninitialized constant IO::WaitReadable / IO::WaitWritable
by MacRuby 05 Jun '10

05 Jun '10

#731: uninitialized constant IO::WaitReadable / IO::WaitWritable ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- {{{ $ macirb irb(main):001:0> require 'net/http' => true irb(main):002:0> Net::HTTP.get('www.apple.com', '/') NameError: uninitialized constant IO::WaitReadable }}} I think that IO::WaitReadable and IO::WaitWritable are not defined. {{{ $ grep "WaitReadable" -r * ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable means SSL needs to read internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitReadable ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable means SSL needs to read internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitReadable ext/openssl/ossl_ssl.c: //rb_extend_object(exc, rb_mWaitReadable); ext/openssl/ossl_ssl.c: * rescue IO::WaitReadable ext/openssl/ossl_ssl.c: * rescue IO::WaitReadable lib/net/protocol.rb: rescue IO::WaitReadable $ grep "WaitWritable" -r * ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitWritable means SSL needs to write internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitWritable ext/openssl/lib/openssl/buffering.rb: # IO::WaitReadable or IO::WaitWritable. ext/openssl/lib/openssl/buffering.rb: # IO::WaitWritable means SSL needs to write internally. ext/openssl/lib/openssl/buffering.rb: # rescue IO::WaitWritable ext/openssl/ossl_ssl.c: //rb_extend_object(exc, rb_mWaitWritable); ext/openssl/ossl_ssl.c: * rescue IO::WaitWritable ext/openssl/ossl_ssl.c: * rescue IO::WaitWritable lib/net/protocol.rb: rescue IO::WaitWritable lib/net/protocol.rb: # OpenSSL::Buffering#read_nonblock may fail with IO::WaitWritable. }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/731> MacRuby <http://macruby.org/>

1 2

[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] #627: Obj-C exception raised within a rescue block are not catched
by MacRuby 02 Jun '10

02 Jun '10

#627: Obj-C exception raised within a rescue block are not catched ----------------------------------------+----------------------------------- Reporter: martinlagardette@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: rescue exception ----------------------------------------+----------------------------------- This file: {{{ #!ruby # test.rb begin begin raise rescue NSString.stringWithCString(nil) end rescue puts "rescued" end }}} Will produce the following: {{{ #!sh $> macruby /tmp/test.rb uncaught Objective-C/C++ exception... 2010-03-01 22:45:58.926 macruby[30392:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSString stringWithCString:]: NULL cString' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff84f80444 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff84db80f3 objc_exception_throw + 45 2 CoreFoundation 0x00007fff84f80267 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x00007fff84f801f4 +[NSException raise:format:] + 148 4 Foundation 0x00007fff87f704ed +[NSString stringWithCString:] + 80 5 ??? 0x0000000101040385 0x0 + 4312007557 6 libmacruby.dylib 0x0000000100174130 rb_vm_dispatch + 2688 7 ??? 0x000000010104015d 0x0 + 4312007005 8 libmacruby.dylib 0x0000000100184ebf rb_vm_run + 351 9 libmacruby.dylib 0x0000000100046459 ruby_run_node + 73 10 macruby 0x0000000100000d28 main + 152 11 macruby 0x0000000100000c88 start + 52 12 ??? 0x0000000000000002 0x0 + 2 ) terminate called after throwing an instance of 'NSException' Abort trap }}} However, using pure Ruby exceptions works without issue: {{{ #!ruby # test2.rb begin begin raise rescue raise end rescue puts "rescued" end }}} {{{ #!sh $> macruby /tmp/test2.rb rescued }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/627> MacRuby <http://macruby.org/>

1 1

[MacRuby] #722: Multiple Threads are causing Segmentation Faults
by MacRuby 02 Jun '10

02 Jun '10

#722: Multiple Threads are causing Segmentation Faults ----------------------------------+----------------------------------------- Reporter: jankassens@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- This little script causes segmentation faults on my machine (unibody MacBook with Core 2 Duo) (using the 0.6 release version) {{{ #!/usr/bin/env macruby framework 'calendarstore' 50.times do Thread.new do loop do pred = CalCalendarStore.eventPredicateWithStartDate(NSDate.date, endDate:NSDate.date, calendars:CalCalendarStore.defaultCalendarStore.calendars) CalCalendarStore.defaultCalendarStore.eventsWithPredicate(pred) sleep 1 end end end sleep 1 }}} Most common is this error: {{{ $ ./test.rb unknown: [BUG] Segmentation fault MacRuby version 0.6 (ruby 1.9.0) [universal-darwin10.0, x86_64] Abort trap }}} but I get this as well: {{{ $ ./test.rb SEGV recieved in SEGV handler unknown: SEGV recieved in SEGV handler }}} Since the programm exits on the seg fault, I didn't manage to get a backtrace with macrubyd. -- Ticket URL: <http://www.macruby.org/trac/ticket/722> MacRuby <http://macruby.org/>

1 5

[MacRuby] #729: rbconfig.rb does not honor ARCH_FLAG
by MacRuby 02 Jun '10

02 Jun '10

#729: rbconfig.rb does not honor ARCH_FLAG ------------------------------+--------------------------------------------- Reporter: joelr1@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- rbconfig.rb file does not honor the ARCH_FLAG environment variable and is hard-coded to "-arch i386 -arch x86_64" -- Ticket URL: <http://www.macruby.org/trac/ticket/729> MacRuby <http://macruby.org/>

1 5

[MacRuby] #732: Ruby strings should have a to_data method
by MacRuby 02 Jun '10

02 Jun '10

#732: Ruby strings should have a to_data method -------------------------------+-------------------------------------------- Reporter: me@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: string encoding -------------------------------+-------------------------------------------- From my mailing list post: ======= Hello, I've been playing around with macruby a bunch and I hit a point of confusion. I basically did "....".pack("H*") which returns a ruby string. This string is an ASCII-8BIT encoded ruby string which is an alias for a Binary string (aka, it has no encoding). IMO, this should really be backed by an NSData class as opposed to an NSString class because it doesn't make much sense. In fact, it's pretty much impossible to get any useful information out of an ASCII-8BIT encoded ruby string from the objective-c side of things. To get around this, I did the following: class String def to_data return NSData.data unless length > 0 bytes = self.bytes.to_a p = Pointer.new_with_type("char *", bytes.length) bytes.each_with_index do |char, i| p[i] = char end NSData.dataWithBytes(p, length:bytes.length) end end I'm not sure what the solution to this is, but I thought I'd bring up the issue on the mailing list. ======= -- Ticket URL: <http://www.macruby.org/trac/ticket/732> MacRuby <http://macruby.org/>

1 1

[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