rubycocoa-talk

[Rubycocoa-talk] objc_method documentation?

[Nathaniel I. <nd...@bu...>]

Is there a source of good documentation for objc_method? I'm trying to call,
from Obj-C, a three-argument Ruby method taking an array and two strings,
and returning a boolean. I'm getting inconsistent results owing to my lack
of understanding -- sometimes the returned result isn't typed as boolean,
sometimes calling the method raises an exception about the wrong number of
arguments. I started with examples from this page:

http://limechat.net/rubycocoa/bridge_test.html

But I'm don't recognize the "B@:@@" syntax, which is proving
google-resistant.

I see some commentary about improved boolean handling in the release notes
for .13, but I can't tell how much trouble I'll be biting off if I move
beyond the Leopard-bundled framework. Any problem reverting, if necessary?

While I'm asking, the .13.2 installer warns "If you overwrote Apple's Ruby
with a custom version, please make sure that it has been built with
--enabled-shared." I trust this is aimed at people who replaced
/usr/bin/ruby for some reason, and not applicable to upstanding individuals
with oddball /usr/local/bin/ruby. --enabled-shared is fine, I just don't
want to discover down the road that my deployment targets expect similarly
oddball ruby installations.

Thanks,

  -nat

Re: [Rubycocoa-talk] objc_method documentation?

[Allison N. <dem...@ma...>]

Nat,

I can't help you with the bridge, but I'm guessing that Apple's  
Scripting Bridge documentation should be of interest in doing what you  
are trying to do.  If you haven't already looked at it, this may help:
http://developer.apple.com/documentation/Cocoa/Conceptual/RubyPythonCocoa/Articles/GenerateFrameworkMetadata.html#/ 
/apple_ref/doc/uid/TP40005426

As mentioned on that page, the manpage ('man BridgeSupport 5' in the  
terminal) also gives some important information.

Other than that, I can't really help you for the bridge.  If all of  
that gets too hard, you might try just writing a plain ol' C extension  
to Ruby, which can also do what you want if all you want is to call  
Ruby from Objective-C, and not the inverse.

As for having multiple copies of ruby installed on your system, it  
won't cause you any dramas if you are just trying to run the app from  
inside XCode, or even a a standalone.  But I had all sorts of problems  
when i wanted to run some rspec unit tests, or run my app inside irb  
to debug it.  My system kept trying to use my copy of ruby stored in / 
usr/local/bin, which wasn't compiled with --enabled-shared.  Worse  
still, its LIBRARIES variable didn't have the RubyCocoa framework in  
its path either.  I ended up just deleting that version of ruby, along  
with its friends (irb, erb, ri, rdoc etc).  If I ever need it again,  
I'll be making sure that it's correctly compiled to work wth RubyCocoa  
when I install it. So be very careful with this, here be dragons...

Alli


Le 13 juin 08 à 02:37, Nathaniel Irons a écrit :

> Is there a source of good documentation for objc_method? I'm trying  
> to call, from Obj-C, a three-argument Ruby method taking an array  
> and two strings, and returning a boolean. I'm getting inconsistent  
> results owing to my lack of understanding -- sometimes the returned  
> result isn't typed as boolean, sometimes calling the method raises  
> an exception about the wrong number of arguments. I started with  
> examples from this page:
>
> http://limechat.net/rubycocoa/bridge_test.html
>
> But I'm don't recognize the "B@:@@" syntax, which is proving google- 
> resistant.
>
> I see some commentary about improved boolean handling in the release  
> notes for .13, but I can't tell how much trouble I'll be biting off  
> if I move beyond the Leopard-bundled framework. Any problem  
> reverting, if necessary?
>
> While I'm asking, the .13.2 installer warns "If you overwrote  
> Apple's Ruby with a custom version, please make sure that it has  
> been built with --enabled-shared." I trust this is aimed at people  
> who replaced /usr/bin/ruby for some reason, and not applicable to  
> upstanding individuals with oddball /usr/local/bin/ruby. --enabled- 
> shared is fine, I just don't want to discover down the road that my  
> deployment targets expect similarly oddball ruby installations.
>
> Thanks,
>
>   -nat
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php_______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] objc_method documentation?

[Nathaniel I. <nd...@bu...>]

On Thu, Jun 12, 2008 at 9:21 PM, Allison Newman <dem...@ma...> wrote:

> Nat,
> I can't help you with the bridge, but I'm guessing that Apple's Scripting
> Bridge documentation should be of interest in doing what you are trying to
> do.  If you haven't already looked at it, this may help:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/RubyPythonCocoa/Articles/GenerateFrameworkMetadata.html#/
> /apple_ref/doc/uid/TP40005426
>
> As mentioned on that page, the manpage ('man BridgeSupport 5' in the
> terminal) also gives some important information.
>

Thanks very much for the suggestions. However, I'm not seeing the connection
between Apple's BridgeSupport infrastructure and RubyCocoa's "objc_method"
method. The BridgeSupport type-encoding syntax, which is XML, doesn't seem
to overlap with the 'B@:@@' syntax used by objc_method, as obliquely
referenced on that limechat.com page.

I've found a lot of references to objc_method in context of returning a
primitive value from a Ruby method to an Objective-C caller (e.g. <
http://tinyurl.com/4bornj>). That shouldn't rise to the level of requiring a
Ruby C extension -- objc_method appears to serve this exact purpose, I just
can't figure out what syntax it expects. I'd still appreciate any assistance
on that point.

Thanks,

  -nat

Re: [Rubycocoa-talk] objc_method documentation?

[Patrick G. <pge...@wa...>]

> Thanks very much for the suggestions. However, I'm not seeing the  
> connection between Apple's BridgeSupport infrastructure and  
> RubyCocoa's "objc_method" method. The BridgeSupport type-encoding  
> syntax, which is XML, doesn't seem to overlap with the 'B@:@@'  
> syntax used by objc_method, as obliquely referenced on that  
> limechat.com page.

Pasting from /System/Library/Frameworks/RubyCocoa.framework/Versions/A/ 
Resources/ruby/osx/objc/oc_import.rb

     OCTYPES = {
       :id       => '@',
       :class    => '#',
       :BOOL     => 'c',
       :char     => 'c',
       :uchar    => 'C',
       :short    => 's',
       :ushort   => 'S',
       :int      => 'i',
       :uint     => 'I',
       :long     => 'l',
       :ulong    => 'L',
       :float    => 'f',
       :double   => 'd',
       :bool     => 'B',
       :void     => 'v',
       :selector => ':',
       :sel      => ':',
       :longlong => 'q',
       :ulonglong => 'Q',
       :cstr     => '*',
     }

Note that bool and BOOL have different signatures. You're using bool  
('B') and Cocoa usually uses BOOL ('c'). That may explain your  
inconsistent results.

-Patrick

Re: [Rubycocoa-talk] objc_method documentation?

[Nathaniel I. <nd...@bu...>]

On Tue, Jun 17, 2008 at 4:51 PM, Patrick Geiller <pge...@wa...>
wrote:


> Pasting
> from /System/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/objc/oc_import.rb
>
>     OCTYPES = {
>       :id       => '@',
>       :class    => '#',
>       :BOOL     => 'c',
>       :char     => 'c',
>       :uchar    => 'C',
>       :short    => 's',
>       :ushort   => 'S',
>       :int      => 'i',
>       :uint     => 'I',
>       :long     => 'l',
>       :ulong    => 'L',
>       :float    => 'f',
>       :double   => 'd',
>       :bool     => 'B',
>       :void     => 'v',
>       :selector => ':',
>       :sel      => ':',
>       :longlong => 'q',
>       :ulonglong => 'Q',
>       :cstr     => '*',
>     }
>
> Note that bool and BOOL have different signatures. You're using bool ('B')
> and Cocoa usually uses BOOL ('c'). That may explain your inconsistent
> results.
>

Thanks! I'd seen this but still hadn't wrapped my head around the idea that
single-character types were meaningful, in large part because the
limechat.com examples all had too many characters to account for the
arguments and return value. For instance:

  objc_method 'control:textView:doCommandBySelector:', 'B@:@@:'

This is defined on NSControl to return a boolean, and accept an NSControl,
an NSTextView, and a selector, so I would expect the stringified encoding to
be "B@@:". Do I now understand correctly that the second and third
characters above, "@:", are the self object and selector that Obj-C hides
from message-passing syntax? That assumption at least produces sane values
in my application.

Thanks,

  -nat

Re: [Rubycocoa-talk] objc_method documentation?

[Jonathan d. S. <mai...@st...>]

On Wed, Jun 18, 2008 at 2:20 AM, Nathaniel Irons <nd...@bu...> wrote:
> On Tue, Jun 17, 2008 at 4:51 PM, Patrick Geiller <pge...@wa...>
> wrote:
>
>>
>> Pasting
>> from /System/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/objc/oc_import.rb
>>     OCTYPES = {
>>       :id       => '@',
>>       :class    => '#',
>>       :BOOL     => 'c',
>>       :char     => 'c',
>>       :uchar    => 'C',
>>       :short    => 's',
>>       :ushort   => 'S',
>>       :int      => 'i',
>>       :uint     => 'I',
>>       :long     => 'l',
>>       :ulong    => 'L',
>>       :float    => 'f',
>>       :double   => 'd',
>>       :bool     => 'B',
>>       :void     => 'v',
>>       :selector => ':',
>>       :sel      => ':',
>>       :longlong => 'q',
>>       :ulonglong => 'Q',
>>       :cstr     => '*',
>>     }
>> Note that bool and BOOL have different signatures. You're using bool ('B')
>> and Cocoa usually uses BOOL ('c'). That may explain your inconsistent
>> results.
>
> Thanks! I'd seen this but still hadn't wrapped my head around the idea that
> single-character types were meaningful, in large part because the
> limechat.com examples all had too many characters to account for the
> arguments and return value. For instance:
>
>   objc_method 'control:textView:doCommandBySelector:', 'B@:@@:'
>
> This is defined on NSControl to return a boolean, and accept an NSControl,
> an NSTextView, and a selector, so I would expect the stringified encoding to
> be "B@@:". Do I now understand correctly that the second and third
> characters above, "@:", are the self object and selector that Obj-C hides
> from message-passing syntax? That assumption at least produces sane values
> in my application.
>


Correct.  I haven't looked at the source, but assume that objc_method
is just calling through to the objc runtime methods; see here in
particular - http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html#//apple_ref/c/func/class_addMethod

Re: [Rubycocoa-talk] objc_method documentation?

[Patrick G. <pge...@wa...>]

> Correct.  I haven't looked at the source, but assume that objc_method
> is just calling through to the objc runtime methods; see here in
> particular - http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html#/ 
> /apple_ref/c/func/class_addMethod

That's right. Ruby is calling it in imp_c_addRubyMethod_withType ( http://www.opensource.apple.com/darwinsource/10.5/RubyCocoa-57/RubyCocoa/framework/src/objc/OverrideMixin.m 
  )

 From the source of objc_method, you should be able to call it with  
more readable arguments :
objc_method [:BOOL, :id]
meaning returning BOOL and taking one NSObject. I didn't test it,  
though.

-Patrick