Re: Non-sandboxed Cocoa app accessing current user preferences using NSTask fails when launched outside Xcode.
On 26. 7. 2013, at 21:36, Jens I've never worked with sandboxing, but I would guess that a sandboxed app can't access arbitrary files in ~/Library/Preferences They can't. Sandboxed apps have own containers in ~/Library/Containers/$BUNDLEID/Data/Library/Preferences ... You can ask for exception in entitlements and when submitting app, you have to describe why do you need this exception. Experience says that Apple is going to reject your exceptions if they do not belong to urgent need category. What I want to say - you never know if they'll be approved, so, it's better to avoid them and try to find another solution. R. ___ 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: NSUserDefaults deeply nested subtle mountain lion difference
On Jul 26, 2013, at 5:15 PM, Keith Knauber wrote: From Apple Docs: Values returned from NSUserDefaults are immutable, even if you set a mutable object as the value. For example, if you set a mutable string as the value for MyStringDefault, the string you later retrieve usingstringForKey: will be immutable. The Apple docs have always said this. In practice, dictionaries and arrays have always been mutable, despite Apple's warning, as long as you used synchronize. The difference in Mountain Lion is that now, if you read/write a deeply nested dictionary, those deeply nested objects are not saved to NSUserDefaults. The moral of the story is, don't rely on undocumented side-effects ;-) It is more likely that this behavior is a bug that has since been fixed. It would be a bug, as the user defaults system *should* know when its values change, but is unable to. The synchronize trick simply forces it to write out its values. I wouldn't be surprised of user defaults now makes immutable copies of nested structures, which is why changing your own structures does not make any changes to the defaults system. They may even look like they've been saved because you can read the values back right before you exit your app. Subtly, they are not there when you relaunch. They likely aren't there to begin with, because you aren't querying the user defaults when you output values, you are querying your own data structures. You will probably find a different behavior if you query NSUserDefaults directly. Even worse, making a mutableCopy doesn't solve the problem. Only making a mutableCopyDeepPropertyList solves the problem (see solution below) Although this is what you need to do to to change the deep structures, you would still need to re-set the top level default with the whole structure. If I were in your shoes, and needed complex nested structures in defaults, I would not use NSUserDefaults at all but instead have a Core Data store. Although it takes a little more up-front prep time, you get a whole lot more bang for your buck You might consider filing a radar for nested structure support in NSUserDefaults. 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: Observing Time
On Jul 27, 2013, at 7:29 AM, dangerwillrobinsondan...@gmail.com wrote: k so I went and looked at sys/time.h and friends and the man page for gettimeofday() And now understand how this struct works. It's literally the same as the NSDate method timeIntervalSince1970 The only difference is NSTimeInterval is representing the values if these struct fields as the respective sides of the decimal point. I grok this. If I want to fire my timer at the second, just supply a tp with tp.tv_usec as zero. If I could verify any consistent lag under load I could offset my timer to fire slightly early to compensate for the lag. I get it. Awesome. But with that in mind, if I care or if the lag becomes significant enough per analog clock displayed for given time zones , then I will measure how the lag increases per additional displayed clock I add. I'll get the rest if the thing built now the way I want it and save this optimization for last. Assuming your update code runs very very fast (which it probably does): What you want to do is check the time and set the timer *after* you have updated all your clocks. That way, if your update took 0.01 seconds, you'd be delaying 0.99 seconds, and so on. But you can neither predict nor control other things that would cause the timer to fire later than you request. The only thing you can do is try to make sure that whatever other code you have to run does not hog the main thread for long. So, roughly speaking, after you have updated your clocks you set a timer for: 1.0 - fmod([[NSDate date] timeInterval], 1); But if your code is not really fast, your delay might need to be: double start = [[NSDate date] timeInterval]; // do all your updates double end = [[NSDate date] timeInterval]; if (end - start 1) // you're screwed, give up ;-) else // setup timer for 1.0 - fmod([[NSDate date] timeInterval], 1) - (end - start) I don't remember why all the UNIXy stuff entered the discussion; it's really not necessary for this. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Non-sandboxed Cocoa app accessing current user preferences using NSTask fails when launched outside Xcode.
On Jul 27, 2013, at 2:58 AM, Robert Vojta rob...@tapmates.com wrote: What I want to say - you never know if they'll be approved, so, it's better to avoid them and try to find another solution. OK. Whereas by you can do this I meant, I added the entitlement with my explanation and it was approved. But in my case they were my own preferences, so I can't make any statement as to what happens if you want access to somebody else's preferences. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On Jul 27, 2013, at 11:37 PM, Ken Thomases k...@codeweavers.com wrote:
On Jul 27, 2013, at 8:29 AM, dangerwillrobinsondan...@gmail.com wrote:
Ok so I went and looked at sys/time.h and friends and the man page for
gettimeofday()
And now understand how this struct works.
It's literally the same as the NSDate method timeIntervalSince1970
The only difference is NSTimeInterval is representing the values if these
struct fields as the respective sides of the decimal point.
I grok this.
If I want to fire my timer at the second, just supply a tp with tp.tv_usec
as zero.
Well, not quite. gettimeofday() fills in a struct timeval and a struct
timezone. dispatch_walltime() takes a struct timespec as its first
parameter. timeval+timezone vs. timespec. It's not entirely clear how you
would map from the first to the second. I suppose you could check the source
for dispatch_walltime() to see how it does it. I recommended continuing to
pass NULL for the timespec so that dispatch_walltime() would just do it for
you and instead pass a delta that adjusts this to (approximately) the next
whole second.
But, yes, if you know the correct way to fill in the timespec for now and
you bump it up to the next whole second by incrementing its tv_sec field and
zeroing its tv_nsec, then that would also work.
According to the man page for gettimeofday, time zone is not required if
timeval is supplied.
According to the docs, dispatch_walltime uses gettimeofday if NULL is passed
for a timespec, and dispatch_walltime is based on gettimeofday.
There is a macro in time.h to convert time spec to and from timeval clearly
showing the two are identical except for the sub second unit used.
#define TIMEVAL_TO_TIMESPEC(tv, ts) { \
(ts)-tv_sec = (tv)-tv_sec;\
(ts)-tv_nsec = (tv)-tv_usec * 1000; \
}
#define TIMESPEC_TO_TIMEVAL(tv, ts) { \
(tv)-tv_sec = (ts)-tv_sec;\
(tv)-tv_usec = (ts)-tv_nsec / 1000; \
}
Thanks Ken, you set me on the right track.
You're welcome. Don't forget Rick Mann's original reply, which was along the
same lines but using NSTimer. (Which may still be a simpler way to go, since
you're reliant on the main thread being responsive anyway.)
I haven't. Rick's clarity was there right off.
But I'm avoiding NSTimer because I want to avoid being run looped in
completely, though it's probably as practical as all this other mess :).
Cheers,
Ken
___
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: Observing Time
On Jul 27, 2013, at 11:46 PM, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 7:29 AM, dangerwillrobinsondan...@gmail.com wrote: k so I went and looked at sys/time.h and friends and the man page for gettimeofday() And now understand how this struct works. It's literally the same as the NSDate method timeIntervalSince1970 The only difference is NSTimeInterval is representing the values if these struct fields as the respective sides of the decimal point. I grok this. If I want to fire my timer at the second, just supply a tp with tp.tv_usec as zero. If I could verify any consistent lag under load I could offset my timer to fire slightly early to compensate for the lag. I get it. Awesome. But with that in mind, if I care or if the lag becomes significant enough per analog clock displayed for given time zones , then I will measure how the lag increases per additional displayed clock I add. I'll get the rest if the thing built now the way I want it and save this optimization for last. Assuming your update code runs very very fast (which it probably does): What you want to do is check the time and set the timer *after* you have updated all your clocks. That way, if your update took 0.01 seconds, you'd be delaying 0.99 seconds, and so on. point taken! But you can neither predict nor control other things that would cause the timer to fire later than you request. The only thing you can do is try to make sure that whatever other code you have to run does not hog the main thread for long. Indeed... So, roughly speaking, after you have updated your clocks you set a timer for: 1.0 - fmod([[NSDate date] timeInterval], 1); But if your code is not really fast, your delay might need to be: double start = [[NSDate date] timeInterval]; // do all your updates double end = [[NSDate date] timeInterval]; if (end - start 1) // you're screwed, give up ;-) else // setup timer for 1.0 - fmod([[NSDate date] timeInterval], 1) - (end - start) I don't remember why all the UNIXy stuff entered the discussion; it's really not necessary for this. Well, maybe not necessary to do it, but appropriate for understanding the mechanism, as it's all based on that UNIXy stuff, even NSDate and timeInterval … ___ 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: Observing Time
On Jul 27, 2013, at 9:15 AM, dangerwillrobinsondan...@gmail.com wrote: But I'm avoiding NSTimer because I want to avoid being run looped in completely Why??? If the run loop on the main thread is busy, your display won't update anyway. I think you're adding a lot of complexity for 0 gain. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On 2013/07/28, at 0:38, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 9:15 AM, dangerwillrobinsondan...@gmail.com wrote: But I'm avoiding NSTimer because I want to avoid being run looped in completely Why??? If the run loop on the main thread is busy, your display won't update anyway. I think you're adding a lot of complexity for 0 gain. Why would I add to slowing down the main thread when I can run a dispatch_timer on another thread and get the timer to fire more reliably? That doesn't make sense. In trying to keep a slim and trim main thread to keep steady movement. NSTimer is not for everything and does not give as much accuracy. ___ 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: Observing Time
On Sat, Jul 27, 2013, at 09:16 AM, dangerwillrobinsondan...@gmail.com wrote: On 2013/07/28, at 0:38, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 9:15 AM, dangerwillrobinsondan...@gmail.com wrote: But I'm avoiding NSTimer because I want to avoid being run looped in completely Why??? If the run loop on the main thread is busy, your display won't update anyway. I think you're adding a lot of complexity for 0 gain. Why would I add to slowing down the main thread when I can run a dispatch_timer on another thread and get the timer to fire more reliably? That doesn't make sense. More threads != more better. You're drawing on the main thread. Firing the timer on a background thread gets you _zero_ benefit, because you have to forward those timer pulses to the main thread anyway! --Kyle Sluder ___ 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: Observing Time
On Jul 27, 2013, at 10:16 AM, dangerwillrobinsondan...@gmail.com wrote: Why would I add to slowing down the main thread when I can run a dispatch_timer on another thread and get the timer to fire more reliably? That doesn't make sense. What's going to slow down the main thread??? Certainly not an NSTimer firing once a second. Hopefully not the calculations involved in drawing a clock--and if that were the case, then yes that might need to be moved to another thread. Hopefully not the actual drawing, since moving that to another thread complicates things with drawing to offscreen and then flushing from the main thread. In trying to keep a slim and trim main thread to keep steady movement. NSTimer is not for everything and does not give as much accuracy. It probably gives way more than enough accuracy to keep steady movement, unless your main thread is bogged down--but in that case all you achieve with your complexity is calculating possibly drawing on time in a background thread, and then waiting for the main thread to update the display: in other words you probably achieve absolutely nothing. It seems to me that you're complicating your life by anticipating and working around problems that simply don't exist, with complexity that probably wouldn't solve the problems even if they did exist. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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
when __bridge isn't required
I feel like I've asked this before, but I don't feel I'm grasping the answer. Why don't these work the same way under ARC: NSString* answer = @42; int ans = CFStringGetIntValue((CFStringRef)answer); and NSURL* imageSource = [NSURL new]; CGImageSourceRef src = CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. But why? They look completely parallel to me. The mystery is compounded by the fact that if you omit the cast entirely in the first example, the compiler claims that you need a bridged cast. But you don't; you just need a cast. That feels like a bug; if a mere cast is sufficient, the compiler should say so (and Fix-It should offer it as a possible fix). m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: when __bridge isn't required
My take: __bridge means 'do not transfer the retain count of whatever on the RHS to the LHS'. If the RHS involves some kind of create or new, then you'll get a leak since ARC won't release it. __bridge_transfer means 'transfer the retain count of whatever on the RHS to the LHS'. If the RHS involves some kind of create or new, then you can just rely on ARC, or you'll have to release via CFRelease(). Since CFStringGetIntValue() does not return an object, you don't need __bridge at all - there's no 'retaining' going on behind the scenes. ARC sees you're getting back a scalar, and the compiler sees no ambiguity or error. But CGImageSourceCreateWithURL() includes the keyword 'create' - so the object you get back has a retain count of 1. ARC will insist that you cast with __bridge or __bridge_transfer. Under ARC, you have to let the compiler know whether you are taking responsibility (__bridge_transfer, ARC will release when it goes out of scope), or not (__bridge, followed by a CFRelease()) for ultimately releasing the newly created object. I'm probably wrong, but this is how I've been working with ARC, based on the docs and blogs. Rob On Jul 27, 2013, at 2:31 PM, Matt Neuburg m...@tidbits.com wrote: I feel like I've asked this before, but I don't feel I'm grasping the answer. Why don't these work the same way under ARC: NSString* answer = @42; int ans = CFStringGetIntValue((CFStringRef)answer); and NSURL* imageSource = [NSURL new]; CGImageSourceRef src = CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. But why? They look completely parallel to me. The mystery is compounded by the fact that if you omit the cast entirely in the first example, the compiler claims that you need a bridged cast. But you don't; you just need a cast. That feels like a bug; if a mere cast is sufficient, the compiler should say so (and Fix-It should offer it as a possible fix). m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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/robmartin%40frontiernet.net This email sent to robmar...@frontiernet.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: when __bridge isn't required
The first gives me the following error: Implicit conversion of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef' (aka 'const struct __CFString *') requires a bridged cast Tom Davie On Jul 27, 2013, at 8:31 PM, Matt Neuburg m...@tidbits.com wrote: I feel like I've asked this before, but I don't feel I'm grasping the answer. Why don't these work the same way under ARC: NSString* answer = @42; int ans = CFStringGetIntValue((CFStringRef)answer); and NSURL* imageSource = [NSURL new]; CGImageSourceRef src = CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. But why? They look completely parallel to me. The mystery is compounded by the fact that if you omit the cast entirely in the first example, the compiler claims that you need a bridged cast. But you don't; you just need a cast. That feels like a bug; if a mere cast is sufficient, the compiler should say so (and Fix-It should offer it as a possible fix). m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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/tom.davie%40gmail.com This email sent to tom.da...@gmail.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: when __bridge isn't required
The first one is a NSConstantString string. It's not like a malloc'd NSString. It's effectively a singleton. It doesn't mater how it's bridged because it can't be released. The second is a new NSURL that is allocated on the heap. It needs to be released so it needs to be bridged correctly to handle things properly. Apple has made this more and more friendly since the WWDC beta of ARC over time with things like flags for constants from system headers and other basically constant things so don't have to bridge as much. Things like #pragma clang system_header and system_prefix in clang. Zac On Jul 27, 2013, at 11:31 AM, Matt Neuburg m...@tidbits.com wrote: I feel like I've asked this before, but I don't feel I'm grasping the answer. Why don't these work the same way under ARC: NSString* answer = @42; int ans = CFStringGetIntValue((CFStringRef)answer); and NSURL* imageSource = [NSURL new]; CGImageSourceRef src = CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. But why? They look completely parallel to me. The mystery is compounded by the fact that if you omit the cast entirely in the first example, the compiler claims that you need a bridged cast. But you don't; you just need a cast. That feels like a bug; if a mere cast is sufficient, the compiler should say so (and Fix-It should offer it as a possible fix). m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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/zac%40zacbowling.com This email sent to z...@zacbowling.com smime.p7s Description: S/MIME cryptographic signature ___ 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: when __bridge isn't required
On Jul 27, 2013, at 11:54 , Robert Martin robmar...@frontiernet.net wrote: But CGImageSourceCreateWithURL() includes the keyword 'create' - so the object you get back has a retain count of 1. ARC will insist that you cast with __bridge or __bridge_transfer. ARC isn't involved with the return value in either case. In the first one, it's a scalar, as you noted. In the second, it's a core foundation object, which isn't managed by ARC … … unless the CGImageSourceCreateWithURL is marked (in the SDK) with the attribute that that says it can be managed by ARC (a fairly recent addition to Clang) … … but that wouldn't be it anyway, since there's no cast needed on the return value, let alone a __bridge. On Jul 27, 2013, at 11:31 , Matt Neuburg m...@tidbits.com wrote: The first one compiles (with no explicit __bridge). The second one doesn't; you must say __bridge explicitly. I tried both your examples in Xcode 4.6.3 and OS X 10.8 SDK, and neither produced an error or a warning. The answer to your question probably depends on: -- the version of Clang you're using -- the particular SDK you're using -- the compiler options you're using ___ 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: when __bridge isn't required
Argh. Okay, I'll ask this on devforums when it comes back up, in case it depends on, uh, the thing I'm using that I can't talk about. m. On Jul 27, 2013, at 12:10 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: I tried both your examples in Xcode 4.6.3 and OS X 10.8 SDK, and neither produced an error or a warning. The answer to your question probably depends on: -- the version of Clang you're using -- the particular SDK you're using -- the compiler options you're using -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: Observing Time
On 2013/07/28, at 1:35, Kyle Sluder k...@ksluder.com wrote: On Sat, Jul 27, 2013, at 09:16 AM, dangerwillrobinsondan...@gmail.com wrote: On 2013/07/28, at 0:38, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 9:15 AM, dangerwillrobinsondan...@gmail.com wrote: But I'm avoiding NSTimer because I want to avoid being run looped in completely Why??? If the run loop on the main thread is busy, your display won't update anyway. I think you're adding a lot of complexity for 0 gain. Why would I add to slowing down the main thread when I can run a dispatch_timer on another thread and get the timer to fire more reliably? That doesn't make sense. More threads != more better. One more thread. Really, surprised by this as I never said anything about more threads being better. Only that I don't want this timer on the main run loop. You're drawing on the main thread. Firing the timer on a background thread gets you _zero_ benefit, because you have to forward those timer pulses to the main thread anyway! I just tried both approaches and guess which one stays right there with the menu bar clock and which one lags? dispatch timer is the winner. And it's not doing a lot. I built a test app for each approach to verify. In each timer I set an NSDate property to the latest date, and set the stringValue on an NSTextField. I'm not using bindings. Maybe I should try a different run loop mode than default for NSTimer? Happy to hear suggestions here, but I see dispatch timer giving the precision desired and I don't feel like its costing me anything to accomplish. As per the docs, NSTimer gives millisecond accuracy, but can fire some undetermined time after the set fire interval. --Kyle Sluder ___ 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: Observing Time
On Jul 27, 2013, at 5:53 PM, dangerwillrobinsondan...@gmail.com wrote: I just tried both approaches and guess which one stays right there with the menu bar clock and which one lags? dispatch timer is the winner. And it's not doing a lot. I think you must be doing something wrong. NSTimer should not be lagging. Post code if you want, otherwise I'm done here. As per the docs, NSTimer gives millisecond accuracy, but can fire some undetermined time after the set fire interval. Usually a fraction of a millisecond, never more than 100ms in my testing, and more than 10ms is rare. And again, as has been pointed out to you REPEATEDLY, if the firing of NSTimer is lagging because your main thread is busy doing something else, you're not going to be able to update your UI anyway. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On Jul 27, 2013, at 7:53 PM, dangerwillrobinsondan...@gmail.com wrote: I just tried both approaches and guess which one stays right there with the menu bar clock and which one lags? dispatch timer is the winner. And it's not doing a lot. I built a test app for each approach to verify. Is it possible there's a difference in how you're doing the math in the two cases, such that the NSTimer case might be firing *early* rather than late? Say the first NSTimer fires a little before the time you intended -- for example, it fires at 00:36. instead of 00:37. Your UI will not get around to displaying the 37 until possibly a whole second later, depending on how you set up the firing of the next timer. If I were using an NSTimer approach I might set it to fire at .001 past the second just to be sure I don't get caught by rounding error in my floating-point math. --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: Observing Time
On 2013/07/28, at 8:57, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 5:53 PM, dangerwillrobinsondan...@gmail.com wrote: I just tried both approaches and guess which one stays right there with the menu bar clock and which one lags? dispatch timer is the winner. And it's not doing a lot. I think you must be doing something wrong. NSTimer should not be lagging. Post code if you want, otherwise I'm done here. Hmm. Initially I did miss the method initWithFireDate:interval:target:selector:userInfo:repeats: That alone makes all the difference over the class factory methods by giving a determined start time. But with that I still see a faint lag that seems to update just a hair slower than the dispatch timer. Noticeable to me at least, I'll post a link to the sample projects in a bit. It's not really enough to care about but I still wonder if there is a difference. As per the docs, NSTimer gives millisecond accuracy, but can fire some undetermined time after the set fire interval. Usually a fraction of a millisecond, never more than 100ms in my testing, and more than 10ms is rare. And again, as has been pointed out to you REPEATEDLY, if the firing of NSTimer is lagging because your main thread is busy doing something else, you're not going to be able to update your UI anyway. Yes I get that. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On Jul 27, 2013, at 9:43 PM, dangerwillrobinsondan...@gmail.com wrote: But with that I still see a faint lag that seems to update just a hair slower than the dispatch timer. Noticeable to me at least, I'll post a link to the sample projects in a bit. FWIW I created a quick test app using NSTimer and didn't notice any lag at first but there was noticeable drift after a while -- not huge, but noticeable. This makes me suspicious of the docs that Steve Sisak quoted earlier, which I was counting on: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html A repeating timer always schedules itself based on the scheduled firing time, as opposed to the actual firing time. I'm trying again, this time creating a new NSTimer each time as suggested by Scott Ribe. Will let it run a while and see if I notice any drift. --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: Observing Time
On Jul 27, 2013, at 7:43 PM, dangerwillrobinsondan...@gmail.com wrote: Hmm. Initially I did miss the method initWithFireDate:interval:target:selector:userInfo:repeats: That alone makes all the difference over the class factory methods by giving a determined start time. Now, combine that with setFireDate: which allows you to adjust it every time… -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On Jul 27, 2013, at 9:57 PM, Andy Lee ag...@mac.com wrote:
I'm trying again, this time creating a new NSTimer each time as suggested by
Scott Ribe. Will let it run a while and see if I notice any drift.
Looks pretty solid after several minutes -- as I would expect. To repeat
Scott's suggestion:
Personally, I'd probably just do a non-repeating timer, set to fire at the
next second roll-over. Alloc'ing, scheduling and releasing 1 timer per second
is not a lot of overhead.
I didn't take my own suggestion to add .001 and it worked fine, though for all
I know it might have a problem once every 10,000 times the app is run.
I stole Rick Mann's code and replaced trunc() with round().
--Andy
==
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[self _resetTimer];
}
- (void)_resetTimer
{
CFAbsoluteTime fireDateAbs = round(CFAbsoluteTimeGetCurrent() + 0.5); //
Round to the next second
NSDate *fireDate = [NSDate
dateWithTimeIntervalSinceReferenceDate:fireDateAbs];
[[self timer] invalidate];
[self setTimer:[[NSTimer alloc] initWithFireDate:fireDate
interval:1.0
target:self
selector:@selector(_timerDidFire:)
userInfo:nil
repeats:NO]];
[[NSRunLoop currentRunLoop] addTimer:[self timer]
forMode:NSRunLoopCommonModes];
}
- (void)_timerDidFire:(NSTimer *)theTimer
{
[self _updateTimeDisplay];
[self _resetTimer];
}
- (void)_updateTimeDisplay
{
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
[dateFormatter setDateStyle:NSDateFormatterNoStyle];
NSString *timeString = [dateFormatter stringFromDate:[NSDate date]];
[[self textField] setStringValue:timeString];
}
@end
___
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: Observing Time
Except for the reschedule after each fire, and the CFAbsoluteTimeGetCurrent call
This is pretty much what I tried.
I had done it with [[NSDate date] timeIntervalSince1970] which might be a hair
longer than a CF call.
I will give it a whirl with this approach and compare.
At this point it's curiosity.
But I've learnt dispatch timer in the process which will come in handy in the
future for some non GUI things.
Thanks to all
Sent from my iPhone
On 2013/07/28, at 11:28, Andy Lee ag...@mac.com wrote:
On Jul 27, 2013, at 9:57 PM, Andy Lee ag...@mac.com wrote:
I'm trying again, this time creating a new NSTimer each time as suggested by
Scott Ribe. Will let it run a while and see if I notice any drift.
Looks pretty solid after several minutes -- as I would expect. To repeat
Scott's suggestion:
Personally, I'd probably just do a non-repeating timer, set to fire at the
next second roll-over. Alloc'ing, scheduling and releasing 1 timer per
second is not a lot of overhead.
I didn't take my own suggestion to add .001 and it worked fine, though for
all I know it might have a problem once every 10,000 times the app is run.
I stole Rick Mann's code and replaced trunc() with round().
--Andy
==
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[self _resetTimer];
}
- (void)_resetTimer
{
CFAbsoluteTime fireDateAbs = round(CFAbsoluteTimeGetCurrent() + 0.5); //
Round to the next second
NSDate *fireDate = [NSDate
dateWithTimeIntervalSinceReferenceDate:fireDateAbs];
[[self timer] invalidate];
[self setTimer:[[NSTimer alloc] initWithFireDate:fireDate
interval:1.0
target:self
selector:@selector(_timerDidFire:)
userInfo:nil
repeats:NO]];
[[NSRunLoop currentRunLoop] addTimer:[self timer]
forMode:NSRunLoopCommonModes];
}
- (void)_timerDidFire:(NSTimer *)theTimer
{
[self _updateTimeDisplay];
[self _resetTimer];
}
- (void)_updateTimeDisplay
{
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
[dateFormatter setDateStyle:NSDateFormatterNoStyle];
NSString *timeString = [dateFormatter stringFromDate:[NSDate date]];
[[self textField] setStringValue:timeString];
}
@end
___
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: Observing Time
On Jul 27, 2013, at 7:57 PM, Andy Lee ag...@mac.com wrote: I'm trying again, this time creating a new NSTimer each time as suggested by Scott Ribe. Will let it run a while and see if I notice any drift. FYI, I think that's fine. You could also take the approach of using a single timer, and using setFireTime every time. (You'd set the repeat interval to something unrealistically large, say a minute or hour, then always use setFireTime to set when the next instance will be.) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Observing Time
On Jul 27, 2013, at 11:05 PM, Scott Ribe scott_r...@elevated-dev.com wrote: On Jul 27, 2013, at 7:57 PM, Andy Lee ag...@mac.com wrote: I'm trying again, this time creating a new NSTimer each time as suggested by Scott Ribe. Will let it run a while and see if I notice any drift. FYI, I think that's fine. You could also take the approach of using a single timer, and using setFireTime every time. (You'd set the repeat interval to something unrealistically large, say a minute or hour, then always use setFireTime to set when the next instance will be.) Yup. --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
