Re: How to draw a NSView on top of a WebView and don't get overriden trying
This worked just great! On Sat, May 16, 2015 at 12:59 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Create a borderless window with your message in it, place it above your web view. Since a screen saver doesn’t move, you could probably leave it at that and not even use a child window? On 16 May 2015, at 17:42, Juanjo Conti jjco...@carouselapps.com wrote: I didnt actually. How can I use the window method for my goal? On Sat, May 16, 2015 at 12:38 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Have you tried it? I haven’t, but NSScreenSaverView inherits a -window method, which probably refers to whatever window the OS uses to cover the desktop and draws the screen saver in. On 16 May 2015, at 16:20, Juanjo Conti jjco...@carouselapps.com wrote: As I'm writing a screen saver, I can't use another window. On Sat, May 16, 2015 at 7:09 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Popovers are popovers. You can’t really configure their appearance enough (using public API) that they would be suitable for this use. However, popovers are separate windows, and likely implemented using child windows under the hood, so you could probably try adding your window as a child window to your view’s parent window. On 12 May 2015, at 23:00, Mike Abdullah mabdul...@karelia.com wrote: The failsafe way is to place a child window over the WebView. I’m not 100% sure but I think popovers work that way behind the scenes, so maybe one of them would be usable for this. On 12 May 2015, at 22:44, Juanjo Conti jjco...@carouselapps.com wrote: I have a WebView and I want to show some messages over it. For this I'm using a NSView. If I add it as a subView of WebView or if I add it as a subView of the WebView's superView, it's shown for a while but if the WebView gets scrolled or if I load sites gmail.com or twitter (without logging in), the website hides my NSView. Is this a known problem? is there any solution? Thanks in advance, -- Juanjo Conti jjconti http://goog_2023646312@carouselapps.com jjco...@carouselapps.com Software Engineer - Carousel Apps https://carouselapps.com -- Carousel Apps Limited, registered in England Wales with registered number 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket Street, London SE1 3HN. Any communication sent by or on behalf of Carousel App Ltd or any of its subsidiary, holding or affiliated companies or entities (together Watu) is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Watu may be monitored to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks. ___ 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/mabdullah%40karelia.com This email sent to mabdul...@karelia.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net This email sent to witness.of.teacht...@gmx.net Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de -- Juanjo Conti jjco...@carouselapps.com Software Engineer - Carousel Apps Carousel Apps Limited, registered in England Wales with registered number 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket Street, London SE1 3HN. Any communication sent by or on behalf of Carousel App Ltd or any of its subsidiary, holding or affiliated companies or entities (together Watu) is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Watu may be monitored to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks. Cheers, -- Uli
Re: Tracking the retain count
On May 17, 2015, at 23:59 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. You’re right to be cautious, but you’ve come to the wrong conclusion. From OS X 10.0 to 10.5 (and beyond for numerous apps), memory was managed manually with ‘retain’ and ‘release’, and that certainly is “using” the retain count. What was frowned upon was reckless *reasoning* about retain counts: “If the retain count is such and such, and I do so and so, then XYZ will happen”. Those sorts of arguments tended to blow up in peoples’ faces**. It is, however, valid to increment the retain count of a valid (that is, live) object, and to reason that the object will stay alive at least until you decrement the retain count. This is sufficient for your scenario. ** For example: If the retain count is 1, and I decrement it, the object will be deallocated.” This is incorrect reasoning, because any code that checks and decrements the retain count is subject to side effects that affect the outcome. ___ 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: Tracking the retain count
On May 18, 2015, at 1:11 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On May 17, 2015, at 23:59 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. You’re right to be cautious, but you’ve come to the wrong conclusion. From OS X 10.0 to 10.5 (and beyond for numerous apps), memory was managed manually with ‘retain’ and ‘release’, and that certainly is “using” the retain count. Yup. I started this whole cocoa-flavored adventure with the Currency Converter tutorial way back on 10.0 running on a G4 with the rounded plastic case. I’ve done it the manual way, taken out the trash (er, run under Garbage Collection), and transitioned my codebase to ARC too… :-) What was frowned upon was reckless *reasoning* about retain counts: “If the retain count is such and such, and I do so and so, then XYZ will happen”. Those sorts of arguments tended to blow up in peoples’ faces**. It is, however, valid to increment the retain count of a valid (that is, live) object, and to reason that the object will stay alive at least until you decrement the retain count. This is sufficient for your scenario. ** For example: If the retain count is 1, and I decrement it, the object will be deallocated.” This is incorrect reasoning, because any code that checks and decrements the retain count is subject to side effects that affect the outcome. In order to maintain graph coherency the object pool controller must ensure that there is only ever one object in memory with a particular UUID. Consequently, I can’t just have the object pool controller release the objects without assurance that nothing else is going to keep it around (and potentially use it after the object pool controller has replaced it with another object with the same UUID, reloaded from disk). Holding a weak link to the objects as well as a strong link does satisfy that constraint… but it’s a definite code smell” (somewhat related to “don’t repeat yourself”) and it eats more memory, etc. I’ll do it if I have to, but… Is the reasoning that: 1: Not under ARC; 2: There is one known strong link to an object; 3: retainCount returned 1 Therefore, the only strong link to the object is the known strong link specified in item 2. … is that not valid? If not, why not? Note that I am *not* asserting that it will be deallocated, just that nothing else has a strong link to it that could use it in a detrimental way (most importantly, mutate 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: Tracking the retain count
On May 18, 2015, at 10:52 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Is the reasoning that: 1: Not under ARC; 2: There is one known strong link to an object; 3: retainCount returned 1 Therefore, the only strong link to the object is the known strong link specified in item 2. … is that not valid? If not, why not? No, I think not. There are at least 2 dimensions of variability that can break this reasoning: time and threads. Furthermore, the assumption that your peek at the object state will reliably (or ever) return a retain count of 1 as opposed to (say) 2 is flawed. For example, if the object is in the autorelease pool, you’ll see a count of at least 2, but you won’t be able to deduce why. Note that I am *not* asserting that it will be deallocated, just that nothing else has a strong link to it that could use it in a detrimental way (most importantly, mutate it). Just so, so I think you need to disentangle the following things: 1. Whether an object is in your data model’s object graph. Note that there is an implicit extended object graph beyond the references between the objects themselves. For example, if an object is (say) set as the delegate of some service, but is no longer in your actual object graph, it may get a delegate message that causes it to intrude unexpectedly. In that case, it’s effectively still in your object graph. 2. Whether an object is alive (has or has not reached dealloc). You actually don’t care about this, though we haven’t convinced you of that yet. ;) 3. Whether an object is discardable from memory in case of (for example) memory pressure. Currently, you’re trying to achieve #1 and #3 by thinking in terms of #2. However, #2 is the one thing you can’t actually control — in any very direct and deterministic way. You currently have an app that controls #1 directly. You’ve also been offered several ways of controlling #3 directly, one of which is to forcibly increment or decrement the retain count in deterministic ways. Your unease is making you think of this as an attempt at #2, but it’s not. It’s really #3. ___ 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
Date Picker
Is there really no way to display a date picker in a pop over view like a keyboard? ___ 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: Tracking the retain count
On May 18, 2015, at 12:52 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: In order to maintain graph coherency the object pool controller must ensure that there is only ever one object in memory with a particular UUID. Consequently, I can’t just have the object pool controller release the objects without assurance that nothing else is going to keep it around (and potentially use it after the object pool controller has replaced it with another object with the same UUID, reloaded from disk). Can you have some sort of -invalidate method on the objects that puts them into a state where they can't be used or confused with a subsequently-loaded object? If necessary, it could clear the UUID or whatever. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Date Picker
David, I’m sorry, but I really don’t understand your question. I’ve been putting date pickers into popovers on iPad since iOS 5. Haven’t looked lately; has something changed? Could you provide more information? Like, what are you trying to do? Why don’t you think a data picker can go into a popover? What did you try that didn’t work? That sort of thing would be greatly helpful in addressing your question in a meaningful way. Cheers, Rick Aurbach On May 18, 2015, at 2:00 PM, cocoa-dev-requ...@lists.apple.commailto:cocoa-dev-requ...@lists.apple.com wrote: Message: 2 Date: Mon, 18 May 2015 11:11:54 -0700 From: David Grant dmgr...@infinitydigital.commailto:dmgr...@infinitydigital.com To: cocoa-dev@lists.apple.commailto:cocoa-dev@lists.apple.com Subject: Date Picker Message-ID: 314cfb5d-41dd-493b-8c1b-d5e6d99cc...@infinitydigital.commailto:314cfb5d-41dd-493b-8c1b-d5e6d99cc...@infinitydigital.com Content-Type: text/plain; charset=us-ascii Is there really no way to display a date picker in a pop over view like a keyboard? ___ 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: Date Picker
Take a look at this: https://github.com/skywinder/ActionSheetPicker-3.0 Sent from my iPhone On May 18, 2015, at 1:11 PM, David Grant dmgr...@infinitydigital.com wrote: Is there really no way to display a date picker in a pop over view like a keyboard? ___ 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/nebiros%40gmail.com This email sent to nebi...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Tracking the retain count
I'm going to butt in here and say that if you've got so many objects that it is causing memory pressure, you really just need to reevaluate and blow up your model. Consider using a database or Core Data. Tracking and storing large relational sets of data is exactly what those things do well. That might just reduce the effort and fragility and complexity tremendously. And it will let you use tried and tested code and focus instead on a schema. Sent from my iPhone On 2015/05/19, at 9:48, Roland King r...@rols.org wrote: On 18 May 2015, at 14:59, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Unfortunately I don’t think NSCache will work for me in this situation. The objects in the pool have a UUID that is used to maintain the graph structure’s coherency when it’s partially or entirely on disk. In RAM, there can be only one object per UUID; but if something points to an object that the cache is trying to evict, that object won’t get deallocated from RAM (because it’s retain count isn’t zero post eviction) but the object pool controller won’t know about it still being in RAM (as it’s no longer in the cache), and when the controller attempts to reload it from disk; there would be multiple in-memory objects purporting to have the same UUID. As is oft claimed about these sorts of situations, hilarity would ensue… Keeping multiple pointers to the same object strikes be as ugly also… perhaps more ugly than just looking at retainCount: it does more or less the same thing, but with a greater footprint (memory, CPU, and battery). My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. However, it’s not actually something that’s likely to get deprecated; and by paying very careful attention to the rules, it should be OK to use in this very narrow circumstance? If this is wrong - please (hopefully someone from Apple) correct me! :-) If I was doing this I’d have an NSMapTable with strong keys (UUID) to weak objects (the objects). Put new objects in the table against their UUIDs, when nothing else references them they get destroyed automagically, When you need an object, look it up by UUID, if it’s there it’s there else create it. If it’s also desirable to have objects stay cached until such time as there’s memory pressure and then release them, I would also then put each created object in a set/array/whatever called TempCache which gives it another strong reference. When the OS rings the doorbell and complains about memory, I throw the cache set away, let the map table destroy stuff now not-referenced, and then put all the remaining objects in the map table back in a new set/array/whatever to start caching again. That requires very little coding, works under ARC and gives me the choice of making the cache smarter without too much effort, ie I could make it an LRU cache referencing the last 1000 objects used, or a full LRU cache where, when I get a memory warning I throw away 100 objects from the end until memory usage has reached a ‘reasonable’ state. Perhaps I missed something germane in the discussion about why a simple scheme like that doesn’t fulfil all requirements. ___ 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/dangerwillrobinsondanger%40gmail.com This email sent to dangerwillrobinsondan...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Tracking the retain count
Let me try and summarize where we are, in response to the several recent suggestions: Britt has an app with an existing, fully functional custom cache of objects that have a UUID property, with the restriction that UUIDs are unique amongst objects in the cache. Objects may be created in various incarnations over time under the same UUID, but only one incarnation can be in the cache using the UUID at any moment. In addition, because of the overhead of managing the uniqueness of the UUIDs, it’s too expensive to create new objects regularly on demand. The purpose of the cache is to extend the lifetime of otherwise unreferenced objects so that they can be reused rather than reincarnated. It does this by taking ownership of (retaining, keeping a strong reference to, however you want to think of it) every object in the cache. This means that objects can exist in memory in one of these states: — “Referenced. That is, there is a strong reference to the object somewhere else in the app’s object graph, beyond the cache’s owning reference. — “Unreferenced. There is no strong reference to the object elsewhere in the app’s object graph. The only “known-for-sure” strong reference is the cache’s owning reference. Britt originally wanted to believe that this meant that the cache contained the only strong reference, period, but I called this out as invalid reasoning about retain counts, because there’s actually a 3rd case … — “Inaccessible. There is a reference to the object somewhere else for some other housekeeping reason. The prime such housekeeping reason is being in the autorelease pool pending draining, but in theory objects may perhaps temporarily be referenced somewhere in the bowels of the frameworks. (This has to be temporary, otherwise these objects would be leaked, but the point of deallocation is theoretically unknown.) I don’t have any other plausible housekeeping reasons, but I do know that “No one else should be using this object right now” is a common prelude to a self-inflicted injury. Now, Britt wants to modify the cache so that is capable of discarding all unreferenced objects. Discarding the sole owning reference would have this effect, but it would also destroy the cache itself, so that’s not feasible. The easiest solution to conceptualize is to give the cache both a strong (owning) and a weak reference to each object. Then, to purge the cache of unreferenced objects, all that’s necessary is to nil the strong references. Thereafter the unreferenced objects will, we hope, become deallocated, though some may remain merely inaccessible. In particular, any objects referred to by an autorelease pool won’t get deallocated until the pool is drained. Once that’s done, as far as the app’s concerned there should be no more inaccessible objects, but in reality we don’t know this for sure — vid. housekeeping reasons — and we have no valid way of *reasoning* them out of existence. Still, armed with a belief that most if not all are deallocated, it’s now possible to re-establish the strong references in the cache, and things go along as before until the next time the cache needs to be purged. All of this is non-controversial. The problem is solved. Except that Britt isn’t happy with the duplication of resources involved in that solution. So, I’ve been trying to sell the idea that you only need one pointer — the weak one — and that the full effect of the strong pointer can be obtained by merely incrementing the retain count (once) when an object enters the cache. To purge the cache, decrement all the retain counts, drain the autorelease pools, then increment them again. There are a couple of ways of doing this in an ARC environment, but I (in a similar situation) use CFRetain (or perhaps CFBridgingRetain, can’t remember) because I’ve found it most readable. Britt’s hesitant about this solution, too, because it apparently reasons about retain counts, which we’re told not to do, and I seem to have just finished saying so too. I claim that there’s no contradiction. It’s valid in this situation, because the only reasoning we’re doing is about *our* ownership reference, not about any others that we don’t control. Indeed, we’re not so much reasoning, as relying on the definition of ownership. On May 18, 2015, at 17:27 , Graham Cox graham@bigpond.com wrote: just pointing you at NSDiscardableContent for a second, that has a “pseudo-retain count” type of mechanism I believe this is functionally identical to incrementing the actual retain counts, so it’d be a matter of personal preference which to use. On May 18, 2015, at 17:48 , Roland King r...@rols.org wrote: Perhaps I missed something germane in the discussion about why a simple scheme like that doesn’t fulfil all requirements. Just that Britt wanted to avoid having two sets of pointers. On May 18, 2015, at 19:46 , dangerwillrobinsondan...@gmail.com wrote: if you've got so many objects
Re: Tracking the retain count
On May 18, 2015, at 16:25 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: If some objects are in autorelease pools, that means that there is a strong link to them out there somewhere (presumably on the stack or in a register where it’s going to go away once the stack frames get popped) and the object pool controller shouldn’t let go of the object yet. Hopefully there will be enough else that can be released that the memory pressure gets satisfied. Also, I can set a flag to cause the object pool controller to re-scan the pool for objects to release after the main autorelease pool is drained in the main event loop. But here we go, reasoning about retain counts — incorrectly. (Your first sentence is just false, BTW, not incorrectly reasoned. An object can be in an autorelease pool with no other strong link anywhere.) And you’ve got me doing it too. What I said previously about retain counts of objects in autorelease pools was just wrong. why I can’t have the object pool controller just drop an object unless the pool controller is the only one with a strong link to the object. Because what you really want is “unless the pool controller is the only one with an accessible link to the object”. You’re trying hard to force “strong link” to do the duty of “accessible link”, and I’m trying hard to tell you that it can’t. Also, I’m not trying to steer you towards the double pointer approach. Paradoxical as it may seem, I’m suggesting you can avoid that by merely incrementing the retain count of objects you *know* to be accessible, and to decrement it when you *know* they become inaccessible. You can reason about *that* retain count (“it keeps objects alive when present”). You just can’t validly reason about anyone else’s retain counts. :) ___ 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: Tracking the retain count
On 18 May 2015, at 14:59, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Unfortunately I don’t think NSCache will work for me in this situation. The objects in the pool have a UUID that is used to maintain the graph structure’s coherency when it’s partially or entirely on disk. In RAM, there can be only one object per UUID; but if something points to an object that the cache is trying to evict, that object won’t get deallocated from RAM (because it’s retain count isn’t zero post eviction) but the object pool controller won’t know about it still being in RAM (as it’s no longer in the cache), and when the controller attempts to reload it from disk; there would be multiple in-memory objects purporting to have the same UUID. As is oft claimed about these sorts of situations, hilarity would ensue… Keeping multiple pointers to the same object strikes be as ugly also… perhaps more ugly than just looking at retainCount: it does more or less the same thing, but with a greater footprint (memory, CPU, and battery). My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. However, it’s not actually something that’s likely to get deprecated; and by paying very careful attention to the rules, it should be OK to use in this very narrow circumstance? If this is wrong - please (hopefully someone from Apple) correct me! :-) If I was doing this I’d have an NSMapTable with strong keys (UUID) to weak objects (the objects). Put new objects in the table against their UUIDs, when nothing else references them they get destroyed automagically, When you need an object, look it up by UUID, if it’s there it’s there else create it. If it’s also desirable to have objects stay cached until such time as there’s memory pressure and then release them, I would also then put each created object in a set/array/whatever called TempCache which gives it another strong reference. When the OS rings the doorbell and complains about memory, I throw the cache set away, let the map table destroy stuff now not-referenced, and then put all the remaining objects in the map table back in a new set/array/whatever to start caching again. That requires very little coding, works under ARC and gives me the choice of making the cache smarter without too much effort, ie I could make it an LRU cache referencing the last 1000 objects used, or a full LRU cache where, when I get a memory warning I throw away 100 objects from the end until memory usage has reached a ‘reasonable’ state. Perhaps I missed something germane in the discussion about why a simple scheme like that doesn’t fulfil all requirements. ___ 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: Tracking the retain count
On May 18, 2015, at 11:38 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On May 18, 2015, at 10:52 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Is the reasoning that: 1: Not under ARC; 2: There is one known strong link to an object; 3: retainCount returned 1 Therefore, the only strong link to the object is the known strong link specified in item 2. … is that not valid? If not, why not? No, I think not. There are at least 2 dimensions of variability that can break this reasoning: time and threads. Furthermore, the assumption that your peek at the object state will reliably (or ever) return a retain count of 1 as opposed to (say) 2 is flawed. For example, if the object is in the autorelease pool, you’ll see a count of at least 2, but you won’t be able to deduce why. The object graph is not thread-safe; so I don’t think that applies? If some objects are in autorelease pools, that means that there is a strong link to them out there somewhere (presumably on the stack or in a register where it’s going to go away once the stack frames get popped) and the object pool controller shouldn’t let go of the object yet. Hopefully there will be enough else that can be released that the memory pressure gets satisfied. Also, I can set a flag to cause the object pool controller to re-scan the pool for objects to release after the main autorelease pool is drained in the main event loop. Note that I am *not* asserting that it will be deallocated, just that nothing else has a strong link to it that could use it in a detrimental way (most importantly, mutate it). Just so, so I think you need to disentangle the following things: 1. Whether an object is in your data model’s object graph. Note that there is an implicit extended object graph beyond the references between the objects themselves. For example, if an object is (say) set as the delegate of some service, but is no longer in your actual object graph, it may get a delegate message that causes it to intrude unexpectedly. In that case, it’s effectively still in your object graph. Right, which is why I can’t have the object pool controller just drop an object unless the pool controller is the only one with a strong link to the object. 2. Whether an object is alive (has or has not reached dealloc). You actually don’t care about this, though we haven’t convinced you of that yet. ;) Actually what I care about is if anybody can access the object. I don’t care if it has reached dealloc yet or not. If the object is reachable, it has to keep it’s singular identity. 3. Whether an object is discardable from memory in case of (for example) memory pressure. Currently, you’re trying to achieve #1 and #3 by thinking in terms of #2. However, #2 is the one thing you can’t actually control — in any very direct and deterministic way. I don’t think I need to control it per se, just catch a very specific case: that nothing has a strong link besides the one held by the object pool controller. You currently have an app that controls #1 directly. You’ve also been offered several ways of controlling #3 directly, one of which is to forcibly increment or decrement the retain count in deterministic ways. Your unease is making you think of this as an attempt at #2, but it’s not. It’s really #3. I haven’t fully rejected the double pointer weak-link strategy… I’m just, as you said, uncomfortable with it, and don’t (as of yet) see it as *necessarily* less ugly than looking at retainCount in this very specific case... *** On May 18, 2015, at 11:25 AM, Ken Thomases k...@codeweavers.com wrote: On May 18, 2015, at 12:52 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: In order to maintain graph coherency the object pool controller must ensure that there is only ever one object in memory with a particular UUID. Consequently, I can’t just have the object pool controller release the objects without assurance that nothing else is going to keep it around (and potentially use it after the object pool controller has replaced it with another object with the same UUID, reloaded from disk). Can you have some sort of -invalidate method on the objects that puts them into a state where they can't be used or confused with a subsequently-loaded object? If necessary, it could clear the UUID or whatever. Regards, Ken There is a large body of pre-existing code that relies on this system; in order to do that I would have to retrofit checks for validity onto every point where the object graph is accessed. At the very least, that’s a *major* project, time-wise, and is also probably a good way to introduce lots of bugs into two other large projects… Also, just clearing the UUID doesn’t
Re: Tracking the retain count
I don’t wish to butt in, since you seem to be doing fine and I probably don’t have too much to contribute, but just pointing you at NSDiscardableContent for a second, that has a “pseudo-retain count” type of mechanism that is independent of the actual retain count. I wonder if that couldn’t help you here - leave the standard retain count to its own devices, and use the access count of NSDiscardableContent to manage your object in these higher-level terms. It requires a little bit of cooperation from all other code that will access your objects, but it makes it a lot saner than trying to reason about retain counts themselves (which I agree with is the path to madness). Since nothing else will be manipulating the access count other than code you write, you can reason about that all day long. —Graham On 19 May 2015, at 10:14 am, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On May 18, 2015, at 16:25 , Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: If some objects are in autorelease pools, that means that there is a strong link to them out there somewhere (presumably on the stack or in a register where it’s going to go away once the stack frames get popped) and the object pool controller shouldn’t let go of the object yet. Hopefully there will be enough else that can be released that the memory pressure gets satisfied. Also, I can set a flag to cause the object pool controller to re-scan the pool for objects to release after the main autorelease pool is drained in the main event loop. But here we go, reasoning about retain counts — incorrectly. (Your first sentence is just false, BTW, not incorrectly reasoned. An object can be in an autorelease pool with no other strong link anywhere.) And you’ve got me doing it too. What I said previously about retain counts of objects in autorelease pools was just wrong. why I can’t have the object pool controller just drop an object unless the pool controller is the only one with a strong link to the object. Because what you really want is “unless the pool controller is the only one with an accessible link to the object”. You’re trying hard to force “strong link” to do the duty of “accessible link”, and I’m trying hard to tell you that it can’t. Also, I’m not trying to steer you towards the double pointer approach. Paradoxical as it may seem, I’m suggesting you can avoid that by merely incrementing the retain count of objects you *know* to be accessible, and to decrement it when you *know* they become inaccessible. You can reason about *that* retain count (“it keeps objects alive when present”). You just can’t validly reason about anyone else’s retain counts. :) ___ 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: Tracking the retain count
Unfortunately I don’t think NSCache will work for me in this situation. The objects in the pool have a UUID that is used to maintain the graph structure’s coherency when it’s partially or entirely on disk. In RAM, there can be only one object per UUID; but if something points to an object that the cache is trying to evict, that object won’t get deallocated from RAM (because it’s retain count isn’t zero post eviction) but the object pool controller won’t know about it still being in RAM (as it’s no longer in the cache), and when the controller attempts to reload it from disk; there would be multiple in-memory objects purporting to have the same UUID. As is oft claimed about these sorts of situations, hilarity would ensue… Keeping multiple pointers to the same object strikes be as ugly also… perhaps more ugly than just looking at retainCount: it does more or less the same thing, but with a greater footprint (memory, CPU, and battery). My understanding of retainCount is that it’s basically considered “taboo” because trying to use it without knowing exactly what you are doing tends to lead to pitfalls, and most people looking at it tend to think it means something that it doesn't. However, it’s not actually something that’s likely to get deprecated; and by paying very careful attention to the rules, it should be OK to use in this very narrow circumstance? If this is wrong - please (hopefully someone from Apple) correct me! :-) ___ 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
