dealloc query for NSTableCellView

[Jonathan Mitchell]

In my arc app I dispose of observers in -dealloc.
The pattern I have established seems to work well but one case has me 
rethinking my approach.
Everything pivots around NSViewController -representedObject;

- (void)setRepresentedObject:(id)object
{
if (self.representedObject) [self removeObservers];
[super setRepresentedObject:object];
if (self.representedObject) [self addObservers];
}

- (void)dealloc
{
if (self.representedObject) [self removeObservers];
}

In my query case I have subclassed NSTableCellView. The principle is the same, 
but the signatures now are:

- (void)setObjectValue:(id)object
{
if (self.objectValue) [self removeObservers];
[super setObjectValue:object];
if (self.objectValue) [self addObservers];
}

- (void)dealloc
{
if (self.objectValue) [self removeObservers]; 
}

Crucially I find that in this case after my subclass -dealloc the superclass 
-dealloc calls -setObjectValue : nil which causes observation warnings to be 
issued (I always try and clear these types of issues because at the very least 
they mask real problems) as _objectValue will still be non nil and [self 
removeObservers] gets called again.

Is it normal for superclasses to message during dealloc?
I could be triggering any sequence of non dealloc friendly actions as a result 
of the call to -setObjectValue:.

Obviously I can use another property to track whether observations have been 
removed but that is just more glue.

Perhaps I just need to treat NSTableCellView as a special case and get out the 
belt and braces?

Thanks

Jonathan














___

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: dealloc query for NSTableCellView

[Roland King]

> On 4 Feb 2015, at 21:16, Jonathan Mitchell  wrote:
> 
> In my arc app I dispose of observers in -dealloc.
> The pattern I have established seems to work well but one case has me 
> rethinking my approach.
> Everything pivots around NSViewController -representedObject;
> 
> - (void)setRepresentedObject:(id)object
> {
>   if (self.representedObject) [self removeObservers];
>   [super setRepresentedObject:object];
>   if (self.representedObject) [self addObservers];
> }
> 
> - (void)dealloc
> {
>   if (self.representedObject) [self removeObservers];
> }
> 
> In my query case I have subclassed NSTableCellView. The principle is the 
> same, but the signatures now are:
> 
> - (void)setObjectValue:(id)object
> {
>   if (self.objectValue) [self removeObservers];
>   [super setObjectValue:object];
>   if (self.objectValue) [self addObservers];
> }
> 
> - (void)dealloc
> {
>   if (self.objectValue) [self removeObservers]; 
> }

If I have an observation pattern which is set up, and the previous one torn 
down, in setXXX:(id)xxx like you do then my dealloc usually goes

[ self setXXX:nil ]

which both removes the observers and sets the property to nil so it doesn’t 
happen again. 

Your problem here seems to be that you’ve tied the property to the observers in 
the set, but you are removing the observers without nil’ing the property in 
dealloc, thus leaving yourself open to another setter getting called. 


> 
> Crucially I find that in this case after my subclass -dealloc the superclass 
> -dealloc calls -setObjectValue : nil which causes observation warnings to be 
> issued (I always try and clear these types of issues because at the very 
> least they mask real problems) as _objectValue will still be non nil and 
> [self removeObservers] gets called again.
> 
> Is it normal for superclasses to message during dealloc?
> I could be triggering any sequence of non dealloc friendly actions as a 
> result of the call to -setObjectValue:.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: dealloc query for NSTableCellView

[Jonathan Mitchell]

> On 4 Feb 2015, at 13:27, Roland King  wrote:
> 
> If I have an observation pattern which is set up, and the previous one torn 
> down, in setXXX:(id)xxx like you do then my dealloc usually goes
> 
> [ self setXXX:nil ]
> 
> which both removes the observers and sets the property to nil so it doesn’t 
> happen again. 
> 
> Your problem here seems to be that you’ve tied the property to the observers 
> in the set, but you are removing the observers without nil’ing the property 
> in dealloc, thus leaving yourself open to another setter getting called. 
Thanks.

That approach does work in this case.
I don’t particularly like it in general because (in the more generic 
NSViewController case) it calls back into a core method generally used to help 
setup an instance.
Calling this in a habitual sense from -dealloc feels sort of wrong!

> 
>> 
>> Crucially I find that in this case after my subclass -dealloc the superclass 
>> -dealloc calls -setObjectValue : nil which causes observation warnings to be 
>> issued (I always try and clear these types of issues because at the very 
>> least they mask real problems) as _objectValue will still be non nil and 
>> [self removeObservers] gets called again.
>> 

>> Is it normal for superclasses to message during dealloc?

I would still like to know what people’s expectations are here.

Thanks

J


___

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

Resolving bizarre autolayout crashes.

[Alex Zavatone]

This problem is behind me but in case something like this appears again, I'm 
wondering how others would attempt to resole this type of issue in autolayout 
on iOS.

Configuration
Xcode 5.1.1
iOS 7

In working on modifying a view controller that someone else wrote with an XIB 
that uses autolayout constraints, suddenly the app threw an exception when 
trying to draw the XIB because "Probably at least one of the constraints in the 
following list is one you don't want." And it followed with a list of 5 
NSLayoutConstraints and NSAutoresizingMaskConstraints.

Looking at the UIScrollView to which they applied, I couldn't make heads or 
tails of how the constraints listed in the console translated into the 
constraints on the only UIScrollView in the XIB.

Attempting to revert the VC and the XIB to what was in the repo had no effect 
on resolving the issue.  

Quitting and restarting Xcode had no effect on resolving the issue.

I had to move my changes into an external file, check out a new copy of the 
branch, verify that it no longer threw an exception and then move my changes 
back in.  All in all, a really cumbersome process.

When the problem occurred, the XIB wasn't modified me and any changes I made in 
code were not touching any constraints, so I have no idea how it started in the 
first place.

What bugs me more is that there was no way I could resolve this type of 
autolayout issue aside from ditching everything and checking out a new branch 
from the repo.

How would those of you who are much better versed in autolayout than I go about 
resolving this type of issue that crops up when the XIB with constraints hasn't 
been modified in the first place and there is no code affecting the XIB's 
constraints at all?

Thanks in advance.
Alex

Sent from my iPad. Please pardon typos.
___

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: dealloc query for NSTableCellView

[Quincey Morris]

On Feb 4, 2015, at 05:43 , Jonathan Mitchell  wrote:
> 
>>> Is it normal for superclasses to message during dealloc?
> 
> I would still like to know what people’s expectations are here.

It is normal for classes to message during dealloc, so it’s normal for 
superclasses to do so. However, it’s always been treacherous, for two reasons:

1. In general, using dealloc to release resources can lead to very subtle 
circular race conditions between objects.

2. In general, you don’t know whether it’s safe to send a message to a 
partially deallocated object, unless you know the exact details of the 
implementation, including superclasses.

You’ve come unstuck with case 2. If you were in control of the implementation, 
you could set _objectValue to nil directly, but you’re not and you can’t. If 
this were the old days, pre-ARC, you could invoke [super dealloc] first, though 
you’d have to assume that there were no subclasses being messed up by that.

In a sense, your existing objectValue solution was always wrong, because you 
never knew for certain whether all changes to the property value went through 
the setter. The same is true of representedObject, although in that case you 
might be prepared to bet on your assumptions never failing.



___

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: Resolving bizarre autolayout crashes.

[Ben Kennedy]

On 04 Feb 2015, at 8:26 am, Alex Zavatone  wrote:

> Looking at the UIScrollView to which they applied, I couldn't make heads or 
> tails of how the constraints listed in the console translated into the 
> constraints on the only UIScrollView in the XIB.

I don't suppose you saved a copy of the log message, did you?  We might be able 
to help shed some light on it.

> Attempting to revert the VC and the XIB to what was in the repo had no effect 
> on resolving the issue.  
> 
> Quitting and restarting Xcode had no effect on resolving the issue.

Did you clean your build folder?  Xcode is well known for leaving compiled xibs 
lying around in the build product after they have been e.g. removed from the 
project.  Recent versions also seem to have a propensity for hanging onto 
diagnostic and error messages that are no longer relevant and which can only be 
cleared by doing a full clean.

b


___

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: Resolving bizarre autolayout crashes.

[Alex Zavatone]

Here's the error log: 

Error message follows.  
UIView property translatesAutoresizingMaskIntoConstraints) 
(
"=1368)]>",
"",
"",
"",
""
)

Will attempt to recover by breaking constraint 
=1368)]>

Break on objc_exception_throw to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed 
in  may also be helpful.


I did do a command shift K to build from scratch.  Didn't make a difference.  
Should I also need to clear the Derived Data folder?

Thanks Ben.

Sent from my iPad. Please pardon typos.

On Feb 4, 2015, at 1:22 PM, Ben Kennedy  wrote:

> On 04 Feb 2015, at 8:26 am, Alex Zavatone  wrote:
> 
>> Looking at the UIScrollView to which they applied, I couldn't make heads or 
>> tails of how the constraints listed in the console translated into the 
>> constraints on the only UIScrollView in the XIB.
> 
> I don't suppose you saved a copy of the log message, did you?  We might be 
> able to help shed some light on it.
> 
>> Attempting to revert the VC and the XIB to what was in the repo had no 
>> effect on resolving the issue.  
>> 
>> Quitting and restarting Xcode had no effect on resolving the issue.
> 
> Did you clean your build folder?  Xcode is well known for leaving compiled 
> xibs lying around in the build product after they have been e.g. removed from 
> the project.  Recent versions also seem to have a propensity for hanging onto 
> diagnostic and error messages that are no longer relevant and which can only 
> be cleared by doing a full clean.
> 
> b
> 
___

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: NSString stringByAbbreviatingWithTildeInPath and Sandboxing

[Jon Baumgartner]

I filed a radar: rdar://19716583

On Thu, Jan 29, 2015 at 10:55 AM, Kyle Sluder  wrote:

> Even in a sandbox, you can get the user’s home directory using getpwuid(3)
> as mentioned in the docs:
> https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html
>
> So you could just search through your string and replace occurrences of
> that with a tilde, but then you have to worry about encodings and all that
> muck. Since there’s no security risk here, it’s reasonable to ask that the
> existing API work in a sandbox too.
>
> --Kyle Sluder
>
> > On Jan 29, 2015, at 7:45 AM, Jon Baumgartner <
> j...@bergenstreetsoftware.com> wrote:
> >
> > I’m happy to do this, but is this really a bug? I was just thinking
> there might be an alternate way to accomplish this.
> >
> >> On 1/27/2015 4:03 PM, Kyle Sluder wrote:
> >> Could you please file a Radar describing your use case and share the
> >> number here?
> >>
> >>
> >
>
___

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: Resolving bizarre autolayout crashes.

[Kyle Sluder]

On Wed, Feb 4, 2015, at 12:24 PM, Alex Zavatone wrote:
> Here's the error log: 
> 
> Error message follows.  
> UIView property translatesAutoresizingMaskIntoConstraints) 
> (
> " V:[UIScrollView:0x16d8df50(>=1368)]>",

This looks like it might be the culprit. Constraints applied to the
scroll view itself that don't relate to a descendant are considered to
affect the scroll view's size within its superview, not its scrollable
area.

If you are trying to force the scrollable area to be at least a certain
size, you can't constrain the scroll view itself. You need to add a
UIView as a subview, pin its sides to its superview, and constrain
_that_ view's height.

--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

Self describing NSObjects.

[Alex Zavatone]

All too often, I have a simple data class that is just a bunch of properties of 
cocoa collections.

When walking through the debugger, it would be nice if these classes could auto 
describe.

Consider this.  I have a class with the properties of NSStrings that are 
firstname, lastname, address.

Calling description or debugDescription on an instance of the class simply 
prints out the memory location.

Is there something that I'm missing here?  I don't want to manually enter each 
of the names of each of the properties to be exposed through a description 
method.  Is there a means to extend NSObject to auto describe the top level of 
properties that are NSStrings, NSDictionaries, NSSets and so on and 
automatically dump them to the console?  

How would you think about implementing this?  It seems like I run into this 
need year after year after year.

Thanks.

Alex

Sent from my iPad. Please pardon typos.
___

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: Self describing NSObjects.

[Pascal J. Bourguignon]

> On 04 Feb 2015, at 19:43, Alex Zavatone  wrote:
> 
> All too often, I have a simple data class that is just a bunch of properties 
> of cocoa collections.
> 
> When walking through the debugger, it would be nice if these classes could 
> auto describe.
> 
> Consider this.  I have a class with the properties of NSStrings that are 
> firstname, lastname, address.
> 
> Calling description or debugDescription on an instance of the class simply 
> prints out the memory location.
> 
> Is there something that I'm missing here?  I don't want to manually enter 
> each of the names of each of the properties to be exposed through a 
> description method.  Is there a means to extend NSObject to auto describe the 
> top level of properties that are NSStrings, NSDictionaries, NSSets and so on 
> and automatically dump them to the console?  
> 
> How would you think about implementing this?  It seems like I run into this 
> need year after year after year.

Have a look at: 
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/index.html#//apple_ref/doc/uid/2050-SW25

You can obtain the attributeKeys, and from there, obtain the value of the 
attributes and therefore implement a -description and/or -debugDescription 
including them.

-- 
__Pascal J. Bourguignon__



___

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: Resolving bizarre autolayout crashes.

[Jonathan Mitchell]

> On 4 Feb 2015, at 16:26, Alex Zavatone  wrote
> 
> How would those of you who are much better versed in autolayout than I go 
> about resolving this type of issue that crops up when the XIB with 
> constraints hasn't been modified in the first place and there is no code 
> affecting the XIB's constraints at all?
> 

You could try using Instruments and the Autolayout instrument to watch auto 
layout in action.

Jonathan 



___

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: Resolving bizarre autolayout crashes.

[Michael Crawford]

If debugging your code or interface builder layouts don't help, it
could be a corrupt Xcode project.

I have at times been able to fix my .pbxproj documents by editing them
with a text editor.  If you study them for a little while you can
obtain some insight as to what the format means.

There exists a market opportunity for validating interface builder
layouts.  I've often thought of writing such a tool but I just don't
have the headspace to deal with it.  I've experienced all manner of
problems because of error between seat and keyboard (or mouse, in the
case of IB).  Such a tool would perform validation that's not already
done by Xcode.

Mike
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Feb 4, 2015 at 10:06 AM, Jonathan Mitchell
 wrote:
>
>
>> On 4 Feb 2015, at 16:26, Alex Zavatone  wrote
>>
>> How would those of you who are much better versed in autolayout than I go 
>> about resolving this type of issue that crops up when the XIB with 
>> constraints hasn't been modified in the first place and there is no code 
>> affecting the XIB's constraints at all?
>>
>
> You could try using Instruments and the Autolayout instrument to watch auto 
> layout in action.
>
> Jonathan
>
>
>
> ___
>
> 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/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Resolving bizarre autolayout crashes.

[Alex Zavatone]

We haven't moved to Xcode 6 yet.  This isn't in Xcode 5, is it?

Sent from my iPad. Please pardon typos.

On Feb 4, 2015, at 1:06 PM, Jonathan Mitchell  wrote:

> 
> 
>> On 4 Feb 2015, at 16:26, Alex Zavatone  wrote
>> 
>> How would those of you who are much better versed in autolayout than I go 
>> about resolving this type of issue that crops up when the XIB with 
>> constraints hasn't been modified in the first place and there is no code 
>> affecting the XIB's constraints at all?
> 
> You could try using Instruments and the Autolayout instrument to watch auto 
> layout in action.
> 
> Jonathan 
> 
> 

___

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: Resolving bizarre autolayout crashes.

[Alex Zavatone]

Thanks Kyle.  The thing that scares me here is that I have no idea why this 
started failing and why it stopped, so I'm afraid it could stop working at any 
time without knowing why.

I can see this constraint on the scroll view itself, and I think you hit the 
nail on the head here.

I'll pass this by the author as we have many other XIB's exactly like this.

We are applying the same constraint in the scroll view's sub view.  

I think this started happening when I changed device size in the simulator, or 
dragged the simulator from one screen to another but still, I'm unsure what 
caused it to start throwing an exception.

Thanks for your help on this.

Alex

Sent from my iPad. Please pardon typos.

On Feb 4, 2015, at 1:33 PM, Kyle Sluder  wrote:

> On Wed, Feb 4, 2015, at 12:24 PM, Alex Zavatone wrote:
>> Here's the error log: 
>> 
>> Error message follows.  
>> UIView property translatesAutoresizingMaskIntoConstraints) 
>> (
>>">V:[UIScrollView:0x16d8df50(>=1368)]>",
> 
> This looks like it might be the culprit. Constraints applied to the
> scroll view itself that don't relate to a descendant are considered to
> affect the scroll view's size within its superview, not its scrollable
> area.
> 
> If you are trying to force the scrollable area to be at least a certain
> size, you can't constrain the scroll view itself. You need to add a
> UIView as a subview, pin its sides to its superview, and constrain
> _that_ view's height.
> 
> --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/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: Resolving bizarre autolayout crashes.

[Ben Kennedy]

On 04 Feb 2015, at 1:08 pm, Alex Zavatone  wrote:

> Thanks Kyle.  The thing that scares me here is that I have no idea why this 
> started failing and why it stopped, so I'm afraid it could stop working at 
> any time without knowing why.

Kyle already gave you a likely reason: you have a height constraint on the 
scroll view which conflicts with other constraints under some circumstances.

> I think this started happening when I changed device size in the simulator, 
> or dragged the simulator from one screen to another but still, I'm unsure 
> what caused it to start throwing an exception.

To be clear, the exception is thrown because your scroll view has two or more 
conflicting constraints in force.

Here again are the constraints from the debugging output you posted earlier:

"=1368)]>",
"",
"",
"",
""

These state that the scroll view is pinned to the same frame as its superview, 
and that its height (and therefore its superview's height) must be >= 1368.  
However, there is also a _UIParallaxDimmingView that is constrained also to 
occupy the same superview, but whose height is fixed at 568.  Clearly, 568 < 
1368; hence a conflict.

No doubt you aren't installing this _UIParallaxDimmingView yourself, but some 
interaction is prompting UIKit to do so (presumably on a transient basis).  
While I don't know anything about such circumstances, it seems to follow that 
if you take Kyle's advice and remove the height constraint on the scroll view, 
it will prevent such a conflict.

b



___

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

Networking framework crash

[Graham Cox]

Anyone seen this? My fault, or...?

OS Version:Mac OS X 10.10.2 (14C109)
Report Version:11
Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F

Sleep/Wake UUID:   5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB

Time Awake Since Boot: 30 seconds
Time Since Wake:   6200 seconds

Crashed Thread:7  Dispatch queue: 
com.apple.networking.connection.0x7fa940613300

Exception Type:EXC_GUARD
Exception Codes:   0x400200fe, 0x7fa94044b9e0


Thread 7 Crashed:: Dispatch queue: 
com.apple.networking.connection.0x7fa940613300
0   libsystem_kernel.dylib  0x7fff83900c1a dup + 10
1   libsystem_network.dylib 0x7fff86cbb3d5 
__tcp_connection_get_socket_block_invoke + 60
2   libdispatch.dylib   0x7fff896f1c13 
_dispatch_client_callout + 8
3   libdispatch.dylib   0x7fff896f2e5e 
_dispatch_barrier_sync_f_invoke + 57
4   libsystem_network.dylib 0x7fff86cbb336 
tcp_connection_get_socket + 135
5   com.apple.CFNetwork 0x7fff8658e018 
SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160
6   com.apple.CFNetwork 0x7fff8658e786 
___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129
7   libdispatch.dylib   0x7fff896f6323 
_dispatch_call_block_and_release + 12
8   libdispatch.dylib   0x7fff896f1c13 
_dispatch_client_callout + 8
9   libdispatch.dylib   0x7fff896f5365 
_dispatch_queue_drain + 1100
10  libdispatch.dylib   0x7fff896f6ecc 
_dispatch_queue_invoke + 202
11  libdispatch.dylib   0x7fff896f46b7 
_dispatch_root_queue_drain + 463
12  libdispatch.dylib   0x7fff89702fe4 
_dispatch_worker_thread3 + 91
13  libsystem_pthread.dylib 0x7fff86028637 _pthread_wqthread + 
729
14  libsystem_pthread.dylib 0x7fff8602640d start_wqthread + 13


--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: Networking framework crash

[Roland King]

You should google EXC_GUARD, it’s interesting. 

0x400200fe

the 02 in the middle says the guard is in dup(), which it is. The 0xfe at the 
end tells you what file descriptor it’s on. (0xfe .. really, seems unusually if 
not impossibly large for a file descriptor, you got that many files open?). 

That next bit 0x7fa94044b9e0 is the magic number for that particular guard 
and how you decode that I have no idea. There’s a suggestion that may be a 
pointer/object reference.

So things which might cause this are using a file descriptor you gave to GCD to 
manage outside any context GCD gives it back to you to manage yourself. Using a 
close()d file descriptor which has then been re-openen by something else which 
‘guards’ it. I initially wondered if there was a block invoke on a block which 
had been released. Have you gone back to non-ARC again? 

Or it’s a framework bug. 

> On 5 Feb 2015, at 9:00 am, Graham Cox  wrote:
> 
> Anyone seen this? My fault, or...?
> 
> OS Version:Mac OS X 10.10.2 (14C109)
> Report Version:11
> Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F
> 
> Sleep/Wake UUID:   5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB
> 
> Time Awake Since Boot: 30 seconds
> Time Since Wake:   6200 seconds
> 
> Crashed Thread:7  Dispatch queue: 
> com.apple.networking.connection.0x7fa940613300
> 
> Exception Type:EXC_GUARD
> Exception Codes:   0x400200fe, 0x7fa94044b9e0
> 
> 
> Thread 7 Crashed:: Dispatch queue: 
> com.apple.networking.connection.0x7fa940613300
> 0   libsystem_kernel.dylib0x7fff83900c1a dup + 10
> 1   libsystem_network.dylib   0x7fff86cbb3d5 
> __tcp_connection_get_socket_block_invoke + 60
> 2   libdispatch.dylib 0x7fff896f1c13 
> _dispatch_client_callout + 8
> 3   libdispatch.dylib 0x7fff896f2e5e 
> _dispatch_barrier_sync_f_invoke + 57
> 4   libsystem_network.dylib   0x7fff86cbb336 
> tcp_connection_get_socket + 135
> 5   com.apple.CFNetwork   0x7fff8658e018 
> SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160
> 6   com.apple.CFNetwork   0x7fff8658e786 
> ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129
> 7   libdispatch.dylib 0x7fff896f6323 
> _dispatch_call_block_and_release + 12
> 8   libdispatch.dylib 0x7fff896f1c13 
> _dispatch_client_callout + 8
> 9   libdispatch.dylib 0x7fff896f5365 
> _dispatch_queue_drain + 1100
> 10  libdispatch.dylib 0x7fff896f6ecc 
> _dispatch_queue_invoke + 202
> 11  libdispatch.dylib 0x7fff896f46b7 
> _dispatch_root_queue_drain + 463
> 12  libdispatch.dylib 0x7fff89702fe4 
> _dispatch_worker_thread3 + 91
> 13  libsystem_pthread.dylib   0x7fff86028637 _pthread_wqthread + 
> 729
> 14  libsystem_pthread.dylib   0x7fff8602640d start_wqthread + 13
> 
> 
> --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: Networking framework crash

[Alex Zavatone]

Hard to tell without the code that surrounds it.

On Feb 4, 2015, at 8:00 PM, Graham Cox wrote:

> Anyone seen this? My fault, or...?
> 
> OS Version:Mac OS X 10.10.2 (14C109)
> Report Version:11
> Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F
> 
> Sleep/Wake UUID:   5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB
> 
> Time Awake Since Boot: 30 seconds
> Time Since Wake:   6200 seconds
> 
> Crashed Thread:7  Dispatch queue: 
> com.apple.networking.connection.0x7fa940613300
> 
> Exception Type:EXC_GUARD
> Exception Codes:   0x400200fe, 0x7fa94044b9e0
> 
> 
> Thread 7 Crashed:: Dispatch queue: 
> com.apple.networking.connection.0x7fa940613300
> 0   libsystem_kernel.dylib0x7fff83900c1a dup + 10
> 1   libsystem_network.dylib   0x7fff86cbb3d5 
> __tcp_connection_get_socket_block_invoke + 60
> 2   libdispatch.dylib 0x7fff896f1c13 
> _dispatch_client_callout + 8
> 3   libdispatch.dylib 0x7fff896f2e5e 
> _dispatch_barrier_sync_f_invoke + 57
> 4   libsystem_network.dylib   0x7fff86cbb336 
> tcp_connection_get_socket + 135
> 5   com.apple.CFNetwork   0x7fff8658e018 
> SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160
> 6   com.apple.CFNetwork   0x7fff8658e786 
> ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129
> 7   libdispatch.dylib 0x7fff896f6323 
> _dispatch_call_block_and_release + 12
> 8   libdispatch.dylib 0x7fff896f1c13 
> _dispatch_client_callout + 8
> 9   libdispatch.dylib 0x7fff896f5365 
> _dispatch_queue_drain + 1100
> 10  libdispatch.dylib 0x7fff896f6ecc 
> _dispatch_queue_invoke + 202
> 11  libdispatch.dylib 0x7fff896f46b7 
> _dispatch_root_queue_drain + 463
> 12  libdispatch.dylib 0x7fff89702fe4 
> _dispatch_worker_thread3 + 91
> 13  libsystem_pthread.dylib   0x7fff86028637 _pthread_wqthread + 
> 729
> 14  libsystem_pthread.dylib   0x7fff8602640d start_wqthread + 13
> 
> 
> --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/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: Networking framework crash

[Graham Cox]

> On 5 Feb 2015, at 12:28 pm, Alex Zavatone  wrote:
> 
> Hard to tell without the code that surrounds it.


That's the problem - there is no code that surrounds it. I'm using the 
NSURLSession/NSURLSessionDataTask interface. This internally calls down into 
operation queues, low level networking, sockets and so on. It's also not 
happening consistently - I had a couple of these today and then it started 
working fine. I haven't seen these before either.

I do kick off a lot of these sessions at once - it kinda depends on how the 
user has configured the app, but I'm currently testing with about 50 separate 
tasks, each of which opens a NSURLSession. These remain in existence and valid 
until the app quits (or until a particular task that owns it is deleted). Maybe 
that's just too many? I haven't read anything that says there is a limit to 
these, and I'm not sure it's going to be easy to reorganise to reduce them.

> On 5 Feb 2015, at 12:20 pm, Roland King  wrote:
> 
> You should google EXC_GUARD, it’s interesting. 
> 
> 0x400200fe
> 
> the 02 in the middle says the guard is in dup(), which it is. The 0xfe at the 
> end tells you what file descriptor it’s on. (0xfe .. really, seems unusually 
> if not impossibly large for a file descriptor, you got that many files 
> open?). 


Well, at the point where this crashes, I haven't opened any files at all 
myself, though it partly depends what you mean by "file" in this context, and 
whether the lower level code invoked by NSURLSession opens files for its own 
use. As I said, I'm creating about 50 NSURLSessions as my app launches, which 
may be simply too many.

I am googling EXC_GUARD but haven't found anything that breaks it down - just a 
bunch of people asking what it is.



--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: Networking framework crash

[Michael Crawford]

There are all kinds of ways that your bug could be somewhere else,
other than where the processor finds an illegal instruction that
generates an exception that yields your panic.

There are a number of strategies for dealing with this that are quite
a lot easier than single-stepping with a debugger or adding lots of
printfs or NSLogs.

Try bisecting your code's history.  If you're not using revision
control, then hopefully you at least keep regular backups.

Try cutting down your existing codebase into a minimal test case.
Perhaps the bug will go away at some point.  Add back to your build
the source you just removed.  Does you bug reappear?  If so then
remove some other code until you have the very smallest amount of
source that you possibly can.

If the bug is not readily reproducible, find some way to stabilize it,
say by feeding it input files or network data that reliably stimulates
the crash.

Add assertions to your source.  Even after you fix the bug, keep the
assertions in your source as they are likely to catch other bugs
later:

   assert() is the Documentation that Keeps On Testing
   http://www.warplife.com/tips/code/quality/test/assertion/

In my personal experience, asserting the validity to subroutine
parameters yields the most productive use of my time.  If that doesn't
find your bug, assert that the return results of subroutine are valid.
If that still doesn't find your bug, assert that class invariants are
valid _outside_ of the "payload" code of any C++ member function or
Objective-C method.  A class invariant is some property of a class
which always holds true, with the possible exception that the
invariant may be temporarily broken within the body of subroutine.

Not all classes have sensible invariants.  If you find that many of
yours do not, perhaps it would help to refactor your classes so that
they do.

Enable guard malloc in Xcode's settings.

Use valgrind: http://www.valgrind.org/

Have a read of the Design for Testability section of John Lakos'
most-excellent "Large Scale C++ Software Design" - even if you don't
use C++, his section on Design for Testability will still apply for
your code.

Refactor your sourcebase so as to enable what he denotes as
"Levelization", and that I denote as "Lakos Levelization".  Many
coders practice unit testing; Lakos Levelization combines unit testing
and refactoring.  The source for a levelized program is quite a lot
easier to understand than the source for one which is not levelized.

If all else fails, mail me off-list and I'll fix it for you for a
reasonable consulting fee.

This Spam Has Been Brought To You By:

Mike Crawford
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Feb 4, 2015 at 5:28 PM, Alex Zavatone  wrote:
> Hard to tell without the code that surrounds it.
>
> On Feb 4, 2015, at 8:00 PM, Graham Cox wrote:
>
>> Anyone seen this? My fault, or...?
>>
>> OS Version:Mac OS X 10.10.2 (14C109)
>> Report Version:11
>> Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F
>>
>> Sleep/Wake UUID:   5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB
>>
>> Time Awake Since Boot: 30 seconds
>> Time Since Wake:   6200 seconds
>>
>> Crashed Thread:7  Dispatch queue: 
>> com.apple.networking.connection.0x7fa940613300
>>
>> Exception Type:EXC_GUARD
>> Exception Codes:   0x400200fe, 0x7fa94044b9e0
>>
>>
>> Thread 7 Crashed:: Dispatch queue: 
>> com.apple.networking.connection.0x7fa940613300
>> 0   libsystem_kernel.dylib0x7fff83900c1a dup + 10
>> 1   libsystem_network.dylib   0x7fff86cbb3d5 
>> __tcp_connection_get_socket_block_invoke + 60
>> 2   libdispatch.dylib 0x7fff896f1c13 
>> _dispatch_client_callout + 8
>> 3   libdispatch.dylib 0x7fff896f2e5e 
>> _dispatch_barrier_sync_f_invoke + 57
>> 4   libsystem_network.dylib   0x7fff86cbb336 
>> tcp_connection_get_socket + 135
>> 5   com.apple.CFNetwork   0x7fff8658e018 
>> SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160
>> 6   com.apple.CFNetwork   0x7fff8658e786 
>> ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129
>> 7   libdispatch.dylib 0x7fff896f6323 
>> _dispatch_call_block_and_release + 12
>> 8   libdispatch.dylib 0x7fff896f1c13 
>> _dispatch_client_callout + 8
>> 9   libdispatch.dylib 0x7fff896f5365 
>> _dispatch_queue_drain + 1100
>> 10  libdispatch.dylib 0x7fff896f6ecc 
>> _dispatch_queue_invoke + 202
>> 11  libdispatch.dylib 0x7fff896f46b7 
>> _dispatch_root_queue_drain + 463
>> 12  libdispatch.dylib 0x7fff89702fe4 
>> _dispatch_worker_thread3 + 91
>> 13  libsystem_pthread.dylib   0x7fff86028637 _pthread_wqt

Re: Networking framework crash

[Graham Cox]

> On 5 Feb 2015, at 1:53 pm, Michael Crawford  wrote:
> 
> This Spam Has Been Brought To You By:


No disrespect, but after 30+ years of developing, I am roughly conversant with 
debugging strategies.

This is not an easy one to isolate, because there's very little information on 
EXC_GUARD that I can find, the code is being run on a thread I didn't create, 
and whose provenance (calling chain) is not directly related to my high-level 
code (NSURLSession/NSURLSessionDataTask). It's also only just started happening 
in an app that has been happily running for months without a problem 
(notwithstanding the memory leak I discussed a couple of weeks ago that was in 
the same app, and also appears not to be my bug).

What is new is that I may have started to hit some sort of unexpected internal 
limit that I hadn't previously triggered. If that's the case it may have 
profound implications for my app's architecture, which does create one session 
per task, rather than one session per app.

--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: Networking framework crash

[Michael Crawford]

> No disrespect, but after 30+ years of developing, I am roughly conversant 
> with debugging strategies.

My apologies, I sent my spam before noting who I was sending it to.
Of course I know you've been a coder, actually for quite a longer time
than I have.

There are some other considerations that you might not have looked into though.

Does this happen on just one machine?  If that's the case perhaps it
could be a hardware problem.  Try installing MemtestOSX, rebooting as
single-user then:

   $ ./memtest all 1

Let the tests run to completion.  Note that this will also indirectly
test for problems with your CPU, memory controller and motherboard.

Is your box overheating?  If so the fans will make a lot of noise.

Perhaps you found a bug in the kernel or one of the userspace
frameworks.  I won't insult you by telling you how to regress that but
if it is in the kernel I have some insight into kernel debugging.

Cheers,

Mike
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, Feb 4, 2015 at 7:04 PM, Graham Cox  wrote:
>
>> On 5 Feb 2015, at 1:53 pm, Michael Crawford  wrote:
>>
>> This Spam Has Been Brought To You By:
>
>
> No disrespect, but after 30+ years of developing, I am roughly conversant 
> with debugging strategies.
>
> This is not an easy one to isolate, because there's very little information 
> on EXC_GUARD that I can find, the code is being run on a thread I didn't 
> create, and whose provenance (calling chain) is not directly related to my 
> high-level code (NSURLSession/NSURLSessionDataTask). It's also only just 
> started happening in an app that has been happily running for months without 
> a problem (notwithstanding the memory leak I discussed a couple of weeks ago 
> that was in the same app, and also appears not to be my bug).
>
> What is new is that I may have started to hit some sort of unexpected 
> internal limit that I hadn't previously triggered. If that's the case it may 
> have profound implications for my app's architecture, which does create one 
> session per task, rather than one session per app.
>
> --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: Networking framework crash

[Roland King]

> 
> 
> I am googling EXC_GUARD but haven't found anything that breaks it down - just 
> a bunch of people asking what it is.
> 

Really? Google sent me to twitter sent me to devforums sent me to eskimo1. eg

https://devforums.apple.com/message/914791#914791 


There’s a bunch more but they all say much the same thing. 

if you aren’t opening your own files/creating your own filehandles I suspect 
you have a bugreport in your future. 

You might also try a post in CoreOS on devforums or on the networking apple 
mail list as that’s where Quinn hangs out. 
___

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: Networking framework crash

[Graham Cox]

> On 5 Feb 2015, at 2:14 pm, Roland King  wrote:
> 
>> 
>> 
>> I am googling EXC_GUARD but haven't found anything that breaks it down - 
>> just a bunch of people asking what it is.
>> 
> 
> Really? Google sent me to twitter sent me to devforums sent me to eskimo1. eg
> 
> https://devforums.apple.com/message/914791#914791


Yep, I found that just after I sent my previous. Interesting, though a little 
difficult to relate exactly to my crash. I guess tcp_connection_get_socket() 
creates a file handle for the socket stream (?? guessing) and that's the one 
tripping the EXC_GUARD.

Do you or anyone else know if there's some inherent limit to the number of 
simultaneous sockets that can be opened? I'm supposing that there's a 1:1 
correspondence between a NSURLSession and a socket, because of the description 
against [NSURLSession resetWithCompletionHandler:] says:

"This method empties all cookies, caches and credential stores, removes disk 
files, flushes in-progress downloads to disk, and ensures that future requests 
occur on a new socket"

This implies that there's a socket associated with the session.

Since I have also a 1:1 correspondence between my app's individual tasks and 
NSURLSession, I'm opening 1 socket per task as my app starts. So around 50 in 
my current test situation.


> if you aren’t opening your own files/creating your own filehandles I suspect 
> you have a bugreport in your future. 
> 
> You might also try a post in CoreOS on devforums or on the networking apple 
> mail list as that’s where Quinn hangs out. 


That sounds like a good thing to try.

--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: Self describing NSObjects.

[Richard Heard]

Or you can call _ivarDescription on the object in question.
-R

> On 4 Feb 2015, at 10:54:49 AM, Pascal J. Bourguignon  
> wrote:
> 
> 
>> On 04 Feb 2015, at 19:43, Alex Zavatone  wrote:
>> 
>> All too often, I have a simple data class that is just a bunch of properties 
>> of cocoa collections.
>> 
>> When walking through the debugger, it would be nice if these classes could 
>> auto describe.
>> 
>> Consider this.  I have a class with the properties of NSStrings that are 
>> firstname, lastname, address.
>> 
>> Calling description or debugDescription on an instance of the class simply 
>> prints out the memory location.
>> 
>> Is there something that I'm missing here?  I don't want to manually enter 
>> each of the names of each of the properties to be exposed through a 
>> description method.  Is there a means to extend NSObject to auto describe 
>> the top level of properties that are NSStrings, NSDictionaries, NSSets and 
>> so on and automatically dump them to the console?  
>> 
>> How would you think about implementing this?  It seems like I run into this 
>> need year after year after year.
> 
> Have a look at: 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/index.html#//apple_ref/doc/uid/2050-SW25
> 
> You can obtain the attributeKeys, and from there, obtain the value of the 
> attributes and therefore implement a -description and/or -debugDescription 
> including them.
> 
> -- 
> __Pascal J. Bourguignon__
> 
> 
> 
> ___
> 
> 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/heardrwt%40gmail.com
> 
> This email sent to heard...@gmail.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Self describing NSObjects.

[Graham Cox]

> On 5 Feb 2015, at 3:38 pm, Richard Heard  wrote:
> 
> Or you can call _ivarDescription on the object in question.
> -R


iOS only, apparently - doesn't seem to exist on Mac. And it's undocumented, 
unlike the runtime functions.

--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