Re: [MacRuby-devel] [MacRuby] #412: Calling return from a Proc raises an exception

2009-10-31 Thread MacRuby 
#412: Calling return from a Proc raises an exception
---+
 Reporter:  m...@… |Owner:  lsansone...@…
 Type:  defect |   Status:  closed   
 Priority:  blocker|Milestone:  MacRuby 0.5  
Component:  MacRuby|   Resolution:  fixed
 Keywords: |  
---+

Comment(by conra...@…):

 In Ruby 1.9, lambda produces a different variant of the Proc object than
 Proc.new.  Also, proc is no longer a synonym for lambda.  However, one can
 use proc as a synonym for Proc.new.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #413: ruby_deploy embeds more than one version of macruby

2009-10-31 Thread MacRuby 
#413: ruby_deploy embeds more than one version of macruby
-+--
 Reporter:  mattaimone...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.5  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:  ruby_deploy  |  
-+--

Comment(by mattaimone...@…):

 tested and confirmed.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #414: Printing Block Instances Inconsistent

2009-10-31 Thread MacRuby 
#414: Printing Block Instances Inconsistent
+---
 Reporter:  conra...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  Beta 1   
+---
 The printing of block instances, lambda and proc, are not consistent with
 Ruby 1.9.1/1.9.2:

 block-instance-output.rb:

 {{{

 a_proc = Proc.new { puts "This is a test proc" }
 p a_proc

 a_lambda = lambda { puts "This is a test lambda" }
 p a_lambda

 }}}

 from command line:

 {{{
 macruby block-instance-output.rb

 #
 #

 }}}

 {{{
 ruby  block-instance-output.rb

 #
 #

 }}}

 from irb:

 {{{

 $ macirb
 irb(main):001:0> load "block-instance-output.rb"
 #
 #
 => true

 }}}


 {{{

 $ irb
 irb(main):001:0> load "block-instance-output.rb"
 #
 #
 => true

 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #391: HotCocoa on_notification method stopped functioning in MacRuby 0.5 under Snow Leopard

2009-10-31 Thread MacRuby 
#391: HotCocoa on_notification method stopped functioning in MacRuby 0.5 under
Snow Leopard
--+-
 Reporter:  tre...@…  |Owner:  lsansone...@…
 Type:  defect|   Status:  closed   
 Priority:  blocker   |Milestone:   
Component:  MacRuby   |   Resolution:  fixed
 Keywords:  HotCocoa on_notification  |  
--+-

Comment(by tre...@…):

 Workaround with instance variable works just fine. Thank you.

 And thanks to Robert for his help.

 Rgds
 Trevor Hills

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #409: Attribute setter should be accepted as KVO setter

2009-10-31 Thread MacRuby 
#409: Attribute setter should be accepted as KVO setter
-+--
 Reporter:  neerac...@…  |   Owner:  lsansone...@…
 Type:  enhancement  |  Status:  new  
 Priority:  minor|   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

Comment(by dy...@…):

 *poke* I just ran into this one and traced it down. Any updates ?

 I've attached a project that shows a naive implementation with bindings
 that shows how someone could get into trouble with this.

 I think this is a little more severe than it appears at first glance. It
 violates the principle of least surprise in a big way; even something a
 simple as adapting example code to a new Mac interface will run afoul of
 this pretty quickly.

 Even if you're familiar with both Ruby and ObjC this generates some
 confusion since you can no longer use idiomatic ruby to change your model
 if you want it bound to the UI at any future date. You currently have to
 get used to always using the ObjC setValue way.

 If you're not familiar with both you're going to be scratching your head
 for a while.

 This is also insidious since your model unit tests will pass and only the
 less easily testable UI will fail, unless you set up explicit bindings
 tests for each property.

 That said, this may not be as simple a fix as it appears. My gut feeling
 was to override attr_accessor and writer to generate a value= method that
 just calls setValue. This works 95% of the time, but gets murky when you
 want to create a custom setter. Which do you override ? Do you always have
 to call setValue from your value= method ? How should it be documented if
 that's the case ? Of course, you still have that confusion the way it
 exists now. Going to implement value= and then finding that your bindings
 don't call that method, for instance.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel