Re: NSFileWrapper and plist
On Sep 13, 2013, at 6:46 PM, Trygve Inda wrote: > I have an NSDictionary that contains objects that support NSCopying. I can > use writeToFile:atomically: and it saves a nice plist file that I can read > cleanly. > > If I use NSFileWrapper however (for my document-based app), I need to use a > keyed archiver to conver the NSDictionary to NSData. After NSFileWrapper > saves it, the plist is no longer really legible as a plist because it has > lots of extra objects list $objects and $top. > > Is there anyway to have NSFileWrapper save my dictionary in a user-friendly > format so that I can see it as a normal dictionary in the plist utility? NSPropertyListSerialization https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/Classes/NSPropertyListSerialization_Class/Reference/Reference.html -- Seth Willits ___ 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
NSFileWrapper and plist
I have an NSDictionary that contains objects that support NSCopying. I can use writeToFile:atomically: and it saves a nice plist file that I can read cleanly. If I use NSFileWrapper however (for my document-based app), I need to use a keyed archiver to conver the NSDictionary to NSData. After NSFileWrapper saves it, the plist is no longer really legible as a plist because it has lots of extra objects list $objects and $top. Is there anyway to have NSFileWrapper save my dictionary in a user-friendly format so that I can see it as a normal dictionary in the plist utility? Thanks, Trygve ___ 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: Helper tool
On Sep 13, 2013, at 6:47 AM, Gerriet M. Denkmann wrote: > I have a helper tool (started via SMJobBless from the main app). > > Its launchd.plist contains (no idea why, probably I copied this from some > sample code): > LaunchOnlyOnce = YES > RunAtLoad = YES > OnDemand = NO > > The problem: it runs even when the the main app has never asked it to run. > Obviously it gets started automatically on login (or even directly after > reboot?). Yep. You asked it to. launchd launched it for you, and your app probably just sits waiting for something to happen vs immediately acting on args and exiting when done. Delete them as Charles said. ;) > What launchd options are needed for this? None at all, actually. Just supply the Label and (likely) the MachServices entry so that you can communicate via XPC or whatnot. > Is there some other way to find out whether it is running? SMJobCopyDictionary(kSMDomainSystemLaunchd, …) There will be a PID entry if it's running. On Sep 13, 2013, at 12:08 PM, Jeremy Matthews wrote: > I'm getting prepped for writing few of those...any good sample code out there? > > I was having some issues compiling Apple sample code from a version of Xcode > that shall not be named...throwing bizarre errors. Figured I'd start with > some sane, validated goodness. I just started doing this yesterday as well. Get the latest SMJobBless sample code and *read everything*. You have to understand all the codesigning nonsense before the sample will even run. It's actually not too difficult. I'm sorting through XPC right now making sure I'm doing it right, but it's all working. -- Seth Willits ___ 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: Helper tool
On Sep 13, 2013, at 10:09 AM, Charles Srstka wrote: > On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann" > wrote: > >> I have a helper tool (started via SMJobBless from the main app). >> >> Its launchd.plist contains (no idea why, probably I copied this from some >> sample code): >> LaunchOnlyOnce = YES >> RunAtLoad = YES >> OnDemand = NO >> >> The problem: it runs even when the the main app has never asked it to run. >> Obviously it gets started automatically on login (or even directly after >> reboot?). > > The problem, obviously, that you don't want those options. Just get rid of > all of them and the default values should be fine for what you want to do. My > launchd.plist just looks like this: > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> > > > label > com.foo.MyGreatApp > MachServices > > com.foo.MyGreatApp.helper > > > ProgramArguments > > > /Library/PrivilegedHelperTools/com.foo.MyGreatApp.helper > > > > > Charles I should add that if you want to see what all the available options are for launchd.plist, you can get a nice description of them by typing "man launchd.plist" in the Terminal. Charles ___ 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: ARC vs Manual Reference Counting
On Sep 13, 2013, at 11:51 AM, Paul Scott wrote: >>> The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you >>> don’t notice, the flat profiles, are in some ways more insidious, as they >>> drag everything down just a bit. Along with all the other things that >>> drag everything down a bit, and soon enough you have something that’s 10% >>> or 2x or 10x slower than it needs to be and no obvious culprits. >> Yes, this is definitely a problem, and an unsolvable one at that. > > Not necessarily. Recently, on IBM z/Architecture platform, some JNI code I > wrote ended up showing a bunch of unremarkable flat profiles when captured > with hardware instrumentation at various intervals. Looking for any possible > performance improvements, I examined the code associated with each > unremarkable profile, and found some routines that were being called > unnecessarily (returned after a quick condition check); when the logic was > changed so as to avoid the checks (which was quite unobviously called from a > loop) there was a 40% improvement in CPU performance. You might be surprised > what you can find by looking at those flat profiles. Sorry, I did not mean that analyzing flat profiles is generally unsolvable, just that when the overhead imposed by ARC is evenly distributed across many call sites, there isn’t an obvious way for a user to recover that performance. John. ___ 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: Helper tool
On 13 Sep 2013, at 17:15, Gerriet M. Denkmann wrote: >> >> I should add that if you want to see what all the available options are for >> launchd.plist, you can get a nice description of them by typing "man >> launchd.plist" in the Terminal. > > This I have done already (but thanks for the hint anyway), but I couldn't > make sense of it. Thus my question here. I had exactly the same experience. I feel that a lot of the documentation relating to Launch Agent and Launch Daemons for OS X is written for an audience of people who come from a very different unix background to OS X and have been used to writing daemons for other unix platforms and using fork to start their daemon process etc.. The documentation is possibly useful to that audience but is not suitable for an audience of OSX developers or iOS developers. I even considered learning about developing daemons for unix platforms other than OS X just so that the documentation might make sense to me but that seemed to open up a whole new can of worms. I have a number of open bug reports on the documentation for this area: Radar: 14479026 Essential documentation is not clear (man launchd.plist) Radar: 14478979 Tech note 2083 is out of date Radar: 1487 Daemons and Services programming guide provides misleading information Kevin ___ 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: Window controllers and memory leaks
On 13 Sep 2013, at 17:12, Jonathan Taylor wrote: > > > However the static analyzer complains that there is a "potential leak" of > myWindowController, because it recognises that it has a retain count of 2 > when it returns from the init method. (The same applies if I don't retain in > init and don't release in TestWindowController). > > It strikes me that this would be quite a common pattern. I appreciate that > the static analyzer doesn't *know* whether there's a leak or not, but if I am > indeed correctly following a common pattern then I would have expected the > analyzer to understand what is going on. > > My question then is whether I am doing things in an unconventional way here, > and/or whether there is something I could change that would help the analyzer > understand what is going on. It's complaining because init is not a "special" (alloc, copy, new, magic method), normally the pattern I would use is to put it into a property and then release it at dealloc time. That way the property is holding a reference to the object and then analyser won't complain! Cheers Dave ___ 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: Window controllers and memory leaks
On Fri, Sep 13, 2013, at 09:12 AM, Jonathan Taylor wrote: > I want to allocate a window + controller, and I want it to live until the > user closes the GUI window, at which point I want it to disappear and > clean up after itself. I believe that the following code does not leak > memory and behaves as intended. Don't do this. Experience has taught us that apps are more stable when developers don't make exceptions to the standard memory management rules. Add a property to your app delegate that retains the window controller. Have your window controller listen for NSWindowDidCloseNotification from its window, and send a message to the app delegate. In response to this message, the app delegate should release the window controller (probably by assigning its property to nil). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Helper tool
I'm getting prepped for writing few of those...any good sample code out there? I was having some issues compiling Apple sample code from a version of Xcode that shall not be named...throwing bizarre errors. Figured I'd start with some sane, validated goodness. Thanks, j ___ 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: Odd NSScroller behavior when clicking page dec/inc areas
On Fri, Sep 13, 2013, at 11:14 AM, Steve Mills wrote: > What's up here? It sure smells like a bug. It does, but it might be one you can work around by changing how you're implementing scrolling. If I understand correctly, you need to pin a pane of controls to the edge of the viewport, and scroll the content underneath. The typical way this is implemented in a Cocoa app is to move those controls to a separate NSView that is a subview of your document view. Listen for NSViewBoundsDidChangeNotification from the clip view, and set the overlaid controls' view's frame such that it is pinned to the side you desire. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Helper tool
On 13 Sep 2013, at 22:10, Charles Srstka wrote: > On Sep 13, 2013, at 10:09 AM, Charles Srstka wrote: > >> On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann" >> wrote: >> >>> I have a helper tool (started via SMJobBless from the main app). >>> >>> Its launchd.plist contains (no idea why, probably I copied this from some >>> sample code): >>> LaunchOnlyOnce = YES >>> RunAtLoad = YES >>> OnDemand = NO >>> >>> The problem: it runs even when the the main app has never asked it to run. >>> Obviously it gets started automatically on login (or even directly after >>> reboot?). >> >> The problem, obviously, that you don't want those options. Just get rid of >> all of them and the default values should be fine for what you want to do. >> My launchd.plist just looks like this: >> >> >> > "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> >> >> >> label >> com.foo.MyGreatApp >> MachServices >> >> com.foo.MyGreatApp.helper >> >> >> ProgramArguments >> >> >> /Library/PrivilegedHelperTools/com.foo.MyGreatApp.helper >> >> >> >> >> Charles > > > I should add that if you want to see what all the available options are for > launchd.plist, you can get a nice description of them by typing "man > launchd.plist" in the Terminal. This I have done already (but thanks for the hint anyway), but I couldn't make sense of it. Thus my question here. Gerriet. ___ 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
Odd NSScroller behavior when clicking page dec/inc areas
We have a scroll view whose horizontal scroller needs to work in a different mode sometimes (same mode that my previous scroll view problem is in). We set the scroller's target and action so we can control the size and position of the thumb via "[scroller setKnobProportion:proportion]" and "scroller.doubleValue = pos" respectively. Here's the problem: First I click and hold in the page-right area for a while to move the thumb to the right. Then I click and hold in the page-left area to go back to the left. Here's where the bug happens. The first page-left will cause a page-left (correct), but all actions after that will cause a page-right (not at all correct). Our action method asks the scroller for the hitPart. It returns NSScrollerDecrementPage correctly for the initial mouseDown, but then returns NSScrollerIncrementPage as the mouse is held down, and the mouse is still clearly to the left of the thumb after we're repositioned it via setting scroller.doubleValue. If I grab the mouse position from the window and convert it to the coords of the scroller, then ask the scroller to testPart that point, it returns the correct part, which is *different* than hitPart. What's up here? It sure smells like a bug. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Window controllers and memory leaks
This must be an incredibly basic question, but I haven't found an answer I'm
convinced by (apologies if I have missed something on the list). My question
relates to window controllers, and how ownership, retain/release etc should be
managed in order to (a) be correct and (b) satisfy the static analyzer. This
has come up because it's only now that I have migrated my codebase to be
compatible with the latest version of xcode that I have been able to run the
static analyzer over it and examine the results.
I want to allocate a window + controller, and I want it to live until the user
closes the GUI window, at which point I want it to disappear and clean up after
itself. I believe that the following code does not leak memory and behaves as
intended.
@interface MyWindowController : NSWindowController
{
}
@end
@implementation MyWindowController
-(id)init
{
if (!(self = [self initWithWindowNibName:@"MyNib"]))
return nil;
// Window will release self when closed, so we need to retain
an extra time here
[self retain];
return self;
}
-(void)dealloc
{
printf("Deallocated\n");
[super dealloc];
}
-(void)windowWillClose:(NSNotification*)note
{
[self autorelease];
}
@end
void TestWindowController(void)
{
MyWindowController *myWindowController = [[MyWindowController alloc]
init];
[myWindowController.window makeKeyAndOrderFront:nil];
// We own a reference to myWindow since we allocated it,
// but we have now finished all the setup we want to do
// and are relinquishing control of the window object,
// releasing it into the big wide world to live or die
// as it may.
[myWindowController release];
}
However the static analyzer complains that there is a "potential leak" of
myWindowController, because it recognises that it has a retain count of 2 when
it returns from the init method. (The same applies if I don't retain in init
and don't release in TestWindowController).
It strikes me that this would be quite a common pattern. I appreciate that the
static analyzer doesn't *know* whether there's a leak or not, but if I am
indeed correctly following a common pattern then I would have expected the
analyzer to understand what is going on.
My question then is whether I am doing things in an unconventional way here,
and/or whether there is something I could change that would help the analyzer
understand what is going on.
Many thanks
Jonny.
___
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: ARC vs Manual Reference Counting
On Sep 13, 2013, at 3:04 AM, Marcel Weiher wrote: > On Sep 11, 2013, at 10:38 , John McCall wrote: >>> [inline reference counts] >> >> >> Right. ARC doesn’t replace the benefit of having an inline reference count. >> I think if we could magically bless all objects with an inline reference >> count without worrying about disrupting existing hard-coded object layouts, >> we probably would. > > I can think of 3 ways, which you obviously never have thought of yourselves, > because you guys just don’t bother with that sort of thing... *g*: > > 1.Non-fragile ivars, just insert one where you want it > > Problem there is probably that ivars aren’t as non-fragile in practice as > we’d like. In addition, a whole word might be a bit much, especially when > you already have an inline refcount tucked away somewhere else. > > 2.IV() trick > > Just tack it on at the end of each object that wants one…problems with > class-size not reported correctly (we’re looking at you, CoreFoundation) and > custom allocs. Right, both of these are very difficult because of widespread code that assumes things about the layout of objects. Also, adding extra fields to objects could easily push them over allocation quanta. It’s a hard problem. > 3.3 bits in the class pointer > > Since we aren’t allowed to get the isa pointer directly these days anyhow, > that means we can mask out the low-order bits in object_getClass(), > objc_msgSend() and the non-fragile ivar access code..hhmmm. Number of bits > depends on whether you just rely on alignment or also grab what’s there from > malloc() bucketing (probably shouldn’t). The “Getting Reference Counting > Back into the Ring” paper claims that with 3 bits of recount, you avoid > overflow for > 95% of objects, so that would be pretty good. We’ve certainly looked into things like this. > Of course, automagic isn’t necessarily a requirement, so my favorite is: > > 4.Do it yourself assistance > > How about a function that takes a pointer to wherever I stashed my reference > count and did all the right things, for example wrt. weak references? Or a > macro. Did I mention this one’s my favorite? You’re certainly welcome to file a radar asking for an SDK feature like that if you haven’t already. >> [opting local variables out of ARC using __unsafe_unretained] >> Absolutely. We’ve found that it usually doesn’t take very many >> __unsafe_unretained annotations to eliminate most regressions. There are a >> ton of places where any human reading the code would immediately realize >> that an object won’t get released, but ARC can’t quite prove that, usually >> because there’s an intervening message send. > > There’s a bunch of interesting research again on region analysis and proving > things statically, now that the practical limitations of copying collectors > are becoming more widely appreciated (see also all the off-heap stuff going > on in Java-land). Rust is also interesting the way it puts in some > programmer involvement in declaring intent, but then helps with making sure > that this intent isn’t violated. The trouble is that Objective-C is essentially immune to non-heuristic static analysis, not just formally but in practice as well. People can and do dynamically add and replace methods on classes, use isa swizzling to change the class of an existing object, and so on, all of which individually make interprocedural region analysis impossible. >> Most of those places don’t detectably affect performance; it’s the one or >> two that happen in a loop and therefore trigger 40,000 times that you >> notice. But by the same token, those sites tend to show up in Instruments >> and so are easy to track down and fix. > > The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you > don’t notice, the flat profiles, are in some ways more insidious, as they > drag everything down just a bit. Along with all the other things that drag > everything down a bit, and soon enough you have something that’s 10% or 2x or > 10x slower than it needs to be and no obvious culprits. Yes, this is definitely a problem, and an unsolvable one at that. John. ___ 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: ARC vs Manual Reference Counting
The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Yes, this is definitely a problem, and an unsolvable one at that. Not necessarily. Recently, on IBM z/Architecture platform, some JNI code I wrote ended up showing a bunch of unremarkable flat profiles when captured with hardware instrumentation at various intervals. Looking for any possible performance improvements, I examined the code associated with each unremarkable profile, and found some routines that were being called unnecessarily (returned after a quick condition check); when the logic was changed so as to avoid the checks (which was quite unobviously called from a loop) there was a 40% improvement in CPU performance. You might be surprised what you can find by looking at those flat profiles. Paul smime.p7s Description: S/MIME Cryptographic Signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Helper tool
On Sep 13, 2013, at 8:47 AM, "Gerriet M. Denkmann" wrote: > I have a helper tool (started via SMJobBless from the main app). > > Its launchd.plist contains (no idea why, probably I copied this from some > sample code): > LaunchOnlyOnce = YES > RunAtLoad = YES > OnDemand = NO > > The problem: it runs even when the the main app has never asked it to run. > Obviously it gets started automatically on login (or even directly after > reboot?). The problem, obviously, that you don't want those options. Just get rid of all of them and the default values should be fine for what you want to do. My launchd.plist just looks like this: http://www.apple.com/DTDs/PropertyList-1.0.dtd";> label com.foo.MyGreatApp MachServices com.foo.MyGreatApp.helper ProgramArguments /Library/PrivilegedHelperTools/com.foo.MyGreatApp.helper Charles ___ 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
Helper tool
I have a helper tool (started via SMJobBless from the main app). Its launchd.plist contains (no idea why, probably I copied this from some sample code): LaunchOnlyOnce = YES RunAtLoad = YES OnDemand = NO The problem: it runs even when the the main app has never asked it to run. Obviously it gets started automatically on login (or even directly after reboot?). This is not necessary. If it is not running, the main app should start it via SMJobBless. If it quits (or crashes) the main app may start it again (no automatic restart necessary). What launchd options are needed for this? Another question: [NSRunningApplication runningApplicationsWithBundleIdentifier: @"name of helper tool" ] returns an empty array. But Activity Monitor shows "name of helper tool" as running and my main app can communicate with it. Is there some other way to find out whether it is running? In the case that the main app cannot communicate with it (because something might be screwed up) I want to know whether it has died or not. Gerriet. ___ 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: ARC vs Manual Reference Counting
On Sep 11, 2013, at 10:38 , John McCall wrote: >> [reduced need for Café Macs dinner tickets] > > Fortunately. :) But you do know where to get them anyway…? ;-) >> [inline reference counts] > > > Right. ARC doesn’t replace the benefit of having an inline reference count. > I think if we could magically bless all objects with an inline reference > count without worrying about disrupting existing hard-coded object layouts, > we probably would. I can think of 3 ways, which you obviously never have thought of yourselves, because you guys just don’t bother with that sort of thing... *g*: 1. Non-fragile ivars, just insert one where you want it Problem there is probably that ivars aren’t as non-fragile in practice as we’d like. In addition, a whole word might be a bit much, especially when you already have an inline refcount tucked away somewhere else. 2. IV() trick Just tack it on at the end of each object that wants one…problems with class-size not reported correctly (we’re looking at you, CoreFoundation) and custom allocs. 3. 3 bits in the class pointer Since we aren’t allowed to get the isa pointer directly these days anyhow, that means we can mask out the low-order bits in object_getClass(), objc_msgSend() and the non-fragile ivar access code..hhmmm. Number of bits depends on whether you just rely on alignment or also grab what’s there from malloc() bucketing (probably shouldn’t). The “Getting Reference Counting Back into the Ring” paper claims that with 3 bits of recount, you avoid overflow for > 95% of objects, so that would be pretty good. Of course, automagic isn’t necessarily a requirement, so my favorite is: 4. Do it yourself assistance How about a function that takes a pointer to wherever I stashed my reference count and did all the right things, for example wrt. weak references? Or a macro. Did I mention this one’s my favorite? > [opting local variables out of ARC using __unsafe_unretained] > Absolutely. We’ve found that it usually doesn’t take very many > __unsafe_unretained annotations to eliminate most regressions. There are a > ton of places where any human reading the code would immediately realize that > an object won’t get released, but ARC can’t quite prove that, usually because > there’s an intervening message send. There’s a bunch of interesting research again on region analysis and proving things statically, now that the practical limitations of copying collectors are becoming more widely appreciated (see also all the off-heap stuff going on in Java-land). Rust is also interesting the way it puts in some programmer involvement in declaring intent, but then helps with making sure that this intent isn’t violated. > Most of those places don’t detectably affect performance; it’s the one or > two that happen in a loop and therefore trigger 40,000 times that you notice. > But by the same token, those sites tend to show up in Instruments and so are > easy to track down and fix. The joys of a nice skewed profile. Ahhh…. :-) Of course, the ones you don’t notice, the flat profiles, are in some ways more insidious, as they drag everything down just a bit. Along with all the other things that drag everything down a bit, and soon enough you have something that’s 10% or 2x or 10x slower than it needs to be and no obvious culprits. Cheers, Marcel ___ 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: Analyser reports memory leak… where?
On 12/09/2013, at 6:07 PM, Kyle Sluder wrote: > Personally, I would avoid doing this, as it could cause reentrancy among > KVO observers of eventTypes. Instead, I'd assign to mEventTypes directly > from your lazy initializer. Or perhaps I would factor out the common > setter code to a private helper method. Indeed, I have changed the code to do just this, which is what I would have written in the first place (honest!). I'm not sure why it wasn't and changing it appears to have not caused any problems. > Hopefully this has the side effect of shutting the analyzer up. It does. I guess the thread is now really about why the analyser was thrown off by this. Academic? Perhaps, but here's the bigger picture: I want to gradually move my codebase to ARC, so in preparation for that, I have been going through and trying to ensure the analyser is happy, since my understanding is that ARC relies on the same analysis to do its thing correctly, so if the analyser is getting it wrong, converting to ARC might introduce a bug here. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Analyser reports memory leak… where?
On 2013-09-12 17:52, Graham Cox wrote:
I believe it does. I think your reading of the getter convention may
be incorrect. If you can point to explicit documentation that states
that the returned object must belong to an autorelease pool, I'll
stand corrected, but that would be the first time I've ever heard that
in 13 years of Cocoa programming!
Even if there is such a rule:
- (id) eventTypes
{
// [self lazyInitEventTypes];
return [[mEventTypes retain] autorelease];
}
Bye,
Daniel
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
