rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] super_init and others (e.g. super_initWithContents)

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

On 26 Nov 2005, at 0:32, Rupert BARROW wrote:
>
> In MyObject, I have defined :
> 	ns_overrides 'init'
> 	MyObject.init
> in which I make a call to super_initWithContents(value)
>
> This method is not found :
> 	RBException_NameError, reason undefined method  
> `super:initWithContents:' for class `MyObject'

The super_* method is only defined after calling ns_overrides. So,  
super_init is defined because you've overridden init, but  
super_initWithContents is not.

Since initWithContents has not been overridden in your subclass, just  
call 'self.initWithContents(value)' - that should fall through to the  
superclass implementation.

Re: [Rubycocoa-talk] Re: Newbie: stack level too deep??[MESSAGE NOT SCANNED]

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

On 28 Nov 2005, at 7:21, Frank Illenberger wrote:

> I could dig a little deeper and found the following stack trace is  
> repsonsible for a "Stack level too deep" exception:

Ah, the problem is that the ruby code is being executed on a  
secondary NSThread. Unfortunately, Ruby is not thread-safe with  
respect to OS-level threads (which an NSThread is).

Ruby checks from time to time that the stack has not overflowed, and  
since the non-main thread will have a different area of memory for  
its stack than the main thread, Ruby thinks a stack overflow has  
occurred.

I'm afraid that there's probably no good way to work around this at  
the moment. It may be possible to get RubyCocoa running with Sydney  
[1], which apparently gives OS-level thread support. Do let us know  
if you give that a shot.

Sorry I don't have better news for you
Cheers
Jonathan


[1] http://blog.fallingsnow.net/articles?page=2

[Rubycocoa-talk] Re: Newbie: stack level too deep??

[Frank I. <ill...@ma...>]

I could dig a little deeper and found the following stack trace is  
repsonsible for a "Stack level too deep" exception:

#0  0x928f6428 in +[NSException exceptionWithName:reason:userInfo:] ()
#1  0x00071c64 in override_mixin_class_method_list ()
#2  0x00071d50 in override_mixin_class_method_list ()
#3  0x000720d0 in override_mixin_class_method_list ()
#4  0x00070ba4 in ocstr_to_rbstr ()
#5  0x928cf574 in -[NSObject(NSForwardInvocation) forward::] ()
#6  0x909c40d0 in _objc_msgForward ()
#7  0x00070c4c in ocstr_to_rbstr ()
#8  0x92938708 in _NSGetUsingKeyValueGetter ()
#9  0x928eb360 in -[NSObject(NSKeyValueCoding) valueForKeyPath:] ()
#10 0x1001badc in -[WBLPart pullValues:] (self=0x673c20,  
_cmd=0x100584bc, key=0x6733f0)
#11 0x1001bc64 in -[WBLPart pullValues] (self=0x673c20, _cmd=0x100584a4)
#12 0x1001bd78 in -[WBLPart pullValues] (self=0x672390, _cmd=0x100584a4)
#13 0x1001bd78 in -[WBLPart pullValues] (self=0x670a90, _cmd=0x100584a4)
#14 0x1001bcb8 in -[WBLPart pullValues] (self=0x670990, _cmd=0x100584a4)
#15 0x1001bd78 in -[WBLPart pullValues] (self=0x664250, _cmd=0x100584a4)
#16 0x1002e14c in -[WBLPhase processRequest:] (self=0x6713c0,  
_cmd=0x100571fc, request=0x66cfa0)
#17 0x10017e1c in -[WBLProject processRequest:] (self=0x627ee0,  
_cmd=0x100571fc, request=0x66cfa0)
#18 0x1001ef98 in -[WBLHandler handleRequest:] (self=0x62d1e0,  
_cmd=0x10058900, request=0x66cfa0)
#19 0x1001f1d0 in -[WBLHandler request:] (self=0x62d1e0,  
_cmd=0x10056fb4, request=0x66cfa0)
#20 0x1001602c in -[WBLApplication request:] (self=0x627ee0,  
_cmd=0x10057ac0, request=0x66cfa0)
#21 0x1003a81c in -[WBLAdaptorThread request:] (self=0x63b980,  
_cmd=0x10057ac0, req=0x66cfa0)
#22 0x1003ab38 in -[WBLAdaptorThread onSocket:didReadData:withTag:]  
(self=0x63b980, _cmd=0x1005bc0c, sock=0x6607e0, data=0x671060, tag=2)
#23 0x100370a0 in -[AsyncSocket completeCurrentRead] (self=0x6607e0,  
_cmd=0x1005b400)
#24 0x10036e18 in -[AsyncSocket doBytesAvailable] (self=0x6607e0,  
_cmd=0x1005b414)
#25 0x10036a30 in -[AsyncSocket maybeDequeueRead] (self=0x6607e0,  
_cmd=0x1005b428)
#26 0x928e6138 in __NSFireDelayedPerform ()
#27 0x90770ae0 in __CFRunLoopDoTimer ()
#28 0x9075d458 in __CFRunLoopRun ()
#29 0x9075ca0c in CFRunLoopRunSpecific ()
#30 0x928ea664 in -[NSRunLoop runMode:beforeDate:] ()
#31 0x9292f298 in -[NSRunLoop runUntilDate:] ()
#32 0x1003a4e0 in -[WBLAdaptorThread runWorkerThread] (self=0x63b980,  
_cmd=0x1005c340)
#33 0x928db6d4 in forkThreadForFunction ()
#34 0x9002b200 in _pthread_body ()

I already tried to increase the stack limit with ulimit -s but this  
did not change anything.

Anyone any ideas?

Cheers

  Frank

Am 27.11.2005 um 03:55 schrieb Frank Illenberger:

> Hi,
>
> this week I discovered RubyCocoa and was impressed how nicely it  
> integrates with cocoa. I immediately tried to include it into my  
> server application. In the beginning it worked as I expected, but  
> after my program runs for a while, it quits with the following  
> error message:
>
> /Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/Contents/ 
> Resources/rb_main.rb:22:in `NSApplicationMain': stack level too  
> deep (SystemStackError)
> 	from /Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/ 
> Contents/Resources/rb_main.rb:22
>
> In my test I have a simple ruby class extending a custom cocoa  
> class and in it is a simple attribute with accessors which the rest  
> of my application calls via KV-coding.
>
> class RubyComponent < OSX::WBLComponent
>
> 	attr_reader :testWert
> 	attr_writer :testWert
>
> end
>
>
> Does anybody know where such a behavior is coming from? Does it  
> play a role that the KV-calls come from different threads/run loops  
> (but never concurrently)?
>
>
> Cheers
>
>
>  Frank
>

Re: [Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles Miller wrote:
> On 25/11/2005, at 9:26 PM, Jonathan Paisley wrote:
> 
>> If you're able to recompile both ruby and rubycocoa, you could give 
>> it a shot. It's still necessary to make AppKit calls on the main 
>> thread (use self.performSelector...), but you can do ruby-level 
>> background tasks ok. I've attached the two patches - one to 
>> ruby-1.8.2 and one to RubyCocoa.
> 
> Is there some way (preferably with idiot-proof instructions :) ) to 
> ship the patched Ruby runtime with an app? I'd like to use RubyCocoa  to
> write an application that pulls information from the network, so  if you
> can't do work in a background thread without recompiling Ruby,  it's
> pretty much a non-starter.

In the archives of this list there's a 'standaloneify' script, and it
seems to work as well with a patched ruby as with an unpatched.

- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDilitf7mnligQOmERArbWAJsGVQ8GiufHTh6h5s3+jhZ0qxKusQCdF2a6
o0gwAFFVCJZyrEKJqqK5q7Y=
=J894
-----END PGP SIGNATURE-----

Re: [Rubycocoa-talk] Long processing?

[Charles M. <cm...@pa...>]

On 25/11/2005, at 9:26 PM, Jonathan Paisley wrote:
> If you're able to recompile both ruby and rubycocoa, you could give  
> it a shot. It's still necessary to make AppKit calls on the main  
> thread (use self.performSelector...), but you can do ruby-level  
> background tasks ok. I've attached the two patches - one to  
> ruby-1.8.2 and one to RubyCocoa.

Is there some way (preferably with idiot-proof instructions :) ) to  
ship the patched Ruby runtime with an app? I'd like to use RubyCocoa  
to write an application that pulls information from the network, so  
if you can't do work in a background thread without recompiling Ruby,  
it's pretty much a non-starter.

C

[Rubycocoa-talk] Newbie: stack level too deep??

[Frank I. <ill...@ma...>]

Hi,

this week I discovered RubyCocoa and was impressed how nicely it  
integrates with cocoa. I immediately tried to include it into my  
server application. In the beginning it worked as I expected, but  
after my program runs for a while, it quits with the following error  
message:

/Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/Contents/ 
Resources/rb_main.rb:22:in `NSApplicationMain': stack level too deep  
(SystemStackError)
	from /Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/Contents/ 
Resources/rb_main.rb:22

In my test I have a simple ruby class extending a custom cocoa class  
and in it is a simple attribute with accessors which the rest of my  
application calls via KV-coding.

class RubyComponent < OSX::WBLComponent

	attr_reader :testWert
	attr_writer :testWert

end


Does anybody know where such a behavior is coming from? Does it play  
a role that the KV-calls come from different threads/run loops (but  
never concurrently)?


Cheers


  Frank

Re: [Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Paisley wrote:
> You may need stopAnimation(nil), which is a method on 
> NSProgressIndicator, whereas stopAnimation_ is defined on  NSAnimation.
> That might fix it.

Good call.   I just slapped a nil onto startAnimation and stopAnimation,
and it's nice and neat now.  I don't even need those hanging underscores
anymore, which suggests to me that the reason I needed them was possibly
that I was missing the argument.

> Sorry, I should have been clearer in my original post.
> 
> self.performSelector doesn't help any here - it just ends up calling 
> back on the same thread. There are some other performSelector... 
> methods that are of use, in particular
> performSelectorOnMainThread_withObject_waitUntilDone. This schedules  a
> call during a pass on the main thread runloop. It's important to  always
> give 'waitUntilDone' as false here, because otherwise it  degenerates
> into a direct call like performSelector.
> 
> I need to have more of a think about the thread safety here, but it's 
> possible that everything will work out if you fix stopAnimation(nil)  -
> without needing to do the performSelector... stuff at all.
> 
> Let me know how you get on.

It worked just doing the calls from the secondary thread, but just in
case, I've switched it to use
performSelectorOnMainThread_withObject_waitUntilDone, and it's still
working great.

Thank you very much.  Without this threading my little XHTML validator
would be unpleasant to use, with its frozen UI during the checking and all.

Thanks again!

- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDiPUaf7mnligQOmERArMIAJwJooyYGAir8hpwG6U0WoS5UToBaACfcQj7
Rj5OMn50Rk6nGL7AdoLDCvI=
=p2fO
-----END PGP SIGNATURE-----

Re: [Rubycocoa-talk] Long processing?

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

On 26 Nov 2005, at 5:40, Neil Stevens wrote:
>
> def endCheck
> 	@resultsSpinner.stopAnimation_
> 	@textField.setEnabled(true)
> 	@button.setTitle('Validate')
> end
>
> The app crashes for me on the stopAnimation_ call, but doesn't crash
> when I omit that call.

You may need stopAnimation(nil), which is a method on  
NSProgressIndicator, whereas stopAnimation_ is defined on  
NSAnimation. That might fix it.

> So am I doing this wrong here?  I'm learning Cocoa as I go here, never
> having used it before trying Ruby Cocoa.  What would be the right  
> way to
> call back to the main thread?

Sorry, I should have been clearer in my original post.

self.performSelector doesn't help any here - it just ends up calling  
back on the same thread. There are some other performSelector...  
methods that are of use, in particular
performSelectorOnMainThread_withObject_waitUntilDone. This schedules  
a call during a pass on the main thread runloop. It's important to  
always give 'waitUntilDone' as false here, because otherwise it  
degenerates into a direct call like performSelector.

I need to have more of a think about the thread safety here, but it's  
possible that everything will work out if you fix stopAnimation(nil)  
- without needing to do the performSelector... stuff at all.

Let me know how you get on.

Thanks
Jonathan

Re: [Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Actually, now I'm having some trouble.  It was actually working for me
just fine when I was disabling an NSTextField, and changing the title of
an NSButton at the start of a thread, then enabling the field and
restoring the button title back at the end.

It started crashing on me when I tried adding an NSProgressIndicator to
spin during the processing, though.  So, I took your hint and looked up
what performSelector is, but it still crashes on me when I do this in my
WindowController:

def buttonClicked
	# Clear table data array

	Thread.new do
		self.performSelector('startupCheck')

		data loop do
			# Do stuff, and add to the table data array
			@table.noteNumberOfRowsChanged
		end

		self.performSelector('endCheck')
	end
end

def startupCheck
	@resultsSpinner.startAnimation_
	@textField.setEnabled(false)
	@button.setTitle('Cancel')
end

def endCheck
	@resultsSpinner.stopAnimation_
	@textField.setEnabled(true)
	@button.setTitle('Validate')
end

The app crashes for me on the stopAnimation_ call, but doesn't crash
when I omit that call.

So am I doing this wrong here?  I'm learning Cocoa as I go here, never
having used it before trying Ruby Cocoa.  What would be the right way to
call back to the main thread?

thanks,

P.S. I have the underscores added because I get a 'methodSignature is
null' exception if I make the call without the underscore.

- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDh/VAf7mnligQOmERAgo5AJ4iwJ4HyerriZbHiXZQrwZw+yvMAACbBqke
u9Ol0ed7N9PpIKE8VjUCF5A=
=uUhx
-----END PGP SIGNATURE-----

[Rubycocoa-talk] Fwd: super_init and others (e.g. super_initWithContents)

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

D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 :

> in which I make a call to super_initWithContents(value)

Sorry, please read :

   in which I make a call to self. super_initWithContents(value)

Rup=

[Rubycocoa-talk] super_init and others (e.g. super_initWithContents)

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

Hi all,

I have defined a subclass of NSObject (eg MyAbstractObject). I now  
define a subclass of this and call it MyObject.

I have defined :
	ns_overrides 'init'
	MyAbstractObject.init
and	MyAbstractObject.initWithContents(value)

In MyObject, I have defined :
	ns_overrides 'init'
	MyObject.init
in which I make a call to super_initWithContents(value)

This method is not found :
	RBException_NameError, reason undefined method  
`super:initWithContents:' for class `MyObject'

Am I proceeding correctly ?  I remember subclassing in RubyCocoa was  
fixed a few weeks ago, but does this also appky for super_init-ing ?

thanks for any help,
Rup

Re: [Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Paisley wrote:
> OS-level threads don't work because Ruby doesn't support them, and  ruby
> threads don't work reliably because of unpleasant interactions  with the
> ObjC exception handling mechanism.
> 
> I made a patch to ruby and rubycocoa a while ago that attempts to  work
> around the latter problem - i.e., it lets you use Ruby threads  in a
> RubyCocoa application.
> 
> If you're able to recompile both ruby and rubycocoa, you could give  it
> a shot. It's still necessary to make AppKit calls on the main  thread
> (use self.performSelector...), but you can do ruby-level  background
> tasks ok. I've attached the two patches - one to  ruby-1.8.2 and one to
> RubyCocoa.

The patches work just great here.  Thanks!

- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDh6Mcf7mnligQOmERAt4nAJ9xdsCplfEHvsUxFLyiQ+WuGqWKxACdFv21
pk4+VDTPBKhf2kncKxr2PyQ=
=AoMe
-----END PGP SIGNATURE-----

Re: [Rubycocoa-talk] Long processing?

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

On 25 Nov 2005, at 8:41, Neil Stevens wrote:

> Dave Baldwin wrote:
>> Run the long processing in a separate thread.
>
> That doesn't seem to work here, probably because ruby threads aren't
> OS-level threads. It was the first thing I tried though, heh.

OS-level threads don't work because Ruby doesn't support them, and  
ruby threads don't work reliably because of unpleasant interactions  
with the ObjC exception handling mechanism.

I made a patch to ruby and rubycocoa a while ago that attempts to  
work around the latter problem - i.e., it lets you use Ruby threads  
in a RubyCocoa application.

If you're able to recompile both ruby and rubycocoa, you could give  
it a shot. It's still necessary to make AppKit calls on the main  
thread (use self.performSelector...), but you can do ruby-level  
background tasks ok. I've attached the two patches - one to  
ruby-1.8.2 and one to RubyCocoa.

Thanks
Jonathan

Re: [Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Baldwin wrote:
> Run the long processing in a separate thread.

That doesn't seem to work here, probably because ruby threads aren't
OS-level threads. It was the first thing I tried though, heh.

thanks again,

- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDhs4vf7mnligQOmERApCZAJ4plgtdZaYqrbhqj22VsBQrQyQk7gCghYMH
l21wD+4kE89v7f097U2mWrE=
=WPQo
-----END PGP SIGNATURE-----

Re: [Rubycocoa-talk] Long processing?

[Dave B. <dav...@3d...>]

On 25 Nov 2005, at 01:56, Neil Stevens wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> How do I keep my GUI responsive during some long processing that I'm
> doing in response to, say, a button press?  Ideally I'd like to  
> update a
> tableview with the results as they come, and allow the user to click a
> cancel button.
>
> thanks,
> - --
> Neil Stevens - ne...@ha...
>

Run the long processing in a separate thread.

Dave.

[Rubycocoa-talk] Long processing?

[Neil S. <ne...@ha...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How do I keep my GUI responsive during some long processing that I'm
doing in response to, say, a button press?  Ideally I'd like to update a
tableview with the results as they come, and allow the user to click a
cancel button.

thanks,
- --
Neil Stevens - ne...@ha...

'A republic, if you can keep it.' -- Benjamin Franklin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDhm9bf7mnligQOmERAl+jAJ9mYIApYO+52vY3pr5/YJ1JsWxYpwCcCWwT
h1H/TAFUfM3VlyE4MUjFKps=
=+uWA
-----END PGP SIGNATURE-----

[Rubycocoa-talk] [ANN]0.4.2 Xcode-2.2 patch

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

Hi,

Building RubyCocoa fails with following environment. We released 
a patch to fix this problem and a patched source archive.

* Mac OS X 10.4.x
* Xcode 2.2
* system built-in ruby (/usr/bin/ruby)

http://sourceforge.net/project/showfiles.php?group_id=44114&package_id=36578&release_id=369687


- In detail -

Xcode 2.2 moved header files of ruby.

* Xcode 2.2 : /usr/lib/ruby/1.8/powerpc-darwin8.0
* Xcode 2.1/2.0 : /usr/lib/ruby/1.8/universal-darwin8.0

/usr/bin/ruby with rbconfig says archdir is same as old value, and 
config step of RubyCocoa installation fails.

This patch replaces strings in archdir value "pewerpc" to "universal"
when ruby.h is not found in archdir. 


-- 
kimura wataru

Re: [Rubycocoa-talk] Comparing to OSX::NSDragOperationDelete

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

Hi,

I think method "draggingSourceOperationMaskForLocal:" of protocol
NSDraggingSource is missing.

http://www.cocoabuilder.com/archive/message/cocoa/2005/8/3/143456

Tom Counsell wrote:
>Hello
>
>I have a feeling this is a stupid question, but I just can't figure  
>it out.
>
>I have created a subclass of an NSOutlineView in order to implement  
>drag to trash.  Everything works fine, except that the operation  
>variable passed by Cococa to the method  
>draggedImage_endedAt_operation isn't one of the OSX::NSDragOperation  
>constants:
>

>Whereas the OSX::NSDragOperationDelete constant is always the Fixnum  
>32, the operation returned is a Bignum with a variety of values.
>
>What am I missing? Why can't I compare the returned operation with  
>the constant?
>


RubyCocoa gets arguments' type of informal protocol from a class
DummyProtocolHandler. I wondered a bug in this process. I tested 
the method draggedImange:endedAt:operation: and got fine result.

------
% cat dnd.rb
require 'osx/cocoa'

class DraggingSource < OSX::NSObject
  def draggedImage_endedAt_operation( animage, apoint, operation )
    raise "error #{operation}" unless operation == OSX::NSDragOperationDelete
    nil
  end
end

drag = DraggingSource.alloc.init
drag.ocm_send('draggedImage:endedAt:operation:', nil, [0,0], OSX::NSDragOperationDelete)

% ruby -d dnd.rb
    :
  2005-11-23 12:59:25.195 ruby[12834] RBOBJ:methodSignatureForSelector(draggedImag
  e:endedAt:operation:)
  2005-11-23 12:59:25.196 ruby[12834] RBOBJ:   --> NSMethodSignature: types=v@:@{_
  NSPoint=ff}I nargs=5 sizeOfParams=160 returnValueLength=0; 
  2005-11-23 12:59:25.196 ruby[12834] OBJWRP:ocm_invoke (draggedImage:endedAt:oper
  ation:): ret_type=v
* 2005-11-23 12:59:25.196 ruby[12834] OBJWRP:    arg_type[0]: @
* 2005-11-23 12:59:25.196 ruby[12834] OBJWRP:    arg_type[1]: {_NSPoint=ff}
* 2005-11-23 12:59:25.197 ruby[12834] OBJWRP:    arg_type[2]: I
* 2005-11-23 12:59:25.197 ruby[12834] OBJWRP:    NSInvocation#invoke (draggedImage
  :endedAt:operation:) ...
  2005-11-23 12:59:25.197 ruby[12834] RBOBJ:methodSignatureForSelector(draggedImag
  e:endedAt:operation:)
    :
------


-- 
kimura wataru

[Rubycocoa-talk] Comparing to OSX::NSDragOperationDelete

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

Hello

I have a feeling this is a stupid question, but I just can't figure  
it out.

I have created a subclass of an NSOutlineView in order to implement  
drag to trash.  Everything works fine, except that the operation  
variable passed by Cococa to the method  
draggedImage_endedAt_operation isn't one of the OSX::NSDragOperation  
constants:

# Method described at http://developer.apple.com/documentation/Cocoa/ 
Reference/ApplicationKit/ObjC_classic/Protocols/NSDraggingSource.html
def draggedImage_endedAt_operation( animage, apoint, operation )
       OSX::NSLog "Trying to delete? #{operation.inspect} # 
{OSX::NSDragOperationDelete}"
       OSX::NSLog("Is a delete operation") if operation ==  
OSX::NSDragOperationDelete
   end

Whereas the OSX::NSDragOperationDelete constant is always the Fixnum  
32, the operation returned is a Bignum with a variety of values.

What am I missing? Why can't I compare the returned operation with  
the constant?

Thanks

Tom

Re: [Rubycocoa-talk] undefined method `%' for nil class

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

On 22 Nov 2005, at 18:06, Dave Baldwin wrote:

> I occasionally get this error:
>
> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
> osx/objc/oc_wrapper.rb:80:in `NSApplicationMain': NSApplicationMain  
> - RBException_NoMethodError - undefined method `%' for nil:NilClass  
> (OSX::OCException)
> 	from /Users/dave/Chips/DES/mediaUI/build/Development/tui.app/ 
> Contents/Resources/rb_main.rb:22
>
> I haven't been able to reproduce it reliably but if you look in the  
> line in question it should be impossible to get this error as far  
> as I can see:
>
>
> 79:	m_args.each_with_index do |val, index|
> 80:	   if (index % 2) == 0 then                             <<<<  
> error on this line
> 81:	       args.push(val)
> 82:	   else
> 83:	       mname += "_#{val.to_s}"
> 84:	    end
> 85:	end

That is indeed strange. Perhaps you could add some code in at line 80  
that explicitly checks if index is nil, and if so dumps contents of  
m_args and val?

Also, if possible, try with ruby 1.8.2. Perhaps it's something  
introduced in 1.8.3 that's triggering the problem.

Cheers
Jonathan

[Rubycocoa-talk] undefined method `%' for nil class

[Dave B. <dav...@3d...>]

I occasionally get this error:

/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_wrapper.rb:80:in `NSApplicationMain': NSApplicationMain -  
RBException_NoMethodError - undefined method `%' for nil:NilClass  
(OSX::OCException)
	from /Users/dave/Chips/DES/mediaUI/build/Development/tui.app/ 
Contents/Resources/rb_main.rb:22

I haven't been able to reproduce it reliably but if you look in the  
line in question it should be impossible to get this error as far as  
I can see:


79:	m_args.each_with_index do |val, index|
80:	   if (index % 2) == 0 then                             <<<<  
error on this line
81:	       args.push(val)
82:	   else
83:	       mname += "_#{val.to_s}"
84:	    end
85:	end


unless the stack is getting corrupted or something.

dave 2% ruby -v
ruby 1.8.3 (2005-09-21) [powerpc-darwin8.2.2]
on Tiger 10.4.3
with rubycocoa version
VERSION = "0.4.2"
STAGE = ""
RELEASE_DATE = "2005-11-10"


I am not doing anything fancy with rubycocoa - some simple drawing to  
the screen (fonts, images and filled rectangles) and handling  
keyboard events.

Does this ring any bells with anyone.  I will try to find a way of  
reproducing the problem reliably.

Dave.

Re: [Rubycocoa-talk] Ruby-fying the SyncServices - SimpleStickies tutorial fom Apple

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

On 18 Nov 2005, at 23:00, Rupert BARROW wrote:

> - I cannot programmatically (from Ruby) add objects to the Notes  
> controller to get them inserted into GUI

I can't see any code that tries to do that. Can you indicate what  
you've tried?

I've figured out the problem with the key-value coding. You can make  
the following simplifications to the code:

  (1) no need for 'kvc_wrapper'
  (2) no need to call kvc_wrapper_representation at all
  (3) no need for @_changed instance variable or corresponding methods

Important bit - change this:

> 	def valueForUndefinedKey(k)
> 		@_representation.valueForKey(k)
> 	end
> 	
> 	def setValue_ForUndefinedKey(v, k)
> 		@_representation.setValueForKey(v, k)
> 	end

to this:

   def rbValueForKey(k)
     @_representation.valueForKey(k)
   end

   def rbSetValue_forKey(v,k)
     self.willChangeValueForKey(k)
     @_representation.setValueForKey(v,k)
     self.didChangeValueForKey(k)
   end

Here's why:

RubyCocoa (in OverrideMixin.m) overrides valueForUndefinedKey: and  
setValue:forUndefinedKey: and passes them through to rbValueForKey  
and rbSetValue_forKey, which are defined in oc_import.rb.

The definition in oc_import.rb looks for ruby-like setters/getters  
and calls them, calling the willChange/didChange... methods when  
necessary also.

So, for example, [obj setValue: x forUndefinedKey: @"y"] ends up  
calling 'obj.y = x' in ruby-land.

Since the valueForUndefinedKey: and setValue... methods are defined  
at a low level in OverrideMixin.m, the original definition in Note.rb  
never took effect. By overriding instead the ruby delegates  
(rbValue.. etc) we can achieve the desired effect.



I think it may be neater in the long-run to make the kvc_accessor  
methods in oc_import.rb define real methods (using  
addRubyMethod_withType) and avoid the undefined key hack altogether.  
I'll have a look into this.

Hope that makes some sense,
Jonathan

Re: [Rubycocoa-talk] Ruby-fying the SyncServices - SimpleStickies tutorial fom Apple

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

> 	def setValue_ForUndefinedKey(v, k)
> 		@_representation.setValueForKey(v, k)
> 	end

That method should probably have 'forUndefinedKey' with a lower-case  
'f'.

[Rubycocoa-talk] [PATCH] Ruby-fying the SyncServices - SimpleStickies tutorial fom Apple

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

On 18 Nov 2005, at 23:00, Rupert BARROW wrote:
>
> What I cannot get to work :
> - reading from the XML persistence file store : this must due to  
> some issue with archiving/unarchiving. To get the program to work  
> properly, delete file in ~/Library/Application Support/SyncExamples  
> before every launch

I haven't looked the whole project in detail yet, but the following  
patch to the RubyCocoa framework fixes this:

=== src/objc/OverrideMixin.m
==================================================================
--- src/objc/OverrideMixin.m    (revision 15)
+++ src/objc/OverrideMixin.m    (local)
@@ -255,7 +255,7 @@
{
    id new_obj;
    id slave;
-  new_obj = class_createInstanceFromZone(klass, 0, zone);
+  new_obj = class_createInstanceFromZone(klass, 0, zone ? zone :  
NSDefaultMallocZone());
    slave = slave_obj_new(new_obj);
    set_slave(new_obj, slave);
    return new_obj;

[Rubycocoa-talk] XCode project for Ruby-fied SImpleStickies Tutorial

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

Jonathan,
Did you receive the XCode project I sent by email ?
Emails to your address are bouncing with the following message :
<jp...@dc...>: host mr1.dcs.gla.ac.uk[130.209.249.184] said:
     550-rejected because 212.27.42.27 is in a black list at 550
     rbl-plus.mail-abuse.ja.net (in reply to RCPT TO command)

Rupert