rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Problem with RubyCocoa install

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

On 17 Sep 2005, at 10:57, Matt Mower wrote:
>
> which I don't really understand since line 68 is passing 'guess1' to
> respond_to?  I didn't get any hits on a google search.

Heh - you beat me to posting about this. After mentioning CVS  
yesterday I realised that I'd had to make the patch below.

The line in question, from:

/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/cocoa_macros.rb:68

looks like this:

     if NKF.respond_to? 'guess1' && NKF::NKF_VERSION == "2.0.4"

which gets parsed as:

     if NKF.respond_to?('guess1' && NKF::NKF_VERSION == "2.0.4")

since NKF::NKF_VERSION is "2.0.4", the argument evaluates to 'true'.

Change the line to:

     if NKF.respond_to?('guess1') && NKF::NKF_VERSION == "2.0.4"
or
     if NKF.respond_to? 'guess1' and NKF::NKF_VERSION == "2.0.4"

[Rubycocoa-talk] Problem with RubyCocoa install

[Matt M. <mat...@gm...>]

Hi,

I'm trying to get RubyCocoa built on my 10.4.2 PowerBook.  I checked
out the CVS version then did

ruby install.rb config
ruby install.rb setup

both of which seemed okay (except for some stroppy warnings that I
shouldn't be using some header file or other).

In the tests folder I ran

ruby testall.rb

and got the following error:

/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/objc/=
cocoa_macros.rb:68:in
`respond_to?': true is not a symbol (TypeError)
        from /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/r=
uby/osx/objc/cocoa_macros.rb:68
        from /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/r=
uby/osx/objc/cocoa.rb:13:in
`require'
        from /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/r=
uby/osx/objc/cocoa.rb:13
        from /opt/local/lib/ruby/site_ruby/1.8/osx/cocoa.rb:12:in `require'
        from /opt/local/lib/ruby/site_ruby/1.8/osx/cocoa.rb:12
        from rb_main.rb:5:in `require'
        from rb_main.rb:5

which I don't really understand since line 68 is passing 'guess1' to
respond_to?  I didn't get any hits on a google search.

Can anyone suggest my next step?

Regards,

Matt

--=20
Matt Mower :: http://matt.blogs.it/

Re: [Rubycocoa-talk] Good news, bad news.

[Tom C. <ta...@ca...>]

On 17 Sep 2005, at 00:39, Dave Howell wrote:
> The "CVS version"? Is that shorthand for "a newer but not  
> officially released version?"

The `work in progress', you can see what is going on with it here:
http://cvs.sourceforge.net/viewcvs.py/rubycocoa/src/ChangeLog? 
view=markup

It is probably shorthand for it will be coming in the next release,  
so if you can wait: wait.

If you can't wait, you can get it, but be prepared for some work  
getting it there, and the danger that there are extra bugs in the  
working copy, and the problem that fewer people use it and so won't  
be able to help as much.

> And would I have to have CVS installed (no, no, not that horrible  
> word!) in order to access it?

I think it comes with OS X.  Go to the command line and try cvs

The commands to get a copy from cvs is:

cvs -d:pserver:ano...@cv...:/cvsroot/rubycocoa login

Just press return when it asks for a password, then do:

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/rubycocoa  
co -P src

Then something like
cd src
ruby install.rb config
ruby install.rb setup
sudo ruby install.rb install

Be prepared for this not to work first time, as there are probably a  
bunch of things that it needs in order to compile which you will need  
to track down (I haven't done it in a while so I'm not sure what they  
are).

Tom

Re: [Rubycocoa-talk] Detecting double-clicks.

[Will T. <wi...@th...>]

You should use the - (void)setDoubleAction:(SEL)aSelector and - (void) 
setTarget:(id)anObject methods on the table and outline views to call  
a method on a delegate object. You can then use clickedRow and  
clickedColumn to find out where you clicked.

On 17 Sep 2005, at 2:39 am, Dave Howell wrote:

> This is a nice, normal, totally on-topic query. :) I have a window.  
> It's got a TableView and an OutlineView. I want to know when a row  
> in either one has been double-clicked so I can open a new 'detail'  
> window for the clicked item. I thought this would work:
>
> class ProjectInterface < OSX::NSWindowController
>
>     ns_overrides  :mouseDown_
>     ib_outlet :projectListView, :taskListView, :window
>
>     def mouseDown(event)
>         if event.clickCount > 1 then
>             puts "I've detected a double-click."
>         end
>     end
> end
>
> Alas, it works, but only on every part of the window BUT the two  
> Views that I want it to work on! I don't care if I've double- 
> clicked the border of the window, after all. :) What am I missing  
> here?
>

[Rubycocoa-talk] Detecting double-clicks.

[Dave H. <gr...@gr...>]

This is a nice, normal, totally on-topic query. :) I have a window. 
It's got a TableView and an OutlineView. I want to know when a row in 
either one has been double-clicked so I can open a new 'detail' window 
for the clicked item. I thought this would work:

class ProjectInterface < OSX::NSWindowController

	ns_overrides  :mouseDown_
	ib_outlet :projectListView, :taskListView, :window

	def mouseDown(event)
		if event.clickCount > 1 then
			puts "I've detected a double-click."
		end
	end
end

Alas, it works, but only on every part of the window BUT the two Views 
that I want it to work on! I don't care if I've double-clicked the 
border of the window, after all. :) What am I missing here?

Re: [Rubycocoa-talk] Good news, bad news.

[Dave H. <da...@gr...>]

On Sep 16, 2005, at 15:35, Jonathan Paisley wrote:

> The crash you're seeing could be a result of a bug in your ruby code 
> that does things with Objective C/Cocoa.

Like what? I've been trying to be extremely "by the book" for just this 
reason.

> Another possibility is that the crash is a result of normal ruby 
> exception being thrown, which the Objective C runtime doesn't know how 
> to deal with it. The CVS version of RubyCocoa has support for handling 
> these correctly.

The "CVS version"? Is that shorthand for "a newer but not officially 
released version?" And would I have to have CVS installed (no, no, not 
that horrible word!) in order to access it?

Re: [Rubycocoa-talk] Good news, bad news.

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

On 16 Sep 2005, at 23:16, Dave Howell wrote:

> So the packaged installer turns out to install powerpc-darwin7.8.0  
> instead of the 7.9.0 I'd been getting from source. On the other  
> hand, it actually worked. That's the good news.
>
> The bad news is, if I tab rapidly through an outline view in my  
> program, or I think just use it beyond a certain point, I still get  
> an unexpected abort:
>
> /Users/snarke/Personal/Programming/My Programs/My Ruby Programs/2Du/ 
> build/2Du.app/Contents/Resources/ProjectInterface.rb:88: [BUG]  
> Segmentation fault
> ruby 1.8.2 (2004-12-25) [powerpc-darwin7.8.0]

The 'powerpc-darwin*' bit from the version is a direct result of the  
version of Mac OS X that was used to build the software - it's not an  
indicator of software version. (7.8.0 is OSX 10.3.8, 7.9.0 is 10.3.9,  
etc).

The crash you're seeing could be a result of a bug in your ruby code  
that does things with Objective C/Cocoa. As a result, you'll need to  
try the same debugging techniques that would be needed with a plain  
Cocoa application. Try running it under the debugger from Xcode and  
you should be able to see where the particular crash is occurring.

Another possibility is that the crash is a result of normal ruby  
exception being thrown, which the Objective C runtime doesn't know  
how to deal with it. The CVS version of RubyCocoa has support for  
handling these correctly.

[Rubycocoa-talk] Good news, bad news.

[Dave H. <da...@gr...>]

So the packaged installer turns out to install powerpc-darwin7.8.0 
instead of the 7.9.0 I'd been getting from source. On the other hand, 
it actually worked. That's the good news.

The bad news is, if I tab rapidly through an outline view in my 
program, or I think just use it beyond a certain point, I still get an 
unexpected abort:

/Users/snarke/Personal/Programming/My Programs/My Ruby 
Programs/2Du/build/2Du.app/Contents/Resources/ProjectInterface.rb:88: 
[BUG] Segmentation fault
ruby 1.8.2 (2004-12-25) [powerpc-darwin7.8.0]

So now what?

[Rubycocoa-talk] New ways to not install Ruby things.

[Dave h. <eb...@Gr...>]

Well, the Rails installation has finally failed completely. I reached 
the point where Rails would get invoked when the right page was called, 
and I could even get results back, usually, *if* I did not attempt to 
communicate with my database. I couldn't get it to generate a useful 
error message, so I shelved that for a couple days.

Then my entire 'server data partition' (where websites, mail, and 
database files live) was obliterated when my RAID array botched a 
rebuild of a faulty drive on the one day in the past three months when 
I didn't have a backup of the whole thing.

So it's something of a moot point. I am now shopping for a used XServe.

I moved back to my other project, the RubyCocoa task list manager. 
That's been blowing up with bus errors for no obvious reason. Since 
it's clearly a fault in RubyCocoa, Ruby, or OSX, instead of programmer 
error, I've been a bit stymied. Since I now know that my 1.8.2 is the 
November version, I decided to install the December one.

Well, from the command line, I get the new 1.8.2 (darwin7.9.0). But 
XCode can't let go of the older, powerpc-darwin7.5.0 version, and 
continues to fail with a bus error semi-randomly. I have no idea how to 
get it to get a clue; repeated fiddling on my part just upsets it when 
it can't find the older libraries or whatever it's looking for.

I decided to scrap everything and reinstall Ruby from scratch.

In order to be able to tell the difference between the older 1.8.2 and 
the newer 1.8.2, I named the newer version "ruby-1.8.2(12/25/04)".  How 
delightful to discover that "make install" can't handle parentheses. 
Configure didn't bat an eye. Make didn't have a problem. But Make 
Install instantly fails. And if I change the directory name, it still 
fails, since it turns out that ./configure hard-coded its own directory 
into the files it built. So I have to start over from the very 
beginning.

Then I can try installing gems. Then RubyCocoa. Then Rails.

[pause]

Or not. Make has failed.

	compiling iconv
	gcc -fno-common -g -O2 -pipe -fno-common  -I. -I../.. -I../../. 
-I../.././ext/iconv 	-DICONV_INPTR_CAST="(char **)"  -c iconv.c
	iconv.c:1: bad macro argument list
	iconv.c:231: illegal function call, found `inptr'
	cpp-precomp: warning: errors during smart preprocessing, retrying in 
basic mode
	<built-in>:1:1: no macro name given in #define directive
	make[1]: *** [iconv.o] Error 1
	make: *** [all] Error 1

Let's try again....nope, my installation directory is now mysteriously 
corrupted. I must now erase it and download a whole new copy of Ruby.  
I guess I'll try the package that 'discordantus' put together. After I 
finish banging my head against the wall.

Re: [Rubycocoa-talk] Re: [Ruby] embedded RubyCocoa available for testing

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

In case anybody's interested, here's a repost of my script  
'standaloneify.rb' for turning a development RubyCocoa app into a  
standalone application. Hopefully it'll survive the mailing list  
posting. Last time I made it an attachment it got lost.


# standaloneify.rb
# Author: Jonathan Paisley <jp-www dcs.gla.ac.uk>
# $Id: standaloneify.rb 736 2005-04-23T09:31:55.719659Z jp  $
#
# Takes a built RubyCocoa app bundle (as produced by the
# Xcode/ProjectBuilder template) and copies it into a new
# app bundle that has all dependencies resolved.
#
# usage:
#   ruby standaloneify.rb -d mystandaloneprog.app mybuiltprog.app
#
# This creates a new application that should have dependencies resolved.
#
# The script attempts to identify dependencies by running the program
# without OSX.NSApplicationMain, then grabbing the list of loaded
# ruby scripts and extensions. This means that only the libraries that
# you 'require' are bundled.
#
# NOTES:
#
#  Your ruby installation MUST NOT be the standard Panther install -
#  the script depends on ruby libraries being in non-standard paths to
#  work.
#
#  I've only tested it with a DarwinPorts install of ruby 1.8.2.
#
#  Extension modules should be copied over correctly.
#
#  Ruby gems that are used are copied over in their entirety (thanks  
to some
#  ideas borrowed from rubyscript2exe)
#
#  install_name_tool is used to rewrite dyld load paths - this may  
not work
#  depending on how your libraries have been compiled. I've not had any
#  issues with it yet though.

module Standaloneify
   MAGIC_ARGUMENT = '--standaloneify'

   def self.find_file_in_load_path(filename)
     return filename if filename[0] == ?/
       paths = $LOAD_PATH.select do |p|
       path = File.join(p,filename)
       return path if File.exist?(path)
       end
       return nil
   end

end

if __FILE__ == $0 and ARGV[0] == Standaloneify::MAGIC_ARGUMENT then
   # Got magic argument
   ARGV.shift

   module Standaloneify
     LOADED_FILES = []
     def self.notify_loaded(filename)
       LOADED_FILES << filename unless LOADED_FILES.include?(filename)
     end
   end

   module Kernel
     alias :pre_standaloneify_load :load
     def load(*args)
       if self.is_a?(OSX::OCObjWrapper) then
         return self.method_missing(:load,*args)
       end

       filename = args[0]
       result = pre_standaloneify_load(*args)
       Standaloneify.notify_loaded(filename) if filename and result
       return result
     end
   end

   module Standaloneify
     def self.find_files(loaded_features,loaded_files)

       loaded_features.delete("rubycocoa.bundle")

       files_and_paths = (loaded_features + loaded_files).map do |file|
         [file,find_file_in_load_path(file)]
       end

       files_and_paths.reject! { |f,p| p.nil? }

       if defined?(Gem) then
         resources_d =  
OSX::NSBundle.mainBundle.resourcePath.fileSystemRepresentation
         gems_home_d = File.join(resources_d,"RubyGems")
         gems_gem_d = File.join(gems_home_d,"gems")
         gems_spec_d = File.join(gems_home_d,"specifications")

         FileUtils.mkdir_p(gems_spec_d)
         FileUtils.mkdir_p(gems_gem_d)

         Gem::Specification.list.each do |gem|
           next unless gem.loaded?
           $stderr.puts "Found gem #{gem.name}"

           FileUtils.cp_r(gem.full_gem_path,gems_gem_d)
           FileUtils.cp(File.join 
(gem.installation_path,"specifications",gem.full_name +  
".gemspec"),gems_spec_d)
           # Remove any files that come from the GEM
           files_and_paths.reject! { |f,p| p.index(gem.full_gem_path)  
== 0 }
         end

       end

       return files_and_paths
     end
   end

   require 'osx/cocoa'

   module OSX
     def self.NSApplicationMain(*args)
       # Prevent application main loop from starting
     end
   end

   $LOADED_FEATURES << "rubycocoa.bundle"

   $0 = ARGV[0]
   require ARGV[0]

   loaded_features = $LOADED_FEATURES.dup
   loaded_files = Standaloneify::LOADED_FILES.dup

   require 'fileutils'

   result = Standaloneify.find_files(loaded_features, loaded_files)
   File.open(ENV["STANDALONEIFY_DUMP_FILE"],"w") {|fp| fp.write 
(result.inspect) }

   exit 0
end


module Standaloneify

   RB_MAIN_PREFIX = <<-EOT.gsub(/^ */,'')
    
######################################################################## 
########
   # #{File.basename(__FILE__)} 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")

    
######################################################################## 
########
   EOT

   def self.patch_main_rb(resources_d)
     rb_main = File.join(resources_d,"rb_main.rb")
     main_script = RB_MAIN_PREFIX + File.read(rb_main)
     File.open(rb_main,"w") do |fp|
       fp.write(main_script)
     end
   end

   def self.get_dependencies(macos_d,resources_d)
     dump_file = File.join(resources_d,"__require_dump")
     # Run the main Mac program
     mainprog = Dir[File.join(macos_d,"*")][0]
     ENV['STANDALONEIFY_DUMP_FILE'] = dump_file
     system(mainprog,__FILE__,MAGIC_ARGUMENT)

     begin
       result = eval(File.read(dump_file))
     rescue
       $stderr.puts "Couldn't read dependency list"
       exit 1
     end
     File.unlink(dump_file)
     result
   end

   class LibraryFixer
     def initialize
       @done = {}
     end

     def self.needs_to_be_bundled(path)
       case path
       when %r:^/usr/lib/:
         return false
       when %r:^/lib/:
         return false
       when %r:^/Library/Frameworks:
         $stderr.puts "WARNING: don't know how to deal with  
frameworks (%s)" % path.inspect
         return false
       when %r:^/System/Library/Frameworks:
         return false
       when %r:^@executable_path:
         $stderr.puts "WARNING: can't handle library with existing  
@executable_path reference (%s)" % path.inspect
         return false
       end
       return true
     end

     ## For the given library, copy into the lib dir (if copy_self),
     ## iterate through dependent libraries and copy them if necessary,
     ## updating the name in self

     def fixup_library(relative_path,full_path,dest_root,copy_self=true)
       prefix = "@executable_path/../lib"

       lines = %x[otool -L '#{full_path}'].split("\n")
       paths = lines.map { |x| x.split[0] }
       paths.shift # argument name

       return if @done[full_path]

       if copy_self then
         @done[full_path] = true
         new_path = File.join(dest_root,relative_path)
         internal_path = File.join(prefix,relative_path)
         FileUtils.mkdir_p(File.dirname(new_path))
         FileUtils.cp(full_path,new_path)
         File.chmod(0700,new_path)
         full_path = new_path
         system("install_name_tool","-id",internal_path,new_path)
       end

       paths.each do |path|
         next if File.basename(path) == File.basename(full_path)

         if self.class.needs_to_be_bundled(path) then
           puts "Fixing %s in %s" % [path.inspect,full_path.inspect]
           fixup_library(File.basename(path),path,dest_root)

           lib_name = File.basename(path)
           new_path = File.join(dest_root,lib_name)
           internal_path = File.join(prefix,lib_name)

           system("install_name_tool","- 
change",path,internal_path,full_path)
         end
       end
     end
   end

   def self.make_standalone_application(source,dest,extra_libs)
     FileUtils.cp_r(source,dest)
     dest_d = Pathname.new(dest).realpath.to_s

     # Calculate various paths in new app bundle
     contents_d = File.join(dest_d,"Contents")
     frameworks_d = File.join(contents_d,"Frameworks")
     resources_d = File.join(contents_d,"Resources")
     lib_d = File.join(contents_d,"lib")
     macos_d = File.join(contents_d,"MacOS")

     # Create Frameworks dir and copy RubyCocoa in there
     FileUtils.mkdir_p(frameworks_d)
     FileUtils.mkdir_p(lib_d)
     FileUtils.cp_r("/Library/Frameworks/ 
RubyCocoa.framework",frameworks_d)

     # Calculate paths to newly copied RubyCocoa framework
     ruby_cocoa_d = File.join(frameworks_d,"RubyCocoa.framework")
     ruby_cocoa_inc = File.join(ruby_cocoa_d,"Resources","ruby")
     ruby_cocoa_lib = File.join(ruby_cocoa_d,"RubyCocoa")

     # Copy in and update library references for RubyCocoa
     fixer = LibraryFixer.new
     fixer.fixup_library(File.basename 
(ruby_cocoa_lib),ruby_cocoa_lib,lib_d,false)

     third_party_d = File.join(resources_d,"ThirdParty")
     FileUtils.mkdir_p(third_party_d)

     # Calculate bundles and Ruby modules needed
     dependencies = get_dependencies(macos_d,resources_d)

     patch_main_rb(resources_d)

     extra_libs.each do |lib|
       dependencies << [lib,find_file_in_load_path(lib)]
     end

     dependencies.each do |feature,path|

       case feature
       when /\.rb$/
         next if feature[0] == ?/
         if File.exist?(File.join(ruby_cocoa_inc,feature)) then
         puts "Skipping RubyCocoa file " + feature.inspect
         next
         end
         if File.exist?(File.join(resources_d,feature)) then
           puts "Skipping existing Resource file " + feature.inspect
           next
         end
         dir = File.join(third_party_d,File.dirname(feature))
         FileUtils.mkdir_p(dir)
         puts "Copying " + feature.inspect
         FileUtils.cp(path,File.join(dir,File.basename(feature)))

       when /\/rubycocoa.bundle$/
         next

       when /\.bundle$/
         puts "Copying bundle " + feature.inspect

         base = File.basename(path)
         if path then
           if feature[0] == ?/ then
             relative_path = File.basename(feature)
           else
             relative_path = feature
           end
           fixer.fixup_library(relative_path,path,lib_d)
         else
           puts "WARNING: Bundle #{extra} not found"
         end

       else
         $stderr.puts "WARNING: unknown feature %s loaded" %  
feature.inspect
       end
     end
   end

end

if $0 == __FILE__ then

   require 'ostruct'
   require 'optparse'
   require 'pathname'
   require 'fileutils'

   config = OpenStruct.new
   config.force = false
   config.extra_libs = []
   config.dest = nil

   ARGV.options do |opts|
     opts.banner = "usage: #{File.basename(__FILE__)} -d DEST  
[options] APPLICATION"
     opts.on("-f","--force","Delete target app if it exists already")  
{ |config.force| }
     opts.on("-d DEST","--dest","Place result at DEST (required)") {| 
config.dest|}
     opts.on("-l LIBRARY","--lib","Extra library to bundle") { |lib|  
config.extra_libs << lib }

     opts.parse!
   end

   if not config.dest or ARGV.length!=1 then
     $stderr.puts ARGV.options
     exit 1
   end

   source_app_d = ARGV.shift

   if config.dest !~ /\.app$/ then
     $stderr.puts "Target must have '.app' extension"
     exit 1
   end

   if File.exist?(config.dest) then
     if config.force then
       FileUtils.rm_rf(config.dest)
     else
       $stderr.puts "Target exists already (#{config.dest.inspect})"
       exit 1
     end
   end

   Standaloneify.make_standalone_application 
(source_app_d,config.dest,config.extra_libs)

end

[Rubycocoa-talk] Re: [Ruby] embedded RubyCocoa available for testing

[Doug B. <do...@be...>]

On Wed, Sep 14, 2005 at 10:55:26PM +0200, Rupert BARROW wrote:
> Sorry, could not get your embedded RubyCocoa (0.4.1) to compile  
> correctly on Tiger.
> Do you have any more recent version ?

hi rup,

i haven't worked on the embedded stuff for a few months, so maybe it
stopped working with newer releases of tiger.  i was also using my own
ruby build for embedding versus the system ruby 1.8.2.

could you please email me the compile errors?  i'll take a look at them
this weekend.  this is a good coincidence, because i was planning on
dusting off the embedded changes and cleaning them up a bit.

thanks,

doug

-- 
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant.  It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

[Sean L. <se...@da...>]

On 16 Sep 2005, at 15:41, Jonathan Paisley wrote:
>
> Yes, those were added after 0.4.1. I think there are quite a few  
> limitations in 0.4.1 release that make things hard! The current CVS  
> has got some nice features added though (like my exception-wrapping  
> patch, which stops applications from dying unexpectedly if any  
> uncaught ruby exceptions occur). :)

I'll have to take another look over CVS head for such goodies...

>>> I still think cocoa_depends_on is useful since it has far nicer  
>>> syntax, and can easily be reimplemented in terms of  
>>> setKeys_trigger... once that works.
>>>
>>
>> OK, sounds like a good idea. I no longer have any basis for  
>> asserting that setKeys_trigger... doesn't work anymore, it seems  
>> fine.
>>
>
> Would 'kvc_depends_on' be a better name, to match up with the other  
> kvc_* methods?

Agreed.

Sean

-- 
Sean Legassick
se...@da...

[Rubycocoa-talk] NSApplication base class for capturing exceptions

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

Hi all,

My patch for bridging exceptions between Ruby and Objective C appears  
to be in the CVS trunk. To go along with this, here's a base-class to  
be used in place of NSApplication that will pop up an NSAlert when a  
ruby exception occurs. The alert has 'Continue' and 'Abort' buttons.

To use this class, it's necessary to adjust 'rb_main.rb to use  
RBCApplication in place of NSApplication:

if $0 == __FILE__ then
   rb_main_init
   OSX::ns_import "RBCApplication"
   OSX::RBCApplication.sharedApplication
   OSX.NSApplicationMain(0, nil)
end

Hope this is of some use.
Jonathan




// RBCApplication.h
#import <Cocoa/Cocoa.h>

@interface RBCApplication : NSApplication {
}
@end

// RBCApplication.m
@implementation RBCApplication

-(void)notifyRubyException:(NSException*)exc
{
     static BOOL handling;
     if (handling) {
         NSLog(@"Got an exception %@ while handling another one!",exc);
         return;
     }
     handling = YES;

     NSMutableString *bs = nil;
     NSArray *backtrace = [[exc userInfo] objectForKey: @"backtrace"];

     if (backtrace) {
         bs = [NSMutableString string];;
         [bs appendString: @"Backtrace: \n"];

         NSString *resources = [[NSBundle mainBundle] resourcePath];

         unsigned int i, count = [backtrace count];
         for (i = 0; i < count; i++) {
             NSString *path = [backtrace objectAtIndex:i];
             if ([path hasPrefix: resources]) {
                 path = [path substringFromIndex:[resources length]+1];
             }
             [bs appendFormat: @"  %@\n", path];
         }
     }

     NSString *s = [NSString stringWithFormat: @"An unhandled Ruby  
exception occurred:\nName: %@\nReason: %@\n%@",
         [[exc name] substringFromIndex: [@"RBException_" length]],
         [exc reason],
         bs ? (NSString*)bs : @""];

     NSAlert *alert = [[NSAlert alloc] init];
     [alert addButtonWithTitle: @"Continue"];
     [alert addButtonWithTitle: @"Abort"];
     [alert setMessageText: @"Ruby Exception"];
     [alert setInformativeText: s];

     if ([alert runModal] == NSAlertSecondButtonReturn) {
         exit(1);
     }
     [alert release];

     handling = NO;
}

-(void)run
{
     while (1) {
         NS_DURING
             [super run];
             NS_VOIDRETURN;
         NS_HANDLER
             if ([[localException name] hasPrefix: @"RBException_"]) {
                 [self notifyRubyException: localException];
             } else {
                 [localException raise];
             }
         NS_ENDHANDLER;
     }
}
@end

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

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

>> I think I'd like to figure out the problem with the Cocoa-provided  
>> mechanisms, since then the dependency tracking should just work  
>> (since we already send change notifications through kvc_accessor).
>
> I hadn't seen kvc_reader, kvc_writer or kvc_accessor previously  
> either - they remove the need for cocoa_property. (they weren't in  
> the 0.4.1 release that I started out with).

Yes, those were added after 0.4.1. I think there are quite a few  
limitations in 0.4.1 release that make things hard! The current CVS  
has got some nice features added though (like my exception-wrapping  
patch, which stops applications from dying unexpectedly if any  
uncaught ruby exceptions occur). :)

>> I still think cocoa_depends_on is useful since it has far nicer  
>> syntax, and can easily be reimplemented in terms of  
>> setKeys_trigger... once that works.
>
> OK, sounds like a good idea. I no longer have any basis for  
> asserting that setKeys_trigger... doesn't work anymore, it seems fine.

Would 'kvc_depends_on' be a better name, to match up with the other  
kvc_* methods?

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

[Sean L. <se...@da...>]

On 16 Sep 2005, at 13:35, Jonathan Paisley wrote:
>
> Can you comment more on the problem with  
> setKeys_triggerChangeNotificationsForDependentKey? I'm currently  
> using it sucessfully.
>
> For example:
>
> class Foo < OSX::NSObject
>   ["prop1","prop2","prop2"].each do |key|
>     Foo.setKeys_triggerChangeNotificationsForDependentKey 
> (["propX"],key)
>   end
>
>   # ... other stuff
> end

Yup, using it like that works for me too. Unfortunately I don't have  
a copy of the code where I was trying to get it to work and it  
didn't. I had just started tinkering around with RubyCocoa so I may  
have just made a silly error, or alternately it may not have been  
working properly on the 0.4.1 release...

> I think I'd like to figure out the problem with the Cocoa-provided  
> mechanisms, since then the dependency tracking should just work  
> (since we already send change notifications through kvc_accessor).

I hadn't seen kvc_reader, kvc_writer or kvc_accessor previously  
either - they remove the need for cocoa_property. (they weren't in  
the 0.4.1 release that I started out with).

> I still think cocoa_depends_on is useful since it has far nicer  
> syntax, and can easily be reimplemented in terms of  
> setKeys_trigger... once that works.

OK, sounds like a good idea. I no longer have any basis for asserting  
that setKeys_trigger... doesn't work anymore, it seems fine.

Sean

-- 
Sean Legassick
se...@da...

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

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

On 15 Sep 2005, at 23:46, Rupert BARROW wrote:

> You have tested a class Controller < OSX::NSObject, but have you  
> also tested a SubController < Controller ?
> When I try this, I get an illegal instruction from Ruby !

I think that currently it's not possible to subclass a Ruby class  
that derives from OSX::NSObject, due to some implementation details  
in the creation of Objective C class corresponding to the Ruby class.

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

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

>>
>> There seem to be some differences in behaviour between Panther and  
>> Tiger. I have a vague recollection of having to disable some of my  
>> ruby-level manual change notifications after the move to Tiger,  
>> since exceptions were appearing. What OS version are you using?
>
> Tiger 10.4.2 - haven't tried this on Panther.

Hmmn. I can't now find the code that I was thinking about after  
scanning the Subversion logs for my project. Hopefully it'll turn up.

>> If you can post your code and any specifics you've identified  
>> about the way RubyCocoa interacts with the Objective C KVO system  
>> that would be great. I'll try to do the same soon with the code I  
>> have.
>
> I've attached my code. It relies on the property handling stuff in  
> CVS HEAD (unless that's been released now ... ?)

Can you comment more on the problem with  
setKeys_triggerChangeNotificationsForDependentKey? I'm currently  
using it sucessfully.

For example:

class Foo < OSX::NSObject
   ["prop1","prop2","prop2"].each do |key|
     Foo.setKeys_triggerChangeNotificationsForDependentKey 
(["propX"],key)
   end

   # ... other stuff
end

I think I'd like to figure out the problem with the Cocoa-provided  
mechanisms, since then the dependency tracking should just work  
(since we already send change notifications through kvc_accessor).

I still think cocoa_depends_on is useful since it has far nicer  
syntax, and can easily be reimplemented in terms of  
setKeys_trigger... once that works.

Thanks
Jonathan

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

[Rupert B. <rup...@fr...>]

Sean,

Thanks for your code for cocoa_depends_on and (most importantly for  
me) for cocoa_property.
I am having trouble testing and understanding something : subclassing  
your Controller.

You have tested a class Controller < OSX::NSObject, but have you also  
tested a SubController < Controller ?
When I try this, I get an illegal instruction from Ruby !

Any ideas ?  My Ruby meta-programming skills are not great ...

TIA,
Rupert

[Rubycocoa-talk] [Ruby] embedded RubyCocoa available for testing

[Rupert B. <rup...@fr...>]

Sorry, could not get your embedded RubyCocoa (0.4.1) to compile  
correctly on Tiger.
Do you have any more recent version ?


Rup

Re: [Rubycocoa-talk] Sob. Here I go again.

[Sam R. <sro...@un...>]

Quoting gr...@gr..., on Tue, Sep 13, 2005 at 02:25:56PM -0700:
> and Steven Arnold wrote:
> >Dumb question -- you _do_ have the latest xcode installed, and you 
> >_can_ compile other packages, right?
> 
> LOL. I don't think that's a dumb question at all. My /usr/bin directory 
> has gcc-3.3 in it, but since so much Unix style installing is a "just 
> type this line, everything will work fine, you don't need to know 
> what's really going on", I have no idea what other dependencies are 

And it usually works like that, on Unix. You're using OS X, its an odd
variant, with many strangenesses, for example, it doesn't actually come
with the development tools installed and automatically updated like the
rest of the s/w. Maybe one day Apple will see fit to use their s/w
updater for development tools...

I feel the pain of installing unix software on my OS X machine at home,
like you, and I develop full-time on Linux at work, so I'm pretty
familiar with "unix", but that doesn't always help. Eventually, enough
OS X users will submit patches to developers, and things will work
out-of-the-box more for them, but remember its still a fringe OS, from a
Unix point-of-view.

Cheers,
Sam

Re: [Rubycocoa-talk] Sob. Here I go again.

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

On 13 Sep 2005, at 22:25, Dave Howell wrote:

> I believe I do not have 'the latest XCode' installed. My laptop  
> has /Developer/Applications/Xcode (version 1.5). My server has / 
> Developer/Applications/ProjectBuilder (2.0).

ProjectBuilder, as far as I remember, is a pre-Xcode thing, so I  
guess that must be an old installation.

> Guess I'll try installing XCode and see if that helps. . . . and  
> eureka. Thank you both very much. Rails is now running. Haven't  
> been able to get the postgres driver to install yet, but that  
> appears to be a matter of psychically guessing what the answer is  
> to the question "--with-pgsql-dir=" is.

Hurrah!

The argument to --pgsql-dir is likely to be the 'prefix' directory  
into which postgres has been installed. The prefix directory is the  
one containing directories like 'bin', 'include', 'lib', 'sbin',  
'share'. For example, if you find your postgres programs in /usr/ 
local/bin, then probably --with-pgsql-dir=/usr/local may do the trick.

Re: [Rubycocoa-talk] Sob. Here I go again.

[Dave H. <gr...@gr...>]

  Jonathan Paisley wrote:
> Looks like your developer tools installation might have got broken at 
> some point. Can you try reinstalling the dev tools?

and Steven Arnold wrote:
> Dumb question -- you _do_ have the latest xcode installed, and you 
> _can_ compile other packages, right?

LOL. I don't think that's a dumb question at all. My /usr/bin directory 
has gcc-3.3 in it, but since so much Unix style installing is a "just 
type this line, everything will work fine, you don't need to know 
what's really going on", I have no idea what other dependencies are 
hidden beneath.

My general experience with installing anything from the command line 
has been horrible, (see 
http://howell.seattle.wa.us/essays/IHateUnix.html for one tragic 
example), so I try very hard not to compile anything, and haven't on 
the server in quite some time.

I believe I do not have 'the latest XCode' installed. My laptop has 
/Developer/Applications/Xcode (version 1.5). My server has 
/Developer/Applications/ProjectBuilder (2.0).

Guess I'll try installing XCode and see if that helps. . . . and 
eureka. Thank you both very much. Rails is now running. Haven't been 
able to get the postgres driver to install yet, but that appears to be 
a matter of psychically guessing what the answer is to the question 
"--with-pgsql-dir=" is.

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

[Sean L. <se...@da...>]

On 13 Sep 2005, at 17:08, Jonathan Paisley wrote:
> Even if the triggerChangeNotifications... method worked, I like the  
> idea of a ruby meta-method for setting them up - much less to type!

Absolutely, and I've made mine more flexible just now so you can say:

cocoa_depends_on :key, :dependency
cocoa_depends_on [ :key1, :key2 ], :dependency
cocoa_depends_on :key, [ :dependency1. :dependency2 ]
cocoa_depends_on [ :key1, :key2 ], [ :dependency1, :dependency2 ]

(I think on reflection cocoa_depends_on is a little more clear than  
cocoa_depends)
>
> There seem to be some differences in behaviour between Panther and  
> Tiger. I have a vague recollection of having to disable some of my  
> ruby-level manual change notifications after the move to Tiger,  
> since exceptions were appearing. What OS version are you using?

Tiger 10.4.2 - haven't tried this on Panther.

> If you can post your code and any specifics you've identified about  
> the way RubyCocoa interacts with the Objective C KVO system that  
> would be great. I'll try to do the same soon with the code I have.

I've attached my code. It relies on the property handling stuff in  
CVS HEAD (unless that's been released now ... ?)

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

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

On 13 Sep 2005, at 15:55, Sean Legassick wrote:

> If you're interested I can post this, alternately is there any  
> interest in getting these into the trunk? Is there perhaps a more  
> elegant way of achieving this?

These things sound interesting. I discovered a similar problem with  
ruby-level changes to bridged objects not sending notifications and  
came up with an
equivalent additional meta-method.

Even if the triggerChangeNotifications... method worked, I like the  
idea of a ruby meta-method for setting them up - much less to type!

There seem to be some differences in behaviour between Panther and  
Tiger. I have a vague recollection of having to disable some of my  
ruby-level manual change notifications after the move to Tiger, since  
exceptions were appearing. What OS version are you using?

If you can post your code and any specifics you've identified about  
the way RubyCocoa interacts with the Objective C KVO system that  
would be great. I'll try to do the same soon with the code I have.

Thanks
Jonathan

Re: [Rubycocoa-talk] Ruby/Cocoa and CoreData

[Sean L. <se...@da...>]

On 13 Sep 2005, at 14:43, Free (rupert.barrow) wrote:
> Has anyone got Ruby/RubyCocoa and CoreData working ?
> Are there any examples out there, of Apps (with GUI) and/or Tools  
> (without GUI).

This isn't quite the same, but bindings/KVO are used by CoreData, so  
this may be useful to you.

I've been working on enhancing RubyCocoa's handling of Key-Value  
observance to allow binding driven applications. I've written a  
little helper that allows code like this:

class Controller < OSX::NSObject

     attr_accessor  :status, :timeConnected
     cocoa_property :status, :timeConnected

     cocoa_depends  :status,          
[ :statusText, :isConnecting, :isConnected,
                                                          :isDisconnecti 
ng, :isDisconnected, :isWorking ]
     cocoa_depends  :timeConnected,  [ :timeConnectedText ]

end

(this was from a little proof-of-concept app I wrote to handle  
activating a PPP connection on my  server from by PB)

The cocoa_property class method creates wrappers for the setter  
methods for those properties that trigger KVO notifications. Note  
this is necessary even with the CVS HEAD RubyCocoa, even with the  
property support in there. That support will only trigger the  
notifications when the property is updated from the other side of the  
ObjC bridge. My code ensures that Ruby code that updates the property  
also triggers the notifications.

The cocoa_depends class method defines dependencies. This is  
necessary because the bridge seems to prevent the  
setKeys:triggerChangeNotificationsForDependentKey: class method on  
NSObject from operating correctly. (I haven't investigated why, but I  
can guess it's to do with the RubyCocoa wrapper for Ruby classes).

If you're interested I can post this, alternately is there any  
interest in getting these into the trunk? Is there perhaps a more  
elegant way of achieving this?

Sean

-- 
Sean Legassick
se...@da...