Re: Locks
Le 7 déc. 2011 à 06:10, Ken Thomases a écrit : > On Dec 6, 2011, at 10:05 PM, Don Quixote de la Mancha wrote: > >> Contrary to Ken Thomases' assertion, there are all kinds of reasons to >> use atomic operations as locking primitives. One is that they cannot >> result in process context switches; if you are certain that you will >> release the lock quite quickly, it is a whole lot faster, and uses >> less memory, to use atomic arithmetic. > > You still shouldn't implement it manually using atomic increment and > decrement. You should use OSSpinLock if that's what you're attempting. > Which was my point. The original code was horrible and horribly misguided > (and suffers from a race condition as others have pointed out, which is > virtually inevitable when people try to reimplement synchronization instead > of using ready-made synchronization primitives). > A better solution would be to use posix mutex and completely avoid OSSpinLock. There is really few situations where SpinLock give you any benefit, as mutex implementation already try to spin a couple of time before locking. So if there is no contention, they are both very cheap and fast, and if there is contention, the mutex is better as it don't consume CPU waiting for other threads. -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Printing patterns
Hi guys, this is my first email to the list. Currently I'm working on an app that has to do with printing and I haven't really had any experience with this. I get the basic concept that print and drawing to screen are the same thing and all was working fine until I wanted to have a striped background - I used the [NSColor colorWithPatternImage:] method and everything works fine but I can't understand one thing. How am I supposed to generate the pattern image to print with the proper size on the printer having it set to 300 dpi for example. While the view is being printed on the screen (for preview or saved to PDF) it's size is calculated with 72 dpi. How can I create a pattern that would either be vector graphics (so it scales fine) or how do I know how to prepare the image given that users can print on different printers with different settings. -- Regards, Janusz Bossy ___ 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: Exceptions and autorelease pools
On Dec 6, 2011, at 6:01 PM, Steve Sisak wrote: > I realize that this is moot in the case of @autorelease, but in the context > of "best practices" for code that can't depend on ARC @autoreleasepool does not require ARC. -- 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: launchctl agents unload clean up
On 7 Dec 2011, at 12:45 AM, Rajendran P wrote: > My problem is that applicationWillTerminate is not being invoked when my > launch agent is manually unloaded . My application is uielement with out > dock entry . I am able to do a signal handling , low level unix signal > handling like sigkill , sighup etc . What makes you believe that killing a process through launchctl calls AppKit methods that propagate nicely to applicationWillTerminate:? "man 5 launchd.plist" says it sends SIGTERM, which I don't believe AppKit intercepts (maybe it would be nice if it did); and after a delay, SIGKILL, which AppKit, I'm pretty sure, does not intercept. "Creating Launch Daemons and Agents" advises you to provide a SIGTERM handler, and doesn't mention AppKit termination at all. — F ___ 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
How to initiate drag&drop for a filename outside of NSView mouseDown
Hi, I need to initiate a simple drag & drop operation for a single filename, but it will not be called within NSView mouseDown, but shortly afterwards (internal reasons). The mouse button will still be pressed, but the mouseDown even will already be finished. How to do this? Regards Vojtech ___ 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
ARC and dealloc
Dear list, A question regarding the proper use of dealloc in ARC-environments (under iOS): I have a need to unregister NSNotification observers during exchange of UiViewControllers. Is implementing - (void)dealloc considered a proper use for this purpose? Is it safe to make assumptions regarding when in the release-process dealloc is called? Incidentally, the Apple List search tool appears not to work (i.e. returns no results). Thanks, Mikkel Islay ___ 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
iOS: How to hide blue personal hotspot status bar?
Angry Birds does it so it must be possible. So how can I do this as well? I need my app to truly take over the entire iPhone screen with no distractions and no dangerous hit area that can take the user out of my app by accident. Thanks ___ 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: ARC and dealloc
My understanding is, due to auto release semantics, your object might be auto released again during current pool draining. So it will be put into outer Autorelease Pool, that's to say the dealloc are not guaranteed to be executed at specific timing. ARC still relies on retain/release/autorelease, so it has the same behavior.If your code must unregister notification before something else. It's better to find a more deterministic timing. Sent from my iPhone On 2011-12-8, at 上午4:56, Mikkel Islay wrote: > Dear list, > > A question regarding the proper use of dealloc in ARC-environments (under > iOS): > I have a need to unregister NSNotification observers during exchange of > UiViewControllers. Is implementing - (void)dealloc considered a proper use > for this purpose? Is it safe to make assumptions regarding when in the > release-process dealloc is called? > > Incidentally, the Apple List search tool appears not to work (i.e. returns no > results). > > Thanks, > Mikkel Islay > > ___ > > 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/yingshen.yu%40gmail.com > > This email sent to yingshen...@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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
bindings duplicates object returned
I have an NSTreeController whose 'content array' is bound to another object's 'content' key. It appears that the binding mechanism duplicates the array that was returned by [foo content]. This is bad, because changes that 'foo' makes later to its m_content never show up in the window. It's also bad because [NSTreeController selectedObject] doesn't correspond to anything in the tree under [foo content]. I can work around this by NOT using bindings to establish the controller's content, instead using [NSTreeController setContent:]. 1. Where in the docs is this binding duplication described? 2. Is there a way to use bindings and avoid having [foo content] duplicated? ___ 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: bindings duplicates object returned
On Dec 7, 2011, at 20:05 , Eric Slosser wrote: > I have an NSTreeController whose 'content array' is bound to another object's > 'content' key. > > It appears that the binding mechanism duplicates the array that was returned > by [foo content]. > > This is bad, because changes that 'foo' makes later to its m_content never > show up in the window. It's also bad because [NSTreeController > selectedObject] doesn't correspond to anything in the tree under [foo > content]. > > I can work around this by NOT using bindings to establish the controller's > content, instead using [NSTreeController setContent:]. > > 1. Where in the docs is this binding duplication described? > 2. Is there a way to use bindings and avoid having [foo content] duplicated? Based on this information, the problem is that your Foo class isn't KVO compliant for the "content" property. Conceptually, it's a mistake to think of "content" as an array property (that is, as a property that has an array as its value). Conceptually, you should think of it as an indexed to-many relationship. The correct approach is to properly implement the KVC indexed collection accessors in your Foo class**. See: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/AccessorConventions.html#//apple_ref/doc/uid/20002174-BAJEAIEE Normally, you need to write only the 'insert' and 'remove' accessors. You can let all of the others default. Then, when changing the value of the property, you should never change m_content directly***. Instead, use the collection accessors, or use the mutable array proxy. For example, to add an object to the array, use either of these: [foo insertObject: newObject inContentAtIndex: newIndex]; // or … [[foo mutableArrayValueForKey: @"content"] insertObject: newObject atIndex]; Both of these are KVO compliant, and functionally equivalent. Once you have this machinery set up, your binding to Foo's "content" should work properly. ** Of course, in practice, the Foo instance has to return *some* object that looks like an array as the value of the "content" getter, since properties have types. But think about what object ought to be returned. You don't want to return your 'm_content' array, because you're exposing an implementation detail to clients of your Foo class. You don't want to return a copy of your 'm_content' array, because that of course won't change after being created. Catch-22, isn't it? Ideally, the Foo instance would return [self immutableArrayValueForKey: @"content"] but unfortunately there's no such method. The simplest choice is probably to return the ivar, but to write no code that uses the @property value. *** When using an array ivar to back an indexed collection property like this, it's safe to modify the ivar directly in the init method only (because there aren't any observers at this point). Apart from that method, you should always use the KVO compliant accessors. ___ 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
