rubycocoa-talk — talking about RubyCocoa

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?

[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?

[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 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] multiple ruby libraries leads to segmentation fault

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

Hi Stephyn,

Can you tell us a little more about your current system?  Did you install RubyCocoa from source, or as a binary?  Do you play around with the source code for Ruby itself (and hence wish to have a bleeding edge installation), or are you looking simply for a stable release?

If you just want to have a stable release of ruby, I would suggest simply using the ruby that comes installed by default with Leopard.  Delete any gems, and any ruby binaries that are in your /usr/local/bin (ruby, rdoc, ri, erb, irb, and maybe others that I've forgotten).  Reinstall using your standard Leopard ruby.

That's the simplest solution for having one, and only one, ruby installation on your computer that can do everything.  If you want to do something special, you're going to have to I think (and maybe someone else can confirm this), you're going to have to modify the source code of RubyCocoa.  As it stands, it seems to me that RubyCocoa compiles explicitly against the standard ruby installed with Leopard, and you will probably have to make changes to the source code to change that.

Hope that helps.

Alli
  
On Saturday, June 14, 2008, at 01:39AM, "Stephyn Butcher" <ste...@co...> wrote:
>I apologize if this has been covered. I tried to go through the  
>archives up until the release of Leopard but I didn't see anything  
>that that specifically addressed this issue.
>
>I was running a simple code example from a book:
>
>require 'osx/cocoa'
>
>include OSX
>
>class AppDelegate < NSObject
>	def applicationDidFinishLaunching( aNotification)
>		puts "#{aNotification.name} makes me say: Hello, world!"
>	end
>end
>NSApplication.sharedApplication
>NSApp.setDelegate( AppDelegate.alloc.init)
>NSApp.run
>
>and because I've quite successfully run RubyCocoa apps, I was quite  
>surprised to see the following error:
>
>$ ruby basic.rb
>2008-06-13 19:24:05.049 ruby[38469:10b] WARNING: multiple  
>libruby.dylib found: '/usr/local/lib/libruby.dylib' and '/System/ 
>Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib'
>2008-06-13 19:24:05.055 ruby[38469:10b]  
>RBCocoaInstallRubyThreadSchedulerHooks: warning:  
>rb_set_cocoa_thread_hooks is linked from a different library (/System/ 
>Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby. 
>1.dylib) than ruby_init (/usr/local/lib/libruby.dylib)
>Segmentation fault
>$
>
>now if I run using the ruby that exists in /System/Library/Frameworks/ 
>Ruby.framework/Versions/1.8/usr/bin/, I get:
>
>$ /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby  
>basic.rb
>NSApplicationDidFinishLaunchingNotification makes me say: Hello, world!
>
>which is the expected behavior.
>
>The basic question is, is there a way to fix this without running two  
>versions of ruby? And by fix, this means having all of my installed  
>gems accessible, being able to do just regular command line ruby, is  
>the /System/Library/.../bin/ruby free of the problem that the version  
>in Tiger had (which I even forget what it was...something about mySQL  
>comes to mind)? Is there any reason to keep up two parallel  
>installations of ruby 1.8.6 and what are the ramifications of picking  
>one installation over the other?
>
>Or is the result of not having compiled with the shared library  
>option? (Sorry, I came to programming in the Java Age, if configure,  
>make, make install doesn't do it, I'm completely lost).
>
>Any help would be appreciated.
>
>-------------------------------------------------------------------------
>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
>
>

[Rubycocoa-talk] multiple ruby libraries leads to segmentation fault

[Stephyn B. <ste...@co...>]

I apologize if this has been covered. I tried to go through the  
archives up until the release of Leopard but I didn't see anything  
that that specifically addressed this issue.

I was running a simple code example from a book:

require 'osx/cocoa'

include OSX

class AppDelegate < NSObject
	def applicationDidFinishLaunching( aNotification)
		puts "#{aNotification.name} makes me say: Hello, world!"
	end
end
NSApplication.sharedApplication
NSApp.setDelegate( AppDelegate.alloc.init)
NSApp.run

and because I've quite successfully run RubyCocoa apps, I was quite  
surprised to see the following error:

$ ruby basic.rb
2008-06-13 19:24:05.049 ruby[38469:10b] WARNING: multiple  
libruby.dylib found: '/usr/local/lib/libruby.dylib' and '/System/ 
Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib'
2008-06-13 19:24:05.055 ruby[38469:10b]  
RBCocoaInstallRubyThreadSchedulerHooks: warning:  
rb_set_cocoa_thread_hooks is linked from a different library (/System/ 
Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby. 
1.dylib) than ruby_init (/usr/local/lib/libruby.dylib)
Segmentation fault
$

now if I run using the ruby that exists in /System/Library/Frameworks/ 
Ruby.framework/Versions/1.8/usr/bin/, I get:

$ /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby  
basic.rb
NSApplicationDidFinishLaunchingNotification makes me say: Hello, world!

which is the expected behavior.

The basic question is, is there a way to fix this without running two  
versions of ruby? And by fix, this means having all of my installed  
gems accessible, being able to do just regular command line ruby, is  
the /System/Library/.../bin/ruby free of the problem that the version  
in Tiger had (which I even forget what it was...something about mySQL  
comes to mind)? Is there any reason to keep up two parallel  
installations of ruby 1.8.6 and what are the ramifications of picking  
one installation over the other?

Or is the result of not having compiled with the shared library  
option? (Sorry, I came to programming in the Java Age, if configure,  
make, make install doesn't do it, I'm completely lost).

Any help would be appreciated.

[Rubycocoa-talk] rubycocoa_bundleForClass doesn't like being called on background threads, causes QTKit crashes

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

While recording using QTCaptureMovieFileOutput, QTKit calls +[NSBundle
bundleForClass:] on a background thread.

RubyCocoa patches +[NSBundle bundleForClass:] in mdl_bundle_support.m.
 For reasons I have yet to figure out, when called on a background
thread, this eventually causes your app to die a horrible death with
"stack level too deep (SystemStackError)", and a badly smashed stack.
Maybe it's just a ruby threading problem - I can't see any way that
RubyCocoa would descend into calling ruby code from within the
rubycocoa_bundleForClass method.

A sample project demonstrating this can be found here -
http://steelskies.com/QTKitTests.zip - it simply kicks off a
background thread, then repeatedly calls bundleForClass:.  If your
experience is anything like mine, it ought to crash after around 10
seconds.

If anyone has a workaround (short of just compiling my own RubyCocoa
that doesn't patch bundleForClass:), I'd love to hear it.

-Jonathan

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

[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] Threads, NSTimers and rspec

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

Ha! Yup, thanks Eloy, that fixed it.  I thought it must be something like that :-)

Alli
 
On Thursday, June 12, 2008, at 01:49PM, "Eloy Duran" <elo...@gm...> wrote:
>Hi Alli,
>
>The cause might be that there's no runloop.
>In all my RC tests I do the following in a test helper:
>
>Thread.new { OSX.CFRunLoopRun }
>
>(See http://github.com/alloy/webapp-app/tree/webapp-app/WebAppApplication/test/test_helper.rb 
>  for an example.)
>
>Eloy
>
>On Jun 12, 2008, at 1:39 PM, Allison Newman wrote:
>
>> Hi everyone,
>>
>> I'm trying to write a unit test at the moment that uses rspec, and  
>> I'm having some problems.
>>
>> In my app I have an NSTimer that fires every second after I call a  
>> start method on my controller.  The callback function of the timer  
>> updates some values on the screen.  It works like a charm in the  
>> real app.
>>
>> In my unitary tests, I try to call the same 'start' method, and then  
>> sleep the test thread for x seconds, at the end of which I try to  
>> verify that a counter has been incremented in my controller 5  
>> times.  The problem is that the timer callback is never called, so  
>> the counter is never updated.
>>
>> I'm guessing that this has something to do with run loops in Cocoa,  
>> and specifically that I never actually set up a Cocoa runtime in my  
>> rspec test.  Can anyone confirm this?  Does anyone have a nice  
>> elegant way of doing this sort of test?
>>
>> If not, I guess I can always manually call the timer callback  
>> manually in the test, to simulate a timer.  Trouble is, that means  
>> that I'm not actually testing the timer functionality itself, which  
>> is nevertheless an important part of my app.
>>
>> Any ideas?
>>
>> Alli
>>
>> -------------------------------------------------------------------------
>> 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
>
>
>-------------------------------------------------------------------------
>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] Threads, NSTimers and rspec

[Eloy D. <elo...@gm...>]

Hi Alli,

The cause might be that there's no runloop.
In all my RC tests I do the following in a test helper:

Thread.new { OSX.CFRunLoopRun }

(See http://github.com/alloy/webapp-app/tree/webapp-app/WebAppApplication/test/test_helper.rb 
  for an example.)

Eloy

On Jun 12, 2008, at 1:39 PM, Allison Newman wrote:

> Hi everyone,
>
> I'm trying to write a unit test at the moment that uses rspec, and  
> I'm having some problems.
>
> In my app I have an NSTimer that fires every second after I call a  
> start method on my controller.  The callback function of the timer  
> updates some values on the screen.  It works like a charm in the  
> real app.
>
> In my unitary tests, I try to call the same 'start' method, and then  
> sleep the test thread for x seconds, at the end of which I try to  
> verify that a counter has been incremented in my controller 5  
> times.  The problem is that the timer callback is never called, so  
> the counter is never updated.
>
> I'm guessing that this has something to do with run loops in Cocoa,  
> and specifically that I never actually set up a Cocoa runtime in my  
> rspec test.  Can anyone confirm this?  Does anyone have a nice  
> elegant way of doing this sort of test?
>
> If not, I guess I can always manually call the timer callback  
> manually in the test, to simulate a timer.  Trouble is, that means  
> that I'm not actually testing the timer functionality itself, which  
> is nevertheless an important part of my app.
>
> Any ideas?
>
> Alli
>
> -------------------------------------------------------------------------
> 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

[Rubycocoa-talk] Threads, NSTimers and rspec

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

Hi everyone,

I'm trying to write a unit test at the moment that uses rspec, and I'm having some problems.

In my app I have an NSTimer that fires every second after I call a start method on my controller.  The callback function of the timer updates some values on the screen.  It works like a charm in the real app.

In my unitary tests, I try to call the same 'start' method, and then sleep the test thread for x seconds, at the end of which I try to verify that a counter has been incremented in my controller 5 times.  The problem is that the timer callback is never called, so the counter is never updated.  

I'm guessing that this has something to do with run loops in Cocoa, and specifically that I never actually set up a Cocoa runtime in my rspec test.  Can anyone confirm this?  Does anyone have a nice elegant way of doing this sort of test?

If not, I guess I can always manually call the timer callback manually in the test, to simulate a timer.  Trouble is, that means that I'm not actually testing the timer functionality itself, which is nevertheless an important part of my app.

Any ideas?

Alli

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

[Craig W. <cwi...@ma...>]

On Jun 11, 2008, at 9:19 AM, Eloy Duran wrote:

> Could you paste the source code it creates in rb_main.rb ?
> I think the problem lies there.
>
> I'll be gone for a few hours though, so I won't be able to respond
> quickly.
>
> Eloy

Here it is. Also, the RubyCocoa.framework is in the Frameworks folder
of the bundle.

Craig


################################################################################
# standaloneify.rb patch
################################################################################
# Remove all entries that aren't in the application bundle

COCOA_APP_RESOURCES_DIR = File.dirname(__FILE__)

$LOAD_PATH.reject! { |d|  
d.index(File.dirname(COCOA_APP_RESOURCES_DIR))!=0 }
$LOAD_PATH << File.join(COCOA_APP_RESOURCES_DIR,"ThirdParty")
$LOAD_PATH << File.join(File.dirname(COCOA_APP_RESOURCES_DIR),"lib")

$LOADED_FEATURES << "rubycocoa.bundle"

ENV['GEM_HOME'] = ENV['GEM_PATH'] =  
File.join(COCOA_APP_RESOURCES_DIR,"RubyGems")

################################################################################
#
#  rb_main.rb
#  ScriptWindow
#
#  Created by Craig Williams on 5/30/08.
#  Copyright (c) 2008 __MyCompanyName__. All rights reserved.
#

require 'osx/cocoa'
include OSX

def rb_main_init
   path = OSX::NSBundle.mainBundle.resourcePath.fileSystemRepresentation
   rbfiles = Dir.entries(path).select {|x| /\.rb\z/ =~ x}
   rbfiles -= [ File.basename(__FILE__) ]
   rbfiles.each do |path|
     require( File.basename(path) )
   end
end

if $0 == __FILE__ then
   rb_main_init
   OSX.NSApplicationMain(0, nil)
end

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

[Craig W. <cwi...@ma...>]

Also, the build from standaloneify says it is skipping these files.

Skipping RubyCocoa file "osx/objc/oc_exception.rb"
Skipping RubyCocoa file "osx/objc/oc_wrapper.rb"
Skipping RubyCocoa file "osx/objc/oc_import.rb"
Skipping RubyCocoa file "osx/objc/oc_types.rb"
Skipping RubyCocoa file "osx/objc/oc_attachments.rb"
Skipping RubyCocoa file "osx/objc/ruby_addition.rb"
Skipping RubyCocoa file "osx/objc/oc_bundle_support.rb"
Skipping RubyCocoa file "osx/objc/oc_all.rb"
Skipping RubyCocoa file "osx/objc/cocoa_macros.rb"
Skipping RubyCocoa file "osx/objc/foundation.rb"
Skipping RubyCocoa file "osx/objc/oc_types_appkit.rb"
Skipping RubyCocoa file "osx/objc/oc_attachments_appkit.rb"
Skipping RubyCocoa file "osx/objc/cocoa.rb"
Skipping RubyCocoa file "osx/cocoa.rb"

Craig

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

[Eloy D. <elo...@gm...>]

Could you paste the source code it creates in rb_main.rb ?
I think the problem lies there.

I'll be gone for a few hours though, so I won't be able to respond  
quickly.

Eloy

On 11 jun 2008, at 17:11, Craig Williams wrote:

>
> On Jun 11, 2008, at 8:52 AM, Allison Newman wrote:
>
>> Either that, or Craig mistyped the name.  There's an  'e' in
>> standaloneify...
>
> Yea, that was it. I still needed the full path though. Too little
> sleep lately.
>
> I ran the standaloneify on the app and when opening on the other  
> machine
> (also running Leopard 10.5.3) it says no file found for 'osx/cocoa'
>
> Craig
>
> -------------------------------------------------------------------------
> 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] Sharing RubyCocoa Apps

[Craig W. <cwi...@ma...>]

On Jun 11, 2008, at 8:52 AM, Allison Newman wrote:

> Either that, or Craig mistyped the name.  There's an  'e' in  
> standaloneify...

Yea, that was it. I still needed the full path though. Too little  
sleep lately.

I ran the standaloneify on the app and when opening on the other machine
(also running Leopard 10.5.3) it says no file found for 'osx/cocoa'

Craig

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

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

Yup, but if the Tiger binary install acts like the Leopard  binary install, it copies it directly into your Frameworks folder - and as I'm quite happy with my WORKING installation at the moment, I'm not too eager to do that, thank you very much! :-)

Anyway, I really do have to get around to downloading the source.  It will help me answer some questions without having to ask the list :-)


On Wednesday, June 11, 2008, at 04:54PM, "Eloy Duran" <elo...@gm...> wrote:
>No unfortunately this isn't possible.... :(
>You have to create a 10.4 and a 10.5 app bundle.
>
>But you don't need to compile to test this as both versions are  
>available from:
>http://sourceforge.net/project/showfiles.php?group_id=44114
>
>Eloy
>
>On 11 jun 2008, at 16:48, Allison Newman wrote:
>
>> There's one thing I don't understand about standaloneifying an app.   
>> On the EmbedRubyCocoa page, it explains that you tell the XCode  
>> project to copy the framework files when building the project, and  
>> then you drag in a RubyCocoa.framework into the new copy files group.
>>
>> OK, so far so good.  I'm on Leopard, and I just upgraded to  
>> RubyCocoa 0.13.2.  If I want to make sure that other Leopard users  
>> can run my app, using the version of RubyCocoa that I have tested,  
>> this function is great.
>>
>> But what happens if I give this standalone app to a Tiger user?  If  
>> I've understood correctly, it won't work.  Is that true?  And what  
>> happens if I try to use the Tiger version of the framework on  
>> Leopard?  I'd do the experiment myself, but I haven't ever compiled  
>> RubyCocoa from source, so I don't have the Tiger version readily  
>> available to me, and I can't afford the time to set the system up  
>> just to do this test.
>>
>> If this doesn't work, has anyone come up with an elegant method of  
>> making a standalone app that is easy to deploy on both Tiger and  
>> Leopard?
>>
>> Alli
>>
>>
>> On Wednesday, June 11, 2008, at 03:29PM, "Eloy Duran" <elo...@gm... 
>> > wrote:
>>> Hey Craig,
>>>
>>> Like someone else already pointed out, you'll need to use  
>>> standaloneify
>>> if you want to package libraries with your app. Like for instance the
>>> sqlite gem.
>>> http://rubycocoa.sourceforge.net/EmbedRubyCocoa
>>>
>>> Cheers,
>>> Eloy
>>>
>>> On 11 jun 2008, at 15:23, Craig Williams wrote:
>>>
>>>> Thanks everyone. The gems is the issue.
>>>>
>>>> Can you point me to some docs on how to remove them and use
>>>> the standard ruby libs?
>>>>
>>>> Craig
>>>>
>>>> -------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> 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
>
>
>-------------------------------------------------------------------------
>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] Sharing RubyCocoa Apps

[Eloy D. <elo...@gm...>]

Hehehe, yeah that's also true. But the Tools dir isn't in the load  
path by default.

On 11 jun 2008, at 16:52, Allison Newman wrote:

> Either that, or Craig mistyped the name.  There's an  'e' in  
> standaloneify...
>
>
> On Wednesday, June 11, 2008, at 04:46PM, "Eloy Duran" <elo...@gm... 
> > wrote:
>>> ruby standalonify.rb -d ScriptWindow_.app ScriptWindow.app
>>> ruby: No such file or directory -- standalonify.rb (LoadError)
>>>
>>> I am in the directory where the app resides before running above  
>>> code.
>>
>> The problem is that standaloneify.rb is not in your load path so you
>> need to specify the full path:
>> $ ruby /System/Library/Frameworks/RubyCocoa.framework/Versions/ 
>> Current/
>> Tools/standalonify.rb -d ScriptWindow_.app ScriptWindow.app
>>
>> Eloy
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
> -------------------------------------------------------------------------
> 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] Sharing RubyCocoa Apps

[Eloy D. <elo...@gm...>]

No unfortunately this isn't possible.... :(
You have to create a 10.4 and a 10.5 app bundle.

But you don't need to compile to test this as both versions are  
available from:
http://sourceforge.net/project/showfiles.php?group_id=44114

Eloy

On 11 jun 2008, at 16:48, Allison Newman wrote:

> There's one thing I don't understand about standaloneifying an app.   
> On the EmbedRubyCocoa page, it explains that you tell the XCode  
> project to copy the framework files when building the project, and  
> then you drag in a RubyCocoa.framework into the new copy files group.
>
> OK, so far so good.  I'm on Leopard, and I just upgraded to  
> RubyCocoa 0.13.2.  If I want to make sure that other Leopard users  
> can run my app, using the version of RubyCocoa that I have tested,  
> this function is great.
>
> But what happens if I give this standalone app to a Tiger user?  If  
> I've understood correctly, it won't work.  Is that true?  And what  
> happens if I try to use the Tiger version of the framework on  
> Leopard?  I'd do the experiment myself, but I haven't ever compiled  
> RubyCocoa from source, so I don't have the Tiger version readily  
> available to me, and I can't afford the time to set the system up  
> just to do this test.
>
> If this doesn't work, has anyone come up with an elegant method of  
> making a standalone app that is easy to deploy on both Tiger and  
> Leopard?
>
> Alli
>
>
> On Wednesday, June 11, 2008, at 03:29PM, "Eloy Duran" <elo...@gm... 
> > wrote:
>> Hey Craig,
>>
>> Like someone else already pointed out, you'll need to use  
>> standaloneify
>> if you want to package libraries with your app. Like for instance the
>> sqlite gem.
>> http://rubycocoa.sourceforge.net/EmbedRubyCocoa
>>
>> Cheers,
>> Eloy
>>
>> On 11 jun 2008, at 15:23, Craig Williams wrote:
>>
>>> Thanks everyone. The gems is the issue.
>>>
>>> Can you point me to some docs on how to remove them and use
>>> the standard ruby libs?
>>>
>>> Craig
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
> -------------------------------------------------------------------------
> 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] Sharing RubyCocoa Apps

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

Either that, or Craig mistyped the name.  There's an  'e' in standaloneify...


On Wednesday, June 11, 2008, at 04:46PM, "Eloy Duran" <elo...@gm...> wrote:
>> ruby standalonify.rb -d ScriptWindow_.app ScriptWindow.app
>> ruby: No such file or directory -- standalonify.rb (LoadError)
>>
>> I am in the directory where the app resides before running above code.
>
>The problem is that standaloneify.rb is not in your load path so you  
>need to specify the full path:
>$ ruby /System/Library/Frameworks/RubyCocoa.framework/Versions/Current/ 
>Tools/standalonify.rb -d ScriptWindow_.app ScriptWindow.app
>
>Eloy
>
>-------------------------------------------------------------------------
>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] Sharing RubyCocoa Apps

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

There's one thing I don't understand about standaloneifying an app.  On the EmbedRubyCocoa page, it explains that you tell the XCode project to copy the framework files when building the project, and then you drag in a RubyCocoa.framework into the new copy files group.

OK, so far so good.  I'm on Leopard, and I just upgraded to RubyCocoa 0.13.2.  If I want to make sure that other Leopard users can run my app, using the version of RubyCocoa that I have tested, this function is great.

But what happens if I give this standalone app to a Tiger user?  If I've understood correctly, it won't work.  Is that true?  And what happens if I try to use the Tiger version of the framework on Leopard?  I'd do the experiment myself, but I haven't ever compiled RubyCocoa from source, so I don't have the Tiger version readily available to me, and I can't afford the time to set the system up just to do this test.

If this doesn't work, has anyone come up with an elegant method of making a standalone app that is easy to deploy on both Tiger and Leopard?

Alli

 
On Wednesday, June 11, 2008, at 03:29PM, "Eloy Duran" <elo...@gm...> wrote:
>Hey Craig,
>
>Like someone else already pointed out, you'll need to use standaloneify
>if you want to package libraries with your app. Like for instance the  
>sqlite gem.
>http://rubycocoa.sourceforge.net/EmbedRubyCocoa
>
>Cheers,
>Eloy
>
>On 11 jun 2008, at 15:23, Craig Williams wrote:
>
>> Thanks everyone. The gems is the issue.
>>
>> Can you point me to some docs on how to remove them and use
>> the standard ruby libs?
>>
>> Craig
>>
>> -------------------------------------------------------------------------
>> 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
>
>
>-------------------------------------------------------------------------
>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] Sharing RubyCocoa Apps

[Eloy D. <elo...@gm...>]

> ruby standalonify.rb -d ScriptWindow_.app ScriptWindow.app
> ruby: No such file or directory -- standalonify.rb (LoadError)
>
> I am in the directory where the app resides before running above code.

The problem is that standaloneify.rb is not in your load path so you  
need to specify the full path:
$ ruby /System/Library/Frameworks/RubyCocoa.framework/Versions/Current/ 
Tools/standalonify.rb -d ScriptWindow_.app ScriptWindow.app

Eloy

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

[Craig W. <cwi...@ma...>]

On Jun 11, 2008, at 8:22 AM, Allison Newman wrote:

> Craig,
>
> I think you may have misunderstood me, or perhaps misunderstood what  
> a gem actually is.  Anyway, I'll try to clarify.  My current app  
> doesn't use gems, because I don't have need of any of the  
> functionality that gems give.  If I've understood you correctly, you  
> wish to use sqlite, and hence need a gem to do this.
>
> In the Ruby world, gems are libraries that are installed into a  
> specific folder on your computer, using the gem command line tool.   
> This folder is NOT inside your application - it is globally  
> accessible by all Ruby apps on your computer.  Unfortunately for  
> you, if you use the gem in your app, your app will no longer work on  
> another computer that does not have the gem installed.
>
> Fortunately for you, the gurus that created RubyCocoa have created a  
> tool called standaloneify.rb that Eloy keeps talking about.  This  
> tool goes your code, identifies all libraries that your app depends  
> on, and copies them into the Resources folder of a new, standalone,  
> version of your app.  It really is very simple to use - using  
> Terminal, simply cd to the folder containing your app, and run the  
> command:
>
> ruby standalonify.rb -d MyStandaloneProg.app MyBuiltinProg.app
>
> changing the names for your original app, and it's standalone  
> version, evidently.
>
> The link that Eloy gave you explains all of this pretty clearly (or  
> at least I personally find it very clear, your mileage may  
> vary :-) ).  I think it really is going to be the simplest solution  
> for you.
>
> Hope that helps.
>
> Alli
>


That helps alot! Thank you both for the explanation.

I have standalonify.rb exactly where Eloy point to but when I run the  
code above I get the following error:

ruby standalonify.rb -d ScriptWindow_.app ScriptWindow.app
ruby: No such file or directory -- standalonify.rb (LoadError)

I am in the directory where the app resides before running above code.

Craig

Re: [Rubycocoa-talk] Sharing RubyCocoa Apps

[Eloy D. <elo...@gm...>]

Alli, thanks for the more elaborate email :)

Eloy

On 11 jun 2008, at 16:22, Allison Newman wrote:

> Craig,
>
> I think you may have misunderstood me, or perhaps misunderstood what  
> a gem actually is.  Anyway, I'll try to clarify.  My current app  
> doesn't use gems, because I don't have need of any of the  
> functionality that gems give.  If I've understood you correctly, you  
> wish to use sqlite, and hence need a gem to do this.
>
> In the Ruby world, gems are libraries that are installed into a  
> specific folder on your computer, using the gem command line tool.   
> This folder is NOT inside your application - it is globally  
> accessible by all Ruby apps on your computer.  Unfortunately for  
> you, if you use the gem in your app, your app will no longer work on  
> another computer that does not have the gem installed.
>
> Fortunately for you, the gurus that created RubyCocoa have created a  
> tool called standaloneify.rb that Eloy keeps talking about.  This  
> tool goes your code, identifies all libraries that your app depends  
> on, and copies them into the Resources folder of a new, standalone,  
> version of your app.  It really is very simple to use - using  
> Terminal, simply cd to the folder containing your app, and run the  
> command:
>
> ruby standalonify.rb -d MyStandaloneProg.app MyBuiltinProg.app
>
> changing the names for your original app, and it's standalone  
> version, evidently.
>
> The link that Eloy gave you explains all of this pretty clearly (or  
> at least I personally find it very clear, your mileage may  
> vary :-) ).  I think it really is going to be the simplest solution  
> for you.
>
> Hope that helps.
>
> Alli
>
>
> On Wednesday, June 11, 2008, at 04:09PM, "Craig Williams" <cwi...@ma... 
> > wrote:
>>
>> On Jun 11, 2008, at 7:29 AM, Eloy Duran wrote:
>>
>>> Hey Craig,
>>>
>>> Like someone else already pointed out, you'll need to use
>>> standaloneify
>>> if you want to package libraries with your app. Like for instance  
>>> the
>>> sqlite gem.
>>> http://rubycocoa.sourceforge.net/EmbedRubyCocoa
>>>
>>> Cheers,
>>> Eloy
>>
>>
>> Hi Eloy,
>>
>> I am going through the Sparkle tutorial right now. What I was wanting
>> to do
>> is *remove* the gems from my computer and install the standard way  
>> like
>> Alli is doing so that I do not have to package the gems.
>>
>> From what everyone is saying this appears to be the preferable way.
>>
>> I have searched for standaloneify on my computer and have not located
>> it.
>> I do not have a Tools folder.
>>
>> Forgive my ignorance in all this. I just started learning Ruby two
>> weeks ago.
>> I am coming from AppleScript where very little *core operating  
>> system*
>> knowledge is required.
>>
>> I can tell you that programming in Ruby is more fun than AppleScript
>> and a lot less wordy.
>>
>> Anyway, thanks again for all the help. Once I get going my questions
>> will
>> become less *junior*:)
>>
>> Cheers,
>>
>> Craig
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
> -------------------------------------------------------------------------
> 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] Sharing RubyCocoa Apps

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

Craig,

I think you may have misunderstood me, or perhaps misunderstood what a gem actually is.  Anyway, I'll try to clarify.  My current app doesn't use gems, because I don't have need of any of the functionality that gems give.  If I've understood you correctly, you wish to use sqlite, and hence need a gem to do this.

In the Ruby world, gems are libraries that are installed into a specific folder on your computer, using the gem command line tool.  This folder is NOT inside your application - it is globally accessible by all Ruby apps on your computer.  Unfortunately for you, if you use the gem in your app, your app will no longer work on another computer that does not have the gem installed. 

Fortunately for you, the gurus that created RubyCocoa have created a tool called standaloneify.rb that Eloy keeps talking about.  This tool goes your code, identifies all libraries that your app depends on, and copies them into the Resources folder of a new, standalone, version of your app.  It really is very simple to use - using Terminal, simply cd to the folder containing your app, and run the command:

ruby standalonify.rb -d MyStandaloneProg.app MyBuiltinProg.app

changing the names for your original app, and it's standalone version, evidently.

The link that Eloy gave you explains all of this pretty clearly (or at least I personally find it very clear, your mileage may vary :-) ).  I think it really is going to be the simplest solution for you.

Hope that helps.

Alli


On Wednesday, June 11, 2008, at 04:09PM, "Craig Williams" <cwi...@ma...> wrote:
>
>On Jun 11, 2008, at 7:29 AM, Eloy Duran wrote:
>
>> Hey Craig,
>>
>> Like someone else already pointed out, you'll need to use  
>> standaloneify
>> if you want to package libraries with your app. Like for instance the
>> sqlite gem.
>> http://rubycocoa.sourceforge.net/EmbedRubyCocoa
>>
>> Cheers,
>> Eloy
>
>
>Hi Eloy,
>
>I am going through the Sparkle tutorial right now. What I was wanting  
>to do
>is *remove* the gems from my computer and install the standard way like
>Alli is doing so that I do not have to package the gems.
>
> From what everyone is saying this appears to be the preferable way.
>
>I have searched for standaloneify on my computer and have not located  
>it.
>I do not have a Tools folder.
>
>Forgive my ignorance in all this. I just started learning Ruby two  
>weeks ago.
>I am coming from AppleScript where very little *core operating system*
>knowledge is required.
>
>I can tell you that programming in Ruby is more fun than AppleScript
>and a lot less wordy.
>
>Anyway, thanks again for all the help. Once I get going my questions  
>will
>become less *junior*:)
>
>Cheers,
>
>Craig
>
>
>-------------------------------------------------------------------------
>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
>
>