Re: NSRunLoop method - configureAsServer alternative in 10.6.1?
It was actually deprecated in 10.5 according to the header, and the
10.5 release notes explain:
Deprecated NSRunLoop API
The -configureAsServer method is deprecated in 10.5. It never did
anything, so there was never a point in calling it in Mac OS X.
Since time immemorial the implementation looked like this:
- (void)configureAsServer {
}
So any apparently beneficial effect of calling it was entirely
coincidental.
Chris Kane
Cocoa Frameworks, Apple
On Sep 30, 2009, at 7:23 AM, Nick Rogers wrote:
Hi,
When I use [[NSRunLoop currentRunLoop] configureAsServer]; after
creating a service using NSConnection, it works.
But -configureAsServer is declared as deprecated with no alternative
suggested.
I tried removing it and the code doesn't work.
server code snippet: (doesn't work)
MYMessageServer *server = self;// here "self" is in instance of
MyMessageServer class
NSConnection *defaultConnection;
[[NSNotificationCenter defaultCenter] addObserver:server
selector:@selector(connectionDidDie:)
name:NSConnectionDidDieNotification
object:nil];
defaultConnection = [NSConnection
serviceConnectionWithName:@"MyCompanyName.MyProductName.serverFull"
rootObject:server];
[defaultConnection addRunLoop:[NSRunLoop currentRunLoop]];
// not doing [[NSRunLoop currentRunLoop] run]; here as its the main
thread.
Client code snippet:
server = [[NSConnection
rootProxyForConnectionWithRegisteredName
:@"MyCompanyName.MyProductName.serverFull" host:nil] retain];
server is nil after the above line is executed.
Where can I find a simple implementation?
Or what changes to make to the above code?
Thanks,
Nick
___
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/ckane%40apple.com
This email sent to ck...@apple.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: Rescheduling an NSTimer from a completion method
On Aug 11, 2009, at 10:28 AM, Fritz Anderson wrote:
iPhone OS 3.0
Can an NSTimer be rescheduled after firing, and after another trip
through the run loop?
I'd like to "reschedule" a NON-repeating timer in my own code. I
assume that in the simple case it would be something like:
- (void) handleTimer: (NSTimer *) aTimer
{
// ... do things ...
[aTimer setFireDate: someTimeInTheFuture];
[[NSRunLoop currentRunLoop] addTimer: aTimer forMode:
NSDefaultRunLoopMode];
}
I'm pretty sure that this is legal — am I right?
No, as you suspected farther down in your message. NSTimers which are
not repeating are one-shot -- they cannot be rescheduled. Create a
new NSTimer, when you next need it, and add it to the run loop. [And
also self.myTimerIvar = nil; in your timer handler as you thought.]
Chris Kane
Cocoa Frameworks, Apple
___
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: NSDateFormatter formats from NSLocale
You can call [[NSLocale currentLocale] localeIdentifier], to get the locale identifier of the user's preferred locale, and then create another NSLocale from it. This will be a locale that doesn't have any (not just formatting) user preference overrides in it but is still the user's preferred base locale. That might be close to what you want. Contrary to popular opinion [not just yours], NSLocale and NSDateFormatter also do not know the element orders. They just pass off the work to lower-level libraries, which -- as far as I understand it -- also do not themselves directly know what the order is (only indirectly through sets of format strings). For one thing, the Short date format for a locale might have one order, the Medium another, the Long yet another, and so on. Chris Kane Cocoa Frameworks, Apple On Aug 11, 2009, at 9:51 AM, Houdah - ML Pierre Bernard wrote: Hi Sean, I want to respect the user's locale, yet ignore his/her preferences as to formatting. I thought about modifying the format I get from the standard styles. I would however expect NSLocale to know the correct order of elements in the date format. Pierre So you want to use the user's preference and yet you don't. The choice of leading zeros or no is part of the user's choice. But if you must, you could get the user's format string and carefully alter it to add leading zeros. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: Adding more and more key/value observers is much too slow - workaround needed.
Don't pass the observer as the context: argument; pretty much anything
else is better. Passing NULL (just, for example) flattens the curve
quite a bit. If you have nothing better to pass in, put this in your
code and pass the address of it:
static char _xyzzy_ = 0;
Chris Kane
Cocoa Frameworks, Apple
On Aug 3, 2009, at 6:51 AM, Andreas Känner wrote:
Hi,
If you add more and more key/value observers with
addObserver:forKeyPath:options:context: this call takes longer and
longer in a non-linear way.
I posted a bug report today (ID: 7112953) but maybe someone already
has a workaround. Here is my sample code:
#include
@interface ModelObject : NSObject
{
NSString* title;
}
@property (readwrite, copy) NSString* title;
@end
@implementation ModelObject
@synthesize title;
@end
@interface Observer : NSObject
{}
@end
@implementation Observer
@end
void addObservers(NSUInteger count)
{
// Create model objects and observers:
NSMutableArray* modelObjects = [NSMutableArray
arrayWithCapacity:count];
NSMutableArray* observers = [NSMutableArray
arrayWithCapacity:count];
for(NSUInteger i=0; i options:NSKeyValueObservingOptionNew |
NSKeyValueObservingOptionOld
context:observer];
}
NSLog(@"time to add %d observers: %f s", count, -[startDate
timeIntervalSinceNow]);
}
int main (int argc, const char * argv[])
{
NSAutoreleasePool* pool = [NSAutoreleasePool new];
addObservers(10);
addObservers(100);
addObservers(1000);
addObservers(1);
[pool release];
}
In my test case an observer does always observe only one object and
each observed object is only observed by one observer. I think this
is a common use case.
I have results for Snow Leopard too, but I think I'm not allowed to
post them on this mailing list. Here are the results for Leopard:
I tested this with different build settings (with/without GC and
32/64bit)
Machine: iMac 2.4 GHz Intel Core 2 Duo
Leopard (10.5.7/9J61):
32Bit:
With GC:
time to add10 observers: 0.001008 s
time to add 100 observers: 0.001796 s
time to add 1000 observers: 0.174864 s
time to add 1 observers: 10.746330 s
Without GC:
time to add10 observers: 0.000920 s
time to add 100 observers: 0.000956 s
time to add 1000 observers: 0.056894 s
time to add 1 observers: 4.615175 s
64Bit:
With GC:
time to add10 observers: 0.001340 s
time to add 100 observers: 0.001533 s
time to add 1000 observers: 0.125700 s
time to add 1 observers: 7.545702 s
Without GC:
time to add10 observers: 0.001058 s
time to add 100 observers: 0.000831 s
time to add 1000 observers: 0.053189 s
time to add 1 observers: 4.006754 s
Notes:
If you know a workaround for this bottleneck please drop me an email.
___
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/ckane%40apple.com
This email sent to ck...@apple.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: Need localization-proof method of transporting dates.
Now that everybody else has had their say, I'll throw in my two bits: ;-) * as others have pointed out, never store the hash of an object or data computed from the hash, nor transmit the hash of an object outside a process, if your goal is to compare it in any way with anything else (for example, storing it as [part of] keys in a database with the later hope of using the hash to retrieve records). * the best thing to compare against (and include in your SHA-1 hash) is the result of the -timeIntervalSinceReferenceDate method (- timeIntervalSince1970 is equivalent, just shifted by a constant offset); the time interval is an absolute timescale that is not affected by time zones, locales, or calendars. * the current time interval of the machine can be gotten with +[NSDate timeIntervalSinceReferenceDate], and you need not mess with an NSDate object itself if you don't want to. * NSDates just store a time interval in the absolute scale; they themselves are not affected by time zones, locales, or calendars. However, when you produce a different representation of the date, that different representation can be affected by other factors. For example, breaking down the time interval into calendrical components (year, month, day, ...) must be done in relation to some calendar, and often in relation to some time zone. So, if you ever rely on the user's settings of these on their machine for their account, you've lost. Plus the algorithms for "breaking down" and "reconstituting" from components can have bugs or get changes from OS release to OS release (unless you just write your own), and of course time zone data can change between OS releases (and software updates), so going through the extra steps of using calendrical components would have you relying on a lot more stuff remaining unchanged. * Using a string representation of a date is the absolute worst possibility, since it's affected by all those things listed above (time zones, locales, and calendars), plus involves components, plus is a different representation. There might be some people who would say "an all-numeric components representation would be fine [if you made sure to generate it with respect to some specific fixed calendar and time zone]", but beyond what I've already noted, with a string representation you have the excitement of different Unicode code points that could be used to represent the digits (e.g., try running in an Arabic locale) or even different number representation systems (e.g., the Roman numerals of the Romans or the base-60 of the Babylonians -- I don't know if any locales have such a thing today, but unless _you_ know, it's best to just stay away). So you should be sure to also generate the string description entirely yourself as well; don't use the system code for that. So all that is why I suggest skipping all the extra work and intermediate steps and just use the timeIntervalSinceReferenceDate. It's a nice double, and you can compare with <, >, etc. (Of course, if you choose to hash the 8 bytes of the double as a chunk of bytes, then you have to take machine representation of doubles into account and make sure you know what you're doing there.) Chris Kane Cocoa Frameworks, Apple On Apr 4, 2009, at 5:01 AM, Graham Cox wrote: My app encodes expiry dates for demo versions, etc. One problem I've had occasional reports of is that the expiry is prematurely detected, and it seems to be on systems with system language set other than English. I need to store and check the dates in a way that is not sensitive to this. I thought I was, yet the reports persist. Here's what I'm doing: The stored date originally comes from a NSDatePicker control, textual with stepper. I retrieve the date using its -dateValue method. The date, along with other data, is digitally signed with a SHA-1 hash, which in turn is based on the object's -hash method. As far as I could tell, the -hash method returns a value that is sensitive to the actual stored date, but not to the date localization on the system. At runtime, the date is recovered and verified by rehashing and comparing the hash, then the date value is simply compared to see if the current date is before or after it using [[NSDate date] timeIntervalSinceDate:expiryDate] (if negative, hasn't expired). Can anyone spot any problem with this approach? Note that the SHA-1 check appears to pass OK - it's the date comparison that seems to be wrong. Unfortunately I can't reproduce the bug locally so I'm relying on reports from relatively non-technical testers who aren't able to give me much to go on. --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/Up
Re: Date parsing problem (when running on iphone only)
On Mar 4, 2009, at 4:22 AM, Jacob Rhoden wrote: On 4/3/09 10:15 PM, Jacob Rhoden wrote: Anyone experience this weird behaviour with date parsing? Given the following code, it produces a different log output when running in the simulator or on the iPhone!!! NSString* test = @"Monday 26 January 2009 3:47:33 pm +"; NSDateFormatter *df = [[NSDateFormatter alloc] init]; [df setDateFormat: @" dd h:mm:ss a Z"]; NSLog(@"DATE: %@ to %i", test, [df dateFromString: test]); This is the NSLog output on the iphone: 2009-03-04 22:08:49.645 Test[2875:20b] DATE: Monday 26 January 2009 3:47:33 pm + to 0 And this on the simulator: 2009-03-04 22:09:05.095 Test[68041:20b] DATE: Monday 26 January 2009 3:47:33 pm + to 5432224 It seems that if you have your Regional settings to Chinese the date is not parsed. What is the proper way to parse an "English" formatted date? Yes, the date formatter you're creating defaults to using the user's locale, which can have settings which override even your attempt to set a specific format string. Do this after creating the formatter: [df setLocale:[NSLocale systemLocale]]; to set a generic locale object on the formatter. [This applies to Mac OS X as well as iPhone OS, it's just that iPhone OS tends to exercise such override settings more -- currently.] Chris Kane Cocoa Frameworks, Apple ___ 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: NSNumber Formatter with percent?
On Jul 19, 2008, at 5:13 PM, Todd Heberlein wrote: I was working through Hillegass's latest book and chapter 8 has me applying an NSNumberFormatter to one of the columns of a table view. Unfortunately I get unexpected behavior when I modify one of the values in the column. For example, if I add several employees (which have a default value of 5%), then I modify one of the numbers (say to 7%) then *all* the other number values get displayed as 500%. Furthermore, all new values are automatically displayed with a raise of 500% (as opposed to just 5%). This is a known bug in 10.5 with NSNumberFormatter (and perhaps earlier), when the string to be parsed can't be initially parsed and has to try again in a different way. As for the suggestion to use the 10.0 behavior mode, the multiplier property and the percent style don't work with 10.0 behavior, so you'll have to roll your own percent handling and multiplication and division. A workaround for 10.5 might be to set the multiplier after each string- >number parse attempt (and the various methods which do that). Something like [formatter setMultiplier:[formatter multiplier]] perhaps, due to the indirect things that happen when you do that. This is not particularly easy though if you have a number formatter set up in a nib file and/or attached to a cell. You might subclass NSNumberFormatter, or implement a post-user-input delegate method on the particular control, or perhaps something else. Chris Kane Cocoa Frameworks, Apple ___ 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 [EMAIL PROTECTED]
Re: NSDateComponents question
On Jul 1, 2008, at 1:08 AM, mmalc crawford wrote: On Jun 30, 2008, at 10:27 AM, Jason Wiggins wrote: Thanks mmalc for your reply. What you say makes sense. So comps is the whole date (now) minus 3 days. I wasn't expecting that. I should've made it clear what I was trying to achieve. I want to set the start date to the start of the week, hence line 11. 3 was just an arbitrary figure that happens to be today (localised in Sydney at 3:20am) I want to get the weekday and subtract *that* from the current date. I can't get a weekday figure without line 7. Any suggestions? Assuming you want just the actual day of the beginning of the week, rather than a specific time on the day (and assuming a Gregorian calendar and that you want the week to start on a Sunday): NSDate *currentDate = [NSDate date]; /* Get the components required to: (a) determine the current day of the week, and (b) create the day of the beginning of the week. */ NSDateComponents *components = [gregorian components:NSWeekdayCalendarUnit | NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit fromDate:currentDate]; /* Update the components to represent the beginning of the week by subtracting the weekday number from the current day. Weekday for Sunday in the Gregorian calendar is 1, so subtract 1 from the number of days you want to subtract from the date in question. (If today's Sunday, subtract 0 days.) */ [components setDay:([components day] - ([components weekday] - 1))]; It is probably a little bit better to also set the weekday to undefined before the next computation: [components setWeekday: NSUndefinedDateComponent]; so that the dateFromComponents: operation doesn't try to use the weekday info, which now is not in agreement with the day, so "who knows what might happen". The more subtle and serious issue is that Sunday in the current week might be in the previous Month (so, Day < Weekday), or even previous Year, so setting the Day to a negative value and keeping the Month and Year the same will have ... "who knows what effect". A more robust approach would be to just get the weekday value: NSDateComponents *components = [gregorian components:NSWeekdayCalendarUnit fromDate: currentDate]; and subtract WD-1 days, e.g. (in the most straightforward way): NSDateComponents *toSubtract = [[NSDateComponents new] autorelease]; [toSubtract setDay: - ([components weekday] - 1)]; NSDate * beginningOfWeek = [currentDate dateByAddingComponents: toSubtract toDate: currentDate options:0]; That gets you to Sunday, at least, though not necessarily the first day of the week in the user's current locale. Note that in this case, beginningOfWeek has the same hour, minute, and second as the original date currentDate. Another go with components:fromDate: and dateFromComponents: is one straightforward way to normalize those to midnight: components = [gregorian components: NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit fromDate: beginningOfWeek]; beginningOfWeek = [gregorian dateFromComponents: components]; Fetching hour, minute, and second into the original 'components' and subtracting them would have been another way, though DST transitions might be a "gotcha" there, spoiling that approach (you'd subtract one too many or few hours to actually get back to midnight). Probably better to explicitly state what you want in that case (ie, use dateFromComponents: not dateByAddingComponents:...). Chris Kane Cocoa Frameworks, Apple // Create the day for the beginning of the week from the updated components. NSDate *beginningOfWeek = [gregorian dateFromComponents:components]; mmalc ___ 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/ckane%40apple.com This email sent to [EMAIL PROTECTED] ___ 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 [EMAIL PROTECTED]
