rubycocoa-talk — talking about RubyCocoa

[Rubycocoa-talk] RubyCocoa macosx bundle without installed ruby ?

[Remo E. <re...@pl...>]

hi all ( sorry for my english)

i have two questions:

- is there a way to build a rubycocoa-application WITHOUT  a 
preinstalled ruby-runtime ? i mean a static compile of the 
ruby-runtime.
- is there a compiler or a obfuscator to build a rubycocoa-application ?

my goal is to build a application without the distribution of the 
source-code :)

regards,

Remo Eichenberger

Re: [Rubycocoa-talk] Thread bug analyzed

[kimura w. <ki...@us...>]

Hi,

I added this problem to the tracker on sf.net. 

Fri, 15 Apr 2005 13:40:33 +0100, Jonathan Paisley wrote:
>Hi all,
>

>Following up from my earlier thread "Thread scheduling", I've 
>identified the precise cause of the problems I've been seeing.
>

>As I see it, this means it is never safe to use any objective c calls 
>from the non-main Ruby thread.
>
I get it. 

>Setting rb_thread_critical for the lifetime of each NSAutoreleasePool 
>or exception context should resolve the issue, but means that 
>concurrency is prevented during all Cocoa calls. I shall investigate 
>how this affects the application I'm working on.
>

I'm looking for reading your next report.
Thanks a lot!

Re: [Rubycocoa-talk] ptr to enum array ?

[Remo E. <re...@pl...>]

Dear Jonathan Paisley

thank you very much for your help :) both answers from you helped me.


Am 17.04.2005 um 13:45 schrieb Jonathan Paisley:

>  attribs = [OSX:: NSOpenGLPFADoubleBuffer,
>   OSX::NSOpenGLPFAAccelerated,
>   OSX::NSOpenGLPFAColorSize, BITS_PER_PIXEL,
>   OSX:: NSOpenGLPFADepthSize, DEPTH_SIZE, 0].pack("i*")

Re: [Rubycocoa-talk] ptr to enum array ?

[Jonathan P. <jp...@dc...>]

On 17 Apr 2005, at 12:33, Remo Eichenberger wrote:

> hi all
>
> i try to implement the following:
>
> OSX::NSOpenGLPixelFormat.alloc.initWithAttributes(attribs)
>
> i found this in the cocoa-documentation:
>
> - (id)initWithAttributes:(NSOpenGLPixelFormatAttribute *)attribs
>
> How i can create "attribs"-variable with RubyCocoa ? must i use NSData 
> ?
>
> i would translate the following:
>
>    NSOpenGLPixelFormatAttribute attr[] =     {
>     NSOpenGLPFADoubleBuffer,
>     NSOpenGLPFAAccelerated,
>     NSOpenGLPFAColorSize, BITS_PER_PIXEL,
>     NSOpenGLPFADepthSize, DEPTH_SIZE,
>     0

Try:

  attribs = [OSX:: NSOpenGLPFADoubleBuffer,
   OSX::NSOpenGLPFAAccelerated,
   OSX::NSOpenGLPFAColorSize, BITS_PER_PIXEL,
   OSX:: NSOpenGLPFADepthSize, DEPTH_SIZE, 0].pack("i*")

  OSX::NSOpenGLPixelFormat.alloc.initWithAttributes(attribs)

[Rubycocoa-talk] ptr to enum array ?

[Remo E. <re...@pl...>]

hi all

i try to implement the following:

OSX::NSOpenGLPixelFormat.alloc.initWithAttributes(attribs)

i found this in the cocoa-documentation:

- (id)initWithAttributes:(NSOpenGLPixelFormatAttribute *)attribs

How i can create "attribs"-variable with RubyCocoa ? must i use NSData ?

i would translate the following:

    NSOpenGLPixelFormatAttribute attr[] =     {
     NSOpenGLPFADoubleBuffer,
     NSOpenGLPFAAccelerated,
     NSOpenGLPFAColorSize, BITS_PER_PIXEL,
     NSOpenGLPFADepthSize, DEPTH_SIZE,
     0
    };

thanks,

Remo Eichenberger

Re: [Rubycocoa-talk] does parse RubyCocoa external declarated strings from cocoa-headers ?

[Jonathan P. <jp...@dc...>]

On 17 Apr 2005, at 11:58, Remo Eichenberger wrote:

> require 'osx/cocoa'
> include OSX
>
> NSRunLoop.currentRunLoop.addTimer(timer, NSEventTrackingRunLoopMode)
>
> But "NSEventTrackingRunLoopMode" is not in the symboltable of Ruby. i 
> found this in the file: "NSApplication.h" as following:
>
> APPKIT_EXTERN NSString *NSEventTrackingRunLoopMode;

Because NSEventTrackingRunLoopMode isn't a compile-time constant, 
RubyCocoa implements it as a method (rather than a Ruby constant) on 
module OSX which can look it up when necessary.

This is confusing in Ruby because symbols with initial capital letters 
are treated as constants. So, your code above ends up looking for

	OSX::NSEventTrackingRunLoopMode

but, because it's a method and not a constant, you must explicitly use:

	OSX.NSEventTrackingRunLoopMode

I hope that makes sense.

[Rubycocoa-talk] does parse RubyCocoa external declarated strings from cocoa-headers ?

[Remo E. <re...@pl...>]

hi all

i try to implement the following:

require 'osx/cocoa'
include OSX

NSRunLoop.currentRunLoop.addTimer(timer, NSEventTrackingRunLoopMode)


But "NSEventTrackingRunLoopMode" is not in the symboltable of Ruby. i 
found this in the file: "NSApplication.h" as following:

APPKIT_EXTERN NSString *NSEventTrackingRunLoopMode;

does parse the RubyCocoa such external declarations ? when yes, how i 
can access it ?

regards,

Remo Eichenberger

Re: [Rubycocoa-talk] Pure ruby object from cocoa object

[kimura w. <ki...@us...>]

Hi,

I fixed this problem in latest CVS. Thanks!


Mon, 11 Apr 2005 21:36:53 -0600, Rod Schmidt wrote:
>I've cut out the irrelevant  code, but here's what happen. addProfile 
>gets called from another controller which created the pure ruby object 
>profile by calling Profile.new. When addProfile gets it, it has become 
>an OCObject. Then when addProfile is called and there is more than one 
>profile to sort, then profile <=> method is called and I get the 
>following error:
>
>`<=>': failed to convert OSX::OCObject into String (TypeError)
>
>In other words the name attributes of the profile objects is not a pure 
>ruby string. So, back to my original question. How do I put a pure ruby 
>object in the @profiles array instead of the OCObject (the objective-C 
>wrapper around the ruby object)?

[Rubycocoa-talk] Thread bug analyzed

[Jonathan P. <jp...@dc...>]

Hi all,

Please let me know what the best place for reporting bugs is, if this 
mailing list isn't appropriate.

Following up from my earlier thread "Thread scheduling", I've 
identified the precise cause of the problems I've been seeing.

The fundamental problem is bad interaction with Ruby's manual thread 
switching (using setjmp/longjmp) and the mechanism used in RubyCocoa to 
deal with Objective C object ownership.

RubyCocoa manages ownership by bracketing every Cocoa invocation with 
an NSAutoreleasePool. Unfortunately, the NSAutoreleasePool stack is 
*per-NSThread*. Therefore, if a Ruby thread yields whilst an 
NSAutoreleasePool is being used, it's possible for another thread to 
get scheduled which then creates its own pool. This means that the 
object lifetimes are not what RubyCocoa expects.

The same problem exists for the per-NSThread exception handler stack, 
as outlined in my previous messages.

As I see it, this means it is never safe to use any objective c calls 
from the non-main Ruby thread.

Setting rb_thread_critical for the lifetime of each NSAutoreleasePool 
or exception context should resolve the issue, but means that 
concurrency is prevented during all Cocoa calls. I shall investigate 
how this affects the application I'm working on.

Another fix, which I have implemented out of interest, is to manually 
fiddle NSThread's exception and autorelease pool stacks when ruby 
switches threads. Unfortunately, this requires patching the ruby 
interpreter to provide the necessary hooks, and also means accessing 
some private member variables of the NSThread class.

Thanks
Jonathan

Re: [Rubycocoa-talk] Thread scheduling

[Jonathan P. <jp...@dc...>]

On 14 Apr 2005, at 16:13, kimura wataru wrote:

> RubyCocoa apps with ruby threads normarlly work fine, like  
> SimpleApp.app
> in examples. But in this case, calling NSApplication#endSheet fails.
>
> I found NSApplication#endSheet succeeded when the method was invoked  
> with
> new NSThread. I guess a sheet expects to receive "endSheet:" from other
> run-loop.

It's not the secondary run loop that's the problem, but rather  
unfortunate interactions between Ruby's thread scheduling and Cocoa's  
exception handling. Starting a new NSThread certainly solves the  
problem (since it uses a separate exception stack).

I'll try to explain:

Cocoa's exception handlers (NS_DURING etc) work by maintaining a  
per-pthread list of exception handlers. Therefore, when native code  
does:

   NS_DURING
     // some code
   NS_HANDLER
     // handler code
   NS_ENDHANDLER

what actually happens is

   if (setjmp()) {
     // add jmp_buf to exception handler list for the current pthread
     // some code
   } else {
     // handler code
   }
   remove jmp_buf from exception handler list for the current thread

The problem arises under the following circumstances (not related to  
endSheet at all):

	The main run loop calls a ruby callback, which spawns a thread.

	The secondary thread invokes an objective-c method which makes a  
callback to a ruby object.
	Ruby ruby callback runs long enough to yield back to the main thread.

		At this point, the NS_DURING exception handler for the objc method  
call (from ocm_perform) is on the exception handling stack, and if the  
main run loop handler returns (popping its exception handler) it'll  
find the wrong handler at the top of the stack. This causes a warning  
message, and then the program crashes.

The following small program demonstrates this fairly repeatedly  
(doesn't happen every time though).

The reason for this problem is that Ruby thread switching changes the  
stack, but Cocoa isn't aware of this.

#############################################################
require 'osx/cocoa'

class ExceptionTest < OSX::NSObject
     def foo
         Thread.new do
             self.performSelector_withObject(:bar,nil)
         end
     end

     def bar
         Thread.pass
     end
end

a = ExceptionTest.alloc.init
t = a.performSelector_withObject(:foo,nil)
t.join
#############################################################

The error output looks like this:
2005-04-14 17:14:35.409 ruby[15510] *** Exception handlers were not  
properly removed. Some code has jumped or returned out of an  
NS_DURING...NS_HANDLER region without using the NS_VOIDRETURN or  
NS_VALUERETURN macros.
/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_wrapper.rb:17: [BUG] Bus Error
ruby 1.8.2 (2004-12-25) [powerpc-darwin7.7.0]

Re: [Rubycocoa-talk] Thread scheduling

[kimura w. <ki...@us...>]

Thanks,

I see that you said. 

RubyCocoa apps with ruby threads normarlly work fine, like SimpleApp.app
in examples. But in this case, calling NSApplication#endSheet fails.

I found NSApplication#endSheet succeeded when the method was invoked with 
new NSThread. I guess a sheet expects to receive "endSheet:" from other 
run-loop. 

    app = OSX.NSApp
    app.beginSheet(@sheet, ...)
    Thread.start do 
      <<some procedure>>
      # send NSApplication#endSheet to new NSThread
      OSX::NSThread.detachNewThreadSelector('endSheet:',
        :toTarget, app, :withObject, @sheet)
    end

Wed, 13 Apr 2005 18:46:59 +0100, Jonathan Paisley wrote:
>On 13 Apr 2005, at 18:20, kimura wataru wrote:
>

>The problem is that the lengthy processing (in your example the 1..3  
>sleep loop) doesn't allow for any GUI events to be processed. The run  
>loop is suspended (handling our click event) until the ruby method  
>returns. I don't want the GUI to lock up like this.
>
>What I wanted to be able to do was:
>
>def buttonHandler(sender)
>   ...beginSheet(...)
>   Thread.new do
>     <<lengthy processing>>
>     ...orderOut(...)
>     ...endSheet(...)
>   end
>end
>
>This fails (sometimes) because calling the Cocoa methods (orderOut,  
>endSheet) from the non-main Ruby thread is unsafe.
>

Re: [Rubycocoa-talk] Thread scheduling

[Jonathan P. <jp...@dc...>]

On 13 Apr 2005, at 18:20, kimura wataru wrote:

> The method NSApplication#beginSheet... is asynchronous. You not need
> to create a new thread.

I understand that beginSheet... is asynchronous, but the problem is  
that I want the Cocoa GUI to continue to respond to user interaction  
(other windows, menus, etc) whilst the ruby code that's doing the  
processing is working.

Let's assume that the ruby method is called from the action of a button  
on a window. The method shows the sheet, does some lengthy processing,  
then hides the sheet.

Therefore the call hierarchy is:

   run loop waiting for events
	handling mouse click event
        passing that to button
          button invokes action on its target
            <<ruby method here, doesn't return until lengthy processing  
complete>>

The problem is that the lengthy processing (in your example the 1..3  
sleep loop) doesn't allow for any GUI events to be processed. The run  
loop is suspended (handling our click event) until the ruby method  
returns. I don't want the GUI to lock up like this.

What I wanted to be able to do was:

def buttonHandler(sender)
   ...beginSheet(...)
   Thread.new do
     <<lengthy processing>>
     ...orderOut(...)
     ...endSheet(...)
   end
end

This fails (sometimes) because calling the Cocoa methods (orderOut,  
endSheet) from the non-main Ruby thread is unsafe.

I'm sorry that I wasn't very clear in my first message. Does this  
explain the situation any better?

> NSApplication#endSheet does not close the sheet. We must call  
> "orderOut"
> of the sheet in delegate method.
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/ 
> Tasks/UsingCustomSheets.html

You're right - I had forgotten about that in my example code.

Many thanks for your help.
Jonathan

Re: [Rubycocoa-talk] Thread scheduling

[kimura w. <ki...@us...>]

Hi,

The method NSApplication#beginSheet... is asynchronous. You not need
to create a new thread.

I wrote a testing app and it works fine.

controller class:
----
class AppCtl < OSX::NSObject

  ib_outlet :window, :sheet
  
  def showSheet(sender)
    app = OSX::NSApplication.sharedApplication
    app.beginSheet(@sheet, 
      :modalForWindow, @window, 
      :modalDelegate, self,
      :didEndSelector, 'endSanmpleSheet',
      :contextInfo, nil)
    # wait...
    (1..3).each do |i|
      p i
      sleep 1
    end
    app.endSheet(@sheet)
  end
  
  def endSanmpleSheet
    @sheet.orderOut(self)
  end
  
end
----

NSApplication#endSheet does not close the sheet. We must call "orderOut" 
of the sheet in delegate method.

http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingCustomSheets.html


Tue, 12 Apr 2005 10:39:09 +0100, Jonathan Paisley wrote:
>Below are some code fragments describing (1) and (2).
>
>(1)
>
>   OSX::NSApplication.sharedApplication.beginSheet_...(@sheet,...)
>
>   done = false
>   rl = OSX::NSApplication.sharedApplication.currentRunLoop
>   t = Thread.new do
>   rl.runMode_beforeDate(OSX::NSDefaultRunLoopMode, OSX::NSDate.date) 
>until done
>   end
>
>   @doc = REXML::Document.new(big_xml_string)
>   ## code here to populate GUI from contents of @doc
>
>   done = true
>   t.join
>   OSX::NSApplication.sharedApplication.endSheet(@sheet)
>

Re: [Rubycocoa-talk] Pure ruby object from cocoa object

[kimura w. <ki...@us...>]

Thanks, 

I found a bug in RubyCocoa.

This is a ad-hock patch but you will get expected results. Patch to 
RBObject.m, in framework/src/objc, and rebuild RubyCocoa.

----
Index: framework/src/objc/RBObject.m
===================================================================
RCS file: /cvsroot/rubycocoa/src/framework/src/objc/RBObject.m,v
retrieving revision 1.2
diff -u -r1.2 RBObject.m
--- framework/src/objc/RBObject.m 12 Dec 2002 07:05:15 -0000  1.2
+++ framework/src/objc/RBObject.m 12 Apr 2005 14:58:37 -0000
@@ -286,8 +286,8 @@
 - (BOOL)isKindOfClass: (Class)klass
 { 
   BOOL ret;
-  DLOG1("isKindOfClass(%@)", klass);
-  ret = NO;
+  DLOG1("isKindOfClass(%@)", NSStringFromClass(klass));
+  ret = (klass == [RBObject class]) ? YES : NO;
   DLOG1("   --> %d", ret);
   return ret;
 }
----

Mon, 11 Apr 2005 21:36:53 -0600, Rod Schmidt wrote:
>When I try to call __rbobj__, I get a method missing error. I think 
>that is because __rbobj__ is a "C" method and is not supposed to be 
>called on a ruby object. Let me explain my problem better.
>
>First, I have a profile class like this:
>

I tested your classes. 
----
require 'osx/cocoa'

  array = OSX::NSMutableArray.alloc.init
  array.addObject(Profile.new("Taro","01-01")) # ruby object into Cocoa

  controller = ProfileTableController.alloc.init
  controller.addProfile(Profile.new("Ruby","02-24"))
  controller.addProfile(array.objectAtIndex(0)) # -- A.
----
RubyCocoa should get instance of Profile at A. but not. I found  
the function rbobj_get_ocid(), in framework/src/objc, didn't 
work correctly.

>In other words the name attributes of the profile objects is not a pure 
>ruby string. So, back to my original question. How do I put a pure ruby 
>object in the @profiles array instead of the OCObject (the objective-C 
>wrapper around the ruby object)?
>

Re: [Rubycocoa-talk] Pure ruby object from cocoa object

[kimura w. <wan...@ni...>]

Thanks, 

I found a bug in RubyCocoa.

This is a ad-hock patch but you will get expected results. Patch to 
RBObject.m, in framework/src/objc, and rebuild RubyCocoa.

----
Index: framework/src/objc/RBObject.m
===================================================================
RCS file: /cvsroot/rubycocoa/src/framework/src/objc/RBObject.m,v
retrieving revision 1.2
diff -u -r1.2 RBObject.m
--- framework/src/objc/RBObject.m 12 Dec 2002 07:05:15 -0000  1.2
+++ framework/src/objc/RBObject.m 12 Apr 2005 14:58:37 -0000
@@ -286,8 +286,8 @@
 - (BOOL)isKindOfClass: (Class)klass
 { 
   BOOL ret;
-  DLOG1("isKindOfClass(%@)", klass);
-  ret = NO;
+  DLOG1("isKindOfClass(%@)", NSStringFromClass(klass));
+  ret = (klass == [RBObject class]) ? YES : NO;
   DLOG1("   --> %d", ret);
   return ret;
 }
----

Mon, 11 Apr 2005 21:36:53 -0600, Rod Schmidt wrote:
>When I try to call __rbobj__, I get a method missing error. I think 
>that is because __rbobj__ is a "C" method and is not supposed to be 
>called on a ruby object. Let me explain my problem better.
>
>First, I have a profile class like this:
>

I tested your classes. 
----
require 'osx/cocoa'

  array = OSX::NSMutableArray.alloc.init
  array.addObject(Profile.new("Taro","01-01")) # ruby object into Cocoa

  controller = ProfileTableController.alloc.init
  controller.addProfile(Profile.new("Ruby","02-24"))
  controller.addProfile(array.objectAtIndex(0)) # -- A.
----
RubyCocoa should get instance of Profile at A. but not. I found  
the function rbobj_get_ocid(), in framework/src/objc, didn't 
work correctly.

>In other words the name attributes of the profile objects is not a pure 
>ruby string. So, back to my original question. How do I put a pure ruby 
>object in the @profiles array instead of the OCObject (the objective-C 
>wrapper around the ruby object)?
>

[Rubycocoa-talk] Thread scheduling

[Jonathan P. <jp...@dc...>]

Hi,

I've been trying to do some Ruby processing in the background (parsing 
a large XML file with REXML upon opening a document) while letting the 
Cocoa GUI still be responsive.

I've tried a number of techniques to achieve this, and was wondering if 
anybody had any comments or suggestions - particularly to do with how 
Ruby threads are expected to work in RubyCocoa.

I have a document window, and during loading I'm posting a sheet with 
an indeterminate progress bar in it. I want the progress bar to animate 
(and other windows/menus to be responsive) while doing the REXML 
parsing.

(1) I've tried calling the run loop in a loop from a Ruby thread to get 
events processed whilst REXML works on the main Ruby thread. For some 
reason I haven't figured out, no events were processed. This may be 
because I was calling the run loop from within an existing run loop 
invocation.

(2) I've tried doing the REXML processing in a Ruby thread and calling 
NSApplication endSheet.

Both of these techniques suffered from the problem of invoking Cocoa 
methods from a non-main Ruby thread. Largely things would be okay, but 
occasionally AppKit would get unhappy because the per-NSThread 
exception handler list (NS_DURING etc) becomes invalid when Ruby 
switches the C stack between its threads.

This is unfortunate, because it means we can't even call normally 
thread-safe Foundation methods because Cocoa exception handlers are 
used in RubyCocoa.

Any ideas how to get around this?

Thanks.
Jonathan

Below are some code fragments describing (1) and (2).

(1)

   OSX::NSApplication.sharedApplication.beginSheet_...(@sheet,...)

   done = false
   rl = OSX::NSApplication.sharedApplication.currentRunLoop
   t = Thread.new do
	rl.runMode_beforeDate(OSX::NSDefaultRunLoopMode, OSX::NSDate.date) 
until done
   end

   @doc = REXML::Document.new(big_xml_string)
   ## code here to populate GUI from contents of @doc

   done = true
   t.join
   OSX::NSApplication.sharedApplication.endSheet(@sheet)

(2)

   OSX::NSApplication.sharedApplication.beginSheet_...(@sheet,...)
   Thread.new do
      @doc = REXML::Document.new(big_xml_string)
      ## code here to populate GUI from contents of @doc
      OSX::NSApplication.sharedApplication.endSheet(@sheet)
   end

[Rubycocoa-talk] Bindings working with notification from Ruby

[Jonathan P. <jp...@dc...>]

Hi,

After following the instructions on the FAQ [1], with a few fiddles, I 
have got Cocoa bindings on a Ruby object to work well. Please let me 
know what you think of these modifications - if they seem ok I'll try 
to update the Wiki FAQ page.

The main thing I wanted to support was notification from Ruby to Cocoa 
upon changing a value in Ruby.

I created the NSObject+RubyCocoaBindings.[mh] and ObjcID.rb files, 
adjusting the latter slightly. I've attached the modified ObjcID.rb 
file to this message. The result is a model object like this:

   class MyModel < OSX::NSObject
     kvc_accessor :name, :title
   end

The kvc_accessor meta-method takes care of wrapping the setter (key=) 
with the Cocoa bindings notifications. If the setter is already 
defined, it will be wrapped by the kvc_accessor:

   class MyModel < OSX::NSObject
     def foo=(value)
       @foo = value
       @foo_parsed = ... # do some parsing of foo
     end

     kvc_accessor :foo # wraps foo= with notification, also defines foo 
reader method
   end

Now, in other code, if you do 'model.foo = "Something"', any GUI 
objects bound will automatically update.

Thanks
Jonathan

[1] http://rubycocoa.sourceforge.net/w.en/FAQ.html

Re: [Rubycocoa-talk] Pure ruby object from cocoa object

[Rod S. <rsc...@xm...>]

When I try to call __rbobj__, I get a method missing error. I think 
that is because __rbobj__ is a "C" method and is not supposed to be 
called on a ruby object. Let me explain my problem better.

First, I have a profile class like this:

class Profile
	include Comparable

	attr_reader :name;
	attr_reader :birthdate;

	def initialize(name, birthdate)
		@name = name;
		@birthdate = birthdate;
	end
		
	def to_s
		"Profile: #{name}, #{birthdate}"
	end
		
	def <=>(anotherProfile)
		@name <=> anotherProfile.name
	end		
end

The key here is the <=> method. Next, I have a controller that gets 
called from elsewhere:

class ProfileTableController < OSX::NSObject
	include OSX
	
	def initialize
		@profiles = []
	end
	
	def addProfile(profile)
		puts profile.class
		@profiles.push(profile)
		@profiles.sort!
	end
	
end

I've cut out the irrelevant  code, but here's what happen. addProfile 
gets called from another controller which created the pure ruby object 
profile by calling Profile.new. When addProfile gets it, it has become 
an OCObject. Then when addProfile is called and there is more than one 
profile to sort, then profile <=> method is called and I get the 
following error:

`<=>': failed to convert OSX::OCObject into String (TypeError)

In other words the name attributes of the profile objects is not a pure 
ruby string. So, back to my original question. How do I put a pure ruby 
object in the @profiles array instead of the OCObject (the objective-C 
wrapper around the ruby object)?

Thanks,

Rod Schmidt
infiniteNIL, LLC.

On Apr 8, 2005, at 9:09 AM, kimura wataru wrote:

> Hi,
>
> method "__rbobj__" returns wrapped ruby object.
>
> RubyCocoa picks up a ruby object from a Cocoa object
> when the Cocoa object is a parameter of ruby method.
> I think we do not have to convert ruby <=> Cocoa normally.
>
> If not, please tell me more detail.
>
>
>> I want my model objects to be pure ruby objects and of course the UI
>> classes (controllers, etc.) are Cocoa objects (they inherit from
>> NSObject). However whenever a controller creates a pure ruby object 
>> and
>> passes it as a parameter to a method (say to tell another controller
>> about it). The pure ruby object gets wrapped up and becomes a Cocoa
>> object. Then when I execute code that expects pure ruby objects, it
>> doesn't work. Any suggestions? Is there a way to get the pure ruby
>> object back from the wrapper?
>>
>> Thanks,
>>
>> Rod Schmidt
>> infiniteNIL, LLC.
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

Re: [Rubycocoa-talk] Pure ruby object from cocoa object

[kimura w. <ki...@us...>]

Hi,

method "__rbobj__" returns wrapped ruby object.

RubyCocoa picks up a ruby object from a Cocoa object
when the Cocoa object is a parameter of ruby method.
I think we do not have to convert ruby <=> Cocoa normally.

If not, please tell me more detail.


>I want my model objects to be pure ruby objects and of course the UI 
>classes (controllers, etc.) are Cocoa objects (they inherit from 
>NSObject). However whenever a controller creates a pure ruby object and 
>passes it as a parameter to a method (say to tell another controller 
>about it). The pure ruby object gets wrapped up and becomes a Cocoa 
>object. Then when I execute code that expects pure ruby objects, it 
>doesn't work. Any suggestions? Is there a way to get the pure ruby 
>object back from the wrapper?
>
>Thanks,
>
>Rod Schmidt
>infiniteNIL, LLC.
>

[Rubycocoa-talk] Pure ruby object from cocoa object

[Rod S. <rsc...@xm...>]

I want my model objects to be pure ruby objects and of course the UI 
classes (controllers, etc.) are Cocoa objects (they inherit from 
NSObject). However whenever a controller creates a pure ruby object and 
passes it as a parameter to a method (say to tell another controller 
about it). The pure ruby object gets wrapped up and becomes a Cocoa 
object. Then when I execute code that expects pure ruby objects, it 
doesn't work. Any suggestions? Is there a way to get the pure ruby 
object back from the wrapper?

Thanks,

Rod Schmidt
infiniteNIL, LLC.

Re: [Rubycocoa-talk] Distributing RubyCocoa Apps

[Postmaster <pos...@cj...>]

On Mar 28, 2005, at 7:10 AM, kimura wataru wrote:

> BaseSystem.pkg :
>   dynamic libraries - /usr/lib/libruby*.dylib
>
> Essentials.pkg :
>   ruby libraries - /usr/lib/ruby/*

Cool. So all you need to worry about is Apple changing the version of  
Ruby shipped with the system to one that's binary incompatible.

Chris

Re: [Rubycocoa-talk] Distributing RubyCocoa Apps

[kimura w. <ki...@us...>]

>I believe Ruby is part of the "BSD Subsystem" install, which is  
>enabled by default. I may be wrong; you might check your Mac OS X  
>install disks (Open the installer package and File > Show Files).  
>It's not part of the developer tools.
>

I checked /Library/Receipts/.../Archive.bom on Mac OS X 10.3, today.
interesting results;

BaseSystem.pkg : 
  dynamic libraries - /usr/lib/libruby*.dylib 

Essentials.pkg :
  ruby libraries - /usr/lib/ruby/* 

BSD.pkg : 
  command, manpage - /usr/bin/ruby, /usr/share/man/man1/ruby.1

BSDSDK.pkg : 
  header files - /usr/lib/ruby/1.6/powerpc-darwin7.0/*.h

Mac OS X requires BaseSystem and Essentials. So, libruby exists
on any Mac OS X 10.3. 


-- 
kimura wataru

Re: [Rubycocoa-talk] Distributing RubyCocoa Apps

[Chris T. <ch...@cj...>]

I believe Ruby is part of the "BSD Subsystem" install, which is  
enabled by default. I may be wrong; you might check your Mac OS X  
install disks (Open the installer package and File > Show Files).  
It's not part of the developer tools.

You really want to bundle libruby as well as RubyCocoa with your app  
for two reasons:

1. The version of Ruby shipped with the system will change at Apple's  
whim.
2. The BSD Subsystem install can be disabled by the user.

> Also, since an app bundle is essentially a special kind of
> folder, would the licensing be treated as though I were linking to any
> other external LGPL library such as GTK+, thus allowing my freedom of
> license on the rest of the program in the bundle(I prefer the CPL)?

There isn't an exception in the LGPL (or the GPL) for dynamic  
linking. Also, the LGPL is very permissive, so I'd be curious to know  
what about the CPL conflicts with it? The "spirit" of the LGPL is  
satisfied if the source code to the LGPL portions of your app is  
available.

Chris

On Mar 27, 2005, at 5:39 AM, Brandon Sharitt wrote:

> I'm doing some Mac programming, and Ruby is my language of choice, but
> I had a few questions regarding distribution of RubyCocoa apps. One
> thing I'm uncertain about is dependencies. I know I have Ruby
> installed now, but I don't remember if it was there before the
> developer tools were installed(and removing and reinstalling is a huge
> pain in the ass), so is ruby installed on OS X by default(even if 10.3
> and above)? Also in line with dependancies, can the RubyCocoa
> framework be bundled with the app bundle so the user can just drag,
> drop, and use(like all good OS X apps, development frameworks
> excluded)? Also, since an app bundle is essentially a special kind of
> folder, would the licensing be treated as though I were linking to any
> other external LGPL library such as GTK+, thus allowing my freedom of
> license on the rest of the program in the bundle(I prefer the CPL)?
> I'm not a member of the list so please cc any replies to me personally
> at bsh...@gm...
>
> Thank You,
> Brandon Sharitt
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real  
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>

[Rubycocoa-talk] Distributing RubyCocoa Apps

[Brandon S. <bsh...@gm...>]

I'm doing some Mac programming, and Ruby is my language of choice, but
I had a few questions regarding distribution of RubyCocoa apps. One
thing I'm uncertain about is dependencies. I know I have Ruby
installed now, but I don't remember if it was there before the
developer tools were installed(and removing and reinstalling is a huge
pain in the ass), so is ruby installed on OS X by default(even if 10.3
and above)? Also in line with dependancies, can the RubyCocoa
framework be bundled with the app bundle so the user can just drag,
drop, and use(like all good OS X apps, development frameworks
excluded)? Also, since an app bundle is essentially a special kind of
folder, would the licensing be treated as though I were linking to any
other external LGPL library such as GTK+, thus allowing my freedom of
license on the rest of the program in the bundle(I prefer the CPL)?
I'm not a member of the list so please cc any replies to me personally
at bsh...@gm...

Thank You,
Brandon Sharitt

Re: [Rubycocoa-talk] [ANN]RubyCocoa 0.4.1 was released!

[FUJIMOTO H. <hi...@fo...>]

Hi,

kimura-san, thank you very much.  RubyCocoa 0.4.1 could be
released by great effort of kimura-san who have become a rubycocoa
project member/developer.

cheers,
--
FUJIMOTO Hisa

At Sat, 26 Mar 2005 18:17:09 +0900,
kimura wataru wrote:
> 
> RubyCocoa 0.4.1 was released!
> 
>    http://rubycocoa.sourceforge.net/
>    (The web site have been moved from http://www.fobj.com/rubycocoa/)
> 
> The '.pkg' binary packages are available for Mac OS X 10.3/10.2.  
> All of framework, library, documents, samples and Xcode/ProjectBuilder 
> templates are contained in the package. These items will be installed 
> into the appropriate place. It is available to start of RubyCocoa 
> programming or use of RubyCocoa application immediately.
> 
> 
> == Changes from 0.4.0
> 
>   * enable bundling RubyCocoa.framework within an application bundle                
> 
>     Change a build configration of RubyCocoa.framework project, to 
>     execute a RubyCocoa application on the environment which is not 
>     installed RubyCocoa. It allows that RubyCocoa application itself 
>     bundles with RubyCocoa.framework.
> 
>   * Mac OS X 10.3 and Xcode supported
>                                                                                 
> 
> == What's RubyCocoa?
> 
>   RubyCocoa is a Mac OS X framework that allows Cocoa programming in
>   the Object-Oriented Scripting Language Ruby.
> 
>   RubyCocoa allows writing a Cocoa application in Ruby.  It allows
>   creating and using a Cocoa object in a Ruby script.  In Cocoa
>   application, mixture of program written by both Ruby and Objective-C
>   is possible.
> 
>   Some cases using RubyCocoa:
> 
>     * Exploration of a Cocoa object's feature with 'irb' interactively
>     * Prototyping of a Cocoa application
>     * Cocoa application that include good feature of Ruby and Objective-C
>     * Wrapping Mac OS X native GUI for Ruby script
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk