rubycocoa-talk

[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-----

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.

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?

[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

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?

[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-----

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

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?

[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

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-----