Re: [MacRuby-devel] Pointer.new_with_type("v")-is-unsized shocker

2010-01-21 Thread Carlo Zottmann 
Thanks, for the pointers, guys! (Pun not really intended.)

I'm sure I'll find something there. :) And Laurent, I'll file a ticket
later today.

Cheers,
C.

-- 
Carlo Zottmann
Munich, Germany.  --  http://carlo.zottmann.org

TwerpScan -- Anti-Fool Twitter Contact Management Tool. http://twerpscan.com/
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] OpenGL/GLUT Bridgesupport

2010-01-21 Thread John Shea 
Yes as far as I know bridge support does not support GLUT.

So you (obviously) have two other options other than gen_bridge_metadata (which 
I gave up on after a few tries) :

- don't use GLUT - use the equivalent (set of) non GLUT openGL calls
- place the GLUT calls in an ObjC class - and call out to that class from 
MacRuby

you might find that the second option is quite quick - i found that for some 
openGL calls (but not all) that dispatching to my own bridge class which then 
called opengl functions was quicker than going through BridgeSupport.

There are other good reasons to have your own bridge class anyway - i imagine 
that BridgeSupport is always going to be lagging Cocoa a bit (eg Core Animation 
constants), and it might just be easier allocating OpenGL texture memory in 
ObjC (well I still use objC for that)

HTH,
J


On Jan 20, 2010, at 8:14 PM, Jonathan Waddilove wrote:

> Hi, I'm back to using MacRuby again and I'm confused about Bridge Support.
> 
> I have been using the excellent sojaster port of the Cocoa OpenGL example to 
> help develop an OpenGL playpen. However, when I started using glut calls 
> (glutBitmapCharacter, glutStrokeString, etc) I started to get problems.
> 
> It seems that the OpenGL glut.framework (10.6.2) doesn't include bridge 
> support. I've tried using gen_bridge_metadata to add bridge support but 
> without success.
> 
> Should glut work in MacRuby? How does one add BridgeSupport to the Apple 
> shipped frameworks?
> 
> Sorry if I have missed some very obvious step.
> 
> regards and thanks,  Jonathan
> 
> ___
> 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] #569: macrake crashes with abort trap when compiling Phusion Passenger

2010-01-21 Thread MacRuby 
#569: macrake crashes with abort trap when compiling Phusion Passenger
-+--
 Reporter:  hongli...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 How to reproduce:
 {{{
 $ git clone git://github.com/FooBarWidget/passenger.git
 $ cd passenger
 $ macrake nginx
 $ macrake nginx
 (in /Users/hongli/Projects/passenger)
 mkdir -p ext/nginx/libboost_oxt/boost
 Abort trap
 }}}

 GDB backtrace:
 {{{
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x0001
 0x0001001647bb in rb_vm_call_with_cache2 (cache=0x1, block=0x0,
 self=0, klass=8590686624, sel=0x104f1f710, argc=1, argv=0x7fff5fbeb280) at
 dispatcher.cpp:577
 577 if (cache->flag == 0) {
 (gdb) bt
 #0  0x0001001647bb in rb_vm_call_with_cache2 (cache=0x1, block=0x0,
 self=0, klass=8590686624, sel=0x104f1f710, argc=1, argv=0x7fff5fbeb280) at
 dispatcher.cpp:577
 #1  0x000100176eba in rb_vm_block_eval2 (b=0x200362fa0,
 self=8593484896, sel=0x100fc3790, argc=1, argv=0x7fff5fbeb280) at
 dispatcher.cpp:1549
 #2  0x000101165c58 in ?? ()
 #3  0x00010116bf3e in ?? ()
 #4  0x000101174115 in ?? ()
 #5  0x000105723431 in ?? ()
 #6  0x00010016b39f in rb_vm_dispatch (cache=0x10153fb90,
 top=8593882176, self=8593881056, sel=0x100f2b770, block=0x0, opt=0 '\000',
 argc=2) at dispatcher.cpp:433
 #7  0x000105740d15 in ?? ()
 #8  0x000100018104 in rb_ary_each_imp () at JIT.h:33
 #9  0x00010016b771 in rb_vm_dispatch (cache=0x100f2b8e0,
 top=8593882176, self=8593882048, sel=0x100f2b7e0, block=0x200384360, opt=0
 '\000', argc=) at
 dispatcher.cpp:130
 #10 0x0001057407fe in ?? ()
 #11 0x00010573dd2f in ?? ()
 #12 0x00010115c617 in ?? ()
 #13 0x0001011698a9 in ?? ()
 #14 0x00010573e075 in ?? ()
 #15 0x000100018104 in rb_ary_each_imp () at JIT.h:33
 #16 0x00010016b771 in rb_vm_dispatch (cache=0x100f2b8e0,
 top=8593924224, self=8593925120, sel=0x100f2b7e0, block=0x2003af3c0, opt=0
 '\000', argc=) at
 dispatcher.cpp:130
 #17 0x00010116b6b6 in ?? ()
 #18 0x00010573dcab in ?? ()
 #19 0x00010115c617 in ?? ()
 #20 0x0001011698a9 in ?? ()
 #21 0x00010573e075 in ?? ()
 #22 0x000100018104 in rb_ary_each_imp () at JIT.h:33
 #23 0x00010016b771 in rb_vm_dispatch (cache=0x100f2b8e0,
 top=8592946752, self=8593594208, sel=0x100f2b7e0, block=0x2003b0140, opt=0
 '\000', argc=) at
 dispatcher.cpp:130
 #24 0x00010116b6b6 in ?? ()
 #25 0x00010573dcab in ?? ()
 #26 0x00010115c617 in ?? ()
 #27 0x0001011698a9 in ?? ()
 #28 0x00010573e075 in ?? ()
 #29 0x000100018104 in rb_ary_each_imp () at JIT.h:33
 #30 0x00010016b771 in rb_vm_dispatch (cache=0x100f2b8e0,
 top=8593966304, self=8593966880, sel=0x100f2b7e0, block=0x2003b4860, opt=0
 '\000', argc=) at
 dispatcher.cpp:130
 #31 0x00010116b6b6 in ?? ()
 #32 0x00010573dcab in ?? ()
 #33 0x00010115c617 in ?? ()
 #34 0x0001011698a9 in ?? ()
 #35 0x00010573d266 in ?? ()
 #36 0x00010573cdae in ?? ()
 #37 0x00010573cc6f in ?? ()
 #38 0x000100018104 in rb_ary_each_imp () at JIT.h:33
 #39 0x00010016b771 in rb_vm_dispatch (cache=0x100f2b8e0,
 top=8592377568, self=8592358688, sel=0x100f2b7e0, block=0x2002c92c0, opt=0
 '\000', argc=) at
 dispatcher.cpp:130
 #40 0x00010573ca5e in ?? ()
 #41 0x00010117f409 in ?? ()
 #42 0x00010573c716 in ?? ()
 #43 0x00010117f361 in ?? ()
 #44 0x00010117f409 in ?? ()
 #45 0x00010117f186 in ?? ()
 #46 0x00010115092c in ?? ()
 #47 0x000100047a69 in rb_load (fname=8592730048, wrap=0) at load.c:95
 #48 0x000100047ac8 in rb_f_load (rcv=8590055616, sel=0x7fff8481aee9,
 argc=1, argv=0x7fff5fbfe880) at load.c:119
 #49 0x00010016b39f in rb_vm_dispatch (cache=0x100ffab30,
 top=8590055616, self=8590055616, sel=0x7fff8481aee9, block=0x0, opt=2
 '\002', argc=1) at dispatcher.cpp:433
 #50 0x0001011102ea in ?? ()
 #51 0x00010003f579 in ruby_run_node (n=0x20001d8c0) at eval.c:199
 #52 0x00010d28 in main (argc=4, argv=0x100f1c290, envp=) at main.cpp:40
 }}}

 MacRuby trunk revision 3317.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #570: Some STDOUT write function doesn't handle spaces or tabs correctly or something

2010-01-21 Thread MacRuby 
#570: Some STDOUT write function doesn't handle spaces or tabs correctly or
something
-+--
 Reporter:  hongli...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 How to reproduce:
 {{{
 $ macgem help commands
 GEM commands are:

 buildBuild a gem from a gemspec
 ...
 }}}

 Notice the lack of spacing between "build" and "Build a gem ...".

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] [MacRuby] #571: #respond_to? should return false for unimplemented methods

2010-01-21 Thread MacRuby 
#571: #respond_to? should return false for unimplemented methods
-+--
 Reporter:  hongli...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 MRI >= 1.9.2's #respond_to? method now returns false for unimplemented
 methods. By "unimplemented" I mean methods which are #defined as
 rb_f_notimplement in the MRI 1.9 source code. rb_f_notimplemented is a
 method which raises NotImplementedErrror.

 An example of this is Process.fork, implemented on MRI 1.9 as rb_f_fork.
 The #fork method is defined on all platforms, even on platforms where fork
 is not actually supported (i.e. rb_f_fork is #defined to
 rb_f_notimplemented). However Process.respond_to?(:fork) now returns false
 instead of true on these platforms.

 MacRuby should follow this behavior.

-- 
Ticket URL: 
MacRuby 

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

[MacRuby-devel] My class's initialize not called

2010-01-21 Thread steve ross 
I'm sure this is an elementary question, but I have the class below. In IB, I 
set several NSTextField controls to this class. Everything works in the blah, 
blah, blah part, but strangely enough the 

puts "initialize dctf"

never seems to be called. Any thoughts as to why?

require 'strings'

class DuplicateCounterTextField < NSTextField
  include Strings
  
  attr_accessor :splitter, :completions
  attr_accessor :wordCount, :duplicateCount
  
  def initialize
puts "initialize dctf"
@splitter = /\W+/
@wordCount = 0
@cachedWordCount = 0
@duplicateCount = 0
  end
  
  # blah, blah, blah working code

  def textDidChange(notification)
words = stringValue.split(@splitter)
@wordCount = words.length
@duplicateCount = @wordCount - words.uniq.length

if delegate.respond_to?('controlCountDidChange:wordCount:duplicateCount:')
  delegate.controlCountDidChange(self, 
   wordCount:@wordCount, 
  duplicateCount:@duplicateCount) 
end
  end

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

Re: [MacRuby-devel] My class's initialize not called

2010-01-21 Thread Matt Aimonetti 
When reopening a Cocoa class, you should not overwrite initialize and if you
were to do it anyway, don't forget to call super and to return self.
The Cocoa way is to create your own initializer to end up with something
like DuplicateCounterTextField.alloc.initWithDuplicate

Also, remember that when initializing a Cocoa class, you need to do
DuplicateCounterTextField.alloc.init

- Matt


On Thu, Jan 21, 2010 at 3:20 PM, steve ross  wrote:

> I'm sure this is an elementary question, but I have the class below. In IB,
> I set several NSTextField controls to this class. Everything works in the
> blah, blah, blah part, but strangely enough the
>
> puts "initialize dctf"
>
> never seems to be called. Any thoughts as to why?
>
> require 'strings'
>
> class DuplicateCounterTextField < NSTextField
>  include Strings
>
>  attr_accessor :splitter, :completions
>  attr_accessor :wordCount, :duplicateCount
>
>  def initialize
>puts "initialize dctf"
>@splitter = /\W+/
>@wordCount = 0
>@cachedWordCount = 0
>@duplicateCount = 0
>  end
>
>  # blah, blah, blah working code
>
>  def textDidChange(notification)
>words = stringValue.split(@splitter)
>@wordCount = words.length
>@duplicateCount = @wordCount - words.uniq.length
>
>if
> delegate.respond_to?('controlCountDidChange:wordCount:duplicateCount:')
>  delegate.controlCountDidChange(self,
>   wordCount:@wordCount,
>  duplicateCount:@duplicateCount)
>end
>  end
>
>  # etc.
> end
> ___
> 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] #572: ConditionVariable#wait should accept a timeout argument

2010-01-21 Thread MacRuby 
#572: ConditionVariable#wait should accept a timeout argument
-+--
 Reporter:  hongli...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--
 Right now, ConditionVariable#wait waits forever until the condition is
 signaled. There should be a way to wait on a condition variable for a
 bounded time. A typical use case is as follows:

   There is a background thread which performs some cleaning function every
 x seconds. We also want to be able to tell the thread to clean now, or to
 exit (i.e. quitting its main loop so that we can join the thread). This
 thread waits on a condition variable for x seconds, and then checks
 whether there was a timeout on the wait, or whether the wait as signaled.
 In case of the former it will run the cleanup code. In case of the latter
 it'll check whether @quit is set, and then either stop the loop or run the
 cleanup code.

 This support for bounded waiting should be implemented by supporting an
 extra 'timeout' argument in ConditionVariable#wait. In fact JRuby and MRI
 1.9.2dev already support it, though differenly. The call seqs are as
 follows:
 {{{
 MRI <= 1.9.1: ConditionVariable#wait(mutex)
No native support for bounded time waiting. In Phusion Passenger
we emulate this with timeout.rb which is very hacky, though it
seems to work.

 MRI 1.9.2dev: ConditionVariable#wait(mutex, timeout)   => integer
Waits for at most 'timeout' time. 'timeout' may be a floating
point number.
Returns the number of *seconds* spent waiting. So even if it
actually spent 3.5 seconds waiting, it'll either return 3 or 4.
There is no way to check whether the wait was signaled or
timed out, you have to guess based on the time waited.

 JRuby: ConditionVariable#wait(mutex, timeout)   => boolean
Waits for at most 'timeout' time. 'timeout' may be a floating
point number.
Returns true if condition was signaled, false if it timed out.
 }}}

 I think the JRuby approach makes most sense. We should also convince the
 MRI developers to change the behavior to match JRuby's before 1.9.2 is
 released.

 Bounded wait can be implemented with pthread_cond_timedwait.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] My class's initialize not called

2010-01-21 Thread steve ross 
So, this class doesn't reopen a Cocoa class, it subclasses it. Same anyhow? The 
real problem is that the class is instantiated as a side effect of nib loading, 
and the only place I've been able to successfully set initial state is 
awakeFromNib. I either can't, or don't know how to make the nib load process 
call a DuplicateCounterTextField.initWithSomeCoolState method. My impression is 
that awakeFromNib is a poor place for setting initial state because the order 
in which awakeFromNib's are called is undefined (or is it?). Not to 
overcomplicate things, but the controller needs to be able to tweak the state 
of the control -- for example, to change the splitter regex.

Thanks for helping out here.

Steve

On Jan 21, 2010, at 3:25 PM, Matt Aimonetti wrote:
> When reopening a Cocoa class, you should not overwrite initialize and if you 
> were to do it anyway, don't forget to call super and to return self.
> The Cocoa way is to create your own initializer to end up with something like 
> DuplicateCounterTextField.alloc.initWithDuplicate
> 
> Also, remember that when initializing a Cocoa class, you need to do 
> DuplicateCounterTextField.alloc.init
> 
> - Matt
> 
> 
> On Thu, Jan 21, 2010 at 3:20 PM, steve ross  wrote:
> I'm sure this is an elementary question, but I have the class below. In IB, I 
> set several NSTextField controls to this class. Everything works in the blah, 
> blah, blah part, but strangely enough the
> 
> puts "initialize dctf"
> 
> never seems to be called. Any thoughts as to why?
> 
> require 'strings'
> 
> class DuplicateCounterTextField < NSTextField
>  include Strings
> 
>  attr_accessor :splitter, :completions
>  attr_accessor :wordCount, :duplicateCount
> 
>  def initialize
>puts "initialize dctf"
>@splitter = /\W+/
>@wordCount = 0
>@cachedWordCount = 0
>@duplicateCount = 0
>  end
> 
>  # blah, blah, blah working code
> 
>  def textDidChange(notification)
>words = stringValue.split(@splitter)
>@wordCount = words.length
>@duplicateCount = @wordCount - words.uniq.length
> 
>if delegate.respond_to?('controlCountDidChange:wordCount:duplicateCount:')
>  delegate.controlCountDidChange(self,
>   wordCount:@wordCount,
>  duplicateCount:@duplicateCount)
>end
>  end
> 
>  # etc.
> end
> ___
> 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 mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] My class's initialize not called

2010-01-21 Thread Matt Aimonetti 
Sorry I replied too quickly and didn't read properly.

Overwriting the init method of a Cocoa class subclass is not recommended.
Here is an example of what I was suggesting:

http://github.com/mattetti/phileas_frog/blob/master/image_layer.rb#L44

Which then get called there:
http://github.com/mattetti/phileas_frog/blob/master/game_controller.rb#L57

In any cases, you still need to call init (or super if you overwrite
initialize) and you need to return self.

I hope that helps.

- Matt


On Thu, Jan 21, 2010 at 4:09 PM, steve ross  wrote:

> So, this class doesn't reopen a Cocoa class, it subclasses it. Same anyhow?
> The real problem is that the class is instantiated as a side effect of nib
> loading, and the only place I've been able to successfully set initial state
> is awakeFromNib. I either can't, or don't know how to make the nib load
> process call a DuplicateCounterTextField.initWithSomeCoolState method. My
> impression is that awakeFromNib is a poor place for setting initial state
> because the order in which awakeFromNib's are called is undefined (or is
> it?). Not to overcomplicate things, but the controller needs to be able to
> tweak the state of the control -- for example, to change the splitter regex.
>
> Thanks for helping out here.
>
> Steve
>
> On Jan 21, 2010, at 3:25 PM, Matt Aimonetti wrote:
>
> When reopening a Cocoa class, you should not overwrite initialize and if
> you were to do it anyway, don't forget to call super and to return self.
> The Cocoa way is to create your own initializer to end up with something
> like DuplicateCounterTextField.alloc.initWithDuplicate
>
> Also, remember that when initializing a Cocoa class, you need to do
> DuplicateCounterTextField.alloc.init
>
> - Matt
>
>
> On Thu, Jan 21, 2010 at 3:20 PM, steve ross  wrote:
>
>> I'm sure this is an elementary question, but I have the class below. In
>> IB, I set several NSTextField controls to this class. Everything works in
>> the blah, blah, blah part, but strangely enough the
>>
>> puts "initialize dctf"
>>
>> never seems to be called. Any thoughts as to why?
>>
>> require 'strings'
>>
>> class DuplicateCounterTextField < NSTextField
>>  include Strings
>>
>>  attr_accessor :splitter, :completions
>>  attr_accessor :wordCount, :duplicateCount
>>
>>  def initialize
>>puts "initialize dctf"
>>@splitter = /\W+/
>>@wordCount = 0
>>@cachedWordCount = 0
>>@duplicateCount = 0
>>  end
>>
>>  # blah, blah, blah working code
>>
>>  def textDidChange(notification)
>>words = stringValue.split(@splitter)
>>@wordCount = words.length
>>@duplicateCount = @wordCount - words.uniq.length
>>
>>if
>> delegate.respond_to?('controlCountDidChange:wordCount:duplicateCount:')
>>  delegate.controlCountDidChange(self,
>>   wordCount:@wordCount,
>>  duplicateCount:@duplicateCount)
>>end
>>  end
>>
>>  # etc.
>> end
>> ___
>> 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 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] My class's initialize not called

2010-01-21 Thread steve ross 
So that confirms my suspicion. It's not so much a MacRuby thing as a Cocoa 
thing. I just don't see how to set an initial state in a class that's 
instantiated when a nib is loaded. I don't do the alloc.initWithWhatever. On 
the previous subject though, adding super/self does not cause the initialize 
method to be called. Hmm...

On Jan 21, 2010, at 4:20 PM, Matt Aimonetti wrote:
> Overwriting the init method of a Cocoa class subclass is not recommended. 
> Here is an example of what I was suggesting:
> 
> http://github.com/mattetti/phileas_frog/blob/master/image_layer.rb#L44
> 
> Which then get called there: 
> http://github.com/mattetti/phileas_frog/blob/master/game_controller.rb#L57
> 
> In any cases, you still need to call init (or super if you overwrite 
> initialize) and you need to return self.


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

Re: [MacRuby-devel] My class's initialize not called

2010-01-21 Thread Edward Moy 
This sounds like:

https://www.macruby.org/trac/ticket/250

Any subclass of a native Objective C class will fail to call initialize.  I do 
have a fix, but I've been working on other things at the moment.  I'll try to 
finish up and get back to 250 as soon as I can.

Ed

On Jan 21, 2010, at 4:33 PM, steve ross wrote:

> So that confirms my suspicion. It's not so much a MacRuby thing as a Cocoa 
> thing. I just don't see how to set an initial state in a class that's 
> instantiated when a nib is loaded. I don't do the alloc.initWithWhatever. On 
> the previous subject though, adding super/self does not cause the initialize 
> method to be called. Hmm...
> 
> On Jan 21, 2010, at 4:20 PM, Matt Aimonetti wrote:
>> Overwriting the init method of a Cocoa class subclass is not recommended. 
>> Here is an example of what I was suggesting:
>> 
>> http://github.com/mattetti/phileas_frog/blob/master/image_layer.rb#L44
>> 
>> Which then get called there: 
>> http://github.com/mattetti/phileas_frog/blob/master/game_controller.rb#L57
>> 
>> In any cases, you still need to call init (or super if you overwrite 
>> initialize) and you need to return self.
> 
> 
> ___
> 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] [MacRuby] #565: GCD sources should return passed-in handle for handle method

2010-01-21 Thread MacRuby 
#565: GCD sources should return passed-in handle for handle method
---+
 Reporter:  j...@…  |Owner:  ernest.prabha...@…
 Type:  defect |   Status:  closed
 Priority:  blocker|Milestone:  MacRuby 0.6   
Component:  MacRuby|   Resolution:  fixed 
 Keywords: |  
---+
Changes (by ernest.prabha...@…):

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


Comment:

 Fixed in r3320

 Changed to allow (and return) anything that can respond to "to_i" as a
 handle, for maximum flexibility.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] [MacRuby] #571: #respond_to? should return false for unimplemented methods

2010-01-21 Thread MacRuby 
#571: #respond_to? should return false for unimplemented methods
-+--
 Reporter:  hongli...@…  |   Owner:  lsansone...@…
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:   
Component:  MacRuby  |Keywords:   
-+--

Comment(by lsansone...@…):

 Let's follow MRI here and register a common implementation symbol for
 unimplemented methods, then refresh the UNAVAILABLE_IMP macro to also
 check for this symbol.

-- 
Ticket URL: 
MacRuby 

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

Re: [MacRuby-devel] My class's initialize not called

2010-01-21 Thread Brian Chapados 
Hi Steve (et al),

So, there are a couple things going on here.  Cocoa classes use the
concept of a "designated initializer" method, which is a name for the
instance method that calls the initializer method of the superclass.
This chain continues until you hit [NSObject#init]. To figure this out
from the documentation:

- If a class does not document an initializer method, check the
superclass, and continue up the chain until you find it.
- If there are multiple initializer methods, the documentation for
Cocoa classes will always tell you which method is the designated
initializer.

In ObjC/Cocoa:
If you have a subclass that requires input during initialization, you
should create a new designated initializer.  That method should call
the designated initializer of the superclass and you should override
-init to call your new designated initializer.

All of this stuff is explained pretty well in Apple's Objective-C guide.

In Matt's example, he creates a few initialization helper methods, but
-init is still the designated initializer.

In your case, NSTextField is a subclass of NSControl, and the
designated initializer is (from NSControl):

-initWithFrame:(NSRect)frameRect

I think your subclass of NSTextField should have an -initWithFrame:
method or another init method that calls super.initWithFrame:
Although, if you're not supposed to call super.init in MacRuby, then
I'm not sure how this is supposed to work.

Last point: The one odd exception case to the initialization chain is
the one you hit: NIB files!

nib/xib files are basically freeze-dried collections of objects that
are archived into a file.  When they are restored, this is done by
unarchiving the file, which uses the NSCoder methods. Most of the time
if you need to do custom configuration on an object instantiated from
a nib file, you should probably do that in -awakeFromNib.  However, if
for some reason you really need to do something during object
initialization, you need to do that in initWithCoder:, since this
method will be called for objects in a nib file.

Brian

On Thu, Jan 21, 2010 at 4:33 PM, steve ross  wrote:
> So that confirms my suspicion. It's not so much a MacRuby thing as a Cocoa
> thing. I just don't see how to set an initial state in a class that's
> instantiated when a nib is loaded. I don't do the alloc.initWithWhatever. On
> the previous subject though, adding super/self does not cause the initialize
> method to be called. Hmm...
> On Jan 21, 2010, at 4:20 PM, Matt Aimonetti wrote:
>
> Overwriting the init method of a Cocoa class subclass is not recommended.
> Here is an example of what I was suggesting:
>
> http://github.com/mattetti/phileas_frog/blob/master/image_layer.rb#L44
>
> Which then get called
> there: http://github.com/mattetti/phileas_frog/blob/master/game_controller.rb#L57
>
> In any cases, you still need to call init (or super if you overwrite
> initialize) and you need to return self.
>
>
>
> ___
> 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] My class's initialize not called

2010-01-21 Thread steve ross 
Brian--

Thanks for the great explanation. I'm going to have to rethink how my object 
achieves a known initial state.

Steve


On Jan 21, 2010, at 6:41 PM, Brian Chapados wrote:
> 
> Hi Steve (et al),
> 
> So, there are a couple things going on here.  Cocoa classes use the
> concept of a "designated initializer" method, which is a name for the
> instance method that calls the initializer method of the superclass.
> This chain continues until you hit [NSObject#init]. To figure this out
> from the documentation:
> 
> - If a class does not document an initializer method, check the
> superclass, and continue up the chain until you find it.
> - If there are multiple initializer methods, the documentation for
> Cocoa classes will always tell you which method is the designated
> initializer.
> 
> In ObjC/Cocoa:
> If you have a subclass that requires input during initialization, you
> should create a new designated initializer.  That method should call
> the designated initializer of the superclass and you should override
> -init to call your new designated initializer.
> 
> All of this stuff is explained pretty well in Apple's Objective-C guide.
> 
> In Matt's example, he creates a few initialization helper methods, but
> -init is still the designated initializer.
> 
> In your case, NSTextField is a subclass of NSControl, and the
> designated initializer is (from NSControl):
> 
> -initWithFrame:(NSRect)frameRect
> 
> I think your subclass of NSTextField should have an -initWithFrame:
> method or another init method that calls super.initWithFrame:
> Although, if you're not supposed to call super.init in MacRuby, then
> I'm not sure how this is supposed to work.
> 
> Last point: The one odd exception case to the initialization chain is
> the one you hit: NIB files!
> 
> nib/xib files are basically freeze-dried collections of objects that
> are archived into a file.  When they are restored, this is done by
> unarchiving the file, which uses the NSCoder methods. Most of the time
> if you need to do custom configuration on an object instantiated from
> a nib file, you should probably do that in -awakeFromNib.  However, if
> for some reason you really need to do something during object
> initialization, you need to do that in initWithCoder:, since this
> method will be called for objects in a nib file.
> 
> Brian
> 
> On Thu, Jan 21, 2010 at 4:33 PM, steve ross  wrote:
>> So that confirms my suspicion. It's not so much a MacRuby thing as a Cocoa
>> thing. I just don't see how to set an initial state in a class that's
>> instantiated when a nib is loaded. I don't do the alloc.initWithWhatever. On
>> the previous subject though, adding super/self does not cause the initialize
>> method to be called. Hmm...
>> On Jan 21, 2010, at 4:20 PM, Matt Aimonetti wrote:
>> 
>> Overwriting the init method of a Cocoa class subclass is not recommended.
>> Here is an example of what I was suggesting:
>> 
>> http://github.com/mattetti/phileas_frog/blob/master/image_layer.rb#L44
>> 
>> Which then get called
>> there: 
>> http://github.com/mattetti/phileas_frog/blob/master/game_controller.rb#L57
>> 
>> In any cases, you still need to call init (or super if you overwrite
>> initialize) and you need to return self.
>> 

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