NSLocale currentLocale for Root User
Hi, What is the expected value for [[NSLocale currentLocale] objectForKey:NSLocaleLanguageCode] when running as root? In my French installed version (actually selected French for install, did not change user pref) of 10.5.8, I get back ³fr², however, in my French installed version of 10.6, I get back ³en². Ed *** This e-mail and its attachments are confidential, legally privileged, may be subject to copyright and sent solely for the attention of the addressee(s). Any unauthorized use or disclosure is prohibited. Statements and opinions expressed in this e-mail may not represent those of Radialpoint. Le contenu de ce courriel est confidentiel, privilégié et peut être soumis à des droits d'auteur. Il est envoyé à l'intention exclusive de son ou de ses destinataires. Il est interdit de l'utiliser ou de le divulguer sans autorisation. Les opinions exprimées dans le présent courriel peuvent diverger de celles de Radialpoint. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Garbage collecting live threads
thanks! On Mon, Sep 14, 2009 at 3:26 PM, Jens Alfke wrote: > > On Sep 14, 2009, at 11:54 AM, Edward Chan wrote: > > Would mythread be considered garbage and be collected even though it >> hasn't >> finished running? If so, would it be cancelled first? Or would it just get >> killed? >> > > Threads aren't garbage collected; they're implemented at a lower level. (Or > you can think of it as that the thread scheduler always has a reference to > all live threads.) They'll remain in existence until they exit or are > explicitly killed. > > —Jens ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Garbage collecting live threads
Hi,
How does the garbage collector react to live threads in which there are no
references to it?
For example,
myclass {
NSThread *mythread;
}
mythread = [[NSThread alloc] initWith];
[mythread start];
...
//mythread is still running its main method
mythread = nil;
Would mythread be considered garbage and be collected even though it hasn't
finished running? If so, would it be cancelled first? Or would it just get
killed?
Ed
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: KVO on Distributed Objects with exception handling.
I've just tested it on Snow Leopard (10a380), and it works as expected.
Do you happen to remember the technical reasons why KVO on DOs would fail?
Ed
On Mon, Sep 7, 2009 at 11:55 PM, Scott Anguish wrote:
> In spite of the fact that it might be working, it isn't supported.
>
> When I talked to engineering about this, this is what I was told. He was a
> bit shocked it worked at all, and it isn't tested as part of releases.
>
>
>
> On Sep 7, 2009, at 3:02 PM, Edward Chan wrote:
>
>> Hello,
>>
>> I'm using KVO on a Distributed Object, and I am binding my UI controls
>> based on the observer.
>>
>> For example:
>>
>> MonkeyViewController.isEatingABanana -> Binded to a UI checkbox.
>>
>> MonkeyViewController.m:
>>
>> @propery (readwrite, assign) BOOL isEatingABanana;
>>
>> -(id)init {
>> ...
>> [MonkeyBrainDOObject addObserver:self
>> forKeyPath:@"banana"
>> options:(NSKeyValueObservingOptionNew |
>> NSKeyValueObservingOptionOld)
>> context:NULL];
>>
>> ...
>> }
>>
>> - (void)observeValueForKeyPath:(NSString *)keyPath
>> ofObject:(id)object
>> change:(NSDictionary *)change
>> context:(void *)context
>> {
>> if ([keyPath isEqualToString:@"banana]") {
>> [self willChangeValueForKey:@"isEatingABanana"];
>> isEatingABanana = [change objectForKey:NSKeyValueChangeNewKey]
>> boolValue];
>> [self didChangeValueForKey:@"isEatingABanana"];
>> }
>> }
>>
>> - (void)setIsEatingABanana:(BOOL)flag
>> {
>> [MonkeyBrainDOObject setBanana:flag];
>> isEatingABanana = flag;
>> }
>>
>>
>> This indeed works, and we save some hassles of sending NSNotifications and
>> such.
>>
>> So, what I'm wondering is if the following code is sufficient enough
>> for the IPC exception handling?
>> Instead of having to manually write @try/@catch wherever I doing some
>> IPC, I create a wrapper object around the DO to handle the exceptions.
>> This wrapper class is simply an NSObject, and will call the methods
>> methodSignatureForSelector, and forwardInvocation when I try to use
>> MonkeyBrainDOObject methods (since the wrapper does not understand
>> them). I can then insert a @try/@catch when I forward the invokations
>> to the actual DO object.
>>
>> MonkeyBrainWrapper.m : NSObject
>>
>> - (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
>> {
>> return [MonkeyBrainDOObject methodSignatureForSelector:selector];
>> // maybe I can use extra code to make sure MonkeyBrainDOObject
>> responds to the selector.
>> }
>>
>> - (void)forwardInvocation:(NSInvocation *)invocation
>> {
>> �...@try {
>> [invocation invokeWithTarget:MonkeyBrainDOObject];
>> } @catch (NSException *e) {
>> // Oh no! some went wrong with the IPC. But it's ok, I caught you..
>> :P
>> }
>> }
>>
>> So, instead of calling directly on the MonkeyBrainDOObject in my
>> MonkeyViewController, I would now call my MonkeyBrainWrapper object,
>> which has explicit exception handling rather than the one handle by
>> the NSApplication.
>>
>>
>> Should that be enough for exception handling on both ends of the IPC?
>> Or do I need some explicit exception handling on the other end? It
>> seems when I tested it out, my other end never threw anything when the
>> connection broke.
>> Also, is there maybe a better approach to all of this? My old code had
>> a bunch of NSNotifications being sent/received whenever something
>> needed updating on the UI, and I found this approach to be a lot
>> cleaner.
>>
>> Edward
>> ___
>>
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/scott%40cocoadoc.com
>>
>> This email sent to sc...@cocoadoc.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: KVO on Distributed Objects with exception handling.
Also, Did they explain why they didn't want to support it? Thanks, Ed On Mon, Sep 7, 2009 at 4:45 PM, Edward Chan wrote: > Great... > > How long ago did you ask the Apple engineers? I haven't tried this > piece of code with Snow Leopard actually... > > > On Mon, Sep 7, 2009 at 3:29 PM, Graham Lee wrote: >> On Sep 7, 2009, at 20:02 , Edward Chan wrote: >> >>> Hello, >>> >>> I'm using KVO on a Distributed Object, and I am binding my UI controls >>> based on the observer. >> >> Hi, >> >> not much of constructive help from me I'm afraid, just a warning. I also did >> the same thing once, and the reaction from Apple engineers went through >> denial, shock and fear, but never got as far as acceptance. In fact I was >> told that combining KVO with DO is not supported and if it does work now, >> don't expect it to work in the future. >> >> Cheers, >> >> Graham. >> > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: KVO on Distributed Objects with exception handling.
Great... How long ago did you ask the Apple engineers? I haven't tried this piece of code with Snow Leopard actually... On Mon, Sep 7, 2009 at 3:29 PM, Graham Lee wrote: > On Sep 7, 2009, at 20:02 , Edward Chan wrote: > >> Hello, >> >> I'm using KVO on a Distributed Object, and I am binding my UI controls >> based on the observer. > > Hi, > > not much of constructive help from me I'm afraid, just a warning. I also did > the same thing once, and the reaction from Apple engineers went through > denial, shock and fear, but never got as far as acceptance. In fact I was > told that combining KVO with DO is not supported and if it does work now, > don't expect it to work in the future. > > Cheers, > > Graham. > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
KVO on Distributed Objects with exception handling.
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI controls
based on the observer.
For example:
MonkeyViewController.isEatingABanana -> Binded to a UI checkbox.
MonkeyViewController.m:
@propery (readwrite, assign) BOOL isEatingABanana;
-(id)init {
...
[MonkeyBrainDOObject addObserver:self
forKeyPath:@"banana"
options:(NSKeyValueObservingOptionNew |
NSKeyValueObservingOptionOld)
context:NULL];
...
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
{
if ([keyPath isEqualToString:@"banana]") {
[self willChangeValueForKey:@"isEatingABanana"];
isEatingABanana = [change objectForKey:NSKeyValueChangeNewKey] boolValue];
[self didChangeValueForKey:@"isEatingABanana"];
}
}
- (void)setIsEatingABanana:(BOOL)flag
{
[MonkeyBrainDOObject setBanana:flag];
isEatingABanana = flag;
}
This indeed works, and we save some hassles of sending NSNotifications and such.
So, what I'm wondering is if the following code is sufficient enough
for the IPC exception handling?
Instead of having to manually write @try/@catch wherever I doing some
IPC, I create a wrapper object around the DO to handle the exceptions.
This wrapper class is simply an NSObject, and will call the methods
methodSignatureForSelector, and forwardInvocation when I try to use
MonkeyBrainDOObject methods (since the wrapper does not understand
them). I can then insert a @try/@catch when I forward the invokations
to the actual DO object.
MonkeyBrainWrapper.m : NSObject
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
{
return [MonkeyBrainDOObject methodSignatureForSelector:selector];
// maybe I can use extra code to make sure MonkeyBrainDOObject
responds to the selector.
}
- (void)forwardInvocation:(NSInvocation *)invocation
{
@try {
[invocation invokeWithTarget:MonkeyBrainDOObject];
} @catch (NSException *e) {
// Oh no! some went wrong with the IPC. But it's ok, I caught you.. :P
}
}
So, instead of calling directly on the MonkeyBrainDOObject in my
MonkeyViewController, I would now call my MonkeyBrainWrapper object,
which has explicit exception handling rather than the one handle by
the NSApplication.
Should that be enough for exception handling on both ends of the IPC?
Or do I need some explicit exception handling on the other end? It
seems when I tested it out, my other end never threw anything when the
connection broke.
Also, is there maybe a better approach to all of this? My old code had
a bunch of NSNotifications being sent/received whenever something
needed updating on the UI, and I found this approach to be a lot
cleaner.
Edward
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
NSWorkspace openURL does not launch application
Hello, It seems that NSWorkspace.openURL() is not launching my default application. For example, if I try use openURL to open http://www.nhl.com, Safari/Firefox/etc will not launch and ultimately fail to load the url. However, if Safari/Firefox is already running, it will open the url in a new window/tab. Has anyone encountered a similar problem? Ed ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
