On 13 Sep 2013, at 22:09, Charles Srstka cocoa...@charlessoft.com wrote:
On Sep 13, 2013, at 8:47 AM, Gerriet M. Denkmann gerr...@mdenkmann.de
wrote:
I have a helper tool (started via SMJobBless from the main app).
Its launchd.plist contains (no idea why, probably I copied this from
I have a Helper Tool, running as root, started via SMJobBless and communicating
vie Xpc.
Works fine, but:
1. it cannot stop (CFRunLoopStop),
2. Timers never fire
3. NSRunLoop currentMode returns nil.
Maybe all three things are related.
To 1:
if ( asked to quit )
{
NSRunLoop
On Sep 13, 2013, at 6:47 AM, Gerriet M. Denkmann wrote:
I have a helper tool (started via SMJobBless from the main app).
Its launchd.plist contains (no idea why, probably I copied this from some
sample code):
LaunchOnlyOnce = YES
RunAtLoad = YES
OnDemand = NO
The problem: it
XPC is based on GCD. There is chance that your request handling occurs in a GCD
thread and not on the main thread.
[NSRunLoop currentRunLoop] returns the current thread run loop. If you are not
on the main thread, it will not work.
Try that instead: CFRunLoopStop(CFRunLoopGetMain());
Le 15
I'm using ARC on Xcode (unmentionable) on OS X redacted using latest features.
I do believe however that we are allowed to discuss ARC related issues as they
are already published on the clang.llvm.org website.
Anyway I'd like to have the CGImageRef object treated the same as any cocoa
object
On 15 Sep, 2013, at 6:26 pm, Kevin Meaney k...@yvs.eu.com wrote:
I'm using ARC on Xcode (unmentionable) on OS X redacted using latest
features. I do believe however that we are allowed to discuss ARC related
issues as they are already published on the clang.llvm.org website.
Anyway I'd
The clang document which bbum links to says it has to be a typedef. So that
gives you two good reasons, one that the documentation mandates a typedef and
the other that Bill Bumgarner weighed in. So I'd say, if you want to try
this, you have to use a typedef.
It wasn't Bill linking to that
On 15 Sep 2013, at 16:42, Jean-Daniel Dupas devli...@shadowlab.org wrote:
XPC is based on GCD. There is chance that your request handling occurs in a
GCD thread and not on the main thread.
Correct. NSThread tells me:
mainThread NSThread: 0x7f92b14096a0{name = (null), num = 1}
On Sep 15, 2013, at 10:32 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
I have a Helper Tool, running as root, started via SMJobBless and
communicating vie Xpc.
Works fine, but:
1. it cannot stop (CFRunLoopStop),
Do all the cleanup you want to do and then exit(0) ?
Marcel
Interesting that you should say that.
I was doing exit(0) but after reading this discussion I thought it would be
cleaner to do the CFRunLoopStop on the main thread. Unfortunately I'd broken my
LaunchAgent doing some other stuff at the time and just now I've got stuff
working and then I've
Le 15 sept. 2013 à 16:23, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :
On 15 Sep 2013, at 16:42, Jean-Daniel Dupas devli...@shadowlab.org wrote:
XPC is based on GCD. There is chance that your request handling occurs in a
GCD thread and not on the main thread.
Correct. NSThread
On Sep 15, 2013, at 2:02 AM, Gerriet M. Denkmann wrote:
I have a helper tool (started via SMJobBless from the main app).
Its launchd.plist contains (no idea why, probably I copied this from some
sample code):
LaunchOnlyOnce = YES
RunAtLoad = YES
OnDemand = NO
The problem: it runs
I have a Helper Tool, running as root, started via SMJobBless and communicating
vie Xpc.
Sometimes it does:
[[NSOperationQueue mainQueue] addOperationWithBlock:^
{
NSDistributedNotificationCenter *d = [
NSDistributedNotificationCenter defaultCenter ];
Hi Gerriet.
You need to use the option NSNotificationPostToAllSessions.
-Jeff
On Sep 15, 2013, at 12:15 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
I have a Helper Tool, running as root, started via SMJobBless and
communicating vie Xpc.
Sometimes it does:
[[NSOperationQueue
On 16 Sep 2013, at 00:26, Jeff Johnson publicpost...@lapcatsoftware.com wrote:
You need to use the option NSNotificationPostToAllSessions.
Jeff, you are absolutely right. Now everything works as it should.
Thank you very much!
Kind regards,
Gerriet.
On Sep 15, 2013, at 12:15 PM,
On Sep 15, 2013, at 17:04 , Kevin Meaney k...@yvs.eu.com wrote:
On 15 Sep 2013, at 15:30, Marcel Weiher marcel.wei...@gmail.com wrote:
Do all the cleanup you want to do and then exit(0) ?
I was doing exit(0) but after reading this discussion I thought it would be
cleaner to do the
Does anyone know whether it is useful to implement primitivekey accessors for
scalar attributes modeled with standard attribute types that are backed by
ivars? The docs show both approaches (with/without) but don't show why the
difference, although I am inclined to think it is just a
On Sep 14, 2013, at 16:58 , David Duncan david.dun...@apple.com wrote:
On Sep 14, 2013, at 7:37 AM, vipgs99 vipg...@gmail.com wrote:
So do I need replace all int to NSInteger?
Technically no, but generally you do need to evaluate every usage of data
types of a specific width and ensure
On Sep 10, 2013, at 23:47 , Tom Davie tom.da...@gmail.com wrote:
Note, this was actually more significant on x86, where most of the mess
caused by CISC (like having bugger all registers) got sorted out.
? VAX had 16, M68K had 16, hmm, NS32032 only had 8. I’d say this was a an
Intel ’86
On Sep 15, 2013, at 10:50 AM, Marcel Weiher marcel.wei...@gmail.com wrote:
On Sep 15, 2013, at 17:04 , Kevin Meaney k...@yvs.eu.com wrote:
On 15 Sep 2013, at 15:30, Marcel Weiher marcel.wei...@gmail.com wrote:
Do all the cleanup you want to do and then exit(0) ?
I was doing exit(0) but
20 matches
Mail list logo
