Re: NSFontPanel swamping the responder chain (and crashing)
On May 21, 2015, at 00:18 , Graham Cox graham@bigpond.com wrote: How did you determine that it’s this property that is stale? Er, I think it was a deduction. The crash occurs during traversal of the responder chain (apparently), and it’s got as far as the window controller without crashing, and the document is next, but the document isn't “really” in the responder chain, so this private ‘supplementalTargetForAction:sender:’ looks like it must be what fakes this up, and the only reference the window controller has to the document is “document”, and the “document” property is unsafe_unretained, which would be an incredible coincidence otherwise. I guess it’s more of a guess than a deduction, but I can’t think of any better explanation of why it would crash exactly here. If the responder chain traversal knew about the document from somewhere else, I’d expect the ‘supplementalTargetForAction:sender:’ to be unnecessary. Or if the ‘supplementalTargetForAction:sender:’ was for another purpose, I would expect no crash there. Well, trouble is because the Font Panel is calling through this on every single event, it’s breaking all the time. Oh, yeah, I didn’t think of that. Perhaps you can leave the breakpoint disabled until you hit another breakpoint at a close method, or something like that. Or live dangerously and override ‘supplementalTargetForAction:sender:’? I thought I’d add an action to ‘po self’ but that doesn’t work - self isn’t recognised at this level. I guess you’d need to po one of the registers, but I don’t know which one. ___ 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 21 May 2015, at 5:45 pm, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On May 21, 2015, at 00:18 , Graham Cox graham@bigpond.com wrote:
How did you determine that it’s this property that is stale?
Er, I think it was a deduction.
Ah, fair enough. It was my deduction as well, but I thought you’d arrived there
by a more sure route. At least we’re thinking the same way… and I do appreciate
your help by the way.
I do wonder if this deduction is correct though. Here’s a bit of evidence to
the contrary.
I overrode -removeWindowController: in my document and I force the controller’s
document reference to be nil:
- (void)removeWindowController:(NSWindowController*) windowController
{
NSLog(@removing window controller %@, window=%@, windowController,
windowController.window );
[windowController retain];
[super removeWindowController:windowController];
windowController.document = nil;
[windowController release];
}
This doesn’t interfere with the normal deallocation of the document, but it
stll goes and crashes exactly the same. Therefore either the crash is not due
to window.windowController.document being stale after all, or something’s
putting that reference back after the window controller is removed (which would
be very strange). Or the window/windowController that’s crashing isn’t this one
at all- it may as I suggested before be the Save panel (the crash only occurs
if the save panel is made to appear by dirtying the document and setting the
system pref to review unsaved changes).
Log output:
2015-05-21 18:22:10.702 Artboard[26228:1678806] window closing: NSWindow:
0x6080001f1600
2015-05-21 18:22:10.702 Artboard[26228:1678806]
-[GCOrteliusDocument0x101108ab0 cleanUpIfNeeded].406 window closing, cleaning
up. Doc: GCOrteliusDocument: 0x101108ab0
2015-05-21 18:22:10.727 Artboard[26228:1678806] removing window controller
NSWindowController: 0x60887fd0, window=NSWindow: 0x6080001f1600
2015-05-21 18:22:10.737 Artboard[26228:1678806]
-[GCOrteliusDocument0x101108ab0 dealloc].1121 deallocating DKDrawingDocument
GCOrteliusDocument: 0x101108ab0
2015-05-21 18:22:10.743 Artboard[26228:1678806] *** -[GCOrteliusDocument
respondsToSelector:]: message sent to deallocated instance 0x101108ab0
Oh, yeah, I didn’t think of that. Perhaps you can leave the breakpoint
disabled until you hit another breakpoint at a close method, or something
like that.
I can’t do a ‘po self’, even just typing it in, at this point, no matter how
cunning I am at breaking at the right time. It seems as if there really isn’t
enough info to resolve ‘self’ (the message is error: use of undeclared
identifier ‘self’)
As you suggest, it’s probably a register, but don’t know which. I get the same
error if I try any of them - undeclared identifier ‘r15’ for example.
Might this strengthen the argument that this window/controller is not what was
assumed? If it’s a PowerBox object, maybe that’s why the debugger refuses to
divulge any information about it?
Recall also that the non-sandboxed version doesn’t crash either.
Or live dangerously and override ‘supplementalTargetForAction:sender:’?
Might have to - even though it’s a pain to insert a custom window controller
between a document and its window. However I’m beginning to think it’s not
going to help.
—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 21 May 2015, at 2:41 pm, Quincey Morris quinceymor...@rivergatesoftware.com wrote: It looks to me like the problem is that the NSWindowController’s “document” property is still set to the NSDocument object that was just deallocated How did you determine that it’s this property that is stale? The stack trace includes a whole bunch of assembly language, but it’s not directly traceable to that property (or at least I can’t trace it). Is there some Insruments magic I haven’t stumbled across yet? I would be inclined to try putting a breakpoint at the -[NSWindow supplementalTargetForAction:sender:] method, and poke around once there. Easier than Instruments, I’d imagine. Well, trouble is because the Font Panel is calling through this on every single event, it’s breaking all the time. I thought I’d add an action to ‘po self’ but that doesn’t work - self isn’t recognised at this level. I have no idea how to just log the address (or better, the -description) of self and continue. —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 19 May 2015, at 17:52, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: 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!” :-) Actually, AIUI it’s already something you’re not allowed to do under ARC, and also in Swift. So given the doubleplusungood feeling this gives me, I probably wouldn’t do it anymore for shipping code. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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 21, 2015, at 01:33 , Graham Cox graham@bigpond.com wrote: Therefore either the crash is not due to window.windowController.document being stale after all, According to Instruments, there’s only one NSWindow object ever been allocated, and only one NSWindowController, and both were created when the document was opened. I was going to say that the only possible route from that window to that document is window.windowController.document (apart from something so internal to Cocoa that we have no hope of deducing it). However, there is actually one more possibility: window.delegate. If that’s set to the document rather than the window controller, I suppose that might account for the crash. But I can’t imagine it would be. or something’s putting that reference back after the window controller is removed (which would be very strange). windowController.document = nil; It might be worth checking that setting it to nil isn’t ignored. Or the window/windowController that’s crashing isn’t this one at all- it may as I suggested before be the Save panel Instruments seems to confirm that the Save panel is in a different process’s address space, so I don’t see how to get here from there. We start at the window (your window) and end at the document (the zombie). What chain of references comes in the middle I don’t know for sure, but the end-points seem to be a given. ___ 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: Disabling auto-synthesis of property accessors.
On 21 May 2015, at 12:27 PM, Kyle Sluder k...@ksluder.com wrote: On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote: Jens mentioned that it was possible to turn off the auto-synthesis of properties in the build options of the target. This would be quite useful to help me iron out items that need to be refactored in my current project. My google skills are weak. I can't find out how to do this. Anyone care to clue me in? All the responses I see state that it's not possible. Project editor Build Settings Search for synth I must have misinterpreted the question. I had understood Alex wanted a build option to turn off the auto-synthesis of properties, so the compiler could complain at every conflation of ivars with @propertys. The search you suggest (at least in the ObjC project I have open in 6.3.2) turns up only the warning for the lack of @synthesize in the @implementation. The global feature itself seems to be mandatory. (I could guess why that would be reasonable.) — F ___ 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: Disabling auto-synthesis of property accessors.
On May 21, 2015, at 10:40 , Fritz Anderson fri...@manoverboard.org wrote: I must have misinterpreted the question. I had understood Alex wanted a build option to turn off the auto-synthesis of properties, so the compiler could complain at every conflation of ivars with @propertys. You didn’t misinterpret the question, but there’s no such build setting, so you have to solve the problem indirectly. — You turn on the @synthesize warning. — The warning message tells you when you’ve omitted a @synthesize. — You add the “new-style” @synthesize: @synthesize myProperty = _myProperty; — Then all of your old naked ‘myProperty’ ivar references produce compile errors. QED. Changing an old-style ‘@synthesize myProperty;’ to the new style leads to a similar result, but there’s no initial warning message to lead you there by the hand. ___ 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: Disabling auto-synthesis of property accessors.
On May 21, 2015, at 10:40 AM, Fritz Anderson fri...@manoverboard.org wrote: I must have misinterpreted the question. I had understood Alex wanted a build option to turn off the auto-synthesis of properties, so the compiler could complain at every conflation of ivars with @propertys. The warning causes the compiler to complain exactly as you describe, only it doesn’t do it by turning off auto-synthesis; instead it makes the auto-synthesis trigger a warning. —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: NSFontPanel swamping the responder chain (and crashing)
On 21 May 2015, at 8:09 pm, Graham Cox graham@bigpond.com wrote: And just to verify this finding, if I add a -prepareSavePanel: method to my simple test app, I can reproduce the identical crash there. I’m thinking that could be worth a radar, because it’s pretty easy to forget to remove that reference from the save panel (especially as in the modern block-based world, what the save panel calls is mostly internal to NSDocument and there isn’t a very obvious place to undo the -prepareSavePanel: work). I just realised this is a worse bug that it seemed, because in the “dont save” case, no user code is run that responds to the save panel, so there’s nowhere clean and simple to clear the delegate. Radar: 21055437 If anyone’s interested in seeing this problem in the flesh (pretty unlikely, but I’ll put it out there), here’s my test case: http://apptree.net/code/NSFontPanelBugger.zip —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 21 May 2015, at 7:31 pm, Quincey Morris quinceymor...@rivergatesoftware.com wrote: However, there is actually one more possibility: window.delegate. If that’s set to the document rather than the window controller, I suppose that might account for the crash. But I can’t imagine it would be. Well, I was going to say that in fact my window’s delegate is the document, but that I set it to nil early on during the closure sequence, so that couldn’t be it. However, you got me thinking (finally!). So I set a breakpoint on -[NSWindow setDelegate:]. It’s called quite a lot, but one place it was called unexpectedly was in -[NSDocument prepareSavePanel:] - I set the save panel’s delegate to the document. I can’t remember why I did this - it’s ancient code, and looking at it now it doesn’t appear to be implementing any delegate methods of NSSavePanel. So I tried commenting it out - BINGO, crash gone. So the crash was indeed caused by the Save panel having a stale ref to the document. (I’m supposing that even though PowerBox is a separate process, presumably the local save panel sheet is an interface and proxy for it, so it exists within the local process). And just to verify this finding, if I add a -prepareSavePanel: method to my simple test app, I can reproduce the identical crash there. I’m thinking that could be worth a radar, because it’s pretty easy to forget to remove that reference from the save panel (especially as in the modern block-based world, what the save panel calls is mostly internal to NSDocument and there isn’t a very obvious place to undo the -prepareSavePanel: work). So it looks as if the mystery is solved, subject to mopping up and checking that there’s no needed functionality that requires the save panel’s delegate to be my doc. Realising how simple this is, I’m wondering why it’s taken me so long to track this down. Basic dumbness, probably. Anyway, thanks for all your help, above and beyond for sure. —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 7:16 PM, Michael David Crawford wrote: You could comment off their declarations in your header files, then have a look at which uses of them in your sources result in fatal compiler errors. Bingo. That will do it. Thanks much to everyone on this. It's certainly gotten me a little more in touch with the guts of this all. Alex Zavatone ___ 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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 20, 2015, at 7:17 PM, Jens Alfke wrote: On May 20, 2015, at 4:08 PM, Eric Wing ewmail...@gmail.com wrote: You could use the Objective-C runtime to find out which things are properties. You could, but isn’t it a lot easier to just look at the character before the name and check whether it’s a “.”? —Jens This brings me back to a point of confusion in 2011 where I created properties in a class and accessed them without the self. Or so I thought. Anyway, time for a little research to narrow this down. On another note, I'm with you on disliking autosynthesis. What I like about having to manually create the @synthesis is that this creates a nice little table of contents at the top of my .m file. An easy single place where I can see all the props listed within my class. A point of reference. Putting each property @synthesis on its own line also provides ample room for comments to make everything nice and clear. Also, you can turn it off autosynthesis? How? That would be a big help for me to straighten out this iOS project where the original developers thought everything needed to be a java bean. Thanks much. Alex Zavatone NSBean - it's what happens when you have Java programmers try to create iOS apps. ___ 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: Collection Views Breaking
Thanks for digging in and tracking that down Bill! Very much appreciated!
It actually makes sense with what I'm now reading about Collection Views.
And thanks Kyle. I've seen that breakpoint behavior before and just dealt
with it ... but your statement about hardware exceptions really clarifies
it succinctly.
-Luther
On Wed, May 20, 2015 at 3:24 PM, Bill Monk billm...@mac.com wrote:
That's crashing because after going back, FirstViewController is using
SecondViewController as it's collectionView's delegate dataSource,
resulting in messages to a dealloc-ed object. Turn on NSZombies to see this.
This appears to happen because when going Back from your
SecondViewController's, FirstViewController is using SecondViewController
as its collection view's delegate / dataSource. Note that if you make a
strong reference to SecondViewController someone, so it isn't dealloced,
FirstViewController will start drawing its content using
SecondViewController's colors via SecondViewController's
cellForItemAtIndexPath.
One way to fix that is to add, in both view controllers:
- (void)viewWillAppear:(BOOL)animated {
self.collectionView.delegate = self;
self.collectionView.dataSource = self;
}
Also good practice to do:
- (void)dealloc
{
self.collectionView.delegate = nil;
self.collectionView.dataSource = nil;
}
That lets it run OK, but I'm not sure *why* your FirstViewController ends
up using Second as its delegate. The project doesn't contain any code that
directly does that. So I can't tell if the -viewWillAppear above is a
Band-Aid, or a correct solution. Perhaps it is with
useLayoutToLayoutNavigationTransitions? I haven't used that before.
Anyway that should get you started.
On May 20, 2015, at 7:45 AM, cocoa-dev-requ...@lists.apple.com wrote:
--
Message: 1
Date: Tue, 19 May 2015 23:46:28 -0500
From: Luther Baker lutherba...@gmail.com
To: Cocoa Developers Cocoa-dev@lists.apple.com
Subject: Collection Views Breaking
Message-ID:
cal5mv1m-u82zgvr6uacgy+9avn-cc1uo6++xvcfot7sd8qu...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
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 22 May 2015, at 3:14 am, Jens Alfke j...@mooseyard.com wrote: Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment” sketch: Spring Surprise: Pop one in your mouth and steel bolts plunge straight through both cheeks! —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 22 May 2015, at 2:28 am, Alex Zavatone z...@mac.com wrote: if you use myThing, it's not visually obvious that you're directly accessing the ivar This is where a consistent and deeply ingrained naming convention is useful. The leading underscore has always been Cocoa’s “way” of doing that, and with auto-synthesis that’s now baked in. But actually because of that, it’s less useful as a naming convention, because it puts you back to square 1 with knowing which is an ivar you added and which is a synthesised property. Because I came to Cocoa from C++, I have long had a habit of prefixing all my ivars with ‘m’ (for ‘member’). Some Cocoa folks don’t like that idiom, but I know that any time I see an access to anything starting with ‘m’ it’s a direct member. Sometimes I do m_ which makes it stand out even more. A lot of sample code seems to encourage the use of ‘my’ for anything that’s not part of the framework, but it quickly becomes overloaded. Whatever you choose, stick to it, that’s the important thing. (Not sure, but it might also be possible to set up syntax colouring so that ivars you declare are highlighted differently). —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On 22 May 2015, at 3:02 am, Jens Alfke j...@mooseyard.com wrote: Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. Anecdotally, with some coarse measurements to confirm it, I changed a bunch of code in -initWithCoder: to set ivars directly instead of using the property accessors (or -setFoo:). For a very large object graph - I’m talking hundreds of thousands of objects - the speed-up was dramatic. Dearchiving that large file went from 11 MINUTES to about 2 seconds. Because -initWithCoder: is an init method, setting ivars directly is par for the course, and at that time there can’t be any KVO observations depending on the property accessors, so it’s fine. However, if you have autosynthesized all your properties, to be completely safe and future-proof, you probably shouldn’t be doing this, even though right now the ivar names are predictable. That means that performance could be an issue with autosynthesized properties. —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 4:44 PM, Graham Cox graham@bigpond.com wrote: On 22 May 2015, at 3:02 am, Jens Alfke j...@mooseyard.com wrote: Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. Anecdotally, with some coarse measurements to confirm it, I changed a bunch of code in -initWithCoder: to set ivars directly instead of using the property accessors (or -setFoo:). For a very large object graph - I’m talking hundreds of thousands of objects - the speed-up was dramatic. Dearchiving that large file went from 11 MINUTES to about 2 seconds. Because -initWithCoder: is an init method, setting ivars directly is par for the course, and at that time there can’t be any KVO observations depending on the property accessors, so it’s fine. However, if you have autosynthesized all your properties, to be completely safe and future-proof, you probably shouldn’t be doing this, even though right now the ivar names are predictable. That means that performance could be an issue with autosynthesized properties. The synthesized ivar name algorithm is not an implementation detail. It is fully specified as follows: the compiler prepends a ‘_’ to the property name. Do not worry about future releases of the language changing the ivar name. 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: NSFontPanel swamping the responder chain (and crashing)
On May 21, 2015, at 9:51 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: 5 AppKit +[NSSavePanel _crunchyRawUnbonedPanel] The only way it could be any better is if it were huggable, too. Ha! That’s actually a reference to the Monty Python “Whizzo Candy Assortment” sketch: Inspector: People won't expect there to be a frog in there. They're bound to think it's some sort of mock frog. Candy maker: (insulted) Mock frog? We use no artificial preservatives or additives of any kind! Inspector: Nevertheless, I must warn you that in future you should delete the words 'crunchy frog', and replace them with the legend, 'crunchy raw unboned real dead frog' if you want to avoid prosecution. Candy maker: What about our sales?! (http://www.ibras.dk/montypython/episode06.htm http://www.ibras.dk/montypython/episode06.htm) —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 6:43 AM, Alex Zavatone z...@mac.com wrote: Also, you can turn it off autosynthesis? How? That would be a big help for me to straighten out this iOS project where the original developers thought everything needed to be a java bean. As Graham said, go to the build settings and turn on the warning for “Implicit Synthesized Properties”. While you’re at it, turn on “Treat Warnings As Errors”. You’ll now get a compile error any time you forget to add an @synthesize directive (or implement explicit accessor methods.) —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: NSFontPanel swamping the responder chain (and crashing)
On May 21, 2015, at 03:09 , Graham Cox graham@bigpond.com wrote: So it looks as if the mystery is solved Yes. The funny thing is that I could have sworn that NSSavePanel wasn’t a NSWindow subclass, but of course it is. The other funny thing is that if you look in your Instruments data for the allocation event that creates it, you see this: 5 AppKit +[NSSavePanel _crunchyRawUnbonedPanel] The only way it could be any better is if it were huggable, too. ___ 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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
On May 21, 2015, at 9:28 AM, Alex Zavatone z...@mac.com wrote: @synthesize thing = _thing; Which makes the internal and private ivar to be _thing while the property becomes thing. In my case, this helps to uncover where the original code is accessing the ivar as opposed to the property. I always use this naming convention. Not just for the reason you state, but because it makes it obvious which variables are ivars, i.e. which have object scope and which have local scope. (Yeah, you can make Xcode color them differently, but it’s not as obvious.) I highly recommend it. Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. And it’s not just about clock cycles, it’s also about code size — that blog post you linked to shows that ivar access is less than half as many instructions, plus the value can be saved in a register and reused. Code size significantly affects performance because of CPU’s limited instruction cache sizes. In most high level app code it probably doesn’t make much of a difference. Me, I tend to write lower-level code that does things like data storage and database queries, which are often seriously CPU-bound and where shaving off CPU cycles wherever possible does produce real improvements. (Plus, I’m lazy and it’s faster to type “_foo” than “self.foo”.) —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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?
Ahh. A little follow up. One area we all know about is that you can specialize the name of the property's ivar like so: @synthesize thing = _thing; Which makes the internal and private ivar to be _thing while the property becomes thing. In my case, this helps to uncover where the original code is accessing the ivar as opposed to the property. Instantly, as soon as you manually synthesize this way, the compiler points out every case in the class where the instance name is no longer valid. The problem behind this all is that if you use self.myThing, that's obviously a property, but if you use myThing, it's not visually obvious that you're directly accessing the ivar, not the property. When Xcode creates your properties with auto-synthesis, the compiler appears to create an ivar with the same name as property. Within the class itself, you can access self.myThing and myThing interchangeably and they will both end up with the same value as expected. Unfortunately, this makes it not visual no brainer which one you're accessing unless you pay attention. In my case, the wonderful original programmers created the instance variables and properties with the same name and frequently accessed both as if they were one and the same, resulting in some rather dense code. In an effort to refactor the code for readability and clarity, going through each class and making this change makes it painfully clear when the ivar's being accessed and when the property is. The reason why this matters is when trying to refactor code like this if you have ivars and properties declared with the same name, Xcode's refactoring fails if you try to refactor the property first. At least in my case, it does. In the effort to put some clarity into our large-ish classes, refactoring the ivars first means that I have to identify where they are used and using this @synthesize approach allows that. Now that I have a path forward and understand why things are what they are, this brings up the wonderful speed issue of how much slower is property access vs ivar access. Whichever you use depends on just how much you need speed vs encapsulation. Thankfully, that difference is summarized in charts at the end of the link below. https://www.bignerdranch.com/blog/should-i-use-a-property-or-an-instance-variable/ Again, thanks all who took their time to provide the backing information on this for me. Cheers, Alex Zavatone On May 21, 2015, at 9:45 AM, Alex Zavatone wrote: On May 20, 2015, at 7:16 PM, Michael David Crawford wrote: You could comment off their declarations in your header files, then have a look at which uses of them in your sources result in fatal compiler errors. Bingo. That will do it. Thanks much to everyone on this. It's certainly gotten me a little more in touch with the guts of this all. Alex Zavatone ___ 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/zav%40mac.com This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Disabling auto-synthesis of property accessors.
Jens mentioned that it was possible to turn off the auto-synthesis of properties in the build options of the target. This would be quite useful to help me iron out items that need to be refactored in my current project. My google skills are weak. I can't find out how to do this. Anyone care to clue me in? All the responses I see state that it's not possible. Thanks in advance, Alex Zavatone ___ 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: Disabling auto-synthesis of property accessors.
On Thu, May 21, 2015, at 12:11 PM, Alex Zavatone wrote: Jens mentioned that it was possible to turn off the auto-synthesis of properties in the build options of the target. This would be quite useful to help me iron out items that need to be refactored in my current project. My google skills are weak. I can't find out how to do this. Anyone care to clue me in? All the responses I see state that it's not possible. Project editor Build Settings Search for synth --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
