Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?

[John McCall]

> On May 21, 2015, at 4:44 PM, Graham Cox  wrote:
>> On 22 May 2015, at 3:02 am, Jens Alfke  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 -set:). 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)

[Graham Cox]

> On 22 May 2015, at 3:14 am, Jens Alfke  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?

[Graham Cox]

> On 22 May 2015, at 3:02 am, Jens Alfke  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 -set:). 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?

[Graham Cox]

> On 22 May 2015, at 2:28 am, Alex Zavatone  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: Disabling auto-synthesis of property accessors.

[Jens Alfke]

> On May 21, 2015, at 10:40 AM, Fritz Anderson  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: Disabling auto-synthesis of property accessors.

[Quincey Morris]

On May 21, 2015, at 10:40 , Fritz Anderson  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: NSFontPanel swamping the responder chain (and crashing)

[Jens Alfke]

> On May 21, 2015, at 9:51 AM, Quincey Morris 
>  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 
)

—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: Disabling auto-synthesis of property accessors.

[Fritz Anderson]

On 21 May 2015, at 12:27 PM, Kyle Sluder  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.

[Kyle Sluder]

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

Disabling auto-synthesis of property accessors.

[Alex Zavatone]

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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?

[Jens Alfke]

> On May 21, 2015, at 9:28 AM, Alex Zavatone  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: NSFontPanel swamping the responder chain (and crashing)

[Quincey Morris]

On May 21, 2015, at 03:09 , Graham Cox  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?

[Alex Zavatone]

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

Re: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?

[Jens Alfke]

> On May 21, 2015, at 6:43 AM, Alex Zavatone  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: Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?

[Alex Zavatone]

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?

[Alex Zavatone]

On May 20, 2015, at 7:17 PM, Jens Alfke wrote:

> 
>> On May 20, 2015, at 4:08 PM, Eric Wing  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

[Luther Baker]

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  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 
> > To: Cocoa Developers 
> > 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)

[Graham Cox]

> On 21 May 2015, at 8:09 pm, Graham Cox  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)

[Graham Cox]

> On 21 May 2015, at 7:31 pm, Quincey Morris 
>  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: NSFontPanel swamping the responder chain (and crashing)

[Quincey Morris]

On May 21, 2015, at 01:33 , Graham Cox  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: Tracking the retain count

[Uli Kusterer]

On 19 May 2015, at 17:52, Britt Durbrow  
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)

[Graham Cox]

> On 21 May 2015, at 5:45 pm, Quincey Morris 
>  wrote:
> 
> On May 21, 2015, at 00:18 , Graham Cox  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: 
2015-05-21 18:22:10.702 Artboard[26228:1678806] 
-[GCOrteliusDocument<0x101108ab0> cleanUpIfNeeded].406 window closing, cleaning 
up. Doc: 
2015-05-21 18:22:10.727 Artboard[26228:1678806] removing window controller 
, window=
2015-05-21 18:22:10.737 Artboard[26228:1678806] 
-[GCOrteliusDocument<0x101108ab0> dealloc].1121 deallocating DKDrawingDocument 

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)

[Quincey Morris]

On May 21, 2015, at 00:18 , Graham Cox  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)

[Graham Cox]

> On 21 May 2015, at 2:41 pm, Quincey Morris 
>  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