Re: Basic Question
On May 9, 2012, at 9:47 AM, koko k...@highrolls.net wrote: I wanted to avoid that as the documentation for NSView shows - (void)print:(id)sender as the method signature. IBAction is #def'd as void -- it is just a hook for IB's benefit. That isn't the problem. More likely than not, your view isn't first responder or otherwise in the responder chain. Thus, when the AppKit dispatches the action down the responder chain, your view isn't in the chain. b.bum ___ 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: Allocating too much memory kills my App rather than returning NULL
On Nov 10, 2011, at 6:03 PM, Don Quixote de la Mancha wrote: I don't have a problem with the system killing runaway processes. What I have a problem with is that calloc() NEVER returns NULL. If it ever did, I would have plenty of opportunity to deallocate ALL of the memory I just allocated, and stop attempting to allocate any more. The only situation where this would ever work is if the process were single threaded. As well, every single call to an allocator everywhere in the entire system would have to check for NULL and provide a recovery codepath. Not only would this be rife with bugs, it would also explode the size of the code. Multiple threads are effectively a red herring in this; threads just mean that all that failsafe code also has to deal with failing safely in a multi-thread environment. And for what purpose? In a 64 bit world with a VM, your system will be completely unusable long, long, long before the first failed allocation because you'll be paging like mad (unless whatever volume that holds VM is already full). b.bum ___ 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: What is last number at end of crash log line?
On Sep 12, 2011, at 10:27 AM, lbland wrote: What does the 98 at the end of this line mean:? 8 com.apple.CoreFoundation 0x7fff90662d32 -[NSMutableArray removeObjectsInRange:] + 98 … all the tech notes I can find explains everything else, but neglects describing that last number (as if it is not there) … Byte offset into the symbol. I.e. that means that the backtrace is at the instruction 98 bytes from the beginning of that particular method. b.bum ___ 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: Why RunLoop?
In short, do **not** poll. Not ever.
If you are doing something like this:
while (stillDontGotIt) {
sleepForAMomentAndHopeWeGetIt();
}
(or the obvious spin-and-try-lock variant).
Then you are doing it wrong.
It eats CPU, makes your app less responsive, eats battery life, and is less
efficient. Far far more efficient is to set up various triggers or points of
coordination -- queues, callbacks, run loop events, etc… -- through which your
app will be notified when something is ready to be processed.
b.bum___
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: Are the progress spinner images publically available?
Am 01.04.2011 um 18:38 schrieb James Bucanek: So I'm going with plan B, which is create a custom CALayer that draws a single spinner wheel image and then rotate it using a key-frame animation. As long as you don't actually show rotation of the lines of the progress indicator, that'll work... I've now seen several progress indicators that were, quite literally, just smoothly rotating bitmaps. Looked really bad. ___ 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: NSThread
On Mar 8, 2011, at 12:33 AM, Bruno Causse wrote: the performance is not a problem, all my threads are waiting for a answer to a request. That is potentially still a big problem as every thread uses kernel resources, reserves memory for a stack, and otherwise pollutes the kernel's scheduling information. A far better approach is to having a single thread that handles all the waiting and then spews off the work to be done to a [reasonably sized] pool of threads. An even better approach than that would be to use GCD. Do the waiting threads wait on something that is covered by dispatch sources? If so, that solution will be significantly cleaner and more efficient than anything you could do using the lower level APIs [since GCD can collude with the kernel]. If not, dispatching the units of work via the GCD APIs will likely be more efficient and generally be simpler than managing a pool of threads. my program is a kind of working's Distributor. ___ 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: NSThread
On Mar 7, 2011, at 12:27 PM, Bruno Causse wrote: hi all, how many NSThread i can create? Quite a few more than are useful, performant, or optimal... b.bum ___ 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: Performing the selector from a stored IMP
On Feb 11, 2011, at 1:16 PM, Joanna Carter wrote: I would totally agree that it is a phenomenally powerful concept, giving just the kind of functionality I was originally looking for, as a replacement for method pointers. I will be using it as soon as I find a need that warrants it. But, in my current code, I realise now that it was a lot easier to simply take the protocol/method approach. While fast, IMP caching can also be dangerous. If anything happens such that the IMP changes while you have it cached, you'll end up calling the wrong thing. In particular, if you cache an IMP for something that can be observed with KVO, it can lead to problems. Bundle loading can also be an issue; categories can replace IMPs. Obviously, method swizzling -- in general -- will cause issues. (Just an FYI -- none of these are *huge* issues, just something to be aware of) b.bum ___ 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: Help with Basics
On Nov 23, 2010, at 5:41 PM, Rob Ross wrote: otherwise you are not responsible and More or less (there are some exceptions). the object will be auto-released. Sometimes. [NSString stringWithString: @Foobar]; [NSNumber numberWithInt: 7]; Typically returns an object that is not auto-released, nor something you need to worry about releasing. Note that [NSNumber numberWithInt: 42]; *does* release an auto-released object (and you still don't need to worry about releasing). b.bum ___ 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: On self = [super init...] ...
On Nov 18, 2010, at 1:10 PM, John Engelhart wrote: The basic premise behind self = [super init...] is that the lower levels of initialization are free to return a different object than the one passed in. However, there is an unstated assumption in this reasoning: whatever object is returned by [super init...] is the one that will be used. I don't understand the above claim; Why must the object returned by [super init*] be the one that is used? I'm certainly not aware of any limitation on an init method that would prevent it from… say… calling [super init], releasing whatever is returned if deemed unfit and then allocating an initializing some other instance. The documentation (http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAllocInit.html) doesn't seem to make any such claim either. I haven't read beyond the above yet. Maybe the unstated assumption is explained? b.bum ___ 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: On self = [super init...] ...
On Nov 18, 2010, at 2:34 PM, John Engelhart wrote: method is just going to -dealloc my object and do something else (you know, basically exactly what I'm trying to do with my own object substitution, hint hint), then what's the point in even trying to do object substitution in the first place? The documentation says: In general, if there is a problem during an initialization method, you should call [self release]and return nil. Thus, no, there is no problem if multiple classes in the hierarchy participate. The only stumbling point is that this: self = [super init]; May cause 'self' to be released; if you have code that is still referring to self via some other means, it better had darned well retained it before making that call. b.bum ___ 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 Collection, Standard Out, NSTask
The issue [I'd bet -- don't have time to dive deep] is that you don't have a strong reference to the Tasker instance. Since notification observers don't hold strong references to observers, either, the garbage collector sees Tasker as garbage and collects it. You could fix this any number of ways; - keep a reference to the Tasker instance as an iVar - keep a global set around of active taskers and have 'em remove themselves when they are done - use CFRetain or the NSGarbageCollector API to tell the collector not to collect the tasker before done. b.bum ___ 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: Custom setter for atomic property
On Oct 28, 2010, at 7:01 AM, Jonny Taylor wrote: I currently have a property declared as follows: @property(atomic, readwrite, retain) MyFrame* latestFrame; When the value is set, I would like to broadcast a notification on the main thread, and one way of doing that would be to write my own custom setter that sets the value and then broadcasts the notification. What I am not sure about is how much I need to do to ensure this is threadsafe. I have only been able to find limited, rather contradictory information on this. When I write my own setter function, does the atomic qualifier have any meaning? What I am trying to work out is whether the runtime will bracket my function with appropriate locking code, or whether I need to do that myself - and so crucially, do I ALSO need to write a custom getter function that is subject to the same manual locking? [I have since wondered whether actually the right way of achieving what I want is to implement a didChangeValueForKey method from which I do the broadcasting. Any comments on that approach would also be welcome!] In the manual case, 'atomic' only has meaning if you make it meaningful. I'd be interested in knowing why you need an atomic property in this case as atomicity at the property level rarely contributes to thread safety. If you do go this route, you need to write both the getter and setter with relative atomicity between the two. You can't write just one as there is no way for your custom getter or setter to interact with the atomicity mechanism of the other. There is no way for the runtime to bracket your code with an atomicity ensuring mechanism as there is no complete way to figure out what locking you might be doing in your code. Note that sending notifications to other threads while holding locks in the current thread (or queue) is rife with danger fragility. It is great way to create deadlocks and, if not, to end up with a solution that has all the maintenance costs of multi-threaded code combined with all the performance wins of single threaded execution b.bum ___ 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: Custom setter for atomic property
On Oct 28, 2010, at 9:16 AM, Jonny Taylor wrote: Note that sending notifications to other threads while holding locks in the current thread (or queue) is rife with danger fragility. It is great way to create deadlocks and, if not, to end up with a solution that has all the maintenance costs of multi-threaded code combined with all the performance wins of single threaded execution My situation is that I am receiving camera frames on a background thread, and need a way of informing various windows that their displays should be updated to reflect the fact that a new frame has been received. This GUI work needs to be done on the main thread (I believe...). In addition, I take advantage of the coalescing features of notifications to avoid unnecessary updates. Thus I am keeping the currentFrame variable up to date in a threadsafe manner, and then after updating it (and releasing the lock) I post a notification to the main queue, with coalescing. Does that sound like a reasonable approach? I definitely need to access currentFrame in a threadsafe manner, but hopefully my description shows that the multithreaded relationship for the notifications and variable updates is not there for performance reasons, if that makes sense. I am more than aware of the trouble multithreading brings, but the nature of the code makes it pretty unavoidable. The best way to access something in a threadsafe manner is to only access it from one thread at a time without locking. And the best way to do that is to perpetuate the notion of thread ownership. When thread A is accessing the object, thread B not only does not access the object, thread B doesn't even have a reference to the object in its scope of execution. Not ever. When B -- likely the main thread -- needs to access the object, then A passes ownership to B, typically via GCD, operations or -performSelectorOnMainThread: b.bum ___ 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: Thread not registered mystery under GC
On Oct 26, 2010, at 12:42 PM, Sean McBride wrote: And presumably objc_unregisterThreadWithCollector() at the end of your thread's function... yes? Yes; it'll happen automatically on thread death, effectively. Registering/unregistering a thread on the fly isn't really something that is supported well. I.e. once a thread goes GC, it really should stay that way. Andy, also beware that those two functions are not properly marked as weak, and so if your deployment target is 10.6 and even if you test them against NULL, you will crash. :( rdar://8508911 Boo. Thanks for the bug. b.bum ___ 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: Thread not registered mystery under GC
On Oct 25, 2010, at 2:22 PM, Andy O'Meara wrote: Per Apple GC Programming Guide (page 15): // SNIP // Garbage collection is performed on its own thread--a thread is explicitly registered with the collector if it calls NSThread's currentThread method (or if it uses an autorelease pool). There is no other explicit API for registering a pthread with the collector. // SNIP // That'd be a bug; please file via http://bugreport.apple.com/ and provide an URL to the document. However when my bundle runs under as a 64 bit GC app or a 64 bit screen saver (via the sys prefs app), the following log msg shows up for each call to [NSThread currentThread] I make when the thread first starts: [0x0-0x8b08b0].com.apple.systempreferences[1198] System Preferences(1198,0x11a8f9000) malloc: *** auto malloc[1198]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug. As the message directs, I set that breakpoint, and I see the following stack inside of the [NSThread currentThread] call: #00x7fff81b08c64 in auto_zone_thread_registration_error #10x7fff81b089aa in Auto::Zone::registered_thread #20x7fff81b01df0 in auto_zone_allocate_object #30x7fff85c8602a in _internal_class_createInstanceFromZone #40x7fff866d56e9 in +[NSObject(NSObject) allocWithZone:] #50x7fff866d5671 in +[NSObject(NSObject) new] #60x7fff88e553b5 in _NSThreadGet0 So, it seems like I'm following the spec yet I can't seem to shake that error message. Anyone on the inside care to illuminate what's happening here? Apart from those [NSThread currentThread] calls I make when the pthread first starts, is there something else I need to call that the GC spec doesn't discuss? Yes. Call objc_registerThreadWithCollector() from the thread. The behavior was changed because folks were surprised to see the collector being registered on their thread when they were only using Core Foundation code and no Objective-C. Core Foundation is actually implemented using a growing chunk of Objective-C code. Thus, the collector became noisy about this so people wouldn't be surprised -- or, more importantly, would be surprised but would figure out what is up more quickly. That document is wrong. b.bum ___ 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: Heapshot Analysis to find Memory Accretion (Leaks)
On Oct 18, 2010, at 8:33 PM, Gerriet M. Denkmann wrote: First of all: Thank you very much for this very helpful article. I just created a new Cocoa Document based app in Xcode (Version 3.2.4). I did not edit any of the Xcode supplied files. Clicked Build and then Run with Performance Tool → Allocations. The I did 10 times: New Close Click Mark Heap in Instruments But there are several kiloBytes of Heap Growth in (almost) each Heapshot. These are: CFBasicHash (value-store) CFBasicHash (count-store) non-object None of these have any of my code (except main()) in their respective backtraces. So, what to do now? Conclude that AppKit is full of leaks? Investigate further? If yes, in which direction? Investigate Further, of course! :) I just did the same thing. Try for a few more iterations. Or, more quickly, create a bunch of new document windows all at once (cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n cmd-n etc),then close them all (opt-cmd-w, I think) and then mark the heap. What I saw was the earlier iterations went to zero objects. Most likely, what we are seeing -- and I should probably do a follow-up posts on some of the patterns that are non-obvious until you understand them (took me a while to figure 'em out, certainly -- is a combination of lazy initialization and self-pruning caches. In particular: • As an application runs and touches more and more of the Cocoa APIs, including touching some multiple times, subsystems will be lazily initialized. This will show up as an odd allocation here and there. • Some subsystems have caches for expensive-to-compute items such as glyph caches, image caches, and the like. These are typically keyed on some configuration information such that, for example, as long as you keep rendering text with the same configuration -- the same attributes -- you won't be recomputing glyphs. Since there is no way to know when an app will stop using a particular cache entry (at least, not within the AppKit itself), the caches are pruned automatically as they reach a certain size by pruning the least recently used item(s). • As a program runs, the backing stores of certain collections may need to increase in size. This will cause completely random, typically malloc block, allocations to pop up in the middle of a set of heapshots. In general, what you are looking for is any iteration with ZERO allocations. If you see even one iteration -- one heapshot sample -- with zero allocations, it means that the code that you are directly testing (in this case, new document, close document) **does not directly cause any permanent allocations**. b.bum ___ 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: Heapshot Analysis to find Memory Accretion (Leaks)
On Oct 18, 2010, at 8:42 AM, Matt Gough wrote: Perhaps Apple should aim Instruments at itself. Inspired by Bill's post, I just did a HeapShot test on my own app. Instruments went up to 2.5GB real Mem and stayed at that when I closed the Instrument window. 2.5GB Real Mem is relatively meaningless. Furthermore, it is quite reasonable for it to not drop after you close all windows as the system isn't going to spend the cycles reaping memory unless there is demand for it. Activity Monitor -- assuming that is where you got the Real Mem number -- is pretty much entirely useless for doing any kind of performance testing beyond monitoring for the most basic symptom of a problem. If you see the Real Mem of an application climbing over time, that is a bad sign. Maybe. Beyond that, the number isn't useful. 'top' tends to be a much better tool for detecting such symptoms. Open a Terminal window and issue the command top -u -o pid. It display something akin to Activity Monitor, but with the numbers broken down a bit more and a more detailed systemic summary. It also uses less resources than AM in that it doesn't try to draw a picture. b.bum ___ 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
Heapshot Analysis to find Memory Accretion (Leaks)
Folks-- I wrote up an article on how to use the Mark Heap / Heapshot Analysis tools in Instruments to detect, analyze, and fix memory leaks, including those that leaks can't find. http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ I would encourage everyone to give it a spin with your app. If it is document based, then: - launch your app under Instruments with the Allocations Instrument - (1) open a document - select a thing, copy, paste - close the document (without saving) - press Mark Heap in Instruments - goto (1) Ideally, each Heapshot iteration should show 0 growth in almost all cases. enjoy, b.bum ___ 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: checking for thread existance
On Oct 16, 2010, at 11:46 AM, Dave DeLong wrote: You can save the NSThread instance in an ivar (after alloc/init'ing it), and then use all the NSThread methods to figure out what to do. (Don't forget to -start the thread when you're ready to kick it off) A far better solution, though, would be to use queues, if at all possible Either NSOperationQueue or GCD queues, specifically. b.bum ___ 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: NSScanner Failing with EXC_BAD_ACCESS
On Oct 15, 2010, at 12:00 PM, Hank Heijink (Mailinglists) wrote: NSString *theScannedString; I would set theScannedString to nil here to avoid your crash below. That would be making the assumption that the implementation of scanCharactersFromSet:intoString: does not muck with the pointer regardless of return value. Making such an assumption is no more safe here than it is with NSError** parameters. Check the return value and ***ONLY*** use the pass-by-reference return value if success is indicated. To do otherwise is to beg for a crash in the future. b.bum ___ 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: How did gcc handle synthesized atomic vs custom nonatomic setter/getter?
On Oct 10, 2010, at 5:10 AM, Jerry Krinock wrote: In deciding how to solve the problem, I'd like to know how gcc solved the problem! It seems there are three choices: (1) Wrap my non-atomic custom setter/getter code to make it atomic. (2) Change my declaration to make it nonatomic. (3) Somehow ignore the rule and compile the code as I wrote it. Which did gcc do? GCC ignored the problem and happily generated code that wasn't atomic. b.bum ___ 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: How did gcc handle synthesized atomic vs custom nonatomic setter/getter?
On Oct 10, 2010, at 10:20 AM, Bill Bumgarner wrote: On Oct 10, 2010, at 5:10 AM, Jerry Krinock wrote: In deciding how to solve the problem, I'd like to know how gcc solved the problem! It seems there are three choices: (1) Wrap my non-atomic custom setter/getter code to make it atomic. (2) Change my declaration to make it nonatomic. (3) Somehow ignore the rule and compile the code as I wrote it. Which did gcc do? GCC ignored the problem and happily generated code that wasn't atomic. That is, GCC is broken. LLVM is correct in indicating that your code is broken. To fix, either let the compiler synthesize both getter and setter or implement both. Note that 'atomic' has nothing to do with thread safety. In almost all cases, declaring the @property as 'nonatomic' is the right answer (in that your thread safety -- if needed -- is at a higher level of then individual properties). b.bum ___ 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: Return value of performSelector:onThread:?
On Oct 8, 2010, at 11:52 AM, Kyle Sluder wrote:
Using GCD:
id myObj;
dispatch_sync(dispatch_get_main_queue(), ^{ myObj = CreateTheObject(); });
__block id myObj;
dispatch_sync(dispatch_get_main_queue(), ^{ myObj = CreateTheObject(); });
___
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: Trouble calling class_addIvar()
On Oct 8, 2010, at 5:27 PM, Rick Mann wrote: Hmm...thinking about it a bit more...how do dynamically-synthesized property ivars work (where you just @synthesize them without declaring an ivar)? Do they use class_addIvar()? That suggests I'm wrong about class layout. It be compilation time code generation with the new runtime(s), the compiler can generate the storage during compilation of the class's implementation b.bum ___ 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: Encoding of property_getName() result?
On Oct 7, 2010, at 10:26 PM, Rick Mann wrote: The doc says that property_getName() returns a C string, but doesn't specify the encoding. I would like to work with the property name as an NSString, but I can't really make one without knowing the encoding. Assume UTF8 (really, ASCII) for now and file a bug asking for clarification (and send me the bug # offline; I'll follow up). b.bum ___ 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: What's the point of @properties?
On Sep 19, 2010, at 1:11 PM, Markus Spoettl wrote: One thing you get is automatic KVO change notifications. When you set a property through its setter, you don't have to use -willChangeValueForKey: and -didChangeValueForKey: in order to trigger -observeValueForKeyPath: messages for those objects observing the property (via -addObserver:). You'd get that anyway. The point of @property was to capture getters and setters into a single syntactic unit such that it is easy to see exactly what should be treated as a property/attribute/data-thingy on any given class. But not just that the set/get methods exist, but: - the memory management policy is now declarative in the interface - atomic vs. nonatomic is declarative - setter/getter can be mapped to other methods (getter=isEnabled, for example) - synthesis just works (pretty much every attempt at hand-rolled atomicity I've seen has been wrong or bog slow) - the IDE can deduce additional details of your code based on declaration (code-sense prefers properties on the RHS of a dot, for example) - minimize lines of code That last point has been achieved in stages. In the move to the modern Objective-C 2.0 ABI (the runtime you get on iPhone and 64 bit Mac OS X), you don't need to declare iVars for @property()s as the compiler will synthesize the storage, too. In llvm 2.0 top-of-tree, @synthesize is on by default for all @properties. Thus, with the latest bleeding edge compiler, all you need is the @property() (and cleanup in -dealloc) to declare a fully KVO compliant attribute of your class. The dot is syntactic convenience and pretty much nothing more. The dot does enforce more compiler checking than regular method invocations, though (can't use dot w/id and the compiler will whine if you use the dot in a non setter/getter role). b.bum (Who is still on the fence as to whether the dot was a good idea; it sure does cause confusion, but damned if it isn't awfully convenient. Sigh.) ___ 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 collection 32 64-bit
On Sep 14, 2010, at 7:34 AM, Jonathan Guy wrote: I was under the impression that if you compile GC in supported mode it was capable of loading code with or without GC? I'm a bit confused as to why this is happening. Can any GC gurus out the shed any light? Everything in an application must either be GC or non-GC, there is no mix-and-match. Sounds like the 32 bit non-GC flash plug-in is trying to load into the process and failing (assuming that is the mismatch). This also poses the question, if I create a dual architecture app can I specify GC for 64bit and non-GC for 32bit without having to create each binary separately and lipo-ing the two together manually. Yes -- Xcode supports per architecture flags and you can compile the 32 bit architecture non-GC and the 64 bit GC. b.bum ___ 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: How to debug this?
On Sep 9, 2010, at 4:27 AM, Luca C. wrote: 0 libobjc.A.dylib 0x7fff8766c11c objc_msgSend + 40 1 com.apple.CoreFoundation 0x7fff882e9cc6 _CFAutoreleasePoolPop + 230 2 com.apple.Foundation 0x7fff87a4881a Classic overrelease problem. Something, somewhere, is being over-released. First, run build and analyze on your source and fix (or explain) every issue it identifies. If still not fixed, run with zombie detection enabled (using Instruments, most easily). b.bum ___ 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: Embedding a system preference pane
On Aug 20, 2010, at 3:44 AM, Jon Guy wrote: Hi I'm trying to embed a couple of the system pref panes into an app by following the Apple documented method, here's basically whats going on: NSBundle *bundle = [NSBundle bundleWithPath:@/System/Library/PreferencePanes/SharingPref.prefPane]; Class principalClass = [bundle principalClass]; prefPane = [[principalClass alloc] initWithBundle:bundle]; [prefPane loadMainView]; [prefPane willSelect]; prefView = [prefPane mainView]; [[[self window] contentView] addSubview:prefView]; [[self window] makeKeyAndOrderFront:self]; [prefPane didSelect]; This works fine for one of the other panes. I then tried it for the Sharing pref pane but it only seems to be half working. The Pane appears and I can see the computer name and the table with the list of services but only the DVD Sharing service is working (somewhat). None of the other services are reflecting the state of that service and they are always greyed out. Also when you select a service it's corresponding settings view does not appear on the right side of the table (I hope this is making sense). This is not something hacky, it is documented by Apple and is supposed to work but it's clearly not or I'm doing something wrong. Any help would be appreciated. Preference panes are not designed to be embedded into applications other than the System Preferences application. Even if you were to make it work (which would require duplicating all of the internal functionality of the System Preferences application), you are setting yourself up for a maintenance and testing nightmare in that System Preferences' internal implementation details may change with any version of the OS, including the one-off interim versions that sometimes ship with new hardware. I.e. don't do that. b.bum ___ 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: Cocoa-dev Digest, Vol 7, Issue 847
On Aug 20, 2010, at 2:33 PM, Gregory Weston wrote: Bill Bumgarner wrote: Preference panes are not designed to be embedded into applications other than the System Preferences application. Even if you were to make it work (which would require duplicating all of the internal functionality of the System Preferences application), you are setting yourself up for a maintenance and testing nightmare in that System Preferences' internal implementation details may change with any version of the OS, including the one-off interim versions that sometimes ship with new hardware. I.e. don't do that. Is it fair to say that this caution is about the OP's specific goal of using Apple's prefPanes within another app in that they may have been custom-built to play nice with a custom version of System Preferences? Or does the documentation at http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/PreferencePanes/PreferencePanes.html need to be updated? Oh, wait. Better question: Is http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/PreferencePanes/Tasks/OtherApps.html simply wrong? You can reuse preference panes intended for System Preferences just like the Mac OS X Setup Assistant does with the Date Time preference pane. Yup -- I was channeling Pre-Snow Leopard pref panes. I was totally wrong. b.bum ___ 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: Custom zones...
On Aug 10, 2010, at 9:12 AM, Alastair Houghton wrote: That said, is the part about objects escaping zones really true for *NS*Zone? It's true for malloc zones, for sure, but the docs for NSRecycleZone say: Frees zone after adding any of its pointers still in use to the default zone. (This strategy prevents retained objects from being inadvertently destroyed.) Right -- I was talking about the historical, generic, use of NSZone. which seems to imply otherwise. You *are* just talking about *NS*Zone, right? malloc zones are very useful and I definitely don't want to see those go away (I'm thinking of a certain million-plus node data structure we maintain that we'd have to go calling free() a million or more times to release...) Right. Just NSZone. Malloc zones aren't going anywhere. b.bum ___ 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: Custom zones...
On Aug 10, 2010, at 1:31 AM, Alastair Houghton wrote: Sounds like a bug to me. While zones are *discouraged* (they're very definitely an advanced topic and easily misused), I don't think they're actually deprecated. Their use is deprecated and should be documented as such. Zones were never very useful. They seemed like they might be, but proved to be vastly more problematic than useful. (For those that don't know, the idea was to be able to create a zone for all of, say, a document's objects. Then, when the document was closed, you destroy the zone without destroying the individual objects.) The key problems were two fold. First, if a reference to an object in the zone escaped said zone and wasn't cleaned up prior to zone destruction, you ended up with an entirely unfathomable crash. This happened often. Secondly, if any object was allocated in the zone that required some kind of more-than-dealloc-or-free operations to occur when deallocated, the zone's destruction would bypass that. Nothing like a dangling backing store [window] to brighten your debugging day! Thus, zones haven't been used or really supported in a long, long, time. The only context where they would be safe to use is in sub-graphs of objects that are entirely comprised of classes you've written; where you control every last detail of the implementation and do not allow a reference to escape beyond your very well protected entry points into said sub-graph. b.bum ___ 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: NSTask
On Jul 26, 2010, at 1:39 PM, k...@highrolls.net wrote: What should the launchPath be for [NSTask setLaunchPath:path] ? ?usr/bin/rm is not valid i.e. where is rm? Why use a task to remove a file? Use NSFileManager's APIs. b.bum ___ 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: atomic properties and KVC
On Jul 14, 2010, at 10:50 PM, Michael Link wrote: and I use a KVC method to access the value of foo (e.g. [object valueForKey:@foo]; is it still accessed atomically? Yes. b.bum ___ 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: Pass-by value? warning (was: NSTextField fieldeditor subclass example? (and an unrelated other inquiry))
I missed the OP's post If the static analyzer is barfing up a false positive, please report it (http://bugreport.apple.com/ works fine). b.bum On Jul 7, 2010, at 10:34 AM, Matt Neuburg wrote: Maybe I should report this to the LLVM team? You can, but I wouldn't get my knickers in a twist about it. The static analyzer is just an analyzer. It does get some false positives, but so what? Just think of it as a list of suggested things to maybe think about; it isn't a definitive list of bugs or anything like that. m. ___ 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: static analyzer
On Jul 7, 2010, at 11:33 AM, Matt Neuburg wrote: On or about 7/7/10 11:17 AM, thus spake Bill Bumgarner b...@mac.com: I missed the OP's post If the static analyzer is barfing up a false positive, please report it (http://bugreport.apple.com/ works fine). Is that generally true? I mean, first of all, false positives are a well-known phenomenon with this static analyzer (the Web page at llvm.org talks about this). Second, they do no harm. I get a false positive in *any* of my apps that uses NSURLConnection, for example: Yup. That is really true. False positives are taken very seriously. That triggers a potential leak warning. Well, of course it is a *potential* leak. But it isn't a *real* leak, because I happen to know that I'm going to release this object in either connection:didFailWithError: or connectionDidFinishLoading:. (My code and memory management come right out of Apple's own examples here.) I know how NSURLConnections work; the static analyzer doesn't. But I would hardly call that a bug. The static analyzer can be taught about the idiosyncrasies of NSURLConnection. While the compilers are all about generically compiling code and making sure your code can be predictably evaluated within the defines of the standard and mores of the language, the static analyzer is very much all about making sure your code is behaving appropriately within the confines of the targeted APIs. b.bum ___ 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: inference of block return type
On Jun 28, 2010, at 1:45 PM, Michael Ash wrote:
But I was unable to find any discussion of HOW you explicitly declare
the return value of a block expression.
^ return-type (arg-list) { 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: inference of block return type
Nah -- still Cocoa related.
The syntax serves two purposes:
(1) Allow for fully specified, fully typed, definitions of blocks.
(2) Allow for blocks to be used in the über-simple unit-of-work role offered
by GCD where there are no arguments and no return values
Thus, the syntax full syntax is as I posted:
^return-type (arg-list) {code};
The return type is optional because there are so many cases where it can be
automatically inferred (and the compiler will complain -- loudly -- when that
isn't possible):
^ (arg-list) {code};
If there is no need for an argument list, then it can be omitted (achieving
goal (2)):
^ {code};
While more complex than require all elements all the time, that it makes the
dispatch_*() APIs much easier and more succinct to use (along with a number of
other APIs) was deemed to be powerful enough to warrant the complexity implied
by the additional flexibility.
You are correct that the documentation is lacking, but it is not completely
non-existent.
This document does demonstrate declaring a return type, but only in the context
of a typedef or block variable declaration (and not for a block literal):
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/Blocks/Articles/bxDeclaringCreating.html#//apple_ref/doc/uid/TP40007502-CH4-SW1
The Using Blocks also shows declaring a return type, but only on the type
definition and not on a block literal.
Many of the examples in A Short Practical Guide To Blocks also show declaring
a block with an explicit return type:
http://developer.apple.com/iphone/library/featuredarticles/Short_Practical_Guide_Blocks/
I've filed rdar://problem/8138925 asking for the documentation to treat the
block literal syntax in detail.
b.bum
On Jun 28, 2010, at 2:56 PM, Tony Romano wrote:
The syntax that Bill posted is not in the document. I hate the complexities
in this syntax, there is no reason that I can think of to have multiple
syntax to represent this object. Even talking to the GCD engineers at the
show, they agrees it's overly complex for no apparent good reason.
The syntax below to me seems inconsistent with the analogy the docs claim the
block syntax came from (declaring C function ptrs) or at least I don't
remember it ever using it in that form. (return type) (^blockname)
(parameters) seems sufficient imo. The whole idea was to stick to a format
that had precedence but use the new symbol ^(only remaining operator that is
not overloadable in C++) instead of *(btw, that wasn't a block with a void
return type :-).
Anyhows, I no longer think this is a cocoa question...
-Tony
On 6/28/10 2:41 PM, Michael Ash wrote:
On Mon, Jun 28, 2010 at 4:48 PM, Bill Bumgarnerb...@mac.com wrote:
On Jun 28, 2010, at 1:45 PM, Michael Ash wrote:
But I was unable to find any discussion of HOW you explicitly declare
the return value of a block expression.
^return-type (arg-list) {code};
Sure, but is this documented in Apple's docs? The link to Blocks
Programming Topics posted by Tony Romano doesn't seem to include it,
although it alludes to its existence. That page does link to Apple's
submission to the standard committee which does show that syntax, but
it seems like the sort of thing that ought to be on apple.com too. Did
we miss it?
Mike
___
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/tonyrom%40hotmail.com
This email sent to tony...@hotmail.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/bbum%40mac.com
This email sent to b...@mac.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: inference of block return type
On Jun 28, 2010, at 3:20 PM, Dave DeLong wrote:
Except that the Short Practical Guide to Blocks you linked to uses:
return type ^ (arg-list) { code };
That is a typedef form, not the block literal form.
Wee fun.
BOOL (^blocksOfFun)(int) = ^ BOOL (int x) {
return x % 3;
};
for(int i=0; i10; i++)
NSLog(@Is fun? %@, blocksOfFun(i) ? @YES: @NO);
2010-06-28 15:36:12.989 dfjkdfjk[4852:307] Is fun? NO
2010-06-28 15:36:12.991 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.991 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.992 dfjkdfjk[4852:307] Is fun? NO
2010-06-28 15:36:12.993 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.993 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.994 dfjkdfjk[4852:307] Is fun? NO
2010-06-28 15:36:12.994 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.995 dfjkdfjk[4852:307] Is fun? YES
2010-06-28 15:36:12.995 dfjkdfjk[4852:307] Is fun? NO
The underlying issue being that the C language's syntax -- as defined by
standard syntax -- is drawer full of knives, some without handles. Layer on
the C++ standard [Objective-C++] and some of 'em have blades on both ends that
are rusty.
That is to say that the function declaration comparison for blocks only applies
to typedefs because there is no inline named function form akin to a block
literal.
b.bum
___
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: C arrays as __block variables
On Jun 26, 2010, at 11:09 PM, Tony Romano wrote:
- (void)_copyOrMoveURLs:(SEL) s opMove:(BOOL)op src:(NSDictionary *)URLs
completionHandler:(void (^)(NSDictionary *newURLs, NSError
*error))handler
{
__block char array1[5];
array1[0] = 'W';
NSBlockOperation * foo = [NSBlockOperation
blockOperationWithBlock:^{
array1[1] = array1[0];
char b = array1[0];
NSLog(@char %c %c %c, array1[0],
array1[1], b);
}];
}
Works fine using 3.2.2prints out char W W W
And it will [correctly] break in 3.2.3 (or a later compiler -- LLVM
top-of-tree, for example).
It is only working by coincidence. You can construct a form that doesn't
work, if you are creative.
b.bum
___
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: C arrays as __block variables
On Jun 26, 2010, at 6:38 PM, Matt Neuburg wrote:
The docs say: There are two further restrictions on __block variables: they
cannot be variable length arrays, and cannot be structures that contain C99
variable-length arrays.
This would seem to imply that a __block variable *can* be a *fixed* length
array. But when I try to write into such an array inside a block, I get a
compile error, cannot access __block variable of array type inside block.
Who's mistaken, the compiler or the docs? Thx - m.
Neither. The issue is that a block array in C is, technically, sorta-kinda
variable length unless you do something to make it fixed length. I don't
remember the exact details beyond that it is a subtle edge case.
That something is typically to encapsulate it into a Struct.
This:
void foo() {
char barfy[100];
^() {
char b = barfy[0]; error: cannot access copied-in variable of
array type inside block
b = b;
};
}
This compiles just fine:
void bar() {
struct angus {
char barfy[100];
} kangus;
^() {
char b = kangus.barfy[0];
b = b;
};
}
b.bum
___
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: C arrays as __block variables
On Jun 26, 2010, at 7:48 PM, Tony Romano wrote:
hmmm. Your saying this doesn't work?
NSBlockOperation * foo = [NSBlockOperation
blockOperationWithBlock:^{
__block char array1[5];
array1[0] = 'T';
}];
It works fine for me. Are you saying something different?
No -- that works fine. That is a different expression than the one OP posted.
b.bum
___
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: C arrays as __block variables
On Jun 26, 2010, at 8:56 PM, Kyle Sluder wrote: Putting __block variables inside of blocks is completely pointless. The purpose of the __block qualifier is to mark variables in the enclosing scope to be copied into the block. Unless you have a Block within the Block and you want to share and update the variable across both... b.bum ___ 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: C arrays as __block variables
On Jun 26, 2010, at 9:14 PM, Tony Romano wrote:
That's why I asked for an example of what the op question is
http://lists.apple.com/archives/cocoa-dev/2010/Jun/msg01040.html
This would seem to imply that a __block variable *can* be a *fixed* length
array. But when I try to write into such an array inside a block, I get a
compile error, cannot access __block variable of array type inside block.
void foo() {
__block char barfy[100];
^() {
char b = barfy[0]; error: cannot access __block variable of array
type inside block
b = b;
};
}
void bar() {
__block struct angus {
char barfy[100];
} kangus;
^() {
char b = kangus.barfy[0]; // compiles fine
b = b;
};
}
The reason being that a Block_copy() or [block copy] will cause the __block
variables to be moved to the heap and, thus, the compiler must know the exact
size of all variables to be copied when emitting the copy helper.
b.bum
___
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: autorelease: how does this work!? (if at all)
On Jun 18, 2010, at 12:09 PM, Tony Romano wrote: First, the objects are retained by dispatch_async as others have mentioned. Second, I'm not sure why you used 2 queues for the tasks in your code, seems overly complex. Async queues are serialized, which means that you can continue to add to the queue and the jobs will be done in order which they were added. The next job will not start until the previous one in the queue is completed. To be precise, it is the Blocks runtime that takes care of memory management, triggered by dispatch_async()s copying of the block passed to it. As for their being two queues, that pattern is actually pretty common. A best practice is to subdivide your application into subsystems and then have one (or more, depending on concurrency used) queue per subsystem.The queues both allow the application to do work across many cores simultaneously while also providing a natural lock-less exclusion primitive per subsystem. The trick is to keep the object graphs being acted upon within the subsystems relatively isolated from each other (with the points of contention being carefully considered). b.bum ___ 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: NSLog and va_list
On Jun 17, 2010, at 5:37 AM, Alexander Spohr wrote:
But I think you want to know what the va_list contains.
Then you just loop over it.
man stdarg will help.
Example:
void foo(char *fmt, ...)
{
va_list ap;
int d;
char c, *p, *s;
va_start(ap, fmt);
while (*fmt)
switch(*fmt++) {
case 's': /* string */
s = va_arg(ap, char *);
printf(string %s\n, s);
break;
case 'd': /* int */
d = va_arg(ap, int);
printf(int %d\n, d);
break;
case 'c': /* char */
c = va_arg(ap, char);
printf(char %c\n, c);
break;
}
va_end(ap);
}
That won't work in the general case. In the above, you have arbitrarily
created a function and passed a format string that contains an also-arbitrary
mapping of character - type.
As someone else said, you cannot generically decode a va_list because there is
no type information available. When there is a format string, the rules are
API specific and you are going to have to decode the entire set of possible
combinations in the format string which, for NSLog and the like, can be quite
complex.
b.bum
___
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: Access ObjC class from PyOBJC
On Jun 2, 2010, at 2:16 PM, jonat...@mugginsoft.com wrote: My app is ObjC cocoa based It also loads and executes PyObjC classes. I require my loaded PyObjC code to access an ObjC class (myControllerClass) defined within an ObjC framework linked to the main application. The desired Python looks something like: #py import AppKit taskController = myControllerClass.sharedController() #py Do I need to define a py wrapper from my framework and import it to accomplish this? And if so, how is the wrapper constructed. Or am I missing something simple here. You don't need to define a wrapper or use bridge support metadata *unless* your class's API has methods whose arguments and types can't be handled by default (most can) *and* you need to call those from Python. import Foundation klass = Foundation.NSClassFromString(MyControllerClass) controller = klass.new() Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.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/bbum%40mac.com This email sent to b...@mac.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: Loading iPhone bundle in Mac OS X application
On May 4, 2010, at 11:26 PM, Csaba Trucza wrote: As far as I know the otest unit testing application runs as a command line tool (so I assume it is a Mac OS X application) and somehow manages to load the iPhone bundles. Any ideas? otest doesn't load the bundle at all. It examines the mach-o file directly. See /usr/include/mach-o/ b.bum ___ 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: Loading iPhone bundle in Mac OS X application
On May 5, 2010, at 1:13 PM, Kyle Sluder wrote: It tests the code that was built for the simulator. See here for more information:http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/135-Unit_Testing_Applications/unit_testing_applications.html What Kyle said -- I read otest as otool. :) But, depending on needs, you might likely need to use the mach-o APIs to introspect the binary. b.bum ___ 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: Cocoa Newbie MySQL
On Apr 28, 2010, at 10:35 AM, Jens Alfke wrote: SQLite works fine with multiple clients — it uses file locking to support transactions and ACID properties. I’ve used it that way myself. It just doesn’t scale as well as a full server-based system, because doing locking via the filesystem is slower than doing it in memory. But this is unlikely to affect you unless you’re doing really heavy-duty stuff. On the plus side, sqlite is already installed in the OS and is a zillion times easier to maintain than mysql (since the database is just a file, with no special access/permissions issues.) Only if the underlying filesystem absolutely positively gets locking right. Fine for HFS+, not so fine for various network filesystems and/or other operating systems. Even in the network filesystem case where locking is correct, it may be horrendously inefficient. Coherency can be an issue, too, depending on filesystem. I.e. avoid network filesystems with SQLite multiple clients. Down that path lies pain. Related, don't use SQLite modifications as an IPC mechanism. If you need app A to detect changes to the database from app B, use some other notification mechanism beyond watching the database file for changes. b.bum ___ 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: menu madness with retain count
On Apr 27, 2010, at 1:49 PM, Bill Appleton wrote: it's too bad this is unreliable an object should be able to return this info An object does return this info, the problem is that the # is a meaningless internal implementation detail of the Cocoa frameworks. For example, if you create an instance of NSNumber, you might actually get an allocated instance or you might get an additional reference to an already existing implementation. With NSString, you might get a constant string (i.e. retain counts are entirely meaningless), a cached instance of one of the more common strings, a substring of one of the former two, or you might get a new allocation. NSImage may or may not return a new instance depending on cache availability. Similarly, when you give an object to any API in the framework, what the framework does with it internally is an implementation detail and one that might change from release to release. When you create an NSMenuItem instance and hand it off to the framework, it might be retained once, twice, 10 times or not at all (remember: if you want to keep an object around, you need to maintain a retain on it). All of this is why trying to do debugging on absolute retain counts is a waste of time. and it isn't simple, it gets convoluted in process As do the implementation details of most highly optimized complex software systems if i add a submenu to an item then it is retained by the menu but then if i then set that submenu to nil is it still retained? Maybe so, maybe not. Implementation detail. Maybe it is retained until the next pass through the main event loop? Maybe it is pushed into the autorelease pool? Maybe the retain is held for as long as some internal structure is kept about. The point is that you don't know, can't know, and shouldn't care. The absolute retain count is irrelevant. if retained count was accurate you could test it on final release, etc The retain count is accurate. Is always accurate. It is just that the value of the retain count may be influenced by factors well beyond your control. All you care about is the retain count delta. My code caused the retain count to increase by 1, therefore my code *must* decrease the retain count by 1. My code is 'passing' a reference to this object from thread A to thread B, therefore I *must* have an explicit retain in A and a release in B. Frankly, the -retainCount method should be deprecated and, eventually, removed. b.bum ___ 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: menu madness with retain count
On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote: On 04/27/2010 1:58 PM, Bill Bumgarner b...@mac.com wrote: Frankly, the -retainCount method should be deprecated and, eventually, removed. I wouldn't go THAT far; after all, when you're tracking a memory leak, checking your influence on the retain count is important to your investigation. Hopefully that's why the original poster is looking at it. The combination of leaks, zombies, heap, and malloc stack logging are much *much* more powerful and effective than trying to debug a leak, over-retain or under-retain with -retainCount. b.bum ___ 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: menu madness with retain count
On Apr 27, 2010, at 3:05 PM, Uli Kusterer wrote:
On 27.04.2010, at 23:22, Gary L. Wade wrote:
Calling -retainCount
immediately before and after the -setDelegate call is pretty much the only
way.
Nope. It'll only lead to pain and suffering. And false positives. What if
setDelegate was implemented thus:
-(void) setDelegate: (id)dele
{
mDelegate = dele;
[self detachNewThreadSelector: @selector(useDelegateOnThread:) withObject:
dele];
}
Grand Central Dispatch can confuse matters further and in subtle ways.
Consider:
dispatch_async(..., ^{... time consuming maybe ...;
dispatch_async(dispatch_get_main_queue(), ^{ ... dele ...}); });
In this case, the two dispatch_asyncs are going to call Block_copy() in a
predictable order but with a high degree of variability in timing (both due to
time consumed in outer block and workload on main queue). End result is that
the retain count will be changing behind your back regardless of what you are
doing in other threads. More confusing, still, if the scheduling of the inner
block on the main queue happens before your code runs, but the block's
execution is blocked by your code running on the main queue, you *might* see a
retain from the first block and *will* see the retain from the second block.
b.bum
___
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: Text file
On Apr 15, 2010, at 8:50 AM, Henrietta Read wrote: What's the correct way to open a text file? I'm using: NSError *error = nil; NSStringEncoding encoding; [myMutableString setString:[NSString stringWithContentsOfFile:filePath usedEncoding:encoding error:error]]; but on some files (say, Western Mac OS Roman) it crashes. assembly deleted First, I'd suggest you post the backtrace of the crash, not the assembly. Trying to debug a crash by looking at the assembly at the crash site is typically a method of near-last resort. Given zero context, the above lines of code look fine. Context needed to deduce this farther would be things like how filePath is initialized, how myMutableString was created, and the actual backtrace of the crash (and any other diagnostic messages, including whether or not you took a pass after build and analyze and fixed any problems it identified). b.bum ___ 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: [NSMutableArray array]
On Apr 8, 2010, at 7:35 AM, Patrick M. Rutkowski wrote: What I was worried about is that maybe NSMutableArray (or any sub-class in general) would need to do some special sub-class-specific initialization, which it might not have implemented. I guess though, if you're going to be sub-classing a class, then you ought to generally make sure that all of it's static method will work on your new sub-class? There's always the danger that the super-class will have new static methods added without your knowledge though. There is no such thing as a static method in Objective-C; there are class methods and instance methods. Class methods are inherited just like instance methods. Thus, when you say [NSMutableArray array], NSMutableArray's implementation of +array will be invoked (if it exists), regardless of whether or not said method is declared in the @interface of NSMutableArray. b.bum ___ 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: [NSMutableArray array]
On Apr 8, 2010, at 10:21 AM, Patrick M. Rutkowski wrote: Agreed, but there's always the danger the +array method, which might actually be implemented in NSArray.m, will not properly initialize the more specific NSMutableArray object. Of course, in this specific case that's the case, but it might be the case with other class hierarchies. But, nonetheless I'm troubled that nobody in this thread has acknowledged that yet :-o Because, in practice, that doesn't generally happen. Across the system supplied frameworks, classes generally have designated initializers and those initializers are inherited properly. The convenience creation methods -- factory methods, if you will -- are dead simple stupid, generally doing the equivalent of '[[[self alloc] init*] autorelease]' where the init part calls the designated initializer. If a subclass needs a more specific initializer, the inherited, simpler, initializer from the superclass is typically overridden to barf an error or call the more specific with a default argument. Thus, the risk is largely -- there are probably an exception or two and, if you know of one, file a bug -- confined to the code you write. Generally, class hierarchies in Objective-C tend to be relatively shallow and relatively well factored (if you are doing it right, anyway).When there is inheritance, the most effective use is in maintaining consistency in interface across super and subclasses, including the designated initializers. So, again, in your own code the risk should be relatively minor in a clean design. Now, of course, none of us are perfect and just about all of us have put together a shoddily architected, way too deep, class hierarchy now and again. Even when slinging crap code, there is no reason why it can't be defensive crap code, too! b.bum ___ 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: Switching methods in private classes in Apple frameworks
On Mar 11, 2010, at 8:58 PM, Gideon King wrote: So as long as you are careful about what you do, yes it is entirely possible to replace methods at will. I hope nobody misuses it, but it certainly was essential in my debugging - yes, I found it! Yay! Where careful about what you do includes only use this in debugging code or non-production instrumentation, sure Do *not* ship such shenanigans in production code. One software update later and suddenly the presumptions made about that internal method you are replacing/overriding/augmenting are no longer true and *boom*. (been there, done that, the scars run deep -- seriously, don't ship it that way. :) b.bum ___ 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: Better sorting using threads?
On Mar 11, 2010, at 11:15 AM, Andrew James wrote: Does Cocoa have sorted containers so that an object can be inserted in sorted order? If so it seems like this would be far less expensive. Depends entirely on need. Keeping a container sorted on insert can be quite expensive; potentially considerably more expensive than doing a single batch sort at the end. On-the-fly sorted containers are generally only applicable when updates to the container will be frequently interleaved with read operations. b.bum ___ 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: Question Re Memory Management in Apps
On Mar 8, 2010, at 7:44 PM, Philippe Sismondi wrote: if(![super init]) return nil; Since no one else mentioned it in the followups, the above is wrong. This is correct: self=[super init]; if (!self) return nil; ... etc ... b.bum ___ 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: Deprecated APIs
On Feb 23, 2010, at 8:57 PM, Steve Christensen wrote: That code uses blocks, though, which implies that it will be compiled using a later version of Objective-C. Will that code really run on older versions of OS X? The compile-time conditional assumes that you're building against the 10.6 SDK (or later). Obviously if you're going to support both cases, you'll need to use a compiler configuration that is compatible with all the OS versions you plan to support. There are symbols *sometimes* emitted by compilation of blocks that won't be available on prior releases of Mac OS X and, thus, will cause a dyld error on launch on those platforms. Be careful. b.bum ___ 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: Multithread communication
What Kyle and Jens said, but there is one particular cardiac action impaired horse that I wanted to flog... On Feb 3, 2010, at 8:30 AM, McLaughlin, Michael P. wrote: I thought that this should all be correct but somehow it crashes, at times immediately, at other times only when everything is done and, 90 percent of the time, not at all! I have attempted various remedies, including a static NSLock for getOpResults(), retaining the NSOperations for a while in the main thread, using a dependent signal to say that all threads should be finished, using a countdown int to say the same thing. So far, nothing has solved the problem. No amount of locking around thread unsafe API will make said API thread safe. That is, you can't -- say -- put locks around your calls into the methods of -- say -- the AppKit and make the AppKit magically thread safe. If you are using locks around code that you didn't write to fix threading issues, you aren't actually fixing anything (but you are guaranteed to be making for some terribly fun debugging sessions later). b.bum ___ 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
objc_msgSend() tour
Folks- I finally banged out part IV -- the 'slow path' odds/ends -- of my tour of objc_msgSend() on x86_64. If you want to know how method invocations works in instruction by instruction detail on x86_64, you might find it interesting: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/ (that contains the table of contents to the other three articles) b.bum ___ 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: NSBundle unloading crash
On Jan 29, 2010, at 4:09 AM, Jonathan Guy wrote: Thanks Greg. It was indeed a category issue but I seem to have fixed one problem and found another. If I load the first bundle, make a method call, then immediately unload, load the second bundle and make the same function call (all in the same event) I end up crashing when the autoreleas pool gets popped. If I do each in a separate event everything is fine. Am I right in assuming it is only the code that gets unloaded and no memory that has been initialised by methods in the bundle get freed when the bundle is unloaded i.e. is it safe for me to keep an NSDictionary around that has been passed back to me by a method in the bundle once it has been unloaded? (the dictionary contains only standard foundation kit objects). Also any other things to watch out for would be greatly appreciated. Probably not safe and not because of the dictionary. Namely, if your dictionary contains any keys or values that were constant strings defined in a bundle that has been unloaded, you will crash. In short; unloading bundles is rife with sharp edges to the point of being effectively unsupported. You are far better off *not* supporting bundle unloading. b.bum ___ 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: if statement causing 32 Byte leak?
On Jan 10, 2010, at 10:29 AM, Glenn L. Austin wrote: If Instruments didn't crash on launch of our app, it would have been very helpful. I use it for my own projects (which aren't quite as large), but it wasn't available for this case. malloc_history and MallocStackLoggingNoCompact would very likely have worked, though. b.bum ___ 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: if statement causing 32 Byte leak?
On Jan 10, 2010, at 4:01 PM, Paul Sanders wrote: It would be extremely simple for Apple to implement this suggestion and there's no question in my mind that it would rapidly nail a certain class of bug, so what's to lose? Famous last words ;) b.bum ___ 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: if statement causing 32 Byte leak?
On Jan 10, 2010, at 4:01 PM, Paul Sanders wrote: It would be extremely simple for Apple to implement this suggestion and there's no question in my mind that it would rapidly nail a certain class of bug, so what's to lose? Famous last words ;) All snark aside, I wrote a weblog post detailing how to use tools other than Instruments to debug leaks and over-release bugs. http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/ Some might find it useful. b.bum ___ 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: Question about garbage collection
On Jan 4, 2010, at 5:31 AM, Quincey Morris wrote: On Jan 3, 2010, at 18:21, Ben Haller wrote: Bill, I for one would like to hear a bit more about this. What has changed in SL? Why would it ever be possible to outrun the collector? If the limit of memory is being reached, can't it always just do an immediate, synchronous collection before the call to +alloc returns? I'd love to have a better understanding of what's going on under the hood here... I think this: http://lists.apple.com/archives/Cocoa-dev/2009/Jun//msg01586.html is the thread where b.bum threw some light on that issue. (But I didn't reread the whole thing, so some of what I remember may be from a different thread.) Yes -- this message covers the high level issues related to doing an exhaustive blocking scan-and-collect when memory runs low or, more specifically, out. http://lists.apple.com/archives/Cocoa-dev/2009/Jun//msg01630.html b.bum ___ 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: GC memory leak - what is it?
On Jan 4, 2010, at 11:50 AM, jonat...@mugginsoft.com wrote: A recent post mentioned the concept of GC memory leakage. How is is this defined? Is it merely a failure to nil out a rooted reference? man heap(1) makes reference to over-rooted objects. Are these merely objects with more than one root reference or is something else afoot? Under GC, a memory leak will fall into one of two categories: (1) An object was CFRetain'd, but never CFRelease'd. This is exactly like over-retaining an object in non-GC . Note that, in general, if you are using CFRetain under GC, it is only to work around a limitation somewhere or because of a design flaw. If you need to use CFRetain to work around something, please file a bug! (2) A hard reference to an object that isn't cleaned up. For example, many applications have a cache somewhere, typically key/value pairs. I have seen a number of these where, under non-GC, the cache never retained the values and was never pruned. Because the values were never retained, the values in the cache were released and deallocated, leaving behind a dangling value with a key that would no longer ever be accessed. In the move to GC, this created a leak in that the cache would often default to a strong reference. Lesson; prune your caches! It isn't so much thinking of it as a reference that needs to be nil'd out as much as it is a need to properly disconnect a subgraph of objects from the live object graph in an application such that the subgraph is collected. That is, nil'ing out references is a fix for a symptom where the overarching problem is one of properly managing the connectivity of the object graph within the application. b.bum ___ 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: GC memory leak - what is it?
On Jan 4, 2010, at 1:39 PM, jonat...@mugginsoft.com wrote: How can a multiple stack root occur? Is this just saying that the same object is referenced by multiple stack allocated pointers at the time that the sample was taken? That is correct; the object may be referenced by multiple local variables [on the stack]. Note that since the stack is scanned conservatively, you may be seeing stale references -- references that have gone out of scope. Presumably a stack root cannot be the source of any persistent leak as once the frame is gone so is the root. One would like to believe that, but it isn't always the case. On AMD64, the ABI specifies that there is a red zone of 128 bytes allocated just below the current stack pointer that can be used as scratch space. Thus, the collector has to also scan the red zone conservatively. However, the red zone will often contain whatever local variables -- including arguments (which are an awful lot like local variables, really) -- that were written there when the current frame called a function somewhere, pushing a frame below. Hence the need for objc_clear_stack(). Among other things, it clears the red zone. (Don't let the details scare you -- as long as you are using the recommended run loop / grand central dispatch mechanisms for looping and waiting, clearing the stack is handled automatically. That is, very very few developers will ever run into a need to deal with this directly). Sorry if this is dumb question. I am struggling to comprehend just what the ObjectGraph tool is telling me. Docs seem MIA for this tool (or maybe it's me that's MIA). File a bug, please! Most of my rooted objects are statically allocated singletons. ObjectGraph correctly identifies them as single roots. Good. Note that you can also use gdb to perform the same analysis. In any GC'd program, 'info gc-roots addr' and 'info gc-referers addr' can be used to interrogate the connectivity of the object at addr. b.bum ___ 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: Question about garbage collection
On Jan 3, 2010, at 9:59 AM, Michael Abendroth wrote:
When I write something like:
while (true) {
NSString *s = [[NSString alloc] initWithString:@applejuice];
}
Will s be garbage collected? If not, how can I make sure it does get
deallocated by garbage collection.
I'm not entirely sure what pattern you are asking about; repeated
allocations? ...writing your own looping construct?
In any case, the rules of collection for the stack are thus:
A thread's stack is conservatively scanned. That is, every slot that *could*
hold a pointer is scanned to see if it holds a pointer, regardless of type
declaration. Thus, as long as there is a reference to an object on the stack,
that object will remain uncollected. If the reference is overwritten (and no
references exist elsewhere in the heap and the object has not been CFRetain'd),
the object will be collected.
The stack has to be conservatively scanned because the C ABI makes no guarantee
about stack layout and the compiler is free to put values wherever it sees fit,
including overwriting values with other values as a part of optimization (which
is the same reason why you sometimes can't print local variable's values when
debugging optimized code).
This can cause an object to live longer than expected. In practice, this
rarely happens, though, as run loops zero the stack -- only to the depth needed
-- on each loop (as does Grand Central).
If you are writing your own looping construct, you can call
objc_clear_stack(...) to clear the stack at appropriate times, typically when
the stack is as shallow as possible. Prior to Snow Leopard, writing your own
looping construct was relatively rare in Cocoa. With Snow Leopard's addition
of Grand Central Dispatch, writing your own looping construct is actively
discouraged (though, certainly, there are still reasons to do so).
b.bum
___
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: Question about garbage collection
On Jan 3, 2010, at 2:45 PM, Graham Cox wrote:
On 04/01/2010, at 4:59 AM, Michael Abendroth wrote:
When I write something like:
while (true) {
NSString *s = [[NSString alloc] initWithString:@applejuice];
}
Will s be garbage collected? If not, how can I make sure it does get
deallocated by garbage collection.
As written, it's academic, as your program will never proceed beyond this
point, and will eventually crash with an out of memory error.
In Leopard, definitely.
In Snow Leopard, maybe not. It is a rather contrived test case, but it is much
more difficult to outrun the collector in Snow Leopard than it was in Leopard.
b.bum
___
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: Using performSelector:withObject:afterDelay: to call a delegate method?
On Dec 30, 2009, at 9:08 AM, Helen Cooper wrote:
[self performSelector:@selector(doSomething00) withObject:NULL
afterDelay:4.0];
-(void)doSomething00{
[someDelegate doSomething];
}
I am wondering though, if there might be a way to use
performSelector:withObject:afterDelay: (or some similar method) to call the
delegate method directly?
[delegate performSelector:@selector(doSomething) withObject:nil
afterDelay:4.0];
b.bum
___
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: Core Data Fetch Invariance
On Dec 26, 2009, at 9:38 AM, Richard Somers wrote: Objects in a persistent store are unordered. If I fetch the objects, change nothing in the store, then fetch them again, do the two fetches give me the objects in the same order? Maybe. Behavior is undefined. b.bum ___ 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: Releasing Objects
On Dec 22, 2009, at 11:49 PM, Franck Zoccolo wrote: You said that you're using garbage collection. When using GC retain and release messages do nothing, and the retain count is not used to determine when an objet can be freed from memory. If -retainCount is returning 1, then he can't be using GC. Under GC, -retainCount -- being the utterly useless method that it is that no one should ever call -- returns self. b.bum ___ 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: NSRecursiveLock problems
On Dec 22, 2009, at 11:19 AM, PCWiz wrote: Is there any easy way to execute a portion of code on the main thread without going through the mess of delegates and selectors? Delegates have *nothing* to do with main thread execution. Selectors a bit orthogonal, too. If you want to execute something on the main thread, I would suggest using NSOperationQueue's notion of main queue and enqueuing an operation with a block: - (void)addOperationWithBlock:(void (^)(void))block Quite straightforward. b.bum ___ 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: Releasing Objects
On Dec 22, 2009, at 9:40 PM, Michael Craig wrote: NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]); [converter release]; NSLog(@Reference count: %lx, (unsigned long) [converter retainCount]); If the -release is going to deallocate converter, then the subsequent -retainCount's behavior is undefined. b.bum ___ 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: [ myWorkSpace openURL: myurl ] is leaking. Why??
On Dec 10, 2009, at 11:55 PM, Parimal Das wrote: I must be missing something here. Can anyone point what is wrong here. (1) there is no need for an autorelease pool in such a simple -awakeFromNib. It will be in the context of an autorelease pool to begin with and doesn't create enough memory load to warrant a nested pool. (2) To determine why leaks says those two dictionaries are leaking, first find their content and then turn on malloc stack logging and figure out where they were allocated. To do the first, break into gdb and -- obviously substituting the address that leaks reports -- 'po 0x13b9b0'. That'll dump the contents of the dictionary. If you set the environment MallocStackLoggingNoCompact to YES, then you can do -- also in gdb -- 'info malloc 0x13b9b0' and see the allocation point of the object in question. Or... alternatively... use Instruments as it can track leaks. b.bum ___ 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: Reboot? Slow First Run
On Dec 3, 2009, at 8:10 AM, gMail.com wrote: Thanks. I supposed that I was loading from the cache. It's a pity. It was too nice to load 10,000 files x 4KB each, in only 1.2 secs. Maybe one day, when I will be not longer on this planet :-) Just to mention I run MacOSX 10.6.2 and I build against 10.5 (32 bit). Well 10,000 x 4KB files sounds like an excellent design for the benefit of spotlight [which needs individual files for each data item it indexes] but is a very poor design for reading all that data at once. Prior to the disk cache being warmed up, reading those 10,000 files requires a boatload of I/O of the worst kind in that the data is unlikely to be contiguous. If you want to speed up the initial read, cache the contents of the 10,000 files into a single file. Even those 10,000 files laid out contiguously and memory mapped is going to be faster, but you can do much better by effectively 'compiling' the data into some form that is much more convenient to read. This is *exactly* what Address Book, Mail and other applications do. In the case of AB and Mail, they are using CoreData and SQLite directly respectively to store the data into a single file. Perhaps CoreData would fit your needs as well (you haven't said what the 10,000 files contain). Anyway I would like to say a thing that I wanted to say for years. Despite to the faster and faster processors and machines, the better and better OSs... still today with a Core 2 Duo Intel 2.4GHz and MacOS X 10.6.2 at 64 bits (which is considered mainly as an improvement of the stability and speed), when I open my /Applications folder, I have to wait for 3, 4 or 5 seconds to see the contents of the folder. I recall that my Mac II with the System Mac 1.0 (in 1988) was faster. Think over ;-) Yes, but the one thing that *hasn't* changed in all those years is that hard drives have *not* gotten ~150x faster [CPU speed] and zillions of times faster on the memory speed front. Hard drives are slow, slow, slow. Yet, the metadata being read to -- say -- display that folder full o' applications is considerably larger. Heck; The recommended icon size on Mac OS X Snow Leopard -- 512x512x4 -- is *larger than the total resolution of the original Macintosh's screen*. Even more amusing; a modern icon fully decompressed will take up 1MB of RAM -- it wasn't until the Mac II that a Macintosh had enough memory to even load such a beast! And that is just the icons. You also have the full blown localization support and permissions metadata, too. The first read is several orders of magnitude more data, all spread around the disk, than that Mac II and from a device-- the hard drive-- that is *not* several orders of magnitude. Now, if you want an eye opener, test your 10,000 x 4KB file read w/cold disk cache on a decent SSD drive... b.bum ___ 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: libauto: what's agc error: Can not allocate new region
On Dec 2, 2009, at 12:24 PM, Greg Parker wrote: The 64-bit garbage collector reserves a 32 GB heap and will not expand it further. If you allocate more than 32 GB you'll run out of memory. Actually, it is an 8GB heap. b.bum ___ 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: libauto: what's agc error: Can not allocate new region
On Dec 2, 2009, at 1:01 PM, Sean McBride wrote: If GC memory is really limited to 8 GB (and not 32), then I probably am hitting that limit with the guard pages on. :( Is there a way to increase that limit, at least in debug? 8 is pretty puny. :( Grab the source. It is just a constant. You should be able to build libauto using Xcode and, if in your shared build directory, your app will pick it up (I know you know this, but for the benefit of everyone else) And Jens, AUTO_USE_GUARDS is the same principle as Guard Malloc, but they are not identical. As I understand it, the former applies to memory in the GC zone, the latter to the malloc zone. In my app anyway, AUTO_USE_GUARDS is slow, GuardMalloc is slower, and with them both on it's very slow indeed. That is correct. b.bum ___ 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
What does the 8GB limit in GC really mean? Re: libauto: what's agc error: Can not allocate new region
There seems to be some confusion as to what the 8GB limit under GC means. So, a clarification The 8GB limit is only on GC based allocations. That is, your app can allocate up to 8GB of GC'd allocations, no more. There is no such limit on the other allocation zones (the malloc zone, for example). In practice, applications exceedingly rarely allocate anywhere near 8GB of objects. Almost every large-memory-use application manages a few hundred megabytes or maybe a gig or two of object allocations with the Very Large Allocations typically living in either the malloc zone, mapped memory, caching mechanisms, or managed via some other means. In Leopard, the 64 bit collector's zone was 32GB. Given that nothing was using anywhere near that amount of heap in practice, that a zone of that size *does* have a cost in terms of kernel memory (wired) memory use, and there simply aren't very many machines in the world with more than 8GB of RAM, the size of the zone was lowered to 8GB for Snow Leopard. Obviously, memory prices are falling, CPUs are getting faster, and the # of machines with 8GB+ of RAM will likely rise dramatically in the coming years. There is a bug tracking upping said limit b.bum ___ 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: Keyword @defs
On Nov 30, 2009, at 12:50 PM, Dennis Munsie wrote: Not that I'm advocating it, but you can also declare a field as @public to allow you to access it via the - operator. Of course, I could be missing some compiler magic going on behind the scene as well, and it may not actually be the same speed wise as @defs was. The compiler preserves the non-fragile part of non-fragile ivars when using the - operator. Not to mention that it's just plain nasty :) Yup, that it is. b.bum ___ 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: Keyword @defs
On Nov 29, 2009, at 4:21 PM, Oftenwrong Soong wrote: What exactly is this @defs keyword supposed to do? It effectively turned an Objective-C class declaration into a standard C structure such that you could access the instance variables directly via a simple - operator. Was mostly used for speed of access when working with poorly architected classes. ;) It has been deprecated in 32 bit and removed entirely in the modern ABI [64 bit and iPhone OS] because it, obviously, totally and completely destroys encapsulation. It also makes it impossible to implement non-fragile iVars. b.bum ___ 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: SystemConfiguration.framework
On Nov 28, 2009, at 5:02 PM, William Squires wrote: SCDynamicStoreRef SCDynamicStoreCreate ( CFAllocatorRef allocator, CFStringRef name, SCDynamicStoreCallBack callout, SCDynamicStoreContext, *context ); Here's where my confusion begins. Did you read the documentation for that function? It seems relatively straightforward. What have you tried? 1) Would I declare this as a) SCDynamicStoreRef myRef; b) SCDynamicStore *myRef; c) SCDynamicStore myRef; // Probably not, I believe only C++ defines the operator this way d) SCDynamicStoreRef *myRef; a) SCDynamicStoreRef, as indicated by the Ref suffix, will be a pointer to a structure that contains an SCDynamicStore: typedef const struct __SCDynamicStore * SCDynamicStoreRef; This kind of declaration generally indicates that the contents of whatever the SCDynamicStoreRef points to is opaque; is not something you can muck about with directly. 2) Is a CFStringRef replaceable with a literal NSString via toll-free-bridging? And exactly what does it expect this string to contain? The name of the compiled executable? An NSString will work fine. From the header file, it is described as A string that describes the name of the calling process or plug-in of the caller. And so does the documentation. Lacking more specific information, try calling it with the bundle identifier of your app or plug-in. 3) Do I need the callback? The function to be called when a watched value in the dynamic store is changed. Pass NULL if no callouts are desired. 4) Is there an ObjC class that encapsulates this functionality? Nope; you might file a bug if you would like one. 5) The documentation states that the SCDynamicStoreRef needs to be released. I assume using the free() function in the C stdlib.h header? Copy/paste from the documentation: ... Note that these functions follow Core Foundation function-name conventions. A function that has Create or Copy in its name returns a reference you must release with the CFRelease function. b.bum ___ 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: Apache Module
On Nov 27, 2009, at 4:30 PM, Mr. Gecko wrote: Well I'm wanting to be able to write image generators and other things that is near impossible to do in php or any other web scripting language, also running compiled source is faster then a script. My idea is to write a module so I can just use a SDK that I will write to make different things in Objective-C. For now I have a custom server in cocoa that when you visit it, it returns a image based on parameters and this module would really make my life easier. My recommendation would be to continue with this architecture. Apache tends to spawn a bunch of children -- either in the form of processes [old school] or threads [new school -- IIRC] -- and you are quickly going to find yourself in multi-threading hell if you try to integrate directly with Apache. By running a separate server process, you can choose how and when you apply multithreading hell to achieve scalability (if necessary). For your model, the key is to have the most efficient connection between client [apache] and server [your image server daemon]. For that, rolling your own may be the right answer. Then again, HTTP server - backend server is a very well explored area of technology that may offer a pre-rolled solution for you. b.bum ___ 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: Apache Module
On Nov 27, 2009, at 5:08 PM, Mr. Gecko wrote: My idea was to basically write a module that runs NSTask to start the cocoa binary and just have a framework to like manage the server information and talk to the module, by printf I guess, saying like which headers to return and the data so I can set the content-type to image/png if I wanted to return a png. Well all I can say is it's really complicated, I guess all I need is to write a module that runs exec(); and handles outputs until it quits. As soon as you get NSTask into the mix, you are likely going to kill performance [and might as well just use straight CGI, at that point] If scalability matters at all, you are going to want the image creation to be handled by something that sticks around long enough to cache and otherwise avoid the cost of repeated startup and disk I/O. If there is any text parsing or other transformation between whatever your server or process spews and what is sent back to the client, you are likely going to kill performance, too. b.bum ___ 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: principle classes from two bundles get confused
On Nov 8, 2009, at 5:47 AM, Shai Shasag wrote: How could this be? I think the problem is that both bundle_A bundle_B have principle class with the same name. Somehow Cocoa gets confused. No somehow about it. Objective-C does not support namespaces; all classes (and selectors) exist within the same namespace. If you were to look at the console log, you'd probably see a very specific message indicating where the two identically named classes came from. Why would two different bundles have principle classes with the same name you might ask? Well actually there are more than a hundred such bundles in my project. Each bundle is a plugin that follows the same API. If I was to write a different principle class for each it would be a nightmare to maintain. Is there a way to tell Cocoa to use the class from each bundle regardless that they both have the same name? Yes -- name the classes differently. Some folks use a #define to vary the class name per bundle. And please file a bug via http://bugreport.apple.com/ asking for a solution to this particular issue. You could copy and paste your original message into the bug report, if you want. b.bum ___ 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: NSInvocation and methods with non-pointer parameters
On Nov 2, 2009, at 2:17 AM, Jim Kang wrote:
I seem to be able to use NSInvocation to execute methods that have
parameters are pointers, like NSString* or NSDictionary*, but when I try to
invoke a method with a parameter that is not a point, like this -
(void)methodWithCGPoint: (CGPoint)pos;
- I get an EXC_BAD_ACCESS when I run it with code like this:
SEL sel = @selector(methodWithCGPoint:);
if ([self respondsToSelector: sel])
{
NSMethodSignature *sig = nil;
sig = [[self class] instanceMethodSignatureForSelector:sel];
NSInvocation *invocation = nil;
invocation = [NSInvocation
invocationWithMethodSignature:sig];
[invocation setTarget:self];
[invocation setSelector:sel];
[invocation setArgument:pos atIndex:2];
[invocation invoke];
}
What is the correct way to set the CGPoint argument to NSInvocation? The
CGPoint can't get released before the invocation is finished, so [invocation
retain] doesn't help.
If you are targeting Snow Leopard, use blocks instead... much more
straightforward.
b.bum
___
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: Double-clicking a screensaver
Related, I recently ported a handful of [really ancient NeXTSTEP] screensavers to Snow Leopard, including the ability to run on both 64 bit GC'd and 32 bit non-GC'd Snow Leopard or Leopard (ppc or i386). http://www.friday.com/bbum/2009/10/19/spiroscales-source-for-snow-leopard-available/ http://www.friday.com/bbum/2009/10/25/dphyllotaxis/ The source -- including project files -- can be found here: http://svn.red-bean.com/bbum/trunk/ScreenSavers/ svn co http://svn.red-bean.com/bbum/trunk/ScreenSavers/ (SpiroScalyLizardSaver contains the xcode project, etc...) b.bum ___ 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: Mysterious crash in objc_msgSend in GC app
On Oct 27, 2009, at 10:43 AM, Sean McBride wrote: Occasionally, my GC app crashes in objc_msgSend with none of my code in the backtrace. This only happens to customers; I've never caught it in gdb. I've read through Greg's awesome So you crashed in objc_msgSend() article, but I still don't have a clue. :( I'm able to determine that the selector was from libobjc.A.dylib but I don't know which (the uuid from dwarfdump does not match mine). I guess I'm hoping this backtrace looks familiar to someone out there... :) Look at the argument registers (see Greg's Awesome Article) and see if any of 'em point to a hole in or very near the list of dylibs. The most common cause for a crash like this has been improper unloading of a bundle. There still exists an instance of one of the classes in the bundle (or a reference to one of the classes or a constant NSString) and the messenger is crashing trying to execute a method on said object/class. The other possibility, of course, is memory corruption. Something stomping on the isa of an instance will cause a crash that looks a lot like that one. b.bum ___ 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: Mysterious crash in objc_msgSend in GC app
On Oct 27, 2009, at 3:08 PM, Sean McBride wrote: nor do I do any dynamic loading nor unloading of bundles. You don't, but there appear to be certain QuickTime components -- decoder/encoder modules, perchance? -- that do and will inside your application if you use QuickTime. There may be other plugin-by-implication-of-API-use that do the same. And there appears to be at least one of them that is doing unsafe unloading, given the various crash logs that I have seen in the recent past. If you, or anyone, can provide more specific evidence than that, I would really appreciate an email or bug report (http://bugreport.apple.com) with the additional details! b.bum ___ 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: is GC not available on 10.5.8?
On Oct 23, 2009, at 5:04 AM, Nick Rogers wrote: I compiled using Xcode3.2 on 10.6.1, 10.5 base sdk and for Intel 64-bit only with GC only option. The program compiles fine, but the following error is there when launching it on 10.5.8 system: (window doesn't appear) EXC_BREAKPOINT (SIGABRT) Dyld error message: unknown required load command: 0x8022 GC is fully supported on 10.5.8. Something else is broken. Are you linking against any non-Apple libraries? Have they been built correctly? Also, what is the list of libraries / frameworks you are linking against? b.bum ___ 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: is GC not available on 10.5.8?
On Oct 23, 2009, at 8:40 AM, Nick Rogers wrote: Thanks for the reply. The app actually works as a launcher of another app with root privileges (its only job is this). Hence its a standard cocoa project with the following frameworks: CoreFoundation, Cocoa, AppKit, CoreData, Foundation and Security frameworks. To debug the problem, I would suggest turning on the DYLD_PRINT_LIBRARIES environment variable and see if it stops printing at a certain library, then check to make sure that library is both 64 bit and GC capable. However, for best performance on 10.5.x, I would suggest compiling your launcher app as a 32/64 bit application. 32 bit applications on 10.5.x will be more efficient in that the 32 bit chunks of all the shared frameworks are always kept hot by other applications -- you'll tend to page less under memory pressure with a 32 bit app on 10.5.x. (The opposite is true on Snow Leopard and, as more and more applications go 64 bit, it'll become more-so over time). b.bum ___ 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: Sending a Selector to another Class.
On Oct 22, 2009, at 5:54 AM, Jim Kang wrote: However, a selector is not a string. I was just listening to this podcast with Mike Ash, and he discusses this around the 9:23 mark or so: http://podcast.mobileorchard.com/episode-23-mike-ash-on-the-objective-c-runtime-objects-and-the-runtime-message-sending-and-no-such-method/ He explains that comparing strings is too slow for the runtime to use for finding messages and so it uses integers to represent the messages and calls them selectors. Selectors are strings, but it is an implementation detail. The runtime uniques the strings such that there is only ever one instance of, say, the drawRect: selector floating about. Thus, the runtime can use pointer comparison to determine selector equality. It is an implementation detail though. One that is exceedingly unlikely to ever change but, still, an implementation detail. Use the Objective-C runtime API if you want to do selector comparison. sel_isEqual(), IIRC. b.bum ___ 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: GC Re: Questions about Nib Object Retention
On Oct 21, 2009, at 7:45 AM, Fritz Anderson wrote: Does this mean that there's a race between the NIB loader's need to create a strong reference and the GC thread's imperative to collect the object before it is referenced? No; the objects are strongly referenced by stack or by the de-archival mechanism through until well after the reference on your object has been set. b.bum ___ 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: info gc-roots interpretation
On Oct 21, 2009, at 1:39 AM, Nick Rogers wrote: (gdb) info gc-roots 0x2004f9340 Number of roots: 1 Root: 0 Kind: bytes rc: 1 Address: 0x000200543b40 Offset: 0x0008 1 Kind: object rc: 0 Address: 0x0002004f9340 Class: Volume Is there a retain cycle problem. The memory gathered by this ivar is not freed, as per Obj-Alloc Instrument. What shall I make out of these results and how can they lead to refinement (so that all the memory referenced by this ivar is freed)? rc: 1 means that the object has been CFRetain'd by something. That is, something somewhere decided that it was going to bypass the collector and has failed to call CFRelease when done. Use the ObjectAlloc instrument in Instruments to track it down. You can also: set env MallocStackLoggingNoCompact 1 set env AUTO_REFERENCE_COUNT_LOGGING 1 And then use 'info malloc 0x2004f9340'. It'll typically show all CFRetain/CFRelease events. (But not always -- there is a bug that prevents it from showing all of 'em. However, ObjectAlloc works around it.) b.bum ___ 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: GC and atomic getters/setters
On Oct 17, 2009, at 8:38 AM, BJ Homer wrote: But assuming that you wanted it there in the first place, why does the GC version not need the synchronization? Under GC, object reference assignments -- scanned pointer assignments, technically -- are, in and of themselves, atomic. Note that structures will still require atomicity protection in GC, if desired (though, yes, property level atomicity is generally the wrong answer for ensuring thread safety). In non-gc, the need to send some combination of -retain/-release/- autorelease method calls leaves a window within which a caller may get a hold of an object reference that is about to be released in another thread. Thus, the need to use some form of locking or synchronization primitive to ensure that this doesn't happen. As Kai said, GC's natural atomicity in object assignment is a distinct advantage. In particular, it makes concurrent programming a bit less tricky as there is no need to play retain-on-one-thread-to-release-on- another-thread games. b.bum ___ 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: Programming Style: Method Definition with or without a semicolon.
On Oct 16, 2009, at 12:17 AM, Sander Stoks wrote: If it's a feature, then it's definitely a new one since the original specification of Objective-C. It turned out to be surprisingly hard to find that specification, but I found a grammar description here:http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/Concepts/ ObjectiveC/B_Grammar/Grammar.htmld/index.html There it says: instance-method-definition: sp.gifc2D.gif [ method-type ] method-selector [ declaration- list ] compound-statement method-selector: sp.gifunary-selector sp.gifkeyword-selector [ , ... ] sp.gifkeyword-selector [ , parameter-type-list ] The declaration-list and compound-statement are not specified further and are taken from the C spec. In other words: There's no semicolon. On the other hand, the grammar spec has been removed from Apple's documentation, and I suppose the official line is now Objective-C is whatever we ship with Xcode. I haven't booted my NS 0.8 cube in about a decade, but I'm pretty sure the semi-colon was always required in the header file and always allowed in the @implementation. 'Twas many a moon ago, but, I do distinctly remember triple-clicking method declarations from headers (with semis) to copy-paste into my implementation without deleting the semi. It always stuck with me as an über-convenience. b.bum ___ 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: odd behavior with NSError?
(response is pedantic for the purposes of the archive :)
On Oct 15, 2009, at 10:41 PM, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
Yes; it is incorrect.
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
Specifically, assuming anything about the value of 'internalError'
without first determining the return value of -
somethingReturningBool:error: returned a value indicating an error
(typically NO/0/nil/NULL) is an error.
I got into this habit because most every method is documented to say
things like parameter used if an error occurs and May be NULL.
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm
starting to worry that I'll spend tomorrow fixing much old code
instead of getting to make new mistakes...
They don't go out of the way to trample it, but may trample it as a
part of whatever internal implementation they use.
I have, however, debugged several bugs that have boiled down to code
assuming the NSError**'s value is definitively indicative of an error.
In one case, a method that takes an (NSError **) argument may call
other methods that take the same, it might -- as an implementation
detail -- pass the argument through, maybe even one of those returns
hey, man, an error occurred, and the caller might recover from it
and eventually return success, but not actually clear the error value
in the process (because there is no need to do so, by definition of
the API).
A similar problem occurred when the NSError** was set up to describe
some problem, later corrected, and then the error was released.
Success was returned, but the caller assumed the error was valid...
*boom*.
b.bum
___
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
