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

Re: [MacRuby-devel] [macruby] #14: getting format from artwork doesn't work
by macruby 23 May '08

23 May '08

#14: getting format from artwork doesn't work -------------------------------------+-------------------------------------- Reporter: jordan.breeding(a)mac.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.3 Component: MacRuby | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by lsansonetti(a)apple.com) * milestone: MacRuby 1.0 => MacRuby 0.3 -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/14#comment:3> macruby <http://ruby.macosforge.org/>

1 0

[macruby] #58: shouldaccept arrays instead of structures, like rubycocoa
by macruby 23 May '08

23 May '08

#58: shouldaccept arrays instead of structures, like rubycocoa -----------------------------------+---------------------------------------- Reporter: lsansonetti(a)apple.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.2 Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Currently, when messaging an API that accepts a C structure from MacRuby, you have to provide an instance of the boxed class. RubyCocoa allows you to pass an array of elements instead, which is more user friendly, especially when dealing with NSRect/NSSize/... objects. {{{ window.frame = NSRect.new(NSPoint.new(0, 1), NSSize.new(2, 3)) # working window.frame = [0,1,2,3] # not working yet }}} -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/58> macruby <http://ruby.macosforge.org/>

1 1

Delegate methods defined in modules
by Zach Holt 22 May '08

22 May '08

#!/usr/bin/env macruby framework 'cocoa' module AppDelegateModule def applicationDidFinishLaunching( n ) puts "exiting..." NSApp.terminate( nil ) end end class AppDelegateClass include AppDelegateModule end NSApplication.sharedApplication NSApp.delegate = AppDelegateClass.new NSApp.run __END__ Hi all, I'm porting http://www.paulhammond.org/webkit2png/ as a learning exercise. Should the above terminate? It doesn't on trunk rev 202, but it does if you move applicationDidFinishLaunching to AppDelegateClass. Thanks!

2 1

[ruby] #50: Nested methods don't work
by ruby 21 May '08

21 May '08

#50: Nested methods don't work ------------------------------------+--------------------------------------- Reporter: insanitarian(a)yahoo.com | Owner: lsansonetti(a)apple.com Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: nested ------------------------------------+--------------------------------------- Nested methods in MacRuby don't seem to work; therefore, incompatibilities with porting from Ruby/RubyCocoa arise. Examples: $ irb :> def foo :> def bar; 42; end :> bar :> end => nil :> foo => 42 http://pasternak.superalloy.nl/pastes/329?theme=dawn -- Ticket URL: <http://trac.macosforge.org/projects/ruby/ticket/50> ruby <http://ruby.macosforge.org/>

2 1

irb: uninitialized constant IRB::SLex::Node::DebugLogger
by Eloy Duran 21 May '08

21 May '08

Hi, Anyone else seeing this for macirb on the current trunk? Eloy

2 1

Re: [MacRuby-devel] [macruby] #16: ^C (SIGINT) doesn't interrupt the cocoa runloop
by macruby 21 May '08

21 May '08

#16: ^C (SIGINT) doesn't interrupt the cocoa runloop -----------------------------------+---------------------------------------- Reporter: lsansonetti(a)apple.com | Owner: lsansonetti(a)apple.com Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.2 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Comment (by lsansonetti(a)apple.com) Indeed, looks like SIGINT doesn't immediately interrupt the runloop, but only during the next runloop iteration. It's still better than before, but it's clearly not fixed yet. -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/16#comment:10> macruby <http://ruby.macosforge.org/>

1 0

Re: [MacRuby-devel] [macruby] #16: ^C (SIGINT) doesn't interrupt the cocoa runloop
by macruby 21 May '08

21 May '08

#16: ^C (SIGINT) doesn't interrupt the cocoa runloop -----------------------------------+---------------------------------------- Reporter: lsansonetti(a)apple.com | Owner: lsansonetti(a)apple.com Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.2 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Comment (by z(a)wzph.com) Bah. SIGINT doesn't interrupt :) -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/16#comment:9> macruby <http://ruby.macosforge.org/>

1 0

Re: [MacRuby-devel] [macruby] #16: ^C (SIGINT) doesn't interrupt the cocoa runloop
by macruby 21 May '08

21 May '08

#16: ^C (SIGINT) doesn't interrupt the cocoa runloop -----------------------------------+---------------------------------------- Reporter: lsansonetti(a)apple.com | Owner: lsansonetti(a)apple.com Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.2 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Comment (by z(a)wzph.com) ^C -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/16#comment:8> macruby <http://ruby.macosforge.org/>

1 0

Re: [MacRuby-devel] [macruby] #16: ^C (SIGINT) doesn't interrupt the cocoa runloop
by macruby 21 May '08

21 May '08

#16: ^C (SIGINT) doesn't interrupt the cocoa runloop -----------------------------------+---------------------------------------- Reporter: lsansonetti(a)apple.com | Owner: lsansonetti(a)apple.com Type: defect | Status: reopened Priority: blocker | Milestone: MacRuby 0.2 Component: MacRuby | Resolution: Keywords: | -----------------------------------+---------------------------------------- Changes (by z(a)wzph.com) * status: closed => reopened * resolution: fixed => Comment: I just built from trunk revision 202, and ^C still seems unable to interrupt the run loop. -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/16#comment:7> macruby <http://ruby.macosforge.org/>

1 0

Re: [MacRuby-devel] [macruby] #11: Move Objective-C bits of Kernel#framework to ruby
by macruby 20 May '08

20 May '08

#11: Move Objective-C bits of Kernel#framework to ruby -----------------------------+---------------------------------------------- Reporter: ben(a)tanjero.com | Owner: lsansonetti(a)apple.com Type: defect | Status: closed Priority: minor | Milestone: Component: MacRuby | Resolution: wontfix Keywords: | -----------------------------+---------------------------------------------- Changes (by lsansonetti(a)apple.com) * status: new => closed * resolution: => wontfix Comment: I don't see any benefit of rewriting the framework method in Ruby, it seems to work well as it is. The method is pretty simple, and we anyway have other objc code in the same file (objc.m). Ben, feel free to re-open this ticket if you have a counter argument. -- Ticket URL: <http://ruby.macosforge.org/trac/ticket/11#comment:1> macruby <http://ruby.macosforge.org/>

1 0