[MacRuby-devel] Which MacRuby version, 0.6 or higher, can run the Growl samples?

2010-05-13 Thread hans bennekop 

I've tried v0.6 and several later nightly builds but couldn't get the
official Growl demos to run. (They work fine with 0.5.)

The related ticket ("MacRuby 0.6 breaks Growl",
http://www.macruby.org/trac/ticket/662) has been marked as 'fixed'.
So is there a specific nightly build that is compatible with Growl?

Thanks,
Hans

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

Re: [MacRuby-devel] Mapping of Objective-C Blocks to MacRuby

2010-05-13 Thread Laurent Sansonetti 
Hi Steve,

C-level blocks are not yet supported. But this is something we could do in the 
next release, 0.7! Could you file a bug so that we do not forget about it?

Thanks,

Laurent

On May 12, 2010, at 11:36 PM, steve ross wrote:

> I was thinking syntax like:
> 
>open_panel = NSOpenPanel.openPanel
>open_panel.beginSheetModalForWindow(@main_window,
>  completionHandler:lambda{|arg| "Yo, open file and user arg is #{arg}")
> 
> would be pretty sensible. But it seems not to be. Any hints?
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

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

Re: [MacRuby-devel] Which MacRuby version, 0.6 or higher, can run the Growl samples?

2010-05-13 Thread Laurent Sansonetti 
Hi Hans,

Indeed, 0.6 is supposed to run the Growl stuff, we verified that in #662. If 
you have a specific demo that does not work, could you file a bug? This way we 
can investigate what's going wrong.

Thanks,

Laurent

On May 13, 2010, at 12:17 AM, hans bennekop wrote:

> I've tried v0.6 and several later nightly builds but couldn't get the
> official Growl demos to run. (They work fine with 0.5.)
> 
> The related ticket ("MacRuby 0.6 breaks Growl",
> http://www.macruby.org/trac/ticket/662) has been marked as 'fixed'.
> So is there a specific nightly build that is compatible with Growl?
> 
> Thanks,
> Hans
> 
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

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

[MacRuby-devel] [MacRuby] #709: Different behaviour when including a module into Class in MacRuby vs Ruby 1.9.2

2010-05-13 Thread MacRuby 
#709: Different behaviour when including a module into Class in MacRuby vs Ruby
1.9.2
--+-
 Reporter:  ja...@…   |   Owner:  lsansone...@… 
 Type:  defect|  Status:  new   
 Priority:  major |   Milestone:
Component:  MacRuby   |Keywords:  mocha class module include
--+-
 I'm seeing different behaviour when including a module into Class in
 MacRuby vs Ruby 1.9.2. This is a simplification of a problem I'm seeing
 running Mocha [1] tests in MacRuby. I seems to be specific to including
 the module into the Class class and not a user-defined class. It also
 doesn't seem to matter whether the class has already been defined or not.

 {{{
 $ rvm macruby
 $ irb
 macruby-0.6 > module X; def x; "x"; end; end
  => nil
 macruby-0.6 > class Class; include X; end
  => Class
 macruby-0.6 > Class.new.x
 NoMethodError: undefined method `x' for #
 from /Users/jamesmead/Code/mocha/(irb):3:in `'
 }}}

 {{{
 $ rvm 1.9.2
 $ irb
 ruby-1.9.2-preview1 > module X; def x; "x"; end; end
  => nil
 ruby-1.9.2-preview1 > class Class; include X; end
  => Class
 ruby-1.9.2-preview1 > Class.new.x
  => "x"
 }}}

 {{{
 $ rvm macruby
 $ irb
 macruby-0.6 > module X; def x; "x"; end; end
  => nil
 macruby-0.6 > class Y; include X; end
  => Y
 macruby-0.6 > Y.new.x
  => "x"
 }}}

 {{{
 $ rvm macruby
 $ irb
 macruby-0.6 > module X; def x; "x"; end; end
  => nil
 macruby-0.6 > class Y; end
  => nil
 macruby-0.6 > class Y; include X; end
  => Y
 macruby-0.6 > Y.new.x
  => "x"
 }}}

 [1] http://github.com/floehopper/mocha/tree/macruby

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] Using a context with addObserver

2010-05-13 Thread Dave Baldwin 
I am trying to translate code that looks like this:

static NSString *SKTWindowControllerCanvasSizeObservationContext = 
@"com.apple.SKTWindowController.canvasSize";

and later

[[self document] addObserver:self forKeyPath:SKTDocumentCanvasSizeKey 
options:NSKeyValueObservingOptionNew 
context:SKTWindowControllerCanvasSizeObservationContext];

to Ruby:

SKTWindowControllerCanvasSizeObservationContext = 
"com.apple.SKTWindowController.canvasSize"
document.addObserver(self, forKeyPath: SKTDocumentCanvasSizeKey, 
options: 
NSKeyValueObservingOptionNew,

context:SKTWindowControllerCanvasSizeObservationContext)

but when it runs I get this error:

 expected instance of Pointer, got `"com.apple.SKTWindowController.canvasSize"' 
(String) (TypeError)

How do I get the a pointer to the context string?  All the examples I have 
found for the Pointer class seem to expect an objective C routing to fill it in.

Thanks,

Dave.


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

Re: [MacRuby-devel] [MacRuby] #709: Different behaviour when including a module into Class in MacRuby vs Ruby 1.9.2

2010-05-13 Thread MacRuby 
#709: Different behaviour when including a module into Class in MacRuby vs Ruby
1.9.2
--+-
 Reporter:  ja...@…   |   Owner:  lsansone...@… 
 Type:  defect|  Status:  new   
 Priority:  major |   Milestone:
Component:  MacRuby   |Keywords:  mocha class module include
--+-

Comment(by ja...@…):

 I've just come across this commit [1] which looks like it adds a test for
 this problem to known_bugs.rb.

 I'm now trying to investigate whether the problem has been fixed.

 [1]
 
http://github.com/masterkain/macruby/commit/40455e95942cffb0b30001efb1bc4e55c05ed664

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #709: Different behaviour when including a module into Class in MacRuby vs Ruby 1.9.2

2010-05-13 Thread MacRuby 
#709: Different behaviour when including a module into Class in MacRuby vs Ruby
1.9.2
--+-
 Reporter:  ja...@…   |   Owner:  lsansone...@… 
 Type:  defect|  Status:  new   
 Priority:  major |   Milestone:
Component:  MacRuby   |Keywords:  mocha class module include
--+-

Comment(by ja...@…):

 It now looks like this may be a duplicate of #562.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #626: macruby fails Class.class_eval in macruby but not in 1.8 & 1.9?

2010-05-13 Thread MacRuby 
#626: macruby fails Class.class_eval in macruby but not in 1.8 & 1.9?
+---
 Reporter:  rebo...@…   |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  blocker |   Milestone:   
Component:  MacRuby |Keywords:   
+---

Comment(by ja...@…):

 This looks like it may be a duplicate or at least closely related to #562.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #562: Including a module into class Class or class Module

2010-05-13 Thread MacRuby 
#562: Including a module into class Class or class Module
-+--
 Reporter:  eloy.de.en...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:  mocha
-+--

Comment(by ja...@…):

 Is this resolved or is it still awaiting a fix for the problem alluded to
 in the test in #3300 ? This ticket doesn't seem to exist. Thanks, James.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #710: MacRuby 0.6 performance decline from 0.5 in AO Bench

2010-05-13 Thread MacRuby 
#710: MacRuby 0.6 performance decline from 0.5 in AO Bench
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:  performance  
---+
 AO Bench is a small ambient occlusion renderer for benchmarking floating
 point performance.
 I measure benchmark score of Ruby version of AO Bench with MacRuby 0.5 and
 0.6. MacRuby 0.6 seems performance decline from 0.5.

 Environment
  * Mac OS X 10.6.2 (Snow Leopard)
  * CPU : 2.4 GHz Intel Core 2 Duo (MacBook 2G)
  * RAM : 4 GB 1067 MHz DDR3

 Result (Best score of 5 times test)
 0.5  271.19 real   316.03 user 5.45 sys
 0.6  387.91 real   417.16 user 8.26 sys

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #710: MacRuby 0.6 performance decline from 0.5 in AO Bench

2010-05-13 Thread MacRuby 
#710: MacRuby 0.6 performance decline from 0.5 in AO Bench
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:  performance  
---+

Comment(by nagachik...@…):

 Excuse me, I have a mistake formating the result...

 Result (Best score of 5 times test)
 || Version || real time  ||  user time || systme time ||
 ||   0.5   || 271.19 sec || 316.03 sec ||5.45 sec ||
 ||   0.6   || 387.91 sec || 417.16 sec ||8.26 sec ||

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #710: MacRuby 0.6 performance decline from 0.5 in AO Bench

2010-05-13 Thread MacRuby 
#710: MacRuby 0.6 performance decline from 0.5 in AO Bench
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:  performance  
---+

Comment(by matt...@…):

 I suspect that performance is not on anyone's radar for a 0.6 release.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times

2010-05-13 Thread MacRuby 
#711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:   
Component:  MacRuby|Keywords:   
---+
 When I modify AO Bench script (see #710) to use Dispatch::Job, it caught
 SIGSEGV while executing blocks passed to Dispatch::Job#add.

 backtrace of trunk (revision 4089) with gcc is as follows.

 {{{
 (gdb) run
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x
 [Switching to process 11054]
 0x in ?? ()
 (gdb) where
 #0  0x in ?? ()
 #1  0x00010013b8ad in __rb_vm_objc_dispatch [inlined] () at
 /Users/nagachika/opt/src/MacRuby-trunk/MacRuby/dispatcher.cpp:450
 #2  0x00010013b8ad in rb_vm_call_with_cache2 (cache=0x100e31450,
 block=0x0, self=8592087456, klass=, sel=0x7fff886e8b1e, argc=3, argv=0x104a84900) at
 dispatcher.cpp:904
 #3  0x00010006b3a2 in rb_class_new_instance_imp (klass=8592147264,
 sel=, argc=3,
 argv=0x104a84900) at object.c:1962
 #4  0x0001001481dc in rb_vm_dispatch (cache=0x100e5e870,
 top=8590786400, self=8592147264, sel=0x100e2ffa0, block=0x0, opt=0 '\000',
 argc=3) at dispatcher.cpp:418
 #5  0x000102007d25 in ?? ()
 #6  0x00010013c68a in rb_vm_call_with_cache2 (cache=0x100e312c0,
 block=0x0, self=8590786400, klass=, sel=0x7fff8211c810, argc=, argv=0x104a85950) at dispatcher.cpp:144
 #7  0x00010006b233 in rb_class_new_instance0 [inlined] () at
 /Users/nagachika/opt/src/MacRuby-trunk/MacRuby/object.c:1958
 #8  0x00010006b233 in rb_class_new_instance_imp (klass=8592105184,
 sel=, argc=0,
 argv=0x104a85950) at object.c:1972
 #9  0x0001001481dc in rb_vm_dispatch (cache=0x1038ee910,
 top=8590064448, self=8592105184, sel=0x7fff8211c858, block=0x0, opt=0
 '\000', argc=0) at dispatcher.cpp:418
 #10 0x0001020099b2 in ?? ()
 #11 0x00010013f3e3 in rb_vm_block_eval (b=0x2000e7e20, argc=, argv=0x2000e7e78) at
 dispatcher.cpp:95
 #12 0x0001001481dc in rb_vm_dispatch (cache=0x104839970,
 top=8592071616, self=8590902944, sel=0x7fff85bb1100, block=0x0, opt=0
 '\000', argc=0) at dispatcher.cpp:418
 #13 0x000102009f25 in ?? ()
 #14 0x00010013f3e3 in rb_vm_block_eval (b=0x2000e6e60, argc=, argv=0x2000e6eb8) at
 dispatcher.cpp:95
 #15 0x00010015bd4a in rb_rescue2 (b_proc=, data1=, r_proc=0x1000f2240 ,
 data2=4304291472) at vm.cpp:3596
 #16 0x7fff84ef9b90 in _dispatch_worker_thread2 ()
 #17 0x7fff84ef94e8 in _pthread_wqthread ()
 #18 0x7fff84ef9385 in start_wqthread ()
 }}}

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+
 The following (proposed) syntax should work:

 {{{
 open_panel = NSOpenPanel.openPanel
 open_panel.beginSheetModalForWindow(@main_window,
 completionHandler:lambda{|arg|
   puts "Hello, open file and user arg is #{arg}"
   }
 )
 }}}

 Also, this should work:

 {{{
 def handler(arg)
   puts "Hello, open file and user arg is #{arg}"
 end

 open_panel = NSOpenPanel.openPanel
 open_panel.beginSheetModalForWindow(@main_window,
 completionHandler:handler)
 }}}

 There may be a more elegant Rubyish way to do this, but I'm not seeing how
 the proper selector syntax would be created. Here's what I mean:

 {{{
 open_panel = NSOpenPanel.openPanel
   open_panel.beginSheetModalForWindow(@main_window) do |arg|
 puts "Hello, open file and user arg is #{arg}"
   end
 }}}

 But the last example gives no hint that the block selector should be
 completionHandler:

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+

Comment(by martinlagarde...@…):

 I would say the 2nd and 3rd form wouldn't be good to implement.

 The 3rd one because, well, some parts are missing (the
 `completionHandler:` part). The second one because this looks more like a
 callback, rather than a Proc/lambda, and would have unexpected behavior
 from a ruby point of view. In fact, Ruby-wise, it would be expected that
 "handler" is called and its result is passed to completion handler.

 Otherwise, I agree 100% for the first form :-). I wanted to do it when
 implementing the Proc as callback functions, but we had no C-block
 supports at the time. I hope we can bring them to life (since a C-block is
 not that far from a ruby-block, at least in principle).

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times

2010-05-13 Thread MacRuby 
#711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by martinlagarde...@…):

 Hi!

 Thanks for the report, but would you have a smaller reduction? We do not
 have any input file either btw :-)

 Thanks again!

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+

Comment(by cwdi...@…):

 Replying to [comment:1 martinlagarde...@…]:
 > I would say the 2nd and 3rd form wouldn't be good to implement.
 >
 > The 3rd one because, well, some parts are missing (the
 `completionHandler:` part). The second one because this looks more like a
 callback, rather than a Proc/lambda, and would have unexpected behavior
 from a ruby point of view. In fact, Ruby-wise, it would be expected that
 "handler" is called and its result is passed to completion handler.
 >
 > Otherwise, I agree 100% for the first form :-). I wanted to do it when
 implementing the Proc as callback functions, but we had no C-block
 supports at the time. I hope we can bring them to life (since a C-block is
 not that far from a ruby-block, at least in principle).

 I understand that the 2nd form appears more like a callback, but the
 expectation of a functional programming language -- which Ruby debatably
 is -- is that a Proc is a first-class citizen. Therefore, a method should
 be usable where a Proc or a lambda is. Regarding the third, how about
 syntax like:

 {{{
 open_panel.beginSheetModalForWindow(@main_window,
 completionHandler:MACRUBY_BLOCK) do |arg|
   puts "Hello, open file and user arg is #{arg}"
 end
 }}}

 The benefit is that you don't wind up shoehorning all your code inside the
 parentheses of a method call. Dangling close parens are syntax errors
 waiting to happen.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times

2010-05-13 Thread MacRuby 
#711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by lsansone...@…):

 There is no input file, the script creates a new file.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+

Comment(by martinlagarde...@…):

 For the 2nd form, that's not really how ruby works. If lambdas and Procs
 exist, it is for a reason. One of these reasons being that a method is not
 an object. It's not a first-class citizen. Procs are. What you can do,
 however, is call `method(:handler)` to get a Method object. Whatever you
 do, in ruby, `handler` will call the `handler` method and use its result
 as the object being referenced.

 As for the 3rd form, I like it, but we'll have to see how (and if) it is
 possible to implement it :-).

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #710: MacRuby 0.6 performance decline from 0.5 in AO Bench

2010-05-13 Thread MacRuby 
#710: MacRuby 0.6 performance decline from 0.5 in AO Bench
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  minor  |   Milestone:   
Component:  MacRuby|Keywords:  performance  
---+

Comment(by lsansone...@…):

 Thanks for the nice benchmark. I cleaned the side effects and noticed that
 trunk is about 2 times slower than 1.9.2.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+

Comment(by jazz...@…):

 my suggestion is:

 {{{
 open_panel = NSOpenPanel.openPanel
   open_panel.beginSheetModalForWindowOnCompletion(@main_window) do |arg|
 puts "Hello, open file and user arg is #{arg}"
   end
 }}}

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #712: Feature Request: Add Support for C-Level Blocks

2010-05-13 Thread MacRuby 
#712: Feature Request: Add Support for C-Level Blocks
---+
 Reporter:  cwdi...@…  |   Owner:  lsansone...@…
 Type:  enhancement|  Status:  new  
 Priority:  blocker|   Milestone:  MacRuby 0.7  
Component:  MacRuby|Keywords:  block
---+

Comment(by lsansone...@…):

 I think only the 1st form should be implemented at the first time. Passing
 the block inline (3rd form) might be a good idea but I'm afraid of
 inconsistencies (since the argument name is no longer passed). Also, it
 wouldn't work if the method accepts 2 blocks.

 2nd solution cannot be implemented easily and I think it's not what users
 would expect (they would expect the method to be called and its return
 value to be passed, not the method itself).

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #623: Overriding setRepresentedObject on NSViewController subclass doesn't seem to work

2010-05-13 Thread MacRuby 
#623: Overriding setRepresentedObject on NSViewController subclass doesn't seem
to work
-+--
 Reporter:  n...@…   |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:  MacRuby 0.6  
Component:  MacRuby  |   Resolution:  fixed
 Keywords:   |  
-+--
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Johannes confirmed that this problem has been fixed in 0.6.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #713: Growl is broken on MacRuby 0.6

2010-05-13 Thread MacRuby 
#713: Growl is broken on MacRuby 0.6
--+-
 Reporter:  ylp...@…  |   Owner:  lsansone...@…
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  MacRuby 0.6  
Component:  MacRuby   |Keywords:  growl
--+-
 Contrary to [http://www.macruby.org/trac/ticket/662 ticket #662], the
 demos in /Developer/Examples/Ruby/MacRuby/Scripts/growl are broken for me
 on MacRuby 0.6.

 E.g., the calls to Growl::Notifier#notify in the two growl_*_samples
 return a NSLocalNotificationCenter object, but no Growl notification is
 shown.

 Installing 0.5 over the existing 0.6 makes both samples work again.
 (Except for a callback bug in the block sample that is unrelated to
 MacRuby.)

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #562: Including a module into class Class or class Module

2010-05-13 Thread MacRuby 
#562: Including a module into class Class or class Module
-+--
 Reporter:  eloy.de.en...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:  mocha
-+--

Comment(by lsansone...@…):

 Looks like this bug, #265, #371 and #709 are all related. The patch eloy
 wrote has not been merged yet AFAIK. I will work on this then verify if
 each ticket can be closed.

 (I am not sure why you refer to #3300. We don't have that many tickets.)

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #562: Including a module into class Class or class Module

2010-05-13 Thread MacRuby 
#562: Including a module into class Class or class Module
-+--
 Reporter:  eloy.de.en...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:  mocha
-+--

Comment(by ja...@…):

 Hi Laurent. That'd be great. #3300 is mentioned in the 2nd paragraph of
 the description on this ticket - "However, as the test in #3300 shows,
 using the two behaviors together still leads to a problem". Thanks, James.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #707: raising an exception inside a rescue raises the rescued exception instead of the new exception

2010-05-13 Thread MacRuby 
#707: raising an exception inside a rescue raises the rescued exception instead
of the new exception
---+
 Reporter:  th...@…|Owner:  lsansone...@…
 Type:  defect |   Status:  closed   
 Priority:  blocker|Milestone:  MacRuby 0.7  
Component:  MacRuby|   Resolution:  fixed
 Keywords: |  
---+
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  => MacRuby 0.7


Comment:

 Should be fixed in r4090.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times

2010-05-13 Thread MacRuby 
#711: MacRuby caught SIGSEGV when call Dispatch::Job#add many times
---+
 Reporter:  nagachik...@…  |   Owner:  lsansone...@…
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:   
Component:  MacRuby|Keywords:   
---+

Comment(by nagachik...@…):

 I will try to make smaller example reproduce the SEGV. Thank you for your
 kindness.

-- 
Ticket URL: 
MacRuby 

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