rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Best practice for Threads

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

Yup. It depends of course on what you're doing, for typical Cocoa  
development trunk has been quite stable. We have been developing a  
Cocoa app on it the last few months.

HTH,
Eloy

On 26 apr 2010, at 13:49, Naughty Nimitz wrote:

> Are you sure? I had the impression that MacRuby is not production  
> ready yet.
>
> 2010/4/25 Eloy Duran <elo...@gm...>
> You'd be better of using MacRuby for threading, regular ruby threads  
> are posix threads there.
>
> Eloy
>
> Sent from my iPad
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Best practice for Threads

[Naughty N. <nau...@gm...>]

Are you sure? I had the impression that MacRuby is not production ready yet.

2010/4/25 Eloy Duran <elo...@gm...>

> You'd be better of using MacRuby for threading, regular ruby threads are
> posix threads there.
>
> Eloy
>
> Sent from my iPad
>
>

Re: [Rubycocoa-talk] Best practice for Threads

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

You'd be better of using MacRuby for threading, regular ruby threads are posix threads there.

Eloy

Sent from my iPad

On 25 apr. 2010, at 02:30, Stefan Bracke <st...@gi...> wrote:

> Anyone have any pointers in how to work best with threads?
> 
> My problem in particular is that I want to do other stuff while rubycocoa-application (together with appscript) controls another application. 
> 
> NSThreads? Emulated threads (whatever that may be, as long as it does not involve NSTimer tricks...)
> 
> Stef
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] Best practice for Threads

[Stefan B. <st...@gi...>]

Anyone have any pointers in how to work best with threads?

My problem in particular is that I want to do other stuff while rubycocoa-application (together with appscript) controls another application. 

NSThreads? Emulated threads (whatever that may be, as long as it does not involve NSTimer tricks...)

Stef

[Rubycocoa-talk] Xcode 3.2.1 , Rubycocoa and Activerecord

[Naughty N. <nau...@gm...>]

Ok, so i solved the connection error  (due to incorrect default
architecture)... but still it's impossible to work with a ActiveRecord::Base
record-class.

I 'require' the database object. No luck.
I define the class inside the main class itself. Does not work of course.

Everytime i get this error (after connecting successfully to the db) after
get all records using simple requests like
@task = Task.find(:all)

TypeError: can't dup NilClass

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/base.rb:2184:in
`dup'

Anyone have any ideas? Strange this is, this works fine in irb, but not in a
compiled rubycocoa app...

How do YOU use Activerecord calls in your Rubycocoa application?


-- 
This signature is patented.

[Rubycocoa-talk] Xcode 3.2.1 , Rubycocoa and Activerecord

[Naughty N. <nau...@gm...>]

Aha! I think i found it!

First a small info: before getting to work, i had to install MySQL 64-bit
version for MacOS X on my Snow Leopard machine, because i was not able to
run rails otherwise.

Console: When you use irb it probably automatically switches to 64-bit
modus.

Xcode: And the Xcode project *architecture* is automatically set to "Native
Architecture of building machine"  (which is 32bit because you don't
autoboot in 64bit in Snow Leopard), so i forced it to 64bit.

It seems to work.


-- 
This signature is patented.

Re: [Rubycocoa-talk] Xcode 3.2.1 , Rubycocoa and Activerecord

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

 My first guess would be that you are running off two different rubies in RubyCocoa and irb...

Try doing a simple 'puts RUBY_VERSION' in both environments, and see if you're getting different answers....

If that doesn't get you started on fixing the problem, you might try producing a simple XCode project that reproduces the problem and posting it here, so that we can play with it...

Alli


On Wednesday, April 07, 2010, at 04:35PM, "Naughty Nimitz" <nau...@gm...> wrote:
>------------------------------------------------------------------------------
>Download Intel&#174; Parallel Studio Eval
>Try the new software tools for yourself. Speed compiling, find bugs
>proactively, and fine-tune applications for parallel performance.
>See why Intel Parallel Studio got high marks during beta.
>http://p.sf.net/sfu/intel-sw-dev
>_______________________________________________
>Rubycocoa-talk mailing list
>Rub...@li...
>https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>

[Rubycocoa-talk] Xcode 3.2.1 , Rubycocoa and Activerecord

[Naughty N. <nau...@gm...>]

Strange thing happening here:

Created a new class in a Ruby Cocoa app which connects to mysqlserver and
reads a table.

Works excellent in irb , but fails miserably in compiled Rubycocoa app after
I establish connection with mysqlserver.

Problem starts the moment I ask for data. As simple as fetching the avaiable
tables (using Base.connection.tables) results in a strange error...

uninitialized constant MysqlCompat::MysqlRes

And asking a set of data (@rows = Tasks.find(:all)  ) results in a nilclass
error.

(Although Task is defined as a valid activerecord class, otherwise it
wouldn't work in irb!)

Any ideas anyone?

-- 
This signature is patented.

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Eric C. <ech...@gm...>]

On Sun, Mar 21, 2010 at 4:01 PM, Wolfgang Kittenberger
<kit...@ka...> wrote:
> Hi Eric,
>   The answer to your question I found the book "Programming Cocoa with Ruby"
> (Brian Marik) on the pages 98ff:
> A method super_foo calls the method foo in the first Objective-C ancestor
> class.
> The pseudomethod super calls the first Ruby ancestor.
[...]
> myMini-2:rubycocoa-oddities kittekat$ ruby super-and-super.rb
> super_description says: <RubyFromRuby: 0x1018f8ba0>
> but super says: Some kind of RubyFromObjC
> The super_description comes from NSObject#description.
> myMini-2:rubycocoa-oddities kittekat$
> Regards
> Wolfgang

Thanks!

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Wolfgang K. <kit...@ka...>]

Hi Eric,

  The answer to your question I found the book "Programming Cocoa with Ruby" (Brian Marik) on the pages 98ff:

A method super_foo calls the method foo in the first Objective-C ancestor class.
The pseudomethod super calls the first Ruby ancestor.

myMini-2:rubycocoa-oddities kittekat$ more super-and-super.rb 
#---
# Excerpted from "RubyCocoa",
# published by The Pragmatic Bookshelf.
# Copyrights apply to this code. It may not be used to create training material, 
# courses, books, articles, and the like. Contact us if you are in doubt.
# We make no guarantees that this code is fit for any purpose. 
# Visit http://www.pragmaticprogrammer.com/titles/bmrc for more book information.
#---
require 'osx/cocoa'

# This file shows that the RubyCocoa super_x way of calling a
# superclass method ONLY looks in an Objective-C object, not a
# superclass that's defined in Ruby.

class RubyFromObjC < OSX::NSObject
  def description
    "Some kind of RubyFromObjC"
  end
end

class RubyFromRuby < RubyFromObjC
  def description
    "super_description says: " + super_description +
      "\nbut super says: " + super + 
      "\nThe super_description comes from NSObject#description."
  end
end

if $0 == __FILE__
  puts RubyFromRuby.alloc.init.description
end
    
myMini-2:rubycocoa-oddities kittekat$ ruby super-and-super.rb 
super_description says: <RubyFromRuby: 0x1018f8ba0>
but super says: Some kind of RubyFromObjC
The super_description comes from NSObject#description.
myMini-2:rubycocoa-oddities kittekat$ 

Regards
Wolfgang

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

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

I'm not an expert, but super will call the superclass in ruby. It  
might be a bridge proxy object, not the cocoa "superclass".  Sorry I'm  
not in front of a computer, so I can't check the  source, but I'm  
guessig that's why super_xxxx is used


Hope that helps.
Envoyé de mon iPhone

Le 20 mars 2010 à 21:55, Eric Christopherson  
<ech...@gm...> a écrit :

> On Fri, Mar 19, 2010 at 5:15 AM, Allison Newman <dem...@ma...>  
> wrote:
>> Yup, its a bridge thing. You'll notice that the init method that I  
>> defined
>> in the last post does the same thing as the hillegass example. As  
>> long as
>> you stay on one side of the bridge or the other, you can do as you  
>> please,
>> but as soon as you cross the bridge using super_ you have to keep  
>> the same
>> signature.
>
> Is the bridge also the reason you can't just use super(...)?
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Eric C. <ech...@gm...>]

On Fri, Mar 19, 2010 at 5:15 AM, Allison Newman <dem...@ma...> wrote:
> Yup, its a bridge thing. You'll notice that the init method that I defined
> in the last post does the same thing as the hillegass example. As long as
> you stay on one side of the bridge or the other, you can do as you please,
> but as soon as you cross the bridge using super_ you have to keep the same
> signature.

Is the bridge also the reason you can't just use super(...)?

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Wolfgang K. <kit...@ka...>]

Great, the first step of the Hillegass example 29_ViewSwapping works now with the adapted initialization.

Many thanks again
Wolfgang

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

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

Yup, its a bridge thing. You'll notice that the init method that I  
defined in the last post does the same thing as the hillegass example.  
As long as you stay on one side of the bridge or the other, you can do  
as you please, but as soon as you cross the bridge using super_ you  
have to keep the same signature.

Envoyé de mon iPhone

Le 19 mars 2010 à 11:11, Wolfgang Kittenberger <kit...@ka...> a  
écrit :

> Alli,
>
> Thanks for the fast response and your advice.
>
> Is this a requirement specific for the Rubycocoa bridge?
> I found in the Hillegass book (3rd edition)  on page 359 an  
> Objective-C code snippet like this:
>
> @implementation DepartmentViewController
>
> - (id)init
> {
> 	if (![super initWithNibName:@"DepartmentView"
> 						 bundle:nil])
> 		return nil;
> 	[self setTitle:@"Departments"];
> 	return self;
> }
>
> @end
>
>
> best regards
> Wolfgang
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Wolfgang K. <kit...@ka...>]

Alli,

Thanks for the fast response and your advice.

Is this a requirement specific for the Rubycocoa bridge?
I found in the Hillegass book (3rd edition)  on page 359 an Objective-C code snippet like this:

@implementation DepartmentViewController

- (id)init
{
	if (![super initWithNibName:@"DepartmentView"
						 bundle:nil]) 
		return nil;
	[self setTitle:@"Departments"];
	return self;
}

@end


best regards
Wolfgang

Re: [Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

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

Wolfgang,

When you want to call a super method, you have to do it from inside a  
method having exactly the same signature/name.  So this works:

 >> class VC
 >> def initWithNibName_bundle(nibname, bundle)
 >> super_initWithNibName_bundle(nibname, bundle)
 >> end
 >> end
=> nil
 >> vc = VC.alloc.initWithNibName_bundle('dummy', nil)
=> #<VC:0x32e416 class='VC' id=0x1a001c0>

If you really want to have just a plain init method, you could then  
define it as:
def init
	initWithNibName_bundle('dummy, nil)
end

 > vc = VC.alloc.init
=> #<VC:0x31c306 class='VC' id=0x1a24210>

Please note that the signature of the method really does have to be  
identical, with the same number of parameters.

Alli

Le 19 mars 10 à 08:44, Wolfgang Kittenberger a écrit :

> I run into an other challenge with the bridge:
>
> When initializing a subclass of NSViewController, the bridge claims,  
> that super:initWithNibName:bundle: is a missing method.
>
> Here an sample irb session:
>>> require 'osx/cocoa'
> => true
>>> include OSX
> => Object
>>> class VC < NSViewController
>>> def init
>>>  super_initWithNibName_bundle('dummy',nil)
>>> end
>>> end
> => nil
>>> vc = VC.alloc.init
> OSX::OCMessageSendException: Can't get Objective-C method signature  
> for selector 'super:initWithNibName:bundle:' of receiver #<VC: 
> 0x8093c60c class='VC' id=0x101edeb30>
> 	from /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/ 
> objc/oc_wrapper.rb:50:in `ocm_send'
> 	from /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/ 
> objc/oc_wrapper.rb:50:in `method_missing'
> 	from (irb):5:in `init'
> 	from (irb):8
>>>
>
> I can verify the presence of the initWithNibName:bundle: method
>
>>> VC.superclass
> => OSX::NSViewController
>>> VC.objc_instance_methods.sort
> ...,"infoForBinding:", "init", "initWithCoder:",  
> "initWithNibName:bundle:", "insertText:",...
>
> What is my fault?
>
> Best regards
> Wolfgang Kittenberger
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] super_initWithNibName_bundle not recognized by bridge

[Wolfgang K. <kit...@ka...>]

I run into an other challenge with the bridge:

When initializing a subclass of NSViewController, the bridge claims, that super:initWithNibName:bundle: is a missing method.

Here an sample irb session:
>> require 'osx/cocoa'
=> true
>> include OSX
=> Object
>> class VC < NSViewController
>> def init
>>   super_initWithNibName_bundle('dummy',nil)
>> end
>> end
=> nil
>> vc = VC.alloc.init
OSX::OCMessageSendException: Can't get Objective-C method signature for selector 'super:initWithNibName:bundle:' of receiver #<VC:0x8093c60c class='VC' id=0x101edeb30>
	from /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/oc_wrapper.rb:50:in `ocm_send'
	from /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/oc_wrapper.rb:50:in `method_missing'
	from (irb):5:in `init'
	from (irb):8
>> 

I can verify the presence of the initWithNibName:bundle: method

>> VC.superclass
=> OSX::NSViewController
>> VC.objc_instance_methods.sort
...,"infoForBinding:", "init", "initWithCoder:", "initWithNibName:bundle:", "insertText:",...

What is my fault?

Best regards
Wolfgang Kittenberger

Re: [Rubycocoa-talk] NSFormatter - Hillegass example

[Wolfgang K. <kit...@ka...>]

Hi Alli,

  Thanks again. That was it!

Best regards
Wolfgang

Re: [Rubycocoa-talk] NSFormatter - Hillegass example

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

Wolfgang,

I'm too lazy to type in the whole example from the Hillegass text.   
But just looking at the implementation of the "cast_as" method, I  
would suggest that you try :

     partial = partPtr.cast_as('^@')

Let us know if that helps....

Alli

Le 7 mars 10 à 09:38, Wolfgang Kittenberger a écrit :

> Hi folks,
>
>   has anybody implemented the Hillegass example regarding  
> NSFormatter (chapter 26 in the 3rd edition of "Cocoa Programming for  
> MAC OS X") in rubycocoa?
>
>   I failed to transcript the  
> isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription 
> : method on the pages 336+337:
>
> def  
> isPartialStringValid_proposedSelectedRange_originalString_originalSelectedRange_errorDescription 
> (partPtr, selPtr, origString, origSel, error_ptr)
>     NSLog("partPtr.class = #{partPtr.class}")
>     NSLog("partPtr.inspect = #{partPtr.inspect}")
>     partial = partPtr.cast_as('@')
>     NSLog("partial.class = #{partial.class}")
> ...
>
>  I started with some test-printout, but when entering the cast  
> statement, it blows up! here is the correspondig console output:
>
> 2010-03-07 09:27:38.170 TypingTutor[6519:a0f] partPtr.class =  
> OSX::ObjcPtr
> 2010-03-07 09:27:38.171 TypingTutor[6519:a0f] partPtr.inspect =  
> #<OSX::ObjcPtr:0x29f036 cptr=0xbfffd4dc allocated_size=0 encoding=@>
> Program received signal:  “EXC_BAD_ACCESS”.
> sharedlibrary apply-load-rules all
>
> any ideas?
>
> best regards
>
> Wolfgang Kittenberger
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] NSFormatter - Hillegass example

[Wolfgang K. <kit...@ka...>]

Hi folks,

  has anybody implemented the Hillegass example regarding NSFormatter (chapter 26 in the 3rd edition of "Cocoa Programming for MAC OS X") in rubycocoa?

  I failed to transcript the isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription: method on the pages 336+337: 

def isPartialStringValid_proposedSelectedRange_originalString_originalSelectedRange_errorDescription(partPtr, selPtr, origString, origSel, error_ptr)
    NSLog("partPtr.class = #{partPtr.class}")
    NSLog("partPtr.inspect = #{partPtr.inspect}")
    partial = partPtr.cast_as('@')
    NSLog("partial.class = #{partial.class}")
...

 I started with some test-printout, but when entering the cast statement, it blows up! here is the correspondig console output:

2010-03-07 09:27:38.170 TypingTutor[6519:a0f] partPtr.class = OSX::ObjcPtr
2010-03-07 09:27:38.171 TypingTutor[6519:a0f] partPtr.inspect = #<OSX::ObjcPtr:0x29f036 cptr=0xbfffd4dc allocated_size=0 encoding=@>
Program received signal:  “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all

any ideas?

best regards

Wolfgang Kittenberger

Re: [Rubycocoa-talk] GUI Testing

[Duncan M. <du...@on...>]

On 14 Dec 2009, at 18:35, James Mead wrote:

> I've been playing around with using AppleScript and System Events to
> write automated GUI acceptance tests.


Hey James - had your mail queued to reply to for quite a while!

Thanks for posting, very interesting. I've also been GUI testing through AppleScript, in my case with Cucumber. 

Scenario: Convert a single jpeg file
	When I run the app
	And I open the file "testdata/testcard.jpg"
	Then the front window title should be "testcard.jpg"
	When I wait for window with title "testcard.pdf"
	And I click "Save"
	Then the file "testdata/testcard.pdf" should exist

This is backed by feature-support.rb

When /^I run the app$/ do
  @app = run_app
end

When /^I open the file "([^\"]*)"$/ do |file|
  @app.open file
end

When /^I (?:press|click) "([^\"]*)"$/ do |button_name|
  @app.button(button_name).click
end

and a driver like

include Appscript

def run_app files = []
	VelOCRaptor.new 'VelOCRaptor', Dir.getwd + '/build/release', files
end

class VelOCRaptor

	def initialize app_name, path, files, run = true
		@app_name = app_name
		app_path = File.join(path, "#{app_name}.app")
		if run
			command = "open -W -a #{app_path}"
			files.each { |file| command << %[ "#{file}"] }
			IO.popen command
			sleep 2
		end
		@events = app 'System Events'
		@process = @events.processes[@app_name]
		@app = app app_path
	end

	def open file
		@app.open File.expand_path(file)
	end

etc.

As is usual with GUI tests I'm still fighting occasional failures due to not waiting for things to happen. I'd be very interested to compare more of our drivers if you'd like to contact me off list.

Cheers

Duncan McGregor
www.velOCRaptor.com
Simple Affordable Mac OCR

[Rubycocoa-talk] RubyCocoa code for Apple's Cocoa Application Tutorial

[Thomas O'D. <tho...@tr...>]

Hi Folks,

I looked up Ruby and Cocoa on the Internet and it led me to RubyCocoa
instead of MacRuby.

(I recommend you paste a link and explain to people the state of RubyCocoa
and MacRuby, so we know. I only found out by looking at the developer's
postings...)

Anyway, the examples I got with RubyCocoa were helpful, but a little
difficult to follow, especially as I don't know Cocoa at all.

So instead I followed the Apple Cocoa Application Tutorial
(http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjCTutorial/index.html)
and substituted RubyCocoa code where necessary. Works really well! 
I was able to morph that into the simple Cocoa application I wanted.

For the help of those who are still planning to support RubyCocoa, I offer
my commented versions of Apple's CurrencyConverter app, converted to
RubyCocoa. I recommend you look this over to see if there is anything
I misunderstood, and then put it up somewhere on the website.

START OF CONVERTER.RB:>>>>>>>>>>>>>>>>>>
#
# Converter.rb
# CurrencyConverter
#
# Created by TR Solutions Pte Ltd on 2/22/10.
# This code is in the Public Domain.
# You are free to use it, modify it, and even claim you wrote it.
#
#
# This code is companion to the document
# "Cocoa Application Tutorial"
#http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjCTutorial/index.html
# and shows the Ruby code that would replace the Objective C code
# described in the tutorial (as it was on 2010-02-22).
#
# Note that RubyCocoa does not have separate header files.
# The code in this file covers the code in both Converter.h
# and Converter.m
#
# Also, if you are following the tutorial,
# when you create your version of this file,
# create a new file of type "Ruby NSObject subclass"
# in the category "User Templates" instead of the "Objective-C class"
# described in the tutorial.
#

#
# This line is necessary to enable RubyCocoa support. (It is automatically
# inserted when you make a new Ruby NSObject subclass.)
require 'osx/cocoa'

# class Converter:
# This is the RubyCocoa equivalent of the class Converter
# described in the chapter "Defining the Model"
class Converter < OSX::NSObject
  # Note there is no RubyCocoa equivalent of the line
  # described in the tutorial:
  #   float sourceCurrencyAmount, rate;
  # as Ruby does not need to declare variable types.
  #

  #
  # This is the RubyCocoa equivalent of the lines
  # described in the tutorial:
  #   @property(readwrite) float sourceCurrencyAmount, rate;
  #     (in Converter.h)
  #   @synthesize sourceCurrencyAmount, rate; (in Converter.m)
  # Note that attr_accessor will synthesize the following methods:
  #   sourceCurrencyAmount
  #   sourceCurrencyAmount=(newSourceCurrencyAmount)
  #   rate
  #   rate=(newRate)
  # which are the Ruby equivalents to the functions
  # mentioned in the tutorial:
  #   - (float)sourceCurrencyAmount;
  #   - (void)setSourceCurrencyAmount:(float)newSourceCurrencyAmount;
  #   - (float)rate;
  #   - (void)setRate:(float)newRate;
  attr_accessor :sourceCurrencyAmount, :rate

  # Note there is no RubyCocoa equivalent of the line
  # described in the tutorial:
  #   - (float)convertCurrency;
  # as the RubyCocoa interface is constructed directly from this file.
  #

  #
  # The following lines are the Ruby equivalent of the
  # lines described in the tutorial:
  #   - (float)convertCurrency {
  #     return self.sourceCurrencyAmount * self.rate;
  #   }
  def convertCurrency
    @sourceCurrencyAmount * @rate
  end
end
<<<<<<<<<<<<<<<<<<<<<END OF CONVERTER.RB

START OF CONVERTERCONTROLLER.RB:>>>>>>>>>>>>>>>>>>
#
#  ConverterController.rb
#  CurrencyConverter
#
#  Created by TR Solutions on 2010-02-22.
#  This code is in the Public Domain.
#  You are free to use it, modify it, and even claim you wrote it.
#
#  This code is companion to the document
#  "Cocoa Application Tutorial"
#http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjCTutorial/index.html
#  and shows the Ruby code that would replace the Objective C code
#  described in the tutorial (as it was on 2010-02-22).
#
# Note the code in this file covers both the code mentioned in the
# tutorial as belonging in ConverterController.h and
# that mentioned as belonging in ConverterController.m.
#
# When connecting to the Interface Builder as described in the tutorial,
# read the classes from this file. You may get an error message
# like "No classes found", but if ConverterController shows up
# in your class list, it's okay to proceed.
#

#
# This line is necessary to enable RubyCocoa support. (It is automatically
# inserted when you make a new Ruby NSObject subclass.)
require 'osx/cocoa'
#
# This line is equivalent to the line described in the tutorial:
#   #import "Converter.h"
require 'Converter'

# class ConverterController:
#   This is the RubyCocoa equivalent of the class ConverterController
#   described in the chapter "Bridging the Model and View: The Controller"
class ConverterController < OSX::NSObject
  # The following line is equivalent to the code described in
  # the tutorial:
  #   IBOutlet NSTextField *amountField;
  #   IBOutlet NSTextField *dollarField;
  #   IBOutlet NSTextField *rateField;
  # (ib_outlets is the RubyCocoa equivalent to Cocoa's IBOutlet)
  #
  ib_outlets :amountField, :dollarField, :rateField

  # Note there is no RubyCocoa equivalent of the line
  # described in the tutorial:
  #   Converter *converter;
  # as Ruby does not need to declare variable types.

  #
  # The following lines are the RubyCocoa equivalent of:
  #   - (IBAction)convert:(id)sender {
  #     float amount;
  #     converter = [[Converter alloc]init];                          // 1
  #     [converter setSourceCurrencyAmount:[dollarField floatValue]]; // 2
  #     [converter setRate:[rateField floatValue]];                   // 2
  #     amount =   [converter convertCurrency];                       // 3
  # 
  #     [amountField setFloatValue:amount];                           // 4
  #     [rateField selectText:self];                                  // 5
  #   }
  def convert(sender)
    converter = Converter.new                                          # 1
    converter.sourceCurrencyAmount = @dollarField.floatValue           # 2
    converter.rate = @rateField.floatValue                             # 2
    amount = converter.convertCurrency                                 # 3

    @amountField.setFloatValue(amount)                                 # 4
    @rateField.selectText(self)                                        # 5
  end

  # The following line is the RubyCocoa equivalent of:
  #   - (IBAction)convert:(id)sender;
  # (ib_action is the RubyCocoa equivalent to Cocoa's IBAction)
  # 
  # Note that you need to create at least an empty definition of
  # the convert method before you connect this file to Interface Builder.
  # and that you put this line after your definition.
  #
  ib_action :convert
end
<<<<<<<<<<<<<<<<<<<<<END OF CONVERTERCONTROLLER.RB

That's it! Now I'm on to MacRuby...

Regards,

Thomas O'Dell
TR Solutions Pte Ltd
http://www.trsolutions.biz

Re: [Rubycocoa-talk] Enabling Tk bindings on Snow Leopard

[Eric C. <ech...@gm...>]

On Sun, Feb 21, 2010 at 11:54 PM, Allison Newman <dem...@ma...> wrote:
> Hi Eric,
>
> OK, the first thing to know is that you don't need to recompile ruby
> to add in bindings.  Bindings are added by using Ruby extensions.
> Basically, at start up, the Ruby interpreter looks in a well-known
> location in your file system, and runs any native extensions that it
> finds there.  I don't know if you've already worked with Ruby
> extensions, but if not, this is pretty much the canonical reference
> for them:
> http://ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.html

Thanks.

>
>
> Out of curiousity, what makes you think that Tk bindings have been
> removed in Snow Leopard (I'm still on Leopard, so I can't test it)?
>
> Alli

Personal experience --

>> require 'tk'
LoadError: no such file to load -- tk
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
`require'
	from (irb):1
>>

Also, I read it on the Web. I don't remember the exact page now, but I
did just find this one:
<http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/22e0e72994155258>

Sure enough, there is no tk.rb under /System/Library/Frameworks/Ruby.framework.

When I have time I will try recompiling it.

Now that I think about it, I downloaded and installed RubyCocoa, so
that should have overwritten the RubyCocoa that came with the OS,
right? Or would that just replace the Cocoa-specific parts, and leave
the core Ruby stuff in place? (If I compile my own Ruby, I don't want
to lose the Cocoa-specific parts.)

Re: [Rubycocoa-talk] Enabling Tk bindings on Snow Leopard

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

Hi Eric,

OK, the first thing to know is that you don't need to recompile ruby  
to add in bindings.  Bindings are added by using Ruby extensions.   
Basically, at start up, the Ruby interpreter looks in a well-known  
location in your file system, and runs any native extensions that it  
finds there.  I don't know if you've already worked with Ruby  
extensions, but if not, this is pretty much the canonical reference  
for them:
http://ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.html


Out of curiousity, what makes you think that Tk bindings have been  
removed in Snow Leopard (I'm still on Leopard, so I can't test it)?

Alli

Le 21 févr. 10 à 21:37, Eric Christopherson a écrit :

> I guess Tk bindings for Ruby and Python were removed in Snow Leopard,
> even though Tk is still included. Is there a way to enable/install the
> bindings for Ruby without recompiling Ruby?
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

[Rubycocoa-talk] Enabling Tk bindings on Snow Leopard

[Eric C. <ech...@gm...>]

I guess Tk bindings for Ruby and Python were removed in Snow Leopard,
even though Tk is still included. Is there a way to enable/install the
bindings for Ruby without recompiling Ruby?