WWDC 2013 Core Data Earthquake Sample?
In the WWDC 2013 video about Core Data performance, they used an Earthquake app. But this one is nicer than the threaded Core Data sample code. The sample you can get uses none of the optimizations shown in the WWDC 2013 talk. Is that Earthquake sample available anywhere? If not, Apple really should make all their WWDC talk apps available. For that matter, they should make the WWDC app itself available as source. TIA, -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: WWDC 2013 Core Data Earthquake Sample?
> On 2014/02/16, at 17:50, Rick Mann wrote: > > In the WWDC 2013 video about Core Data performance, they used an Earthquake > app. But this one is nicer than the threaded Core Data sample code. The > sample you can get uses none of the optimizations shown in the WWDC 2013 talk. > > Is that Earthquake sample available anywhere? > > If not, Apple really should make all their WWDC talk apps available. For that > matter, they should make the WWDC app itself available as source. > > TIA, > > -- > Rick File a radar bug requesting it. ___ 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: Display selectd sub-menuItem in NSPopUpButton
Yes, my solution is to put all the items in a simple menu without submenus and indent the subitems, as we can see here https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcQxp-WYrNvXgqix4JRmVyc4 G-4FXagcs6-PQv8gHr6eLndafMHp Easy, simple, it works. Thank you for your suggestions. They drove me here. Regards -- Leonardo > Da: > Data: Sun, 16 Feb 2014 09:45:05 +0900 > A: Leonardo > Cc: Graham Cox , List Developer Cocoa > , Keary Suska > Oggetto: Re: Display selectd sub-menuItem in NSPopUpButton > > Now that I think about it clearly, you might want to consider something like > NSPathControl similar to the way Xcode lets you navigate files. > It probably makes more sense for showing a hierarchical selection in a small > space. > > Sent from my iPhone > >> On 2014/02/16, at 3:00, Leonardo wrote: >> >> I think there should be a way to just open and display the submenus and >> highlight a menu item, even if the mouse is elsewhere. >> Then if the mouse moves and select a different menuItem, ok, I do. >> Otherwise, at the mouseUp, if the mouse didn't move or it is out of the menu >> area, I leave the previous menuItem selected. >> >> John, if you agree, I can send you the xcode project to your email address >> only, since on the list we can't attach documents. Or I can load it on >> github.com. >> >> Regards >> -- Leonardo >> >> >>> Da: Graham Cox >>> Data: Sat, 15 Feb 2014 21:34:36 +1100 >>> A: Leonardo >>> Cc: List Developer Cocoa >>> Oggetto: Re: Display selectd sub-menuItem in NSPopUpButton >>> >>> On 15 Feb 2014, at 8:29 am, Leonardo wrote: I would like to re-click and pre-select that meu item but I didn¹t succeed yet. >>> >>> >>> There isn't a good way to do that using NSPopUpButton, or menus in general, >>> because a submenu is never laid over the actual clicked button. Items in the >>> parent menu do, but never submenus, so there isn't a situation that the user >>> can navigate to that can be represented by that first mouse click. Moving >>> the >>> mouse is possible but a pretty nasty 'solution'. >>> >>> If there isn't a more appropriate UI here, you could do what I've done faced >>> with the same problem, and that is to use bold and/or underlined text for >>> items leading to the selected item, and preselect the first parent item in >>> that 'path'. The user can then follow the trail of bold items to see what >>> the >>> control's current selected item is. It isn't ideal, but about the best I >>> could >>> come up with when a hierarchical menu was unavoidable. >>> >>> --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
ARC and autorelease pools
I've realized that my understanding of ARC is not as good as I thought it was. So I'll be asking couple of questions. With ARC I don't understand why autorelease pools are needed anymore except for with objects passed by reference. What I mean by that is that class methods like: NSString *myString = [NSString stringWithFormat:@"%@", @"my string"]; Why do these methods need to return an autoreleased object, why can't they behave the same as: NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String]; Is the only reason for interoperability with manual retain-release code? It seems that it creates an unnecessary complication when thinking about memory management. Now I'm assuming that any method like: NSString *expandedPath = [myPath stringByExpandingTildeInPath]; returns an autoreleased string so I need to know this if I'm doing this with lots of strings and that I need to put my own autorelease pool in place, something I wouldn't have to think about if it wasn't an autoreleased object. Documentation doesn't provide any information as to which methods return an autoreleased object or not. But since I can't call autorelease myself in ARC code if I have a method like. KMImage *bigImage = [image kmImageByDoublingSize]; I'm not returning an autoreleased object so there is a difference in behaviour between the behaviour of methods in apple frameworks and the ones outside of those frameworks. I've read a couple of posts on stackoverflow in relation to ARC and autorelease, but the justification given in the answers as to why autorelease is needed is because there are methods that return autoreleased objects so we need to have a mechanism to put auto release pools in place, which I feel is a little circular. Is there something more fundamental that I'm missing beyond interoperability that means we still need autorelease pools or is it just that? 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: ARC and autorelease pools
On 16 Feb, 2014, at 9:27 pm, Kevin Meaney wrote: > I've realized that my understanding of ARC is not as good as I thought it > was. So I'll be asking couple of questions. > > With ARC I don't understand why autorelease pools are needed anymore except > for with objects passed by reference. What I mean by that is that class > methods like: > > NSString *myString = [NSString stringWithFormat:@"%@", @"my string"]; > > Why do these methods need to return an autoreleased object, why can't they > behave the same as: > > NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String]; Where did you determine that the first of those returns an autoreleased object and does not, in fact, behave as the second? Where is it documented that [ NSString stringWithFormat:.. ] under ARC returns an autoreleased object? > > Is the only reason for interoperability with manual retain-release code? perhaps - the whole document about ARC is here http://clang.llvm.org/docs/AutomaticReferenceCounting.html, it only says that autorelease pools can exist and that the syntax for them has been tightened up into a real scope. It mentioned a couple of conditions in which it may use them and introduces some qualifiers which force objects into them but nowhere do I see anything which says they are definitely used in any given situation. There are several places it says you may not assume that an object is in an autorelease pool. > > It seems that it creates an unnecessary complication when thinking about > memory management. Now I'm assuming that any method like: > > NSString *expandedPath = [myPath stringByExpandingTildeInPath]; > > returns an autoreleased string so I need to know this if I'm doing this with > lots of strings and that I need to put my own autorelease pool in place, > something I wouldn't have to think about if it wasn't an autoreleased object. > Documentation doesn't provide any information as to which methods return an > autoreleased object or not. before ARC it was pretty much a given a method like that returned an autoreleased object, now it may or may not return one, so you're no worse off than you were before and are possibly better off. The usual advice is to do the simplest thing and if you have memory issues, go hunt them down with Instruments. And also assume that Debug and Release will do entirely different things. > > But since I can't call autorelease myself in ARC code if I have a method > like. > > KMImage *bigImage = [image kmImageByDoublingSize]; > > I'm not returning an autoreleased object so there is a difference in > behaviour between the behaviour of methods in apple frameworks and the ones > outside of those frameworks. I don't think you can know whether or not you are returning an autoreleased object in that case. I'm assuming that method does the obvious thing from the name, creates a double-sized image and returns it. Whether ARC retains it across the return for you or puts it on an autorelease pool, you don't know, how ARC chooses to keep the object valid across the return boundary is not defined by the ARC spec. It might be either but you shouldn't have to care. > > I've read a couple of posts on stackoverflow StackOverflow has a reasonably high noise to signal ratio. I'm pleased you posted here because Greg Parker is going to correct everything I wrote and explain it properly. The usual advice I think still stands. If you create lots of temporary objects in a loop, check for memory issues and put an autorelease pool in there if you have issues. If you don't have issues, let the compiler do the job for you. > > 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
Why is NSCollectionViews drawRect called first instead of subview (isOpaque:YES) bug?
Hey guys, I have a serious problem with the CollectionView and I don’t understand its behavior. My Project has a Splitview into 2 Views, one is a Scrollview with a CollectionView the one is a normal NSView with background image. The other one with the CollectionView has multiple items with own Views. The view of the item and the other „static“ NSView with background image have a subview of MeteringView of the MatrixMixerTest example project from Apple. This Metering View is showing Audio levels passed through it in a Meter. The View has isOpaque:Yes. The problem now is, those Meteringviews get redrawn with a timer to represent the Audio Levels but MeteringView is quite efficient to just draw the difference area what changed. In the „static“ NSView with background this works fine because isOpaque of MeteringView is preventing drawRect of the static View to draw again its background image to draw again, because if it does the meter is gone and just the currently changing parts are getting drawn. The CollectionView works differently, there the drawRect of the Item gets somehow called first causes its background color to redraw hiding my meter. But why does it? MeteringView is added in the same way as a subview and setNeedsDisplay is called in MeteringView to redraw metering view and isOpaque to prevent the „parent“ Views to redraw. I don’t know how to solve this, any ideas? I don’t think this is a bug but I don’t know why drawRect of the CollectionView Item is called in the first place. Thanks - Benjamin ___ 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 and autorelease pools
On Feb 16, 2014, at 7:27 AM, Kevin Meaney wrote: > Why do these methods need to return an autoreleased object, why can't they > behave the same as: > > NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String]; > > Is the only reason for interoperability with manual retain-release code? Foundation, along with the other system frameworks, is not written in ARC. It's written in manual retain-release. If/when Apple eventually converts the frameworks to ARC, they will have to remove the 32-bit versions of the binaries, since ARC is only compatible with the 64-bit runtime. This will break backward compatibility with all 32-bit apps, including all Carbon apps. I don't know about you, but I'm perfectly happy if Apple decides to take their time getting around to that. 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
NSUndoManager, NSTableView with bindings
I have an NSTableView with several columns bound to an NSArrayController which manages the array of my custom objects. Undo of course works while editing a cell in the NSTableView, but once the edit is complete, I need to manage it myself. How is the best way to do this? I need to know the original contents of the cell (property in my object) so do I need to use controlTextDidBeginEditing, save the value somewhere, then in controlTextDidEndEditing, if they are different, push the change onto the undo stack? Since the table uses bindings, the setting of the property is handed by the binding system. 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: ARC and autorelease pools
On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote: > Is the only reason for interoperability with manual retain-release code? For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. > It seems that it creates an unnecessary complication when thinking about > memory management. Now I'm assuming that any method like: > NSString *expandedPath = [myPath stringByExpandingTildeInPath]; > returns an autoreleased string so I need to know this if I'm doing this with > lots of strings and that I need to put my own autorelease pool in place, > something I wouldn't have to think about if it wasn't an autoreleased object. You don't just need to consider whether methods you call return autoreleased objects (and as Roland pointed out, it's not always clear whether a returned object really has been autoreleased or not.) You also need to consider whether the method you called caused objects to be autoreleased as part of the work it did. That is, you might call "[[FooController alloc] init]", which doesn't return an autoreleased object, but perhaps the -init method did a bunch of work that involved autoreleasing objects. In that case your call to that method would still add a bunch of objects to the autorelease pool. You can't tell by looking at the declaration. In practice, I add @autoreleasepool blocks by considering whether I'm writing a loop that will have a lot of iterations and whose body involves method calls that are likely to allocate memory. Then I also look at memory usage over time in the Instruments app and watch for spikes, and look for issues (on iOS) where the app triggers a low-memory notification during some activity. "Likely to allocate memory" is weaselly, I know. It's an educated guess. But you don't have to guess perfectly. An unnecessary @autoreleasepool is unlikely to add noticeable (unless you go overboard with them), and if you leave one out where you need one, you'll probably notice during testing. It's part of the kind of memory/performance tuning you'll be doing anyway later in development. —Jens ___ 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 and autorelease pools
On 16 Feb 2014, at 17:06, Jens Alfke wrote: > On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote: > >> Is the only reason for interoperability with manual retain-release code? > > For backward compatibility. Nearly every piece of existing Cocoa code uses > these methods, so there's no way they could take them out. I didn't say take them out. I said why do they need to return an autoreleased object. Why can't they just return an object like alloc init... does. I think Roland's main point is to ask do they return an autoreleased object. I foolishly assumed they did because a modified version of autorelease was kept with the transition to ARC and my most common experience of dealing with autoreleased objects was via the behaviour of the class methods that create objects. So yes a foolish assumption on my behalf. >> It seems that it creates an unnecessary complication when thinking about >> memory management. Now I'm assuming that any method like: >> NSString *expandedPath = [myPath stringByExpandingTildeInPath]; >> returns an autoreleased string so I need to know this if I'm doing this with >> lots of strings and that I need to put my own autorelease pool in place, >> something I wouldn't have to think about if it wasn't an autoreleased object. > > You don't just need to consider whether methods you call return autoreleased > objects (and as Roland pointed out, it's not always clear whether a returned > object really has been autoreleased or not.) You also need to consider > whether the method you called caused objects to be autoreleased as part of > the work it did. You're missing the question I was trying to ask. Why is autorelease needed at all? If we don't have autorelease then it is precisely clear whether a returned object is autoreleased or not. Something we don't even have to consider. We don't have to worry about whether further down the stack autoreleased objects have been created or not and that in certain situations up the stack we need to add in a autorelease pool. I've read through some of the clang documentation Roland referred to, much of it over my head. I did note that there was some discussion over making sure that objects remain alive over the return boundary and in some cases autorelease was used for this purpose. But I'm still failing to grasp why, if autorelease is being used in some cases for making sure an object remains alive over a return boundary that means there are other ways of dealing with making sure an object remains alive over the return boundary, do we need autorelease? I just feel like I'm missing something. The people at Apple or Clang have decided that keeping autorelease is necessary and I'm struggling to understand why when it seems to me it adds unnecessary complexity. Not major but just another thing that can go wrong if you dont think about it, and so you have to think about it and that takes mental resources away from the job at hand. 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: ARC and autorelease pools
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > I didn't say take them out. I said why do they need to return an autoreleased > object. Why can't they just return an object like alloc init... does. Because if they returned an object that wasn't autoreleased (i.e. that the caller needs to release), non-ARC code that called the method would leak the returned object. These methods have been around for a long time and their semantics can't be changed just because ARC now exists, at least not until some hypothetical future OS release where ARC becomes mandatory. —Jens ___ 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 and autorelease pools
On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > You're missing the question I was trying to ask. Why is autorelease needed at > all? It's needed when a method creates an object [or otherwise gets an object with a reference that needs to be released] and has to return that object, but the caller isn't aware that the reference needs to be released. The method can call -autorelease on that object, which schedules a pending release in the future, balancing the ref-counting. You could argue that if ARC were mandatory [which it isn't, remember] autorelease wouldn't be necessary because the method above can be declared as returning a strong reference, so the caller will know to release it. Unfortunately it isn't that simple, because there can be multiple implementations of a method. For example, a class might implement a -bgColor method that returns an NSColor stored in an instance variable; so the return value doesn't need to be released. But a subclass might override -bgColor to allocate and return a new NSColor instance. Now the caller _does_ need to release it, but the caller doesn't know that because it has no idea which implementation of -bgColor actually got called. The only way to resolve this without autorelease would be to enforce that _all_ methods that return objects have to return a retained reference for the caller to release. This would end up adding a huge number of retain/release calls, which I'm pretty sure would affect performance. —Jens ___ 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 and autorelease pools
And would be just like every other manual reference-counting scheme, with all of the additional code they entail, and the higher liklihood of bugs, and so on... On Feb 16, 2014, at 2:13 PM, Jens Alfke wrote: > The only way to resolve this without autorelease would be to enforce that > _all_ methods that return objects have to return a retained reference for > the caller to release. This would end up adding a huge number of > retain/release calls, which I'm pretty sure would affect performance. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 1:03 PM, Jens Alfke wrote: > On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > >> I didn't say take them out. I said why do they need to return an >> autoreleased object. Why can't they just return an object like alloc init... >> does. > > Because if they returned an object that wasn't autoreleased (i.e. that the > caller needs to release), non-ARC code that called the method would leak the > returned object. > > These methods have been around for a long time and their semantics can't be > changed just because ARC now exists, at least not until some hypothetical > future OS release where ARC becomes mandatory. Also, the ARC model doesn’t support a mandatory cut-over like that. Returning +0 is essentially part of the calling convention: if you know exactly what you’re calling, and you know exactly what’s calling it, maybe then you could automatically change it. In Objective-C both of those conditions are impossible. 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: NSUndoManager, NSTableView with bindings
On Feb 16, 2014, at 9:34 AM, Trygve Inda wrote: > I have an NSTableView with several columns bound to an NSArrayController > which manages the array of my custom objects. > > Undo of course works while editing a cell in the NSTableView, but once the > edit is complete, I need to manage it myself. > > How is the best way to do this? > > I need to know the original contents of the cell (property in my object) so > do I need to use controlTextDidBeginEditing, save the value somewhere, then > in controlTextDidEndEditing, if they are different, push the change onto the > undo stack? > > Since the table uses bindings, the setting of the property is handed by the > binding system. With bindings, the best choice, IMHO, is to handle undo in custom setters. You will get easy redo support this way, as well. Depending on when you would make something un-undoable would determine who will maintain the NSUndoManager instance. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and autorelease pools
On Feb 16, 2014, at 10:22, Kevin Meaney wrote: > > On 16 Feb 2014, at 17:06, Jens Alfke wrote: > >> On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote: >> >>> Is the only reason for interoperability with manual retain-release code? >> >> For backward compatibility. Nearly every piece of existing Cocoa code uses >> these methods, so there's no way they could take them out. > > I didn't say take them out. I said why do they need to return an autoreleased > object. Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code. > Why can't they just return an object like alloc init... does. It can, if both the implementation and the caller are ARC > I think Roland's main point is to ask do they return an autoreleased object. > I foolishly assumed they did because a modified version of autorelease was > kept with the transition to ARC and my most common experience of dealing with > autoreleased objects was via the behaviour of the class methods that create > objects. So yes a foolish assumption on my behalf. > >>> It seems that it creates an unnecessary complication when thinking about >>> memory management. Now I'm assuming that any method like: >>> NSString *expandedPath = [myPath stringByExpandingTildeInPath]; >>> returns an autoreleased string so I need to know this if I'm doing this >>> with lots of strings and that I need to put my own autorelease pool in >>> place, something I wouldn't have to think about if it wasn't an >>> autoreleased object. >> >> You don't just need to consider whether methods you call return autoreleased >> objects (and as Roland pointed out, it's not always clear whether a returned >> object really has been autoreleased or not.) You also need to consider >> whether the method you called caused objects to be autoreleased as part of >> the work it did. > > You're missing the question I was trying to ask. Why is autorelease needed at > all? If we don't have autorelease then it is precisely clear whether a > returned object is autoreleased or not. Something we don't even have to > consider. We don't have to worry about whether further down the stack > autoreleased objects have been created or not and that in certain situations > up the stack we need to add in a autorelease pool. > > I've read through some of the clang documentation Roland referred to, much of > it over my head. I did note that there was some discussion over making sure > that objects remain alive over the return boundary and in some cases > autorelease was used for this purpose. But I'm still failing to grasp why, if > autorelease is being used in some cases for making sure an object remains > alive over a return boundary that means there are other ways of dealing with > making sure an object remains alive over the return boundary, do we need > autorelease? If both sides of the boundary are ARC, and the calling code immediately retains the returned value (as is usually the case), then the autorelease can be skipped (and actually is at runtime; the runtime is smart enough to actually inspect the stack to see whether or not the autorelease is necessary, and if it isnt, it actually skips the autorelease and the following retain). > I just feel like I'm missing something. The people at Apple or Clang have > decided that keeping autorelease is necessary and I'm struggling to > understand why when it seems to me it adds unnecessary complexity. Not major > but just another thing that can go wrong if you dont think about it, and so > you have to think about it and that takes mental resources away from the job > at hand. Keeping autorelease is necessary because without it, there would be no way of maintaining the memory management contract across both ARC and non-ARC 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSUndoManager, NSTableView with bindings
On 17 Feb 2014, at 3:34 am, Trygve Inda wrote: > How is the best way to do this? > > Since the table uses bindings, the setting of the property is handed by the > binding system. One way to handle this is illustrated in Hillegasse's classic book on Cocoa. I'm looking at the 2nd edition, not sure if the 3rd has the same scheme. If your undoable properties are all properties, i.e. they have a getter and a setter, you can use KVO to observe the undoable properties in a handler object that acts solely as a go-between between NSUndoManager and the model class. It observes property changes using KVO and uses the 'will change' info to set up Undo. The target is the handler object and every undo gets the same method. The parameter to the method is the KVO change dictionary. When NSUndoManager undoes, it calls this method on the handler with all of the original observed KVO info. This allows the handler object to simply call the relevant property setter with the original value. The advantage of this approach is that a) no custom getters/setters are needed, it just uses KVO. b) you can set up observation only only those properties that you want to be undoable, others can be ignored if you want. c) Undo automatically updates, through bindings, any UI related to the undone property, d) the data model itself doesn't need to know anything about the undo manager. The only real drawback of this approach is that because Undo in this case is sort of "hanging off the side" of your data model, it doesn't get a simple UI-related string that it can use to label each Undo action. That's a fairly minor problem though, easily solved with some additional work to map property names to a user-readable and localisable string. --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: NSUndoManager, NSTableView with bindings
On 2014 Feb 16, at 08:34, Trygve Inda wrote: > I have an NSTableView with several columns bound to an NSArrayController > which manages the array of my custom objects. > > How is the best way to do this? Don’t. Use Core Data. Core Data will do it. ___ 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: NSUndoManager, NSTableView with bindings
On Sun, Feb 16, 2014, at 05:17 PM, Jerry Krinock wrote: > Don’t. Use Core Data. Remove the period between "Don't" and "Use", and your sentence is correct. Core Data isn't a solution. Removing bindings is the solution. --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
