[MacRuby-devel] [PATCH] Added KVO array accessors

2008-11-07 Thread Benjamin Stiglitz 
These changes let you write methods for KVO accessing using natural  
Ruby syntax:


class T
kvo_array :squares do
  def size
10
  end
  def [](i)
i * i
  end
end
end

>> T.new.valueForKey('squares')
=> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

---
lib/hotcocoa.rb   |1 +
lib/hotcocoa/kvo_accessors.rb |   33 +
2 files changed, 34 insertions(+), 0 deletions(-)
create mode 100644 lib/hotcocoa/kvo_accessors.rb

diff --git a/lib/hotcocoa.rb b/lib/hotcocoa.rb
index 4ca61f0..8b294e9 100644
--- a/lib/hotcocoa.rb
+++ b/lib/hotcocoa.rb
@@ -17,5 +17,6 @@ require 'hotcocoa/data_sources/table_data_source'
require 'hotcocoa/data_sources/combo_box_data_source'
require 'hotcocoa/kernel_ext'
require 'hotcocoa/plist'
+require 'hotcocoa/kvo_accessors'

HotCocoa::Mappings.reload
diff --git a/lib/hotcocoa/kvo_accessors.rb b/lib/hotcocoa/ 
kvo_accessors.rb

new file mode 100644
index 000..1ecacdb
--- /dev/null
+++ b/lib/hotcocoa/kvo_accessors.rb
@@ -0,0 +1,33 @@
+class Object
+
+def self.kvo_array(key, &b)
+   capitalized_key = key.to_s.capitalize
+	signatures = {:size  =>  
{ selector: :"countOf#{capitalized_key}",   
type_signature: "i@:",   flip: false },
+		  :[]=>  
{ selector: :"objectIn#{capitalized_key}AtIndex:",  
type_signature: "@@:i",  flip: false },
+		  :insert=>  
{ selector: :"insertObject:in#{capitalized_key}AtIndex:",   
type_signature: "v@:@i", flip: true  },
+		  :delete_at =>  
{ selector: :"removeObjectFrom#{capitalized_key}AtIndex:",  
type_signature: "v@:i",  flip: false }

+   }
+
+   c = Module.new
+   c.module_eval &b
+   c.instance_methods.each do |m|
+   signature = signatures[m]
+   if signature
+   method = c.instance_method(m)
+   if signature[:flip]
+   method = Proc.new { |a, b| method.bind(self).call(b, a)}
+   end
+   c.send(:define_method, signature[:selector], method)
+   c.send(:remove_method, m)
+   c.method_signature(signature[:selector], 
signature[:type_signature])
+
+   elsif not Module.instance_methods.include?(m)
+   raise ArgumentError, "Method `#{m}' isn't a KVO array accessor"
+   end
+
+   end
+
+   include c
+end
+
+end
--
1.6.0.2

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [PATCH] Support for KVO set accessors

2008-11-07 Thread Benjamin Stiglitz 
We had arrays, now let's have sets, too. Refactored out the base  
redefinition code to make the set case easy to add.

---
 lib/hotcocoa/kvo_accessors.rb |   39 ++ 
+

 1 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/lib/hotcocoa/kvo_accessors.rb b/lib/hotcocoa/ 
kvo_accessors.rb

index 1ecacdb..a029413 100644
--- a/lib/hotcocoa/kvo_accessors.rb
+++ b/lib/hotcocoa/kvo_accessors.rb
@@ -2,27 +2,42 @@ class Object

 def self.kvo_array(key, &b)
capitalized_key = key.to_s.capitalize
-	signatures = {:size  =>  
{ selector: :"countOf#{capitalized_key}",   
type_signature: "i@:",   flip: false },
-		  :[]=>  
{ selector: :"objectIn#{capitalized_key}AtIndex:",  
type_signature: "@@:i",  flip: false },
-		  :insert=>  
{ selector: :"insertObject:in#{capitalized_key}AtIndex:",   
type_signature: "v@:@i", flip: true  },
-		  :delete_at =>  
{ selector: :"removeObjectFrom#{capitalized_key}AtIndex:",  
type_signature: "v@:i",  flip: false }
+	signatures = { :size  =>  
{ selector: :"countOf#{capitalized_key}",   
type_signature: "i@:",   flip: false },
+		   :[]=>  
{ selector: :"objectIn#{capitalized_key}AtIndex:",  
type_signature: "@@:i",  flip: false },
+		   :insert=>  
{ selector: :"insertObject:in#{capitalized_key}AtIndex:",   
type_signature: "v@:@i", flip: true  },
+		   :delete_at =>  
{ selector: :"removeObjectFrom#{capitalized_key}AtIndex:",  
type_signature: "v@:i",  flip: false }

}
+   define_methods_with_signatures(signatures, &b)
+end
+
+def self.kvo_set(key, &b)
+   capitalized_key = key.to_s.capitalize
+	signatures = { :add   =>  
{ selector: :"add#{capitalized_key}Object:",type_signature:  
"v@:@", flip: false },
+		   :delete=>  
{ selector: :"remove#{capitalized_key}Object:", type_signature:  
"v@:@", flip: false},
+		   :merge =>  
{ selector: :"add#{capitalized_key}:",  type_signature:  
"v@:@", flip: false },
+		   :subtract  =>  
{ selector: :"remove#{capitalized_key}:",   type_signature:  
"v@:@", flip: false },
+		   :set   =>  
{ selector: :"#{key}",  type_signature:  
"@@:",  flip: false }

+   }
+   define_methods_with_signatures(signatures, &b)
+end

+private
+def self.define_methods_with_signatures(signatures, &b)
c = Module.new
c.module_eval &b
c.instance_methods.each do |m|
signature = signatures[m]
if signature
-   method = c.instance_method(m)
-   if signature[:flip]
-   method = Proc.new { |a, b| method.bind(self).call(b, a)}
-   end
-   c.send(:define_method, signature[:selector], method)
-   c.send(:remove_method, m)
-   c.method_signature(signature[:selector], 
signature[:type_signature])
+   method = c.instance_method(m)
+   if signature[:flip]
+   method = Proc.new { |a, b| method.bind(self).call(b, a)}
+   end
+   c.send(:define_method, signature[:selector], method)
+   c.send(:remove_method, m)
+	c.method_signature(signature[:selector],  
signature[:type_signature])


elsif not Module.instance_methods.include?(m)
-   raise ArgumentError, "Method `#{m}' isn't a KVO array accessor"
+   raise ArgumentError, "Method `#{m}' isn't a KVO array accessor"
end

end
--
1.6.0.2

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Hotcocoa design ethos [was Re: [feature request] open url in browser]

2008-11-09 Thread Benjamin Stiglitz 
So, which is it, guys?  A glorified macro pre-processor with enough  
canned macros to illustrate how to use the same approach in your own  
applications, or an attempt to simplify Cocoa programming where it  
genuinely cries out for simplification, hopefully also in cases  
which are commonly used enough to generate real bang-for-buck?


Rich, Laurent and I talked about this at length this weekend, and I  
think we can safely say that we’d to improve upon Cocoa and Mac OS X  
development in Ruby.


One example we cooked up was this:

play_sound do |t|
  sin(440.0 * t * 2.0 * Math::PI)
end

Setting up a simple CoreAudio configuration is a pain; you need to  
dive into the component manager, and wire together a bunch of  
callbacks and audio units, and…ugh. In HotCocoa we have a chance to  
make audio generation into a nice simple operation.


We had plenty more ideas; I’m sure they’ll be shared in this forum  
when we all get caught up on the rest of our lives.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] PBI - MacRuby aux Fines Merbs...

2008-11-12 Thread Benjamin Stiglitz 
PS: Credits to Laurent who has been making an effort on writing more  
and more tests for

the core part of MacRuby! :)


Ditto. I should say that the RubySpec effort is also useful for  
testing MacRuby, in as much as it provides coverage for the vast  
majority of the behavior which MacRuby shares with 1.9 (YARV? I never  
know what to call it anymore). There are bound to be wrinkles with  
regards to some of the natively bridged classes, but we ought to  
document these in our own specs as well.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] KVO dot notation bug?

2008-11-20 Thread Benjamin Stiglitz 

Sure seems like a bug to me. Any ideas?


Sounds like it’s related to ticket #164. I’ll be looking into it Real  
Soon Now™.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] What's the best way to implement a delegate/action with multiple parameters?

2008-11-21 Thread Benjamin Stiglitz 
I'm pretty new to Cocoa, so maybe I'm overlooking the obvious here.   
I just want to make sure I'm not doing more work than necessary.


I'd like to be able to control the minimum size for a NSSplitView.   
As I understand it, I need to have a delegate with a method that can  
handle

splitView:constrainMaxCoordinate:ofSubviewAt:

So far that isn't supported using Interface Builder, is it?

If I need to do it 'manually'  - do I get a reference to the  
NSSplitView, and then tell it to set its delegate to something that  
responds to the method?  When/where should I do this - in the Window  
Controller's AwakeFromNib or some other place?


You can set the delegate in Interface Builder by ctrl-clicking from  
the split view to the delegate object and clicking “delegate” in the  
resulting HUD popup. Then just implement that method on your delegate  
object.


If you haven’t already, be sure to check out the Delegates and Data  
Sources guide at:



-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] sub classing with hot cocoa

2008-12-02 Thread Benjamin Stiglitz 
I am sure there is an easy answer to this question, but I have not  
figured it out after some experimenting (nor can I find an example  
in the examples)


What do I do if i want to subclass (say) an NSView ? And yet still  
employ that subclass with all the rest of the hot cocoa magic? (so  
without using nib/xibs)


I would do this to overwrite the drawRect callback for NSView for  
example - perhaps to do some animation.


class MyView < NSView
  def drawRect(r)

  end
end

or, even better in some cases

a = view(:something)
class << a
  def drawRect(r)

  end
end

-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] attr_accessor on NSManagedObject

2009-01-05 Thread Benjamin Stiglitz 

I subclassed a Core Data entity Recipe with PPRecipe < NSManaged
object, and created accessors for the fields:

class PPRecipe < NSManagedObject
 attr_accessor :name, :desc, :type, :imagePath, :serves
end

but these fields now don't save or display correct after I create
objects, and restart the app for example.


The generated accessors are writing to ivars instead of the CoreData  
store.


What do I need to do to get accessors working for NSManagedObject  
attributes?



I think what you really need is either:
• an attr_dynamic to replicate the behavior of the @dynamic property  
getters in Objective-C, or,
• an attr_coredata (or similar) call in HotCocoa which calls the  
primitive getters and setters.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] NSManagedObject being returned in delegate as Pointer

2009-01-05 Thread Benjamin Stiglitz 
In practice, you should avoid passing objects as context to methods  
like this one, because their implementation won't keep a GC  
reference to them, so they might disappear during a collection cycle.


Since the Cocoa frameworks are GC-aware, these are generally strong  
pointers.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] accessing ruby objects from Objective-C

2009-02-10 Thread Benjamin Stiglitz 
 I describe calling ruby side objects from the ObjC side. I can make  
it work using dynamic classes but of course that generates compiler  
warnings (like no '-baz' method found). Of course it still works,  
but is there any way for my ObjC classes to know at compile time  
what are the class names and methods on the ruby classes?


Not really, since this list is potentially dynamic.

That being said, it’d be nice if the runtime could dump a header for  
the current state of a class, ScriptingBridge-style. I might look into  
this.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] accessing ruby objects from Objective-C

2009-02-18 Thread Benjamin Stiglitz 
That being said, it’d be nice if the runtime could dump a header  
for the current state of a class, ScriptingBridge-style. I might  
look into this.


That would be awesome. Something like sdef/sdp for Ruby classes  
maybe those tools would be useful already.


Would be trivial to implement, maybe we could even introduce a  
parameter to the macruby executable to do this post-evaluation! Ben,  
wanna look at this? :-)


Yes, I do. It’ll go to the top of my MacRuby-When-I-Have-Time-And-No- 
Young-Children list. =)


(Actually I can probably take a look sooner than that.)

-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Accessing Obj-C InstVars from Ruby

2009-04-01 Thread Benjamin Stiglitz 
Is there a way to access instance variables defined in an  
Objective-C

class from a Ruby extension?


It is currently not implemented, but it's technically possible. A  
good work-around is to define accessors (properties) as John  
mentioned.


Maybe we need MacRuby::Runtime to bubble up the Obj-C runtime. Or FFI.

-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] # of developers

2009-04-01 Thread Benjamin Stiglitz 

Here is the blurb:
http://www.macruby.org/project.html


I should say that I’m not a very frequent contributor, so you can  
subtract one from the #size of that list.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Strings, Encodings and IO

2009-04-07 Thread Benjamin Stiglitz 
So plan B: We emulate Ruby 1.9 strings behavior on top of of  
NSString/NSData.


I'm really interested in this discussion too. A little background  
for JRuby:


Thanks for the background, Charlie. This sort of history is very  
instructive.


* Java's strings are all UTF-16. In order to represent binary data,  
we ended up using a "raw" encoder/decoder and only using the bottom  
byte of each character. Wasteful, since every string was 2x as  
large, and slow, since IO had to up/downcast byte[] contents to  
char[] and back.


Most CFStrings use a UTF-16 internal store as well.

* We want to move to an intermediate version, where we sometimes  
have a byte[]-backed string and sometimes a char[]/String-backed  
string. IronRuby does this already. This is, however, predicated on  
the idea that byte[]-based strings rarely become char[]-based  
strings and vice versa. I don't have any evidence for or against  
that yet.


So it's a nearly identical problem for MacRuby, as I understand it.  
I'm interested in discussion around this topic, since we are still  
moving forward with JRuby and would like to improve interop with  
Java libraries. I will offer the following food for thought:


* Going with 100% objc strings at first is probably a good pragmatic  
start. You'll have the perf/memory impact of encoding/decoding and  
wasteful string contents, but you should be able to get it  
functioning well. And since interop is a primary goal for MacRuby  
(where it's been somewhat secondary in JRuby) this is probably a  
better place to start.


That’s where things stand today, and with Laurent’s ByteString work  
this all mostly works as long as you don’t try to change encodings  
around on strings.


* Alternatively, you could only support a minimum set of encodings  
and make it explicit that internally everything would be UTF-16 or  
MacRoman. In MacRuby's case, I think most people would happily  
accept that, just as a lot of JRuby users would probably accept that  
everything's UTF-16 since that's what they get from Java normally.


This seems like a bad situation in the face of the varied encoding  
landscape on the Internet.


Ultimately this is the exact reason I argued over a year ago that  
Ruby 1.9 should introduce a separate Bytes class used for IO. I was  
denied.


I was disappointed to see this turned down as well. The encoding  
situation in 1.9 feels worse than it was in 1.8, and that’s pretty  
impressive.


It's definitely a sticky issue, and Ruby has made it even stickier  
in 1.9 with arbitrary encoding support. None of the proposed  
solutions across all implementations (including JRuby) have really  
seemed ideal to me.


Laurent and I discussed this a bit tonight, and here’s what I think we  
can get away with:


By default, store all strings as NSString (UTF-16 backed) with an ivar  
to store the encoding e.

When getting bytes, convert to a ByteString in the appropriate encoding.
When doing force_encoding, convert to a ByteString in the old  
encoding, then try to convert to an NSString in the new encoding. If  
we succeed, great. If not, leave as a tagged ByteString (and probably  
whine about it).

All ASCII-8BIT strings are backed by ByteString.

There’s some simplification here; some of the ByteStrings are really  
just NSDatas, &c., but the flow is there. Sorry the list above is a  
mess, I’m up much later than I’m accustomed to.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Strings, Encodings and IO

2009-04-08 Thread Benjamin Stiglitz 
When doing force_encoding, convert to a ByteString in the old  
encoding, then try to convert to an NSString in the new encoding.  
If we succeed, great. If not, leave as a tagged ByteString (and  
probably whine about it).


That's actually wrong. All force_encoding does is change the  
encoding attribute of the string, it shouldn't change the internal  
encoding of the bytes. The encoding attribute is basically a switch  
to describe which set of string methods should be used on the bytes.


We have to go through this dance to get force_encoding to play nicely  
with NSString. Namely, NSString is always backed by an array of UTF-16  
code points. So, to reinterpret, we have to convert the internal rep  
to whatever the external encoding was, then back in, converting to  
UTF-16 from the new external encoding.


We're in the same hypothetical HTTP library as before, and this  
library author has decided to

_always_ force encoding to Shift JIS because he hates humanity:

 response = HTTP.get('http://example.com')
 response.body.encoding #=> Encoding::Shift_JIS

If MacRuby internally forces the body encoding to Shift JIS  
information might get lost. So when

someone decides to make it right afterwards:

 encoding = response.header['Content- 
type'].split(';').last.split('=').last

 encoding #=> 'utf-8'

They might get into trouble here:

 response.body.force_encoding(Encoding::UTF_8)

Cuz'

 Encoding.compatible?(Encoding::Shift_JIS, Encoding::UTF_8) #=> nil


Vincent already answered this part; we’re still doing reinterpretation  
of what is essentially the original bytestream. Are there any  
encodings that map multiple sequences to the equivalent code point?  
(And I’m not talking about Unicode NFC/NFD/&c., that still makes it  
through the UTF-16 link alright.)


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Cocoa control to replace the GtkTable widget ?

2009-04-08 Thread Benjamin Stiglitz 
Question, I would like to know if there is a "cocoa like" of the  
GtkTable widget


http://pygtk.org/pygtk2tutorial/sec-PackingUsingTables.html


NSMatrix, sort of.

To quote every other post on cocoa-dev: what are you trying to do?

-Ben___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Cocoa control to replace the GtkTable widget ?

2009-04-08 Thread Benjamin Stiglitz 

Sorry, thank you for your help


I’m not sure if I was able to help!

When I asked “what are you trying to do,” I meant: “what does the UI  
you are trying to create look like?” NSMatrix is only appropriate for  
certain, very limited interfaces. Otherwise you’ll need to roll your  
own, or play in IB.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] retrieving password from keychain

2009-04-23 Thread Benjamin Stiglitz 

Thanks for the reply Laurent.  Yes I did generate a BridgeSupport file
and included it in my build.  I did try to call the method and pass in
a pointer for the item reference (using Pointer.new_for_type('@')) but
the object that was assigned after the call was some weird NSCFType
object which, when I googled it, basically translates to "you're
screwed" :)   I do get some malloc warnings when I include the
bridgesupport file so I was a bit uneasy about the whole thing.


Actually, in this particular case an NSCFType is exactly what you  
expect, since SecKeychainItemRef isn’t toll-free bridged with an  
Objective-C type.


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] kvo vs referenced hash

2009-09-08 Thread Benjamin Stiglitz 
 Coming from a Ruby background, I try to understand and pick the  
best from Obj-C/Cococa and learn how to use brilliant ideas to  
improve my coding.


Tonight I was working on a simple demo app to learn how things are  
done in the Obj-C world and see how they would transpose to the  
MacRuby world.


Everything went well until the KVO question came along.

Let's say I have a controller that we are going to call Brain.
We also have a lot of simpler objects that don't do anything but  
having a state and being displayed, we are going to call them Task  
instances. The brain is called every X seconds to "think".


My understanding is that an Obj-C developer would register all the  
tasks instance with the brain using a KVO and the brain would send  
notifications when it's being called to "think".  So, every time a  
new task is being created, an observer is added on the brain with  
the new task key. Each Task instance has an  
observeValueForKeyPath:ofObject:change:context: method implemented  
which checks that the notification is meant for itself and if it is,  
to act accordingly.


While the concept is simple and attractive. I wonder if it wouldn't  
be simpler to forget about kvo's and simply keep the list of  
registered tasks in the brain and the brain would call the tasks  
directly and tell them to change.


It sounds to me that in the MacRuby world, it would be more  
efficient. If we have 250 tasks for instance, when a notification is  
being sent, every single task in the 250 tasks created, will receive  
the notification and will check what to do with it. If we had a  
simple hash/dictionary in the brain, we could directly find the task  
to handle and call it directly without having to go through the 250.


Am I missing something or in this specific case and because we use  
Ruby, KVO aren't the way to go?


KVO isn’t really the right hammer for your nail, but I’m not sure I  
understand your scenario properly.


You have a Brain which every «interval» picks a task to work on and  
does some work.


KVO is about observing changes in a key’s value and doing something  
with it. It’s an inter-object dependency mechanism. A common way to  
use it is to update some UI when the value of a model object’s key  
changes. An example:


You have a table view which shows the current state of all your tasks.  
Each task is just a countdown from 10 to 0, and you want the table to  
display what stage in the countdown each object is at. Your controller  
observes all the tasks, and when a task changes it tells the  
appropriate row in the table to refresh.


In your case, the Brain has nothing the tasks are interested in  
observing. “I’m doing some work” doesn’t make sense from an OO point  
of view since the Brain should be doing the work and not the Task.


Hope that helps,

-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] objc block and ruby block?

2009-09-16 Thread Benjamin Stiglitz 
This is currently not implemented. It is not planned for the  
upcoming release mostly because I don't think it's that important,  
since all block methods in Cocoa also have methods dealing with  
function pointers, which will be supported.


Not true of some of the new Foundation and AppKit APIs. This should be  
doable since we know what the low-level implementation for blocks is  
and we can build a the right trampoline.


Of course, given my circumstances (not enough time for anything), “me”  
means “you.”


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Implementing Undo In RaiseMan / MacRuby

2009-10-27 Thread Benjamin Stiglitz 

  def insertObject(p, inEmployeesAtIndex:index)
NSLog("adding #{p} to #{employees}") # <= Not called, huh?
undo = @undoManager
undo.prepareWithInvocationTarget(self,  
removeObjectFromEmployeesAtIndex:index)

if !undo.isUndoing
  undo.setActionName("Insert Person")
end
employees.insertObject(p, atIndex:index)
  end


FWIW, the third line of the body should read
undo.prepareWithInvocationTarget(self).removeObjectFromEmployeesAtIndex 
(index)


-Ben
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel