rubycocoa-talk — talking about RubyCocoa

[Rubycocoa-talk] Conversion of Ruby <-> ObjC objects

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

This is a simple case that keeps causing me problems. A ruby object  
passed to Cocoa and back doesn't come back as a ruby object. But  
worse its accessors don't return ruby objects either. Why does this  
code not work? IIs there something I should be doing??


class Test
     attr_reader :num

     def initialize
         @num = 3;
     end
end

arr = OSX::NSArray.arrayWithObject(Test.new)

puts arr.objectAtIndex(0)            # <RBObject: 0x4e51f0>
puts arr.objectAtIndex(0).class        # OSX::OCObject
puts arr.objectAtIndex(0).num.class    # OSX::NSDecimalNumber

puts "<10" if arr.objectAtIndex(0).num < 10 #crash


The crash is:
/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_wrapper.rb:17:in `ocm_send': NSDecimalNumber#<: -  
methodSignature is nil. (OSX::OCMessageSendException)
     from /Library/Frameworks/RubyCocoa.framework/Versions/A/ 
Resources/ruby/osx/objc/oc_wrapper.rb:17:in `method_missing'
     from /Users/william/Desktop/Scripting/simpleapp/build/ 
SimpleApp.app/Contents/Resources/rb_main.rb:21



cheers --Will

Re: [Rubycocoa-talk] Problem running test suite

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

On 29 Jul 2005, at 15:01, Matt Mower wrote:

> .....................2005-07-29 14:47:23.044 ruby[15149] *** Uncaught
> exception: <NSCharacterConversionException> Conversion to encoding 30
> failed for string "=E3=82=AA=E3=83=96=E3=82=B8=E3=82=A7=E3=82=AF=E3=83=88=
=E6=8C=87=E5=90=91=E3=82=B9=E3=82=AF=E3=83=AA=E3=83=97=E3=83=88=E8=A8=80=E8=
=AA=9ERuby"
> Trace/BPT trap
> ---output---
>
> A search of the mailing list archives didn't turn up anything about
> this problem.  I did find people talking about NSCharacterConversion
> problems in terms of Cocoa in general but I'm not familar enough the
> Mac/Cocoa to follow.
>
> Can anyone help me?

I think this message from ruby-talk covers the same problem:

    http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/135408

The string is being converted to your local 8-bit character set =20
(probably MacRoman) and that fails. RubyCocoa CVS fixes this by using =20=

UTF-8 throughout.

Hope that makes sense
Jonathan

[Rubycocoa-talk] Problem running test suite

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

Hi.

I'm trying to build ruby-coca 0.4.1 from source on MacOSX 10.4.2 using
the DarwinPorts build of Ruby.  I have my path configured so that
/opt/local/bin/ is before /usr/bin and "which ruby" reports:

  /opt/local/bin/ruby

Ruby version is:

  ruby 1.8.2 (2004-12-25) [powerpc-darwin8.1.0]

I unpacked ruby-cocoa using tar and then built it using install.rb. 
The "config" and "setup" commands seem to work fine.

However when I go into the "tests" folder and run the tests I get:

---output---
Irulan:~/build/rubycocoa-0.4.1/tests matt$
DYLD_FRAMEWORK_PATH=../framework/build ruby -I../lib
-I../ext/rubycocoa testall.rb
tc_nsattributedstring.rb
tc_nsdata.rb
tc_nsstring.rb
tc_objcptr.rb
tc_rubystring.rb
tc_subclass.rb
Loaded suite testall
Started
.....................2005-07-29 14:47:23.044 ruby[15149] *** Uncaught
exception: <NSCharacterConversionException> Conversion to encoding 30
failed for string "オブジェクト指向スクリプト言語Ruby"
Trace/BPT trap
---output---

A search of the mailing list archives didn't turn up anything about
this problem.  I did find people talking about NSCharacterConversion
problems in terms of Cocoa in general but I'm not familar enough the
Mac/Cocoa to follow.

Can anyone help me?

Thanks,

Matt

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

Re: [Rubycocoa-talk] build problem

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

Hi,

I found a problem like yours from macosx-dev archives. I think 
the version of your DevTools is earlier than 2.0.

http://www.cocoabuilder.com/archive/message/cocoa/2005/6/16/139061
http://www.cocoabuilder.com/archive/message/cocoa/2005/6/16/139106


Sun, 24 Jul 2005 11:28:48 -0400, Ryah Dahl wrote:
>Hi,
>
>I am trying to install rubycoca-0.4.1 and I ran into this error while  
>running ruby install.rb setup
>
>/usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0)  
>file: -lSystem is not an object file (not allowed in a library)
>...failed DynamicLibrary.LinkUsingFileList /Users/ryan/Desktop/ 
>rubycocoa0.4.1/framework/build/RubyCocoa.framework/Versions/A/ 
>RubyCocoa ...
>** BUILD FAILED **
>setup failed
>'system xcodebuild' failed
>


-- 
kimura wataru

[Rubycocoa-talk] build problem

[Ryah D. <col...@gm...>]

Hi,

I am trying to install rubycoca-0.4.1 and I ran into this error while  
running ruby install.rb setup

/usr/bin/libtool: for architecture: cputype (16777234) cpusubtype (0)  
file: -lSystem is not an object file (not allowed in a library)
...failed DynamicLibrary.LinkUsingFileList /Users/ryan/Desktop/ 
rubycocoa0.4.1/framework/build/RubyCocoa.framework/Versions/A/ 
RubyCocoa ...
** BUILD FAILED **
setup failed
'system xcodebuild' failed

I don't know much about ruby or macintosh and I'm totally confused  
about this. Any suggestions?

Ryah

Re: [Rubycocoa-talk] Installation problems

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

Hi,

We released a patched source archive of version 0.4.1.

http://prdownloads.sourceforge.net/rubycocoa/rubycocoa-0.4.1-xcode-2.1-patched.tgz
(MD5: ce498e990a4ac9de289c839aaa0c0b57)

Tue, 19 Jul 2005 21:35:10 +0900, kimura wataru wrote:
>Hi,
>
>I wrote a patch. We will release a patched source distribution
>of 0.4.1.
>
Sorry, that patch is not complete. We needed to modify extconf.rb.in 
about build process of a extention module, rubycococa.bundle. The 
released arhive includes this modification.


-- 
kimura wataru

Re: [Rubycocoa-talk] adding to attr_accessor.

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

On Jul 15, 2005, at 5:13, Tom Counsell wrote:

> I find it easiest to think of symbols as strings that never change.

Say, that's good. I like that.

By the way, it works perfectly. :) :)

Re: [Rubycocoa-talk] Installation problems

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

Hi,

I wrote a patch. We will release a patched source distribution
of 0.4.1.

Sun, 17 Jul 2005 17:18:45 +0100, Jonathan Paisley wrote:
>
>On 17 Jul 2005, at 16:52, Marco Righele wrote:
>
>> The install script expect to find the folder 'framework/build/ 
>> RubyCocoa.build', but instead there is a 'framework/build/Default/ 
>> RubyCocoa.framework' folder. Copying the folder (not moving, part  
>> of the install script looks in the right place) to the parent  
>> directory seemed to fix the problem and now I'm happily playing  
>> with shell (cocoa) scripts.
>>
>
>That is due to a change in Xcode 2.1.
>
>Previously, built products were placed in the 'build' directory  
>directly. Xcode 2.1 separates them by build configuration -- that's  
>the 'Default' directory you're seeing (thus saving on rebuilds when  
>switching between configurations).
>
>Glad you got it to work :)
>
>Jonathan
>

--------------
diff -ur rubycocoa-0.4.1.orig/framework/pre-install.rb rubycocoa-0.4.1/framework/pre-install.rb
--- rubycocoa-0.4.1.orig/framework/pre-install.rb   2002-12-28 02:57:59.000000000 +0900
+++ rubycocoa-0.4.1/framework/pre-install.rb    2005-07-19 01:22:39.000000000 +0900
@@ -1,9 +1,18 @@
 install_root = @config['install-root']
+obj_path = 'build'
+if File.basename(buildcommand) == 'xcodebuild'
+  if /DevToolsCore-(\d+)/.match(`#{buildcommand} -version`)
+    xcode_version = $1.to_i
+  else
+    xcode_version = 0 # unknown(< Xcode 2.0?)
+  end
+  obj_path = "#{obj_path}/Default" if xcode_version >= 620
+end
 
 # strip symbols for diet of the object file.
 fwname = @config['framework-name']
 curdir = Dir.pwd
-Dir.chdir "build/#{fwname}.framework/Versions/Current"
+Dir.chdir "#{obj_path}/#{fwname}.framework/Versions/Current"
 command "strip -x #{fwname}"
 Dir.chdir curdir
 
@@ -21,4 +30,4 @@
   command "mv '#{framework_path}' '#{backup_dir}/'"
 end
 command "mkdir -p '#{frameworks_dir}'"
-command "cp -R 'build/#{framework_name}' '#{framework_path}'"
+command "cp -R '#{obj_path}/#{framework_name}' '#{framework_path}'"
--------------

-- 
kimura wataru
<mailto:kimuraw@i.nifty.jp>

Re: [Rubycocoa-talk] Installation problems

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

On 17 Jul 2005, at 16:52, Marco Righele wrote:

> The install script expect to find the folder 'framework/build/ 
> RubyCocoa.build', but instead there is a 'framework/build/Default/ 
> RubyCocoa.framework' folder. Copying the folder (not moving, part  
> of the install script looks in the right place) to the parent  
> directory seemed to fix the problem and now I'm happily playing  
> with shell (cocoa) scripts.
>

That is due to a change in Xcode 2.1.

Previously, built products were placed in the 'build' directory  
directly. Xcode 2.1 separates them by build configuration -- that's  
the 'Default' directory you're seeing (thus saving on rebuilds when  
switching between configurations).

Glad you got it to work :)

Jonathan

Re: [Rubycocoa-talk] Installation problems

[Marco R. <mar...@ya...>]

Jonathan Paisley wrote:

> Ah! I wrongly assumed in my original message that you were installing  
> from source.
>
> I haven't tried any of the binary packages. But I just took a look at  
> the RubyCocoa-0.4.1-tiger.dmg file and it seems that the installer  
> package is missing the necessary files to use RubyCocoa from the  
> command line (via irb or plain ruby). Hopefully the person who  
> created it can fix it.
>
> Until that is fixed, if you're able, you could install RubyCocoa from  
> source. That should install the necessary files.
>
> Jonathan


It seems that there are a few issues with the install process, and maybe 
that's the root of the problems with the package (or maybe it's just 
that my system is messed up so things are not working as expected :D).
The install script expect to find the folder 
'framework/build/RubyCocoa.build', but instead there is a 
'framework/build/Default/RubyCocoa.framework' folder. Copying the folder 
(not moving, part of the install script looks in the right place) to the 
parent directory seemed to fix the problem and now I'm happily playing 
with shell (cocoa) scripts.

Thanks again,
Marco



		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.beta.messenger.yahoo.com

Re: [Rubycocoa-talk] Installation problems

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

>
> I can't find rubycocoa.bundle in the RubyCocoa-0.4.1-tiger.dmg  
> image I downloaded from sourceforge, but it is present in  
> RubyCocoa-0.4.1-panther.dmg. Same thing for the other missing  
> files. Could it be a problem of the tiger version of the package ,  
> or should I find them somewhere else ?

Ah! I wrongly assumed in my original message that you were installing  
from source.

I haven't tried any of the binary packages. But I just took a look at  
the RubyCocoa-0.4.1-tiger.dmg file and it seems that the installer  
package is missing the necessary files to use RubyCocoa from the  
command line (via irb or plain ruby). Hopefully the person who  
created it can fix it.

Until that is fixed, if you're able, you could install RubyCocoa from  
source. That should install the necessary files.

Jonathan

Re: [Rubycocoa-talk] Installation problems

[Marco R. <mar...@ya...>]

First of all thanks for your answer.

Jonathan Paisley wrote:

>
> Is there any chance you have more than one copy of ruby installed  
> (e.g., from darwinports in /opt/local or from fink in /sw or self- 
> installed in /usr/local)? If so, perhaps the files got installed for  
> another ruby than the Apple-installed one in /usr.
>
I removed darwinports ruby just before installing ruby-cocoa, and in 
fact there is no 'rubycocoa.bundle' anywere on the disk, so I guess it 
must be something else.

> Another alternative is to do the install manually. Copy  
> rubycocoa.bundle from
>
>    rubycocoa-0.4.1/ext/rubycocoa/rubycocoa.bundle into the above path
>
> Copy the 'osx' directory from
>
>    rubycocoa-0.4.1/framework/src/ruby/osx
>
> into the path you identified into your original email.
>
I can't find rubycocoa.bundle in the RubyCocoa-0.4.1-tiger.dmg image I 
downloaded from sourceforge, but it is present in 
RubyCocoa-0.4.1-panther.dmg. Same thing for the other missing files. 
Could it be a problem of the tiger version of the package , or should I 
find them somewhere else ?

Thanks,
Marco


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Rubycocoa-talk] Installation problems

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

On 16 Jul 2005, at 21:59, Marco Righele wrote:

> If I'm not wrong I should find something cocoa.rb in /usr/lib/ruby/ 
> site_ruby/1.8/osx, but instead I find only the following files:
>
> addressbook.rb
> aeosa/
> aeosa.rb
>
> What I could do to fix it ?
>

Is there any chance you have more than one copy of ruby installed  
(e.g., from darwinports in /opt/local or from fink in /sw or self- 
installed in /usr/local)? If so, perhaps the files got installed for  
another ruby than the Apple-installed one in /usr.

You could do a Spotlight search-by-name for 'rubycocoa.bundle' to see  
where that got installed. You'd expect it at

    /usr/lib/ruby/site_ruby/1.8/powerpc-darwin7.<<something>>/ 
rubycocoa.bundle


Another alternative is to do the install manually. Copy  
rubycocoa.bundle from

    rubycocoa-0.4.1/ext/rubycocoa/rubycocoa.bundle into the above path

Copy the 'osx' directory from

    rubycocoa-0.4.1/framework/src/ruby/osx

into the path you identified into your original email.

I realise that's an unsatisfactory solution, but without more info  
it's hard to tell where the install went wrong.

Hope that helps,
Jonathan

[Rubycocoa-talk] Installation problems

[Marco R. <mar...@ya...>]

Greetings,

I'm trying to install ruby-cocoa 0.4.1 on a Mac with OS X 10.4.
The installation itself ends without any error, but while I can build 
and run programs with XCode, I'm unable to run scripts from the command 
line.
I get the following error message when I try to load the libraries:

 > require 'osx/cocoa'
LoadError: No such file to load -- osx/cocoa
        from (irb):1:in `require'
        from (irb):1

If I'm not wrong I should find something cocoa.rb in 
/usr/lib/ruby/site_ruby/1.8/osx, but instead I find only the following 
files:

addressbook.rb
aeosa/
aeosa.rb

What I could do to fix it ?

Thanks,
Marco


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

Re: [Rubycocoa-talk] NSBitmapImageRep#bitmapData

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

On 15 Jul 2005, at 21:24, Ralph Brorsen wrote:

> If at all possible I would prefer not to link my C++ stuff against  
> Ruby in order to keep it clean. It is a library meant for stand- 
> alone distribution. I now handle the conversion in the SWIG layer:
>
> // Convert bool from Ruby --> C with type check
> %typemap(in) BitmapPointer {
>     id ocobj = (id) NUM2UINT( rb_funcall($input, rb_intern 
> ("__ocid__"), 0) );
>     $1 = [(NSBitmapImageRep*) ocobj bitmapData];
> }

Did you try linking against RubyCocoa to make use of its dedicated  
function for getting at the __ocid__ of a Ruby object? That way will  
rely less on the internal workings of RubyCocoa.

> Three more things were needed to make it work.
> 1. Testinterface::Test(bitmapRep.bitmapData())   ->     
> Testinterface::Test(bitmapRep)    (duh)
> 2. #include <AppKit/NSBitmapImageRep.h>    (in the SWIG .i file)
> 3. You're now mixing Objective-C and C/C++ (aptly termed Objective-C 
> ++), and the compiler needs to be made aware of this. This is done  
> by changing the extension of the *_wrap.cxx file to .mm, ie.  
> *_wrap.mm. Update your makefile.

Thanks for posting back with your results. Useful recipes.

Jonathan

Re: [Rubycocoa-talk] NSBitmapImageRep#bitmapData

[Ralph B. <ra...@de...>]

Thanks Jonathan! I was able to get it to work.

If at all possible I would prefer not to link my C++ stuff against Ruby 
in order to keep it clean. It is a library meant for stand-alone 
distribution. I now handle the conversion in the SWIG layer:

// Convert bool from Ruby --> C with type check
%typemap(in) BitmapPointer {
	id ocobj = (id) NUM2UINT( rb_funcall($input, rb_intern("__ocid__"), 0) 
);
	$1 = [(NSBitmapImageRep*) ocobj bitmapData];
}

Three more things were needed to make it work.
1. Testinterface::Test(bitmapRep.bitmapData())   ->    
Testinterface::Test(bitmapRep)    (duh)
2. #include <AppKit/NSBitmapImageRep.h>    (in the SWIG .i file)
3. You're now mixing Objective-C and C/C++ (aptly termed 
Objective-C++), and the compiler needs to be made aware of this. This 
is done by changing the extension of the *_wrap.cxx file to .mm, ie. 
*_wrap.mm. Update your makefile.

Thanks again, Jonathan.

Ralph

On Jul 15, 2005, at 00:52, Jonathan Paisley wrote:

> On 14 Jul 2005, at 21:08, Ralph Brorsen wrote:
>
>> The main event here is of course "$1 = StringValuePtr($input);", 
>> which should, as I understand it return a char pointer to the string 
>> data which bitmapRep.bitmapData() returned. The reason it is 
>> converted to a Ruby string, I assume, is because RubyCocoa sees the 
>> char *, and thinks it is a string. Perhaps the string is copied to an 
>> internal buffer?
>
> As you've identified, the return value of bitmapData is being 
> converted to a ruby string. The easiest solution (since you're already 
> dealing with some native code) may be to pass the NSBitmapImageRep 
> pointer to your native code and get the pointer to the bitmapData from 
> within your native code.

Re: [Rubycocoa-talk] adding to attr_accessor.

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

Hello Dave

On 15 Jul 2005, at 04:25, Dave Howell wrote:
> Well, yes, but that was my point. I hadn't the faintest how to do  
> that. I find symbols still quite mysterious.

I find it easiest to think of symbols as strings that never change.   
You can often use a string in place of a symbol (attr_accessor  
"title" works the same as attr_accessor :title) but symbols are one  
character less, and send a signal to anyone reading your code that  
the string is for internal use only (ie it won't be shown on the  
screen to the user).

> Looking at your example, I see I'm going to have to go read up  
> on .class_eval, define_method, and instance_variable, all of which  
> I didn't even know I was looking for. :) But that sure looks like  
> exactly what I wanted to know. Thanks!

You may also want to look at the Observer class that is built into  
ruby http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html  
which reduces the code you need to type a bit.

Tom

Re: [Rubycocoa-talk] adding to attr_accessor.

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

On Jul 14, 2005, at 15:20, Mark Hubbart wrote:
>
> Roll your own attr_accessor.

Well, yes, but that was my point. I hadn't the faintest how to do that. 
I find symbols still quite mysterious. Looking at your example, I see 
I'm going to have to go read up on .class_eval, define_method, and 
instance_variable, all of which I didn't even know I was looking for. 
:) But that sure looks like exactly what I wanted to know. Thanks!

Re: [Rubycocoa-talk] NSBitmapImageRep#bitmapData

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

On 14 Jul 2005, at 21:08, Ralph Brorsen wrote:

> The main event here is of course "$1 = StringValuePtr($input);",  
> which should, as I understand it return a char pointer to the  
> string data which bitmapRep.bitmapData() returned. The reason it is  
> converted to a Ruby string, I assume, is because RubyCocoa sees the  
> char *, and thinks it is a string. Perhaps the string is copied to  
> an internal buffer?

As you've identified, the return value of bitmapData is being  
converted to a ruby string. The easiest solution (since you're  
already dealing with some native code) may be to pass the  
NSBitmapImageRep pointer to your native code and get the pointer to  
the bitmapData from within your native code.

A better solution would involve some changes to RubyCocoa to better  
support this.

You could do the 'easy' solution from Objective C++ or link in a  
small bit of Objective C code to do the work for you.

The Objective C object pointer (of type 'id' or whatever your object  
is - e.g., 'NSBitmapImageRep*') is available by calling __ocid__ on  
the ruby object. So, from within your native code you could do  
something like:

    id ocobj = (id) NUM2UINT( rb_funcall(obj, rb_intern("__ocid__"),  
0) );
    unsigned char *pixels = [(NSBitmapImageRep*) ocobj bitmapFormat];

Another option would be to call into RubyCocoa to get it to do this  
for you. There's a function 'rbobj_get_ocid' which does what you want  
(in a more robust fashion). The C function prototype (from  
mdl_osxobjc.h) is:

     id    rbobj_get_ocid (VALUE rcv);

Provided you can get the linker to be happy with this (e.g., by  
linking your native code against RubyCocoa too) it should work.

I'm sorry if the above is a bit vague. I've not tested it (just typed  
into email), but something along those lines should work.

Jonathan

Re: [Rubycocoa-talk] adding to attr_accessor.

[Mark H. <di...@ma...>]

On Jul 14, 2005, at 2:53 PM, Dave Howell wrote:

> Climb over one hill, find another behind it. I think this is mostly  
> a plain Ruby question, but let's see what happens.
>
> I have a RubyCocoa app I'm working on, a To Do list manager. I can  
> pass a "ToDo" task to a subclassed NSWindowManager, and voila! I  
> have a window with that task in it. Happy me! Make changes, make  
> changes, have changes written back to the task, et cetera.
>
> If I open a *second* window on the same task, however, they're each  
> writing back to the task but not aware of what the other window's  
> doing. Obviously (I hope?) my task needs to know what windows are  
> open onto it, and when it changes, it should tell them all to update.
>
> [Because of RubyCocoa's incomplete support for Bindings and  
> whatnot, I have abandoned trying to do this with CoreData. I figure  
> I'm probably better off learning this one the "old fashioned way,"  
> especially since it's not really that big a project.]
>
> My plan is to give each task a "ViewsOfMe" array property. Whenever  
> a task window controller opens a window, it tells the task it did,  
> and when it closes, ditto. The task would tell all registered  
> window controllers to update whenever one of its relevant  
> properties is changed.
>
> This seemed like a good plan up to this point.
>
>
> But my Task class starts out like this:
>
>         attr_accessor :title, :description, :priority [8 more  
> symbols here....]
>
> I *could* just replace all this with
>
>     def title
>         @title
>     end
>     def title=
>         @title=title
>         #put update windows code here
>     end
>     [repeat 10 more times]
>
> But that seems horribly unRubyesque. I figured I'd just modify/mix- 
> in/replace attr_accessor with one that also sets up the window  
> update triggers. OTOH, I'm absolutely mystified how to modify  
> attr_accessor to stick the updating code in the right spot. I  
> cannot find any reference for how attr actually works. I couldn't  
> even find a file that contained its code. One doc said it was in  
> "objects.c" but I can't find that either. LOL.
>
> Part of what makes this tricky is that I can't just add something  
> to attr, I have to change something it already does.
>
> Thoughts? Suggestions?

Roll your own attr_accessor. attr_accessor is just a method:  
Class#attr_accessor.[1] Define one that creates methods that you  
want. In this case, you want instance variables set, and a hook that  
will let you notify observers.

Here's a quick example done in irb:

class Class
   def observable_attr(*names)
     # Make sure we have the right scope
     self.class_eval do
       names.each do |name|
         define_method name do  # the getter
           instance_variable_get :"@#{name}"
         end
         define_method :"#{name}=" do |value|  # the setter
           instance_variable_set :"@#{name}", value
           update_observers(name)
         end
       end
     end
   end
end
     ==>nil
class Foo
   def update_observers(name) # the hook method
     puts "updating observers regarding '#{name}'"
   end
   observable_attr :foo, :bar, :baz
end
     ==>[:foo, :bar, :baz]
f = Foo.new
     ==>#<Foo:0x121eaa0>
f.foo, f.bar, f.baz = 23, 42, 93
updating observers regarding 'foo'
updating observers regarding 'bar'
updating observers regarding 'baz'
     ==>[23, 42, 93]
[f.foo, f.bar, f.baz]
     ==>[23, 42, 93]

[1] actually, it's Module#attr_accessor, but that's another story.

[Rubycocoa-talk] adding to attr_accessor.

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

Climb over one hill, find another behind it. I think this is mostly a 
plain Ruby question, but let's see what happens.

I have a RubyCocoa app I'm working on, a To Do list manager. I can pass 
a "ToDo" task to a subclassed NSWindowManager, and voila! I have a 
window with that task in it. Happy me! Make changes, make changes, have 
changes written back to the task, et cetera.

If I open a *second* window on the same task, however, they're each 
writing back to the task but not aware of what the other window's 
doing. Obviously (I hope?) my task needs to know what windows are open 
onto it, and when it changes, it should tell them all to update.

[Because of RubyCocoa's incomplete support for Bindings and whatnot, I 
have abandoned trying to do this with CoreData. I figure I'm probably 
better off learning this one the "old fashioned way," especially since 
it's not really that big a project.]

My plan is to give each task a "ViewsOfMe" array property. Whenever a 
task window controller opens a window, it tells the task it did, and 
when it closes, ditto. The task would tell all registered window 
controllers to update whenever one of its relevant properties is 
changed.

This seemed like a good plan up to this point.


But my Task class starts out like this:

		attr_accessor :title, :description, :priority [8 more symbols 
here....]

I *could* just replace all this with

	def title
		@title
	end
	def title=
		@title=title
		#put update windows code here
	end
	[repeat 10 more times]

But that seems horribly unRubyesque. I figured I'd just 
modify/mix-in/replace attr_accessor with one that also sets up the 
window update triggers. OTOH, I'm absolutely mystified how to modify 
attr_accessor to stick the updating code in the right spot. I cannot 
find any reference for how attr actually works. I couldn't even find a 
file that contained its code. One doc said it was in "objects.c" but I 
can't find that either. LOL.

Part of what makes this tricky is that I can't just add something to 
attr, I have to change something it already does.

Thoughts? Suggestions?

[Rubycocoa-talk] NSBitmapImageRep#bitmapData

[Ralph B. <ra...@de...>]

Hey everyone,

I'm having a bit of trouble using NSBitmapImageRep#bitmapData. Or at 
least, I think I am. (Source bits are included below, there is a 
testcase up at http://deadfeed.net/sandbox/testcase.zip - beware, the 
Makefile dependencies are not 100%.)

The NSBitmapImageRep should display data in a window, and that data 
should be coming from a C++ extension, via SWIG. Ruby should create the 
window, create views, and call a C++ function to fill the bitmap. But I 
all I get is a bus error (presumably because the pointer handed to the 
C++ function is off).

I have a class, FracWindow, which initializes the window and views 
(@fracView). FracWindow#ShowImage passes a pointer (char *) to the C++ 
function, which then fills it.

def showImage()
	bitmapRep=OSX::NSBitmapImageRep.alloc.initWithBitmapDataPlanes(nil,
		:pixelsWide, 256,
		:pixelsHigh, 256,
		:bitsPerSample, 8,
		:samplesPerPixel, 4,
		:hasAlpha, true,
		:isPlanar, true,
		:colorSpaceName, "NSDeviceRGBColorSpace",
		:bytesPerRow, 0,
		:bitsPerPixel, 0
	)
	
	Testinterface::Test(bitmapRep.bitmapData())
	
	image=OSX::NSImage.alloc.initWithSize([256, 256])
	image.addRepresentation(bitmapRep)
	@fracView.setImage(image)
	@fracView.setNeedsDisplay(true)
end

Testinterface::Test looks like this:

void Test(BitmapPointer p)
{
	std::cout << &p << std::endl;

	unsigned char *pp=p;

	pp[0]=255;
	pp[1]=0;
	pp[2]=0;
	pp[3]=0;
	pp[4]=0;
	pp[5]=0;
	pp[6]=0;
	pp[7]=0;

/*	for (int y=0; y<256; y++)
	{
		for (int x=0; x<256; x++)
		{
			char f=y/2+x/2;
			*pp++=f;
			// *pp++=f;
			// *pp++=f;
			// *pp++=f;
		}
	}*/
}

I made a BitmapPointer typedef in order to let SWIG distinguish the 
data type (char *). The SWIG typemap looks like this:

%typemap(in) BitmapPointer {
	if (TYPE($input)==T_STRING)
	{
	    $1 = StringValuePtr($input);
	}
	else
	{
		rb_raise(rb_eTypeError, "Expected bitmapdata");
		$1 = 0;
	}
}

The main event here is of course "$1 = StringValuePtr($input);", which 
should, as I understand it return a char pointer to the string data 
which bitmapRep.bitmapData() returned. The reason it is converted to a 
Ruby string, I assume, is because RubyCocoa sees the char *, and thinks 
it is a string. Perhaps the string is copied to an internal buffer?

I'd appreciate it if anyone could point me in the right direction.

Regards,
Ralph Brorsen

Re: [Rubycocoa-talk] methodSignature is nil.

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

On Jun 23, 2005, at 2:05, Jonathan Paisley wrote:

>
> I haven't tried Core Data (either in plain ObjC or RubyCocoa). I 
> suspect not many people have tried CoreData in RubyCocoa yet since 
> bindings aren't fully supported in the current release.

So I take it I'll have to use the bindings workarounds in order to get 
CoreData to work as well.
Hmm. Guess I'm the guinea pig. Or canary, or something.

Re: [Rubycocoa-talk] methodSignature is nil.

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

On 17 Jun 2005, at 21:19, Dave Howell wrote:

> So, um, is RubyCocoa 'out of the box' working with Core Data from  
> Tiger and XCode 2.0? Fiddling with bindings here just seemed like a  
> good opportunity to experiment, but my next project has "I (heart)  
> Core Data" written all over it.

I haven't tried Core Data (either in plain ObjC or RubyCocoa). I  
suspect not many people have tried CoreData in RubyCocoa yet since  
bindings aren't fully supported in the current release.

Re: [Rubycocoa-talk] methodSignature is nil.

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

On Jun 17, 2005, at 3:35 AM, Cornelius Jaeger wrote:

> hi
>
> also if you use bindings updating your array directly won't notify kvo.
> you have to use the proper cover methods required.
>
> if you have am images array you should implement the following and 
> update your array using these, sorry, not translated to ruby

I don't think I actually want an images array. I was trying to send a 
"valuePath", that is, just the file name of the image, and let the 
table get its own images. That didn't work, so I tried giving it the 
images themselves, which didn't work either, but now I know why. :)

> I imagine the cover methods are necessary to avoid having older code 
> exhibiting strange
> side effects (ie sending notifications around it didn't used to send)
> and to abstract (read differentiate) the bindings layer

Thanks.