Re: Tracking the retain count
On May 18, 2015, at 8:59 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Let me try and summarize where we are, in response to the several recent suggestions: Close, but not quite: I have several apps which are built on an existing, fully functional data management layer that was originally built for a full desktop virtual-memory environment (FWIW, it pre-dates the existence of Core Data). I now need to move some of this to run under iOS. I also don’t want to make changes to this data management layer that would require widespread changes to my other apps that rely on it. The objects in question are document model objects; and retrieving them from file storage is indeed non-trivial; and so should be minimized when possible. It is not, however, the end of the world if some of them gets evicted from RAM, and then has to be later reloaded (such is life on iOS). Because these are document model objects, they must be unique in RAM and in file storage; and maintain their identity across RAM/file-storage transitions. If an object is evicted from RAM, it’s contents are written to it’s file storage first, and then later when it is recreated in RAM those contents are reloaded from the file. I am using the UUID of each object to establish the object’s identity across these transitions. However, the object graph while in RAM references other in-memory objects by pointer, not UUID (changing this basic fact of the system would require wide-spread rewrites of all the applications that use this data management system; and I thusly consider it infeasible). 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. It’s not maintaining the UUIDs as unique that makes for the expense, it’s the loading and unloading of the document model objects that does so; and to a lesser extent, keeping the object graph coherent. The objects in the system are not interchangeable or reusable; each one must maintain it’s identity even if it’s in-memory pointer address changes over time. The file storage system also enforces this identity by storing and retrieving objects by UUID. This means that objects can exist in memory in one of these states: The way I see it, any given object can be in one of these states: * Not in RAM at all; only in file storage (and stored under it’s UUID) * In RAM as a fault object. Faults are (like as in Core-Data) proxys for objects in file storage, that reserve RAM for the object, but don’t have any of the object’s contents loaded yet. Because they don’t have any contents, they also don’t store any links to other objects in RAM. When any message is sent to a fault object, it causes the object’s contents to be loaded from file storage, and the class to be swizzled back to it’s actual class (this may in turn cause the creation of other fault objects in RAM for objects that are not in RAM but referenced by the fault’s contents). * In RAM as a fully “inflated” object. This is a regular Objective-C object, with ivars, pointers, methods, and all the associated stuff. Additionally, the objects in RAM (fault or inflated) can be in one of these states: * Referenced. This is as you stated - something has a strong link to it (be it in the graph of document objects, or some other object in the system, or some variable on the stack someplace). * Unreferenced. Also as you stated… except: I’m not drawing a distinction between Referenced and Inaccessible. If there is a link to it somewhere in the system, my reasoning goes, that the object pool controller shouldn’t let it go yet. Obviously, if a given object is not in RAM, it falls in the Unreferenced category, as there can’t be any links to it, strong or weak. :-) 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. I am aware of the fact that if I do use a retainCount based system, I’m aiming a ray-gun at my foot and trying to shoot between my toes, without vaporizing them… :-) 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
Keyboard notifications triggered unnecessarily upon showing UIAlertview on iOS8.3
Greetings!
We are observing unusual behaviour with respect to Keyboard willshow will
hide notification on iOS 8.3.
The viewcontroler (listenig to keyboard notifications) has a textfiled and
upon clicking and upon tapping the submit button, the method first resigns
the first responder from textfield, and shows an alert to inform warning.
Everything works fine, it dismisses the keyboard and shows up the alert as
expected. (calls the UIKeyboardWillHideNotification method too).
However, on 8.3, after tapping OK/Cancel on Alertview delegate, it
dismisses the alert and it calls up UIKeyboardWillShowNotification
UIKeyboardWillHideNotification respectively, though it was not supposed to
be called! This was not expected, as the keyboard was already dismissed
before dispalying the alert!
Here is the code snippet, that we are trying:
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(keyboardWillHide:) name:UIKeyboardWillHideNotification
object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(keyboardWillShow:) name:UIKeyboardWillShowNotification
object:nil];
}
- (IBAction)ShowAlert:(id)sender {
[self.TxtField resignFirstResponder];
//This woudln't make any diff either :(
[self.view endEditing:YES];
[self ShowAlertForTest];
}
-(void)ShowAlertForTest{
UIAlertView *theAlertView= [[UIAlertView alloc]initWithTitle:@Title
message:@msg
delegate:self
cancelButtonTitle:@Cancel
otherButtonTitles:@Yes,
nil];
[theAlertView show];
}
- (void)alertView:(UIAlertView *)alertView
clickedButtonAtIndex:(NSInteger)buttonIndex
{
NSLog(@buttonIndex = %ld,buttonIndex);
}
- (void)keyboardWillShow:(NSNotification *)aNotification
{
NSLog(@keyboardWillShow);
}
- (void)keyboardWillHide:(NSNotification *)aNotification
{
NSLog(@keyboardWillHide);
}
This behaviour is causing issues in our app, when there are cascading
alerts triggered from the previous alertview'd delegate - bringing up the
keyboard in unneeded situations.
Any help /advice is greatly appreciated!
--
Thanks,
Devarshi
___
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 19, 2015, at 20:37 , Graham Cox graham@bigpond.com wrote: I think what the OP says he wants is that the cache can only release when it knows nobody else has a reference to an object as well My answer on this to Britt is that this is unknowable in general. *That* (or so I claim) is why it’s not safe to reason about retain counts. If Britt could be said to be wrong about anything, I’d say it’s this, the idea that “nobody else has a reference” is a meaningful concept. For all practical purposes it isn’t**. — It’s unknowable in general. Various parts of the system frameworks may have a need to reference your object for some reason that you don’t know and don’t care about. One sort of trivial example would be when zombies are enabled. In that case, there’s a strong reference to every object ever created. A more practical (though hypothetical) example might be if your object is retained by a NSInvocation that’s already been used for some purpose, but is itself cached somewhere in the frameworks and won’t be purged until some future time you can’t control. — The state of the memory management system may not be internally consistent at every single moment in time. For example, an object that’s in the process of being freed may for a short while still have an actual retain count of 1 even though there are no strong references to it anywhere. (It’s not the same thing really, but I seem to recall that due to serial nil’ing of weak references in ARC there can be short timing windows during dealloc where a weak reference is still non-nil but the object it refers to is gone. The runtime prevents you from using it, but it still has some very weird consequences. I think this came up on cocoa-dev about a year ago.) — There may be implementation details that you can’t take into account. What if (hypothetically) there were two different retain counters for every object — say a Cocoa retain count and a CF retain count? What could you then conclude from [someObject retainCount] alone? Nothing at all, really. ** Nor does Britt’s app need it to be. All that’s necessary is that old objects be inaccessible. The existing code ensures that. ___ 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
Collection Views Breaking
I've got a simple iOS project consisting of 2 collection view controllers and a navigation controller. Tapping any item in the first collection view simply pushes the second collection view on the stack. Problem is, when I tap Back and then manually scroll up ... the app crashes with a EXC_BAD_ACCESS error in main. Nothing is logged ... and the stack in the thread looks something like 0 objc_msgSend 16 UIApplicationMain 17 main 18 start 19 start with 17 main highlighted. / In the code, FirstViewController and SecondViewController are almost identical save for one line. I am specifically looking at what line 24 in SecondViewController does to the push transition. self.useLayoutToLayoutNavigationTransitions = YES; Upon running, the collection view push animation looks fine - and the Back button actually works ... but once I get back to FirstViewController, the original colors never come back. In addition, when I scroll up, I get the error listed above. I've thrown together a small project to demonstrate: https://github.com/LutherBaker/CollectionViewDemo Thoughts? It feels like I'm not referencing something I should be ... Thanks, -Luther PS: I think you may ignore this but note that when you initially select an item in the FirstViewController and push - the console spits lots and lots of *Snapshotting a view that has not been rendered results in an empty snapshot. Ensure your view has been rendered at least once before snapshotting or snapshot after screen updates.* which I assume is simply a bug or non-relevant logging accidentally left in the framework. ___ 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: NSFontPanel swamping the responder chain (and crashing)
On May 19, 2015, at 9:26 PM, Graham Cox graham@bigpond.com wrote: Just to be clear: it crashes when there is no involvement of my code at all - this is the stack trace without the override, but with zombies enabled: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0002, 0x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x7fff91e9fd20 ___forwarding___ + 768 1 com.apple.CoreFoundation 0x7fff91e9f998 _CF_forwarding_prep_0 + 120 2 com.apple.AppKit 0x7fff8cdf23c7 -[NSWindow supplementalTargetForAction:sender:] + 240 3 com.apple.AppKit 0x7fff8cdf1f74 _objectFromResponderChainWhichRespondsToAction + 227 4 com.apple.AppKit 0x7fff8cdf1ac0 _NSTargetForSendAction + 2861 5 com.apple.AppKit 0x7fff8cdf0e3e -[NSApplication targetForAction:to:from:] + 329 6 com.apple.AppKit 0x7fff8d07b102 -[NSFontPanel _canShowEffects] + 44 7 com.apple.AppKit 0x7fff8d07b0bb -[NSFontPanel _showEffects] + 31 8 com.apple.AppKit 0x7fff8d07a675 -[NSFontPanel windowDidUpdate:] + 537 9 com.apple.CoreFoundation 0x7fff91f1345c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 10 com.apple.CoreFoundation 0x7fff91e03634 _CFXNotificationPost + 3140 11 com.apple.Foundation 0x7fff975a59d1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 12 com.apple.CoreFoundation 0x7fff91e88d80 -[NSArray makeObjectsPerformSelector:] + 496 13 com.apple.AppKit 0x7fff8ccac5ea -[NSApplication(NSWindowCache) _updateWindowsUsingCache] + 495 14 com.apple.AppKit 0x7fff8ccac399 -[NSApplication updateWindows] + 70 15 com.apple.AppKit 0x7fff8d0a181f __38-[NSApplication setWindowsNeedUpdate:]_block_invoke2510 + 76 16 com.apple.CoreFoundation 0x7fff91e73127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 17 com.apple.CoreFoundation 0x7fff91e73080 __CFRunLoopDoObservers + 368 18 com.apple.CoreFoundation 0x7fff91e65188 __CFRunLoopRun + 872 19 com.apple.CoreFoundation 0x7fff91e64bd8 CFRunLoopRunSpecific + 296 20 com.apple.HIToolbox 0x7fff9729656f RunCurrentEventLoopInMode + 235 21 com.apple.HIToolbox 0x7fff972961ee ReceiveNextEventCommon + 179 22 com.apple.HIToolbox 0x7fff9729612b _BlockUntilNextEventMatchingListInModeWithFilter + 71 23 com.apple.AppKit 0x7fff8ccaa9bb _DPSNextEvent + 978 24 com.apple.AppKit 0x7fff8cca9f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 25 com.apple.AppKit 0x7fff8cc9fbf3 -[NSApplication run] + 594 26 com.apple.AppKit 0x7fff8cc1c354 NSApplicationMain + 1832 At line 2, it’s clearly trying to access a NSWindow zombie. I'm not sure that's true. I think if the window were the zombie, the crash would not show a frame in an NSWindow method, it would occur at the point where that method was called. I suspect the problem is that the window is trying to check with its delegate/controller to see if it might respond to the action and the delegate/controller is the zombie. If I'm right, the problem could probably be solved by clearing the window's delegate property in the -dealloc of the delegate/controller object. There should be a log message written which will clarify. It might or might not get included in the crash report, but it should be in the console log. What does that say? I’m pretty sure this is the window I just closed that closed the document. It’s hard to be 100% certain because the same result does not arise in the debugger - I have to export a complete app to see the problem, so I can’t examine the window’s address directly. Exporting a complete app is not mutually exclusive of running the app under the debugger. You can tell Xcode to run the exported app when debugging by mucking with the scheme. Or, you can directly run it using lldb from the command line. Does the problem also not happen if you run the app under Instruments with the Zombies template? If it does happen, that will help identify the history of the zombie. If you're just using NSZombieEnabled=YES and running from the command line, you can also use MallocStackLoggingNoCompact=1. When the breakpoint/trap occurs, you can use the malloc_history tool to examine the history of the address of the zombie object. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Re: NSFontPanel swamping the responder chain (and crashing)
On 20 May 2015, at 12:15 pm, Graham Cox graham@bigpond.com wrote: 'd start by looking at frame #4. The only code of mine involved is at line 4 which is where I overrode targetForAction:to:from to see what was being called from where, and then calls super. Just to be clear: it crashes when there is no involvement of my code at all - this is the stack trace without the override, but with zombies enabled: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0002, 0x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation0x7fff91e9fd20 ___forwarding___ + 768 1 com.apple.CoreFoundation0x7fff91e9f998 _CF_forwarding_prep_0 + 120 2 com.apple.AppKit0x7fff8cdf23c7 -[NSWindow supplementalTargetForAction:sender:] + 240 3 com.apple.AppKit0x7fff8cdf1f74 _objectFromResponderChainWhichRespondsToAction + 227 4 com.apple.AppKit0x7fff8cdf1ac0 _NSTargetForSendAction + 2861 5 com.apple.AppKit0x7fff8cdf0e3e -[NSApplication targetForAction:to:from:] + 329 6 com.apple.AppKit0x7fff8d07b102 -[NSFontPanel _canShowEffects] + 44 7 com.apple.AppKit0x7fff8d07b0bb -[NSFontPanel _showEffects] + 31 8 com.apple.AppKit0x7fff8d07a675 -[NSFontPanel windowDidUpdate:] + 537 9 com.apple.CoreFoundation0x7fff91f1345c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 10 com.apple.CoreFoundation0x7fff91e03634 _CFXNotificationPost + 3140 11 com.apple.Foundation0x7fff975a59d1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 12 com.apple.CoreFoundation0x7fff91e88d80 -[NSArray makeObjectsPerformSelector:] + 496 13 com.apple.AppKit0x7fff8ccac5ea -[NSApplication(NSWindowCache) _updateWindowsUsingCache] + 495 14 com.apple.AppKit0x7fff8ccac399 -[NSApplication updateWindows] + 70 15 com.apple.AppKit0x7fff8d0a181f __38-[NSApplication setWindowsNeedUpdate:]_block_invoke2510 + 76 16 com.apple.CoreFoundation0x7fff91e73127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 17 com.apple.CoreFoundation0x7fff91e73080 __CFRunLoopDoObservers + 368 18 com.apple.CoreFoundation0x7fff91e65188 __CFRunLoopRun + 872 19 com.apple.CoreFoundation0x7fff91e64bd8 CFRunLoopRunSpecific + 296 20 com.apple.HIToolbox 0x7fff9729656f RunCurrentEventLoopInMode + 235 21 com.apple.HIToolbox 0x7fff972961ee ReceiveNextEventCommon + 179 22 com.apple.HIToolbox 0x7fff9729612b _BlockUntilNextEventMatchingListInModeWithFilter + 71 23 com.apple.AppKit0x7fff8ccaa9bb _DPSNextEvent + 978 24 com.apple.AppKit0x7fff8cca9f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 25 com.apple.AppKit0x7fff8cc9fbf3 -[NSApplication run] + 594 26 com.apple.AppKit0x7fff8cc1c354 NSApplicationMain + 1832 At line 2, it’s clearly trying to access a NSWindow zombie. I’m pretty sure this is the window I just closed that closed the document. It’s hard to be 100% certain because the same result does not arise in the debugger - I have to export a complete app to see the problem, so I can’t examine the window’s address directly. However, this is the only window that has ever closed in the entire run. So, NSApplication has a stale reference to a closed window which it accesses in _objectFromResponderChainWhichRespondsToAction. How is that possible? —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: NSFontPanel swamping the responder chain (and crashing)
On 20 May 2015, at 12:09 pm, Kyle Sluder k...@ksluder.com wrote: On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote: 3 com.apple.AppKit0x7fff8fb2fe3e -[NSApplication targetForAction:to:from:] + 329 4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 + 487482 5 com.apple.AppKit0x7fff8fdba102 -[NSFontPanel _canShowEffects] + 44 I'd start by looking at frame #4. The only code of mine involved is at line 4 which is where I overrode targetForAction:to:from to see what was being called from where, and then calls super. —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: Tracking the retain count
On 20 May 2015, at 1:04 pm, Quincey Morris quinceymor...@rivergatesoftware.com wrote: I don’t think you’ve misunderstood anything at all. Kind of you to say so - I’m not so sure :) So, we look at two possible solutions. [Spoiler: Both solutions are 100% correct, because both solutions are 100% identical, as far as memory management is concerned.] Solution A: We create an additional strong reference to each object in the cache, kept in (say) a Cocoa collection. That allows us to selectively mark objects purgeable by removing some or all of these strong references. Drawback: We’re wasting memory for storing the additional strong references. Solution B: We retain each object as it enters the cache. That allows us to selectively mark objects purgeable by releasing them again. Drawbacks: None. The end. I think what the OP says he wants is that the cache can only release when it knows nobody else has a reference to an object as well, hence the temptation to peek at the retain count. In other words it must be the “last owner”, for some reason. The cache may have good reasons for requiring that it be the “last owner” of a cached object, but that seems orthogonal to retain/release. If the argument is that the cache assigns the UUIDs to the objects so it must be the “last owner” in order that these be unique, I think that’s possibly where the reasoning is flawed. A UUID is unique by definition, isn’t it? So there’s no need to do extra work to ensure uniqueness. Or it may have other reasons altogether, and the reasoning might not be flawed. It’s in that case that NSDicardableContent (or something akin to it) might be useful, because it provides something that looks like retain/release in principle but is outside of, and unaffected by it. It would allow the cache to know when any object it owns is not being accessed, even if that object were, from a memory management point of view, owned by something else as well. This is where using retain/release is bad, because an object can’t know if it’s the “last owner” without peeking, and as we know as peeking isn’t reliable, we have to rule it out. There are different ways to solve this - for example, maybe the cache provides an interface for vending and devending objects that it knows about such that it will only discard unvended objects, but in effect, that’s identical to the NSDiscardableContent pattern, just centralised awkwardly. I think the solution to this must come from a really good explanation from the OP as to why the cache MUST be the “last owner”. It’s that requirement that is forcing the issue, but it’s not that clear why that is a requirement. —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
NSFontPanel swamping the responder chain (and crashing)
I’m noticing something odd. When NSFontPanel is visible, it calls -[NSApplication targetForAction:to:from:] excessively often - in fact on every movement of the mouse. The action is -validModesForFontPanel: and the target is nil, so this is being pushed up the responder chain all of the time. This seems to me a huge waste of time and CPU cycles, though it may have its reasons. Why it’s a problem is that I’m experiencing a crash after I close a document due to this invocation - before the document is fully torn down, NSFontPanel sends this message and the responder chain appears to have, at that point, a stale reference to something in my doc*, so it crashes. *this is the theory I’m working on, though it’s hard to be sure. Note that turning on NSZombies doesn’t show what the original target of the call was - it still crashes in the same way. The stack trace is: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0018 Application Specific Information: objc_msgSend() selector name: respondsToSelector: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7fff909040dd objc_msgSend + 29 1 com.apple.AppKit0x7fff8fb30f74 _objectFromResponderChainWhichRespondsToAction + 227 2 com.apple.AppKit0x7fff8fb30ac0 _NSTargetForSendAction + 2861 3 com.apple.AppKit0x7fff8fb2fe3e -[NSApplication targetForAction:to:from:] + 329 4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 + 487482 5 com.apple.AppKit0x7fff8fdba102 -[NSFontPanel _canShowEffects] + 44 6 com.apple.AppKit0x7fff8fdba0bb -[NSFontPanel _showEffects] + 31 7 com.apple.AppKit0x7fff8fdb9675 -[NSFontPanel windowDidUpdate:] + 537 8 com.apple.CoreFoundation0x7fff94c5245c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12 9 com.apple.CoreFoundation0x7fff94b42634 _CFXNotificationPost + 3140 10 com.apple.Foundation0x7fff9a2e49d1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66 11 com.apple.CoreFoundation0x7fff94bc7d80 -[NSArray makeObjectsPerformSelector:] + 496 12 com.apple.AppKit0x7fff8f9eb5ea -[NSApplication(NSWindowCache) _updateWindowsUsingCache] + 495 13 com.apple.AppKit0x7fff8f9eb399 -[NSApplication updateWindows] + 70 14 com.apple.AppKit0x7fff8fde081f __38-[NSApplication setWindowsNeedUpdate:]_block_invoke2510 + 76 15 com.apple.CoreFoundation0x7fff94bb2127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 16 com.apple.CoreFoundation0x7fff94bb2080 __CFRunLoopDoObservers + 368 17 com.apple.CoreFoundation0x7fff94ba4188 __CFRunLoopRun + 872 18 com.apple.CoreFoundation0x7fff94ba3bd8 CFRunLoopRunSpecific + 296 19 com.apple.HIToolbox 0x7fff99fd556f RunCurrentEventLoopInMode + 235 20 com.apple.HIToolbox 0x7fff99fd51ee ReceiveNextEventCommon + 179 21 com.apple.HIToolbox 0x7fff99fd512b _BlockUntilNextEventMatchingListInModeWithFilter + 71 22 com.apple.AppKit0x7fff8f9e99bb _DPSNextEvent + 978 23 com.apple.AppKit0x7fff8f9e8f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 24 com.apple.AppKit0x7fff8f9debf3 -[NSApplication run] + 594 25 com.apple.AppKit0x7fff8f95b354 NSApplicationMain + 1832 The only code of mine involved is at line 4 which is where I overrode targetForAction:to:from to see what was being called from where, and then calls super. Anyone else noticed this, and what can be done about it? I need to make sure this doesn’t crash at the very least, but it also seems to indicate a deeper bug in that NSFontPanel is being extremely wasteful and suboptimal. —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: Tracking the retain count
On May 19, 2015, at 15:50 , Graham Cox graham@bigpond.com wrote: I may have misunderstood the problem such that this is a poor ot for other reasons, but I’m not seeing it. I’m also not sure why there seems to be a tacit resistance to it - seems logical to me. I don’t think you’ve misunderstood anything at all. I’ve hung back from replying for a bit, because I was not sure what to say next. Yesterday, I tried to retreat to firm ground and proceed from there, but apparently I didn’t do that very well. I’m going to try the same strategy one more time, to see if I can get onto even firmer ground, and stay there. I want to go back to Roland’s scenario, since it’s simple and contains the essence of what Britt wants to do. Let’s say we implement a cache as a strong-to-weak NSMapTable. That allows objects that are unreferenced (un-strong-referenced) elsewhere in our code to be purged. However, this is not the complete solution, because we want unreferenced objects to persist as long as they can, and a mere weak reference won’t achieve that. So, we look at two possible solutions. [Spoiler: Both solutions are 100% correct, because both solutions are 100% identical, as far as memory management is concerned.] Solution A: We create an additional strong reference to each object in the cache, kept in (say) a Cocoa collection. That allows us to selectively mark objects purgeable by removing some or all of these strong references. Drawback: We’re wasting memory for storing the additional strong references. Solution B: We retain each object as it enters the cache. That allows us to selectively mark objects purgeable by releasing them again. Drawbacks: None. The end. Note that there’s no objection (in either solution) on the basis of shaky reasoning about retain counts, because retain counts don’t enter into the correctness of what we’re doing. It’s always legal to retain an object, and it’s always legal to release an object we retained. Why are the solutions the same? Because in A, there’s an implicit retain associated with storing a strong reference, and that’s what makes it strong. The reference itself (the 4- or 8-byte pointer) is irrelevant to memory management. In A, it’s merely overhead. In B, we keep the retain, and eliminate the overhead. So, as Graham says, it’s hard to see where the tacit resistance to B comes from. No one seems to be unhappy about A, apart from the waste of memory, and B *is* A without the waste of memory. [Bonus sermon: Of course, if GC were being used, it’s the 4- or 8-byte pointer itself that makes the reference strong. Or, more exactly, its the reachability of the pointer that makes the reference strong. Under GC, you’d either have to use solution A, or invent custom reference counting. Which brings us back to NSDiscardableContent. It was introduced with 10.6, which IIRC makes it pre-ARC, in an era when GC was trying to be dominant. In those terms, it doesn’t seem so weird that a new style of reference counting was introduced, since it didn’t really duplicate anything you could do in GC. I just don’t see it as providing extra value any more.] ___ 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: NSFontPanel swamping the responder chain (and crashing)
On 20 May 2015, at 10:22 am, Graham Cox graham@bigpond.com wrote: *this is the theory I’m working on, though it’s hard to be sure. Note that turning on NSZombies doesn’t show what the original target of the call was - it still crashes in the same way. This is wrong - NSZombies does make it crash differently, by throwing the usual zombies exception. The zombie in this case is NSWindow, being the window that just got closed. The crash does not happen in the debugger/running from Xcode, only when exported as an app. That’s making it more difficult to track down the problem of course. —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: NSFontPanel swamping the responder chain (and crashing)
On Tue, May 19, 2015, at 07:22 PM, Graham Cox wrote: 3 com.apple.AppKit0x7fff8fb2fe3e -[NSApplication targetForAction:to:from:] + 329 4 com.mapdiva.as.artboard 0x000105a3103a 0x1059ba000 + 487482 5 com.apple.AppKit0x7fff8fdba102 -[NSFontPanel _canShowEffects] + 44 I'd start by looking at frame #4. --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
Plugin bundle with Javascript
Hi, I hope this it the right place to ask, if not can you point me the right direction. Is it possible to build plugin bundles using Javascript? I know how to to that with ObjectiveC and python (with py2app) but could’n find anything about Javascript. Georg ___ 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 just finished catching up on the discussion and keep coming back to the fragile nature of relying on retainCount. For now you do, indeed, have the option to vaporize your toes; later you may not have access to a ray gun if Apple decides that it's in the best interests of all concerned that they retain their toes, not their objects. I don't know what your app architecture looks like, but was wondering if you could build in a supportable method of managing what's in the cache without having to do other than a few localized changes. One thought I had was to base all your cacheable objects on a class whose sole function is to notify the cache when the last reference goes away, i.e., when dealloc is called. If the cache kept track of all cached objects using a NSMapTable with weak references then the cache itself wouldn't affect the retain count, so you'd never have to be looking at that. Reads from and writes to the NSMapTable would need to be protected for consistency. Does this sound like it could work? On May 19, 2015, at 12:55 AM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: On May 18, 2015, at 8:59 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: Let me try and summarize where we are, in response to the several recent suggestions: Close, but not quite: I have several apps which are built on an existing, fully functional data management layer that was originally built for a full desktop virtual-memory environment (FWIW, it pre-dates the existence of Core Data). I now need to move some of this to run under iOS. I also don’t want to make changes to this data management layer that would require widespread changes to my other apps that rely on it. The objects in question are document model objects; and retrieving them from file storage is indeed non-trivial; and so should be minimized when possible. It is not, however, the end of the world if some of them gets evicted from RAM, and then has to be later reloaded (such is life on iOS). Because these are document model objects, they must be unique in RAM and in file storage; and maintain their identity across RAM/file-storage transitions. If an object is evicted from RAM, it’s contents are written to it’s file storage first, and then later when it is recreated in RAM those contents are reloaded from the file. I am using the UUID of each object to establish the object’s identity across these transitions. However, the object graph while in RAM references other in-memory objects by pointer, not UUID (changing this basic fact of the system would require wide-spread rewrites of all the applications that use this data management system; and I thusly consider it infeasible). 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. It’s not maintaining the UUIDs as unique that makes for the expense, it’s the loading and unloading of the document model objects that does so; and to a lesser extent, keeping the object graph coherent. The objects in the system are not interchangeable or reusable; each one must maintain it’s identity even if it’s in-memory pointer address changes over time. The file storage system also enforces this identity by storing and retrieving objects by UUID. This means that objects can exist in memory in one of these states: The way I see it, any given object can be in one of these states: * Not in RAM at all; only in file storage (and stored under it’s UUID) * In RAM as a fault object. Faults are (like as in Core-Data) proxys for objects in file storage, that reserve RAM for the object, but don’t have any of the object’s contents loaded yet. Because they don’t have any contents, they also don’t store any links to other objects in RAM. When any message is sent to a fault object, it causes the object’s contents to be loaded from file storage, and the class to be swizzled back to it’s actual class (this may in turn cause the creation of other fault objects in RAM for objects that are not in RAM but referenced by the fault’s contents). * In RAM as a fully “inflated” object. This is a regular Objective-C object, with ivars, pointers, methods, and all the associated stuff. Additionally, the objects in RAM (fault or inflated) can be in one of these states: * Referenced. This is as you stated - something has a strong link to it (be it in the graph of document objects, or some other object in the system, or some variable on the stack someplace). * Unreferenced. Also as you stated… except: I’m not drawing a distinction
Re: Plugin bundle with Javascript
If you can find a way to get the plugin plugged into your code then it is doable. JS can be considered as resources and some custom Info.plist keys can be introduced to index the required files. On May 19, 2015, at 20:21, Georg Seifert georg.seif...@gmx.de wrote: Hi, I hope this it the right place to ask, if not can you point me the right direction. Is it possible to build plugin bundles using Javascript? I know how to to that with ObjectiveC and python (with py2app) but could’n find anything about Javascript. Georg ___ 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/max%40maxchan.info This email sent to m...@maxchan.info 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: Tracking the retain count
On May 19, 2015, at 8:52 AM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: On May 19, 2015, at 7:20 AM, Steve Christensen puns...@mac.com wrote: I just finished catching up on the discussion and keep coming back to the fragile nature of relying on retainCount. For now you do, indeed, have the option to vaporize your toes; later you may not have access to a ray gun if Apple decides that it's in the best interests of all concerned that they retain their toes, not their objects. Restating a previous concern of mine: 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! Yes, I am a bit concerned that it could become deprecated. I suppose that I could just override retain and release in that case; and track the retain count myself; although I seriously doubt that that functionality will be deprecated/removed as there’s too much oddball stuff that depends on it… but uggg… that’s nasty. To borrow a phrase from a lolcat, “DO! NOT! WANT!” :-) I'm not saying that retain/release management would go away entirely, just that could be made private to the compiler's management of ARC, for example, if Apple decides that ARC, Son of Arc, etc., is the only way to manage object lifespan. I don't know what your app architecture looks like, but was wondering if you could build in a supportable method of managing what's in the cache without having to do other than a few localized changes. One thought I had was to base all your cacheable objects on a class whose sole function is to notify the cache when the last reference goes away, i.e., when dealloc is called. If the cache kept track of all cached objects using a NSMapTable with weak references then the cache itself wouldn't affect the retain count, so you'd never have to be looking at that. Reads from and writes to the NSMapTable would need to be protected for consistency. Does this sound like it could work? Um… that’s just a weak link? And the only way for an instance to know that it’s got a reference to it outstanding is to override retain and release? Yes, the cache would be keeping a weak link to each of the in-memory objects it manages via a NSMapTable so that it doesn't affect the retain count of the current actual users of individual objects. By overriding dealloc in a cacheable object base class then you know for a fact that there are no more references to the object since that's the only time that dealloc will be called. Once that dealloc method notifies the cache to remove the object from its NSMapTable then the cache should be in a consistent state. The other benefit of creating this base class (assuming that you don't already have one) is that you don't have to be modifying code all over the place, just creating the common dealloc method and modifying the @interface statements in some headers so that the objects inherit. ___ 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 20 May 2015, at 12:20 am, Steve Christensen puns...@mac.com wrote: One thought I had was to base all your cacheable objects on a class whose sole function is to notify the cache when the last reference goes away, i.e., when dealloc is called This is what NSDiscardableContent is able to do, though the method names it uses are not ‘retain’, ‘release’ and 'retainCount'. As it’s a protocol, not an object, you can implement it however you like. I disagree (with Quincey) that you may as well use retain/release/retainCount because the point is that those things are called behind your back at times you do not control, which surely is why this is looking like such a difficult problem? Instead, if objects that access the cached objects are forced to use ‘beginContentAccess’ and ‘endContentAccess’ then you have a very definite way to find out when nobody is accessing the objects that cannot be interfered with by memory management in any way. I may have misunderstood the problem such that this is a poor ot for other reasons, but I’m not seeing it. I’m also not sure why there seems to be a tacit resistance to it - seems logical to me. —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: Tracking the retain count
On May 19, 2015, at 7:20 AM, Steve Christensen puns...@mac.com wrote: I just finished catching up on the discussion and keep coming back to the fragile nature of relying on retainCount. For now you do, indeed, have the option to vaporize your toes; later you may not have access to a ray gun if Apple decides that it's in the best interests of all concerned that they retain their toes, not their objects. Restating a previous concern of mine: 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! Yes, I am a bit concerned that it could become deprecated. I suppose that I could just override retain and release in that case; and track the retain count myself; although I seriously doubt that that functionality will be deprecated/removed as there’s too much oddball stuff that depends on it… but uggg… that’s nasty. To borrow a phrase from a lolcat, “DO! NOT! WANT!” :-) I don't know what your app architecture looks like, but was wondering if you could build in a supportable method of managing what's in the cache without having to do other than a few localized changes. One thought I had was to base all your cacheable objects on a class whose sole function is to notify the cache when the last reference goes away, i.e., when dealloc is called. If the cache kept track of all cached objects using a NSMapTable with weak references then the cache itself wouldn't affect the retain count, so you'd never have to be looking at that. Reads from and writes to the NSMapTable would need to be protected for consistency. Does this sound like it could work? Um… that’s just a weak link? And the only way for an instance to know that it’s got a reference to it outstanding is to override retain and release? *** On May 19, 2015, at 2:07 AM, dangerwillrobinsondan...@gmail.com wrote: But I'm curious if Instruments tells you anything about where to optimize. Yeah, I’m gonna have to do some profiling to see if my intuitive suspicions are anywhere near accurate… (premature optimization being the hazard that it is) A model that's 12 years old should surely have had memory issues on 12 year old computers as much as on a modern iOS device. Document sizes were smaller then… and the engine has been adapted to new projects since it started out in life. If there's some kind of relationship to a virtual machine there must be a way to give it virtual limits. It’s not a virtual machine that I was referring to (like the Java virtual machine, or like VirtualBox) but the operating system’s virtual memory support, aka swapping-to-disk. The engine was originally designed to just keep all the objects in RAM, and if physical RAM ran out, the OS would page out less used objects to swap space. iOS does not do that; which is why I need to manage the memory myself. ___ 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
