Re: Delayed perform never performing

2018-08-24 Thread Andy Lee
On Aug 24, 2018, at 2:21 PM, James Walker  wrote:
> What could cause a delayed perform (using -[NSObject performSelector: 
> withObject: afterDelay:]) to never happen?

I'm sure you've checked, but *just in case*, I'll ask: are you sure you're not 
sending it to nil?

> I wondered if I needed to do the delayed perform in a particular run loop 
> mode, and found that [[NSRunLoop currentRunLoop] currentMode] is nil, which 
> seems odd.  Why would the run loop not be running?

Where are you checking currentMode?  I did a quick test and noticed currentMode 
is nil in my app delegate's applicationDidFinishLaunching: method (I guess 
because the run loop hasn't started yet?), but it's non-nil a little later when 
my delayed perform is called.

My delayed perform "works for me", so I'm afraid I don't have much to suggest 
regarding that.

- (void)fire:(id)arg {
NSLog(@"FIRED -- current run loop mode: %@",
  [[NSRunLoop currentRunLoop] currentMode]);
NSLog(@"%@", @"You're fired!");
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSLog(@"Did launch -- current run loop mode: %@",
  [[NSRunLoop currentRunLoop] currentMode]);
[self performSelector:@selector(fire:)
   withObject:nil
   afterDelay:0.175];
}

Output:

2018-08-24 17:34:18.852033-0400 Scratchy[94529:13604294] Did launch -- current 
run loop mode: (null)
2018-08-24 17:34:19.035517-0400 Scratchy[94529:13604294] FIRED -- current run 
loop mode: kCFRunLoopDefaultMode
2018-08-24 17:34:19.038105-0400 Scratchy[94529:13604294] You're fired!

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Delayed perform never performing

2018-08-24 Thread James Walker

On 8/24/18 11:21 AM, James Walker wrote:
What could cause a delayed perform (using -[NSObject performSelector: 
withObject: afterDelay:]) to never happen?  The requested delay is 
0.175. I've checked that it's being issued from the main thread, and 
I've checked that cancelPreviousPerformRequestsWithTarget: is not being 
called.  I wondered if I needed to do the delayed perform in a 
particular run loop mode, and found that [[NSRunLoop currentRunLoop] 
currentMode] is nil, which seems odd.  Why would the run loop not be 
running?


Never mind, I figured it out.  I had to add inModes: 
@[NSModalPanelRunLoopMode].  The code had been working when my 
formerly-Carbon app was using RunApplicationEventLoop, but now that I've 
switched
to NSApplicationMain, apparently modal loops have started using 
NSModalPanelRunLoopMode.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Carbon -> Cocoa

2018-08-24 Thread Tor Arne Vestbø
On 24 Aug 2018, at 21:16, Alastair Houghton  
wrote:
> 
> On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
>> 
>> On 23 Aug 2018, at 12:06, Alastair Houghton  
>> wrote:
>>> 
>>> Run loops are based on dispatch queues too, these days.
>> 
>> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
>> I these behave as normal sources without any sign of dispatch queues as far 
>> as I can tell?
>> 
>> I did experiment with using dispatch sources instead, but these can not be 
>> recursed, which was a showstopper unfortunately. I would have loved to use 
>> the queue debugging feature (backtrace recording) to tie posted Qt events 
>> back to their origin.
> 
> You can see the code here
> 
> https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html
> 
> Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
> very tightly integrated… CFRunLoop appears to be using dispatch queues for 
> timers, and there’s clearly integration such that dispatched calls will run 
> within the run loop.
> 
> It does still have its own separate run loop sources, observers and so on, I 
> believe; they all talk to the run loop itself via a set of Mach ports.

Right, that matches my understanding. In a sense dispatch queues are based on 
runloops as well, so your description of “tightly integrated” is accurate  

Cheers,
Tor Arne 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Carbon -> Cocoa

2018-08-24 Thread Alastair Houghton
On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
> 
> On 23 Aug 2018, at 12:06, Alastair Houghton  
> wrote:
>> 
>> Run loops are based on dispatch queues too, these days.
> 
> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
> I these behave as normal sources without any sign of dispatch queues as far 
> as I can tell?
> 
> I did experiment with using dispatch sources instead, but these can not be 
> recursed, which was a showstopper unfortunately. I would have loved to use 
> the queue debugging feature (backtrace recording) to tie posted Qt events 
> back to their origin.

You can see the code here

https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html 


Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
very tightly integrated… CFRunLoop appears to be using dispatch queues for 
timers, and there’s clearly integration such that dispatched calls will run 
within the run loop.

It does still have its own separate run loop sources, observers and so on, I 
believe; they all talk to the run loop itself via a set of Mach ports.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Carbon -> Cocoa

2018-08-24 Thread Tor Arne Vestbø
On 23 Aug 2018, at 12:06, Alastair Houghton  
wrote:
> 
> Run loops are based on dispatch queues too, these days.

Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and I 
these behave as normal sources without any sign of dispatch queues as far as I 
can tell?

I did experiment with using dispatch sources instead, but these can not be 
recursed, which was a showstopper unfortunately. I would have loved to use the 
queue debugging feature (backtrace recording) to tie posted Qt events back to 
their origin.

Cheers,
Tor Arne 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Delayed perform never performing

2018-08-24 Thread James Walker
What could cause a delayed perform (using -[NSObject performSelector: 
withObject: afterDelay:]) to never happen?  The requested delay is 
0.175. I've checked that it's being issued from the main thread, and 
I've checked that cancelPreviousPerformRequestsWithTarget: is not being 
called.  I wondered if I needed to do the delayed perform in a 
particular run loop mode, and found that [[NSRunLoop currentRunLoop] 
currentMode] is nil, which seems odd.  Why would the run loop not be 
running?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com