Re: Helper tool
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 some sample code): LaunchOnlyOnce = YES RunAtLoad = YES OnDemand = NO The problem: it runs even when the the main app has never asked it to run. Obviously it gets started automatically on login (or even directly after reboot?). The problem, obviously, that you don't want those options. Just get rid of all of them and the default values should be fine for what you want to do. My launchd.plist just looks like this: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keylabel/key stringcom.foo.MyGreatApp/string keyMachServices/key dict keycom.foo.MyGreatApp.helper/key true/ /dict keyProgramArguments/key array string/Library/PrivilegedHelperTools/com.foo.MyGreatApp.helper/string /array /dict /plist Charles Following your advice I got rid of all of them and all was well. But then I made some changes in the main app as well as in the helper tool and nothing worked anymore. Turns out that still the old helper tool (which is no longer compatible to the new main app) was running. And nothing did change this: Quitting the helper tool via Activity Monitor, installing a newer version via SMJobBless, Deleting: /Library/PrivilegedHelperTools/name.of.Tool, Deleting: /Library/LaunchDaemons/name.of.Tool.plist , and any random combination thereof. The only way to get the new version was to log out, log in. Could it be that LaunchOnlyOnce = NO (default) means: Mac OS X takes the current version, hides it somewhere and (short of logout) stubbornly ignores all newer versions? The man pages on launchd.plist really are (as Kevin Meaney rightly mentioned) not very clear about this. Kind regards Gerriet. ___ 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
RunLoop in Helper Tool
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 *currentRunLoop = [ NSRunLoop currentRunLoop ];
CFRunLoopRef rl = [ currentRunLoop getCFRunLoop ];
NSLog(@%s will stop runloop %p,__FUNCTION__, rl); // rl ≠
NULL
CFRunLoopStop ( rl ); // runLoop will NOT stop
}
Helper Tool main:
int main(int argc, const char * argv[])
{
@autoreleasepool
{
NSString * bundleIdentifier = [[NSBundle mainBundle]
bundleIdentifier];
NSXPCListener *listener = [[NSXPCListener alloc]
initWithMachServiceName: bundleIdentifier ];
listener.delegate = ...;
[listener resume];
NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];
[ currentRunLoop run ];
}
return EXIT_SUCCESS;
}
___
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: Helper tool
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 runs even when the the main app has never asked it to run. Obviously it gets started automatically on login (or even directly after reboot?). Yep. You asked it to. Which of the 3 options above triggers this behaviour? launchd launched it for you, and your app probably just sits waiting for something to happen vs immediately acting on args and exiting when done. Delete them as Charles said. ;) See also my post one hour ago. Is there some other way to find out whether it is running? SMJobCopyDictionary(kSMDomainSystemLaunchd, …) There will be a PID entry if it's running Thanks a lot. I will check this out. Kind regards, Gerriet. ___ 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: RunLoop in Helper Tool
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 sept. 2013 à 10:32, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :
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 *currentRunLoop = [ NSRunLoop currentRunLoop ];
CFRunLoopRef rl = [ currentRunLoop getCFRunLoop ];
NSLog(@%s will stop runloop %p,__FUNCTION__, rl); // rl ≠
NULL
CFRunLoopStop ( rl ); // runLoop will NOT stop
}
Helper Tool main:
int main(int argc, const char * argv[])
{
@autoreleasepool
{
NSString * bundleIdentifier = [[NSBundle mainBundle]
bundleIdentifier];
NSXPCListener *listener = [[NSXPCListener alloc]
initWithMachServiceName: bundleIdentifier ];
listener.delegate = ...;
[listener resume];
NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];
[ currentRunLoop run ];
}
return EXIT_SUCCESS;
}
___
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/devlists%40shadowlab.org
This email sent to devli...@shadowlab.org
-- Jean-Daniel
___
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
CGImageRef as a property of a cocoa object
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 that is a property using the strong qualifier. I've seen the following discussed on stack overflow. @property (strong) __attribute__((NSObject)) CGImageRef snapShot; The discussion on stack overflow seems to suggest that using this attribute is not recommended and there is contradictory information. That you should use a typedef, or that you shouldn't. http://stackoverflow.com/questions/9684972/strong-property-with-attribute-nsobject-for-a-cf-type-doesnt-retain I'm not worried about the bug related to nonatomic that they are discussing, just the discussion about the use of the attribute. What is the recommended way of achieving what I'd like? Kevin ___ 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: CGImageRef as a property of a 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 like to have the CGImageRef object treated the same as any cocoa object that is a property using the strong qualifier. I've seen the following discussed on stack overflow. @property (strong) __attribute__((NSObject)) CGImageRef snapShot; The discussion on stack overflow seems to suggest that using this attribute is not recommended and there is contradictory information. That you should use a typedef, or that you shouldn't. http://stackoverflow.com/questions/9684972/strong-property-with-attribute-nsobject-for-a-cf-type-doesnt-retain I'm not worried about the bug related to nonatomic that they are discussing, just the discussion about the use of the attribute. What is the recommended way of achieving what I'd like? Kevin 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. The clang document also really recommends against using the typedef. Whereas the pointer will be treated correctly by ARC, it suggests other operations on it might not work, gives two examples, the inference I drew reading it was 'these two or other things we haven't really thought about'. I don't know as there is a recommended way to do what you like. In the past when I have a CoreFoundation object I want as a property, I don't specify anything in the property definition apart from readwrite and I write my own getter and setter to CFRetain()/CFRelease() it (and remember to do something appropriate to release it in dealloc). Always worked fine for me at the expense of a few lines of code. ___ 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: CGImageRef as a property of a cocoa object
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 doc it was Rob Napier. But I think your point still stands. The only comment Bill made was a request for the radar number to be made public. Going down the attribute route I think would be a win, but I think for now I'll stay safe. Kevin ___ 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: RunLoop in Helper Tool
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}
currentThread NSThread: 0x7f92b3502cf0{name = (null), num = 2}
[NSRunLoop currentRunLoop] returns the current thread run loop. If you are
not on the main thread, it will not work.
NSRunLoop *currentRunLoop = [ NSRunLoop currentRunLoop ];
CFRunLoopRef rl1 = [ currentRunLoop getCFRunLoop ]; // mode =
nil
CFRunLoopRef rl2 = CFRunLoopGetMain (); // mode =
kCFRunLoopDefaultMode
Try that instead: CFRunLoopStop(CFRunLoopGetMain());
Tried it. Even tried stopping both run loops, but to no avail. The helper tool
just will not quit.
But maybe I will be able to make my NSTimers work now having a better
understanding of what is going on.
Thanks!
Gerriet.
Le 15 sept. 2013 à 10:32, Gerriet M. Denkmann gerr...@mdenkmann.de a écrit :
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 *currentRunLoop = [ NSRunLoop currentRunLoop ];
CFRunLoopRef rl = [ currentRunLoop getCFRunLoop ];
NSLog(@%s will stop runloop %p,__FUNCTION__, rl); // rl ≠
NULL
CFRunLoopStop ( rl ); // runLoop will NOT stop
}
Helper Tool main:
int main(int argc, const char * argv[])
{
@autoreleasepool
{
NSString * bundleIdentifier = [[NSBundle mainBundle]
bundleIdentifier];
NSXPCListener *listener = [[NSXPCListener alloc]
initWithMachServiceName: bundleIdentifier ];
listener.delegate = ...;
[listener resume];
NSRunLoop *currentRunLoop = [NSRunLoop currentRunLoop];
[ currentRunLoop run ];
}
return EXIT_SUCCESS;
}
___
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: RunLoop in Helper Tool
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 ___ 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: RunLoop in Helper Tool
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 been wondering why LaunchAgent doesn't stop. Back to exit(0) it is. Kevin On 15 Sep 2013, at 15:30, Marcel Weiher marcel.wei...@gmail.com wrote: 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 ___ 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/ktam%40yvs.eu.com This email sent to k...@yvs.eu.com ___ 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: RunLoop in Helper Tool
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 tells me:
mainThreadNSThread: 0x7f92b14096a0{name = (null), num = 1}
currentThread NSThread: 0x7f92b3502cf0{name = (null), num = 2}
[NSRunLoop currentRunLoop] returns the current thread run loop. If you are
not on the main thread, it will not work.
NSRunLoop *currentRunLoop = [ NSRunLoop currentRunLoop ];
CFRunLoopRef rl1 = [ currentRunLoop getCFRunLoop ]; // mode =
nil
CFRunLoopRef rl2 = CFRunLoopGetMain (); //
mode = kCFRunLoopDefaultMode
Try that instead: CFRunLoopStop(CFRunLoopGetMain());
Tried it. Even tried stopping both run loops, but to no avail. The helper
tool just will not quit.
But maybe I will be able to make my NSTimers work now having a better
understanding of what is going on.
Now that you mention it, I remember it is not possible to stop a [NSRunLoop
run] call (at least not in a reliable way).
See the -[NSRunLoop run] documentation for an alternative way to do that, or
just call exit() as others have suggested.
-- Jean-Daniel
___
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: Helper tool
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 even when the the main app has never asked it to run. Obviously it gets started automatically on login (or even directly after reboot?). Yep. You asked it to. Which of the 3 options above triggers this behaviour? RunAtLoad=YES. It launches when the launchd job loads. OnDemand=NO makes sure it stays open. (And is also an old key which is no longer recommended for that use.) It does seem to conflict with LaunchOnlyOnce though. Based on your other email it sounds like OnDemand is winning. Following your advice I got rid of all of them and all was well. But then I made some changes in the main app as well as in the helper tool and nothing worked anymore. Turns out that still the old helper tool (which is no longer compatible to the new main app) was running. And nothing did change this: Quitting the helper tool via Activity Monitor, installing a newer version via SMJobBless, Deleting: /Library/PrivilegedHelperTools/name.of.Tool, Deleting: /Library/LaunchDaemons/name.of.Tool.plist , and any random combination thereof. The only way to get the new version was to log out, log in. Stopping the job with launchctl would work. -- Seth Willits ___ 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
NSDistributedNotificationCenter and Helper Tool
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 ];
NSLog(@%s will postNotificationName on %@,__FUNCTION__,d);
// prints: CFNotificationCenter 0x7f9f
NSDictionary *notificationInfo =
[ d postNotificationName: @some notification
object:
@some name
userInfo:
notificationInfo
];
}
];
But now one ever receives this.
This used to work before I switched to SMJobBless and Xpc.
Why is this not working anymore?
Gerriet.
P.S. I did not see anything in the documentation indicating that the
NSDistributedNotificationCenter does only work on the main thread.
This is just some blind groping in the dark.
___
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: NSDistributedNotificationCenter and Helper Tool
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 mainQueue] addOperationWithBlock:^
{
NSDistributedNotificationCenter *d = [
NSDistributedNotificationCenter defaultCenter ];
NSLog(@%s will postNotificationName on %@,__FUNCTION__,d);
// prints: CFNotificationCenter 0x7f9f
NSDictionary *notificationInfo =
[ d postNotificationName: @some notification
object:
@some name
userInfo:
notificationInfo
];
}
];
But now one ever receives this.
This used to work before I switched to SMJobBless and Xpc.
Why is this not working anymore?
Gerriet.
P.S. I did not see anything in the documentation indicating that the
NSDistributedNotificationCenter does only work on the main thread.
This is just some blind groping in the dark.
___
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: NSDistributedNotificationCenter and Helper Tool
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, 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 mainQueue] addOperationWithBlock:^
{
NSDistributedNotificationCenter *d = [
NSDistributedNotificationCenter defaultCenter ];
NSLog(@%s will postNotificationName on %@,__FUNCTION__,d);
// prints: CFNotificationCenter 0x7f9f
NSDictionary *notificationInfo =
[ d postNotificationName: @some notification
object:
@some name
userInfo:
notificationInfo
];
}
];
But now one ever receives this.
This used to work before I switched to SMJobBless and Xpc.
Why is this not working anymore?
Gerriet.
P.S. I did not see anything in the documentation indicating that the
NSDistributedNotificationCenter does only work on the main thread.
This is just some blind groping in the dark.
___
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: RunLoop in Helper Tool
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 CFRunLoopStop on the main thread. I also used to think it was a good idea to clean up after yourself. However, a lot of in-process cleanup is at best just simply wasted, the OS will recover all those resources much more effectively and safely. What’s worse, the cleanup code can cause significant issues, I remember the image processing program that swapped back a lot of its image-cache in the process of freeing it, because the malloc metadata was kept on the same VM page as the data itself. 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 been wondering why LaunchAgent doesn't stop. Back to exit(0) it is. If you get queasy about exiting so abruptly, remind yourself that sudden termination is a kill -9 … :-) Marcel ___ 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
Core Data: Primitive Accessors Ivar-Backed Properties
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 documentation error (the Core Data Programming Guide is a horrible mess, and yes, I have filed a radar). TIA, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: 64-bit iOS
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 that in 64-bit mode you won’t exceed the bounds of what an int can store. I’d say use long or NSInteger in APIs, but in storage store only what you actually need. The transition guide actually has one of the examples I ferreted out: using 64 bit integers for every part of a struct representing date components. So 64 bit year, 64 bit month (range 1-12), 64 bit day (range 1-31), 64 bit hour, 64 bit minute, 64 bit second. 64 bit doubles per color component may also be overkill, by about a factor of six. It is more common to err on the safe side instead and simply use NSInteger instead however. Alas, this is true. Marcel ___ 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: 64-bit iOS
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 problem, not a CISC problem… Marcel ___ 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: RunLoop in Helper Tool
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 after reading this discussion I thought it would be cleaner to do the CFRunLoopStop on the main thread. Back to exit(0) it is. If you get queasy about exiting so abruptly, remind yourself that sudden termination is a kill -9 … :-) And of course every Cocoa app halts by calling exit(). NSApplicationMain() never returns. (I'm pretty sure it doesn't attempt to stop the main run loop, either.) -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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
