__PRETTY_FUNCTION__.219635

2011-12-24 Thread Peter Hudson 
Hi all

I have been making a few ( trivial ) changes to some code and when the app runs 
it grinds to a halt with an 
Objective-c exception and the next to last item on my stack is 

__PRETTY_FUNCTION__.219635


( the top of the stack being obj_msgSend )


Anybody have any ideas on this one.  I can't get the debugger to show me any 
detail about PRETTY_FUNCTION at all.

OSX 10.7.2  /  xCode 4 /  target OSX 10.6

Peter
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: __PRETTY_FUNCTION__.219635

2011-12-24 Thread Ken Thomases 
On Dec 24, 2011, at 6:11 AM, Peter Hudson wrote:

> I have been making a few ( trivial ) changes to some code and when the app 
> runs it grinds to a halt with an 
> Objective-c exception and the next to last item on my stack is 
> 
> __PRETTY_FUNCTION__.219635
> 
> ( the top of the stack being obj_msgSend )
> 
> Anybody have any ideas on this one.  I can't get the debugger to show me any 
> detail about PRETTY_FUNCTION at all.

That symbol is for a string, which is the name of the function.  It's not a 
function itself.

In C code, you can reference __FUNCTION__, __PRETTY_FUNCTION__, and __func__ in 
cases (usually debugging statements) where you need the name of the function.  
The compiler generates a string variable and the symbol for that variable is 
something like the above.

Since it's not the name of a function, it shouldn't be on the stack.  Some 
possible reasons that it would appear in a stack trace include:

* objc_msgSend can confuse debuggers and strack tracers because it doesn't 
manipulate the stack pointer or frame pointer in the usual way.

* Certain symbols have been stripped from your program and its libraries.  The 
function that's actually on the stack no longer has its symbol, so its address 
is correlated with an arbitrary different symbol that comes earlier.  This 
strikes me as unlikely.

* The program generates new code at runtime and has called such a function.  
That function would have no symbol and, again, its address was just correlated 
with the nearest prior symbol.

* The stack has been corrupted, so the stack tracer is getting bogus results.

I'd recommend enabling zombies, perhaps using the Zombies template for 
Instruments.  Also, see if Xcode's static analyzer finds any problems with your 
code.  If neither of those turns up anything, you can sprinkle printfs or NSLog 
calls through the suspect code to figure out where the crash is happening.

Good luck.

Regards,
Ken

___

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

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

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

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

Re: __PRETTY_FUNCTION__.219635

2011-12-24 Thread Peter Hudson 
Hi Ken

Thanks for this - most illuminating !

I have been checking out code around the crash point - it was easy to isolate - 
and  the exception
may well have emanated from my trying to do a deep copy of a class that does 
not have  initWithCoder / encodeWithCoder methods.

I seem to remember that with past versions of the compiler, performing this 
piece of nonsense produced a warning from the compiler.
It was so long ago now though  …..

Regards
Peter



On 24 Dec 2011, at 13:20, Ken Thomases wrote:

> On Dec 24, 2011, at 6:11 AM, Peter Hudson wrote:
> 
>> I have been making a few ( trivial ) changes to some code and when the app 
>> runs it grinds to a halt with an 
>> Objective-c exception and the next to last item on my stack is 
>> 
>> __PRETTY_FUNCTION__.219635
>> 
>> ( the top of the stack being obj_msgSend )
>> 
>> Anybody have any ideas on this one.  I can't get the debugger to show me any 
>> detail about PRETTY_FUNCTION at all.
> 
> That symbol is for a string, which is the name of the function.  It's not a 
> function itself.
> 
> In C code, you can reference __FUNCTION__, __PRETTY_FUNCTION__, and __func__ 
> in cases (usually debugging statements) where you need the name of the 
> function.  The compiler generates a string variable and the symbol for that 
> variable is something like the above.
> 
> Since it's not the name of a function, it shouldn't be on the stack.  Some 
> possible reasons that it would appear in a stack trace include:
> 
> * objc_msgSend can confuse debuggers and strack tracers because it doesn't 
> manipulate the stack pointer or frame pointer in the usual way.
> 
> * Certain symbols have been stripped from your program and its libraries.  
> The function that's actually on the stack no longer has its symbol, so its 
> address is correlated with an arbitrary different symbol that comes earlier.  
> This strikes me as unlikely.
> 
> * The program generates new code at runtime and has called such a function.  
> That function would have no symbol and, again, its address was just 
> correlated with the nearest prior symbol.
> 
> * The stack has been corrupted, so the stack tracer is getting bogus results.
> 
> I'd recommend enabling zombies, perhaps using the Zombies template for 
> Instruments.  Also, see if Xcode's static analyzer finds any problems with 
> your code.  If neither of those turns up anything, you can sprinkle printfs 
> or NSLog calls through the suspect code to figure out where the crash is 
> happening.
> 
> Good luck.
> 
> Regards,
> Ken
> 

___

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

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

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

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

Re: __PRETTY_FUNCTION__.219635

2011-12-24 Thread Steve Sisak 

At 12:11 PM + 12/24/11, Peter Hudson wrote:
I have been making a few ( trivial ) changes to some code and when 
the app runs it grinds to a halt with an
Objective-c exception and the next to last item on my stack is


__PRETTY_FUNCTION__.219635


IIRC, you'll get an exception if you accidentally use 
__PRETTY_FUNCTION__ in C function and maybe in a class (+) method 
(i.e. copy an NSLog call).


I got bit by this once and fact I got a runtime exception rather than 
a compile error was a complete surprise to me.


HTH,

-Steve
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: presentingViewController docs patently false

2011-12-24 Thread Matt Neuburg 
On Thu, 22 Dec 2011 10:27:32 -0800, Kyle Sluder  said:
>On Dec 22, 2011, at 8:59 AM, Matt Neuburg  wrote:
>
>> Okay, I did eventually find the situation in which the docs are correct. It 
>> only took me two days to figure it out.
>> 
>> But it is up to the docs to state that situation! This really does carry the 
>> notion of coy and allusive (and wrong) to its limit. This is not at all the 
>> way docs should be.
>
>Then please file a bug! The documentation authors can't know about and 
>document every bug in the implementation. Often times I believe they work from 
>the specification in order to have the docs ready for release.
>
>> However, at least my book will be more correct and helpful than the docs, so 
>> I suppose I shouldn't complain. m.
>
>While I wouldn't expect you to go into as much detail as you would in your 
>book, would you mind elaborating a bit more on your findings? Many people are 
>attempting to adopt UIStoryboard around now, and this is pertinent information.

I don't see how this has to do with UIStoryboard. It's about the stated effect 
of definesPresentationContext on presentingViewController. I do now understand 
what's really going on with that, I think, and I state my understand in the iOS 
5 revision of Chapter 19 of my book:

https://plus.google.com/115941336284685245715/posts/4rVkXjS5ME5

I did find that blog post on UIStoryboard very helpful for focussing my 
formulation of why storyboards, as you say, don't feel ready for prime time. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: release sent to deallocated instance under ARC .. how?

2011-12-24 Thread Matt Neuburg 
On Sat, 24 Dec 2011 13:35:07 +0800, Roland King  said:
object being dealloced. This line of code 
>
>return self.delegate == delegateArg
>
>caused self to get a retain/autorelease, resurrecting the object. The change 
>to use the ivar directly fixed it

Using the ivar directly is also a way of using self (saying "delegate" is just 
a way of saying "self->delegate), so it isn't the mention of self that's the 
problem; it's probably that the delegate property has a custom getter doing 
some weird stuff. If so, that's a thing to beware of; getting sneaky with 
accessors is a way to trip oneself up later... I'd examine that getter if I 
were you. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: presentingViewController docs patently false

2011-12-24 Thread Kyle Sluder 
On Dec 24, 2011, at 10:04 AM, Matt Neuburg  wrote:

> I don't see how this has to do with UIStoryboard. It's about the stated 
> effect of definesPresentationContext on presentingViewController. I do now 
> understand what's really going on with that, I think, and I state my 
> understand in the iOS 5 revision of Chapter 19 of my book:
> 
> https://plus.google.com/115941336284685245715/posts/4rVkXjS5ME5

I'm under the impression that the default segues consult the 
definesPresentationContext property to configure the actual animation. I could 
of course be mistaken.

I was unaware that you were offering the draft of your book for free. Thanks 
very much for the link.

Your use of the Music app as an example of view controller presentation puzzles 
me, though. In my app, I was trying to use the definesPresentationContext 
property to cause a "push" transition to affect just a view inside a tab bar 
item inside a navigation controller. Instead, no matter what I tried, the 
entire root view controller (the navigation controller) was always replaced. Is 
this because I was on the iPhone? Your book seems to imply that 
UIModalPresentationCurrentContext is only meaningful on the iPad since the root 
view controller is always the presentingViewController.

--Kyle Sluder (Mac Developer)___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cannot modify autoresizing with some iOS views

2011-12-24 Thread Matt Neuburg 
On Sat, 19 Nov 2011 07:28:07 -0800, Matt Neuburg  said:
>On Fri, 18 Nov 2011 16:22:14 -0500, David Hoerl  said:
>>I have a Xcode 4.2 project with a dozen or so nibs. I'm in the process 
>>of assuring that all the resizing is set up properly.
>>
>>I find that a small number of primary views - the one attached to the 
>>"view" outlet - have "fixed" autoresizing masks, and while I can set or 
>>unset the four outter attachments, I cannot set the inner two lines.
>
>The rule is that when you create a View nib, the view is not resizable, 
>because it is assumed to be a root view. If that isn't what you want, delete 
>that view and replace it. m.

Also the view has a Size popup menu in its Simulated Metrics panel (in the 
Attributes inspector); set that to Freeform and the view becomes manually 
resizable. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: presentingViewController docs patently false

2011-12-24 Thread Matt Neuburg 
On Sat, 24 Dec 2011 10:32:49 -0800, Kyle Sluder  said:
>On Dec 24, 2011, at 10:04 AM, Matt Neuburg  wrote:

>I'm under the impression that the default segues consult the 
>definesPresentationContext property to configure the actual animation. I could 
>of course be mistaken.

I doubt need to "consult" anything. The default segues call what you would have 
called, e.g. presentViewController. How that works is how that works (and that, 
indeed, is what I was trying to figure out).

>I was unaware that you were offering the draft of your book for free. Thanks 
>very much for the link.

You bet. Not the whole book, alas; O'Reilly would kneecap me if I did that. But 
the best chapters, for sure. Plus the code is available for download, including 
*all* the revised code I've done (even from chapters I can't display in 
public), at my github repository.

>Your use of the Music app as an example of view controller presentation 
>puzzles me, though. In my app, I was trying to use the 
>definesPresentationContext property to cause a "push" transition to affect 
>just a view inside a tab bar item inside a navigation controller. Instead, no 
>matter what I tried, the entire root view controller (the navigation 
>controller) was always replaced. Is this because I was on the iPhone?

Yes.

> Your book seems to imply that UIModalPresentationCurrentContext is only 
> meaningful on the iPad since the root view controller is always the 
> presentingViewController.

If the book just "seems to imply" this, I'm writing it wrong! I believe I'm 
jumping up and down and screaming this. Let me know if you think the 
presentation (sorry, bad pun) can be made clearer.

And in fact among the downloadable examples I just mentioned is a project 
that's a universal app constructed in order to demonstrate *exactly* the 
situation you just described. Plus the chapter I pointed you to has the code. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: release sent to deallocated instance under ARC .. how?

2011-12-24 Thread Roland King 
Getter is pretty ordinary

-(id*)delegate
{
return _delegate;
}

So in this case A has a strong reference to B and is B's delegate, fairly 
common pattern. A is now being deallocated and as part of that the delegate 
relationship is being broken, one of two ways, either in A's dealloc it calls [ 
B setDelegate:nil ] or it just waits for B's dealloc which happens as part of 
its own and B cleans up any delegate. In this case A was actually calling it 
explicitly because I prefer things which set things up, to clean them up, I 
like to see the pairing, but either is fine. In the setter, or rather in a 
factored out method called in the setter, I had the 

self.delegate == delegateArg

line. Indeed, as you say, the getter of delegate was causing the current value 
of delegate (which is still A at that point) to be re-retained (not self). 
There was no real good reason to have done that, using _delegate == delegateArg 
is just as good, doesn't call the getter and doesn't retain/autorelease the 
return value and if I hadn't factored the code out into another method, but 
left it in the setter, I would have used the iVar directly for that reason. 

I'm assuming ARC adds the retain/autorelease to stop the return value of the 
getter being released before the caller gets it (section 3.2.3 of the ARC 
spec). 





On Dec 25, 2011, at 2:19 AM, Matt Neuburg wrote:

> On Sat, 24 Dec 2011 13:35:07 +0800, Roland King  said:
> object being dealloced. This line of code 
>> 
>>   return self.delegate == delegateArg
>> 
>> caused self to get a retain/autorelease, resurrecting the object. The change 
>> to use the ivar directly fixed it
> 
> Using the ivar directly is also a way of using self (saying "delegate" is 
> just a way of saying "self->delegate), so it isn't the mention of self that's 
> the problem; it's probably that the delegate property has a custom getter 
> doing some weird stuff. If so, that's a thing to beware of; getting sneaky 
> with accessors is a way to trip oneself up later... I'd examine that getter 
> if I were you. m.
> 
> --
> matt neuburg, phd = m...@tidbits.com, 
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 4!
> http://www.apeth.net/matt/default.html#iosbook

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: release sent to deallocated instance under ARC .. how?

2011-12-24 Thread Roland King 
... and of course the getter is 

-(id)delegate .. no *, writing on my iPhone on the subway, 
can't copy the code from my mac directly. 


> Getter is pretty ordinary
> 
> -(id*)delegate
> {
>   return _delegate;
> }
> 
> So in this case A has a strong reference to B and is B's delegate, fairly 
> common pattern. A is now being deallocated and as part of that the delegate 
> relationship is being broken, one of two ways, either in A's dealloc it calls 
> [ B setDelegate:nil ] or it just waits for B's dealloc which happens as part 
> of its own and B cleans up any delegate. In this case A was actually calling 
> it explicitly because I prefer things which set things up, to clean them up, 
> I like to see the pairing, but either is fine. In the setter, or rather in a 
> factored out method called in the setter, I had the 
> 
>   self.delegate == delegateArg
> 
> line. Indeed, as you say, the getter of delegate was causing the current 
> value of delegate (which is still A at that point) to be re-retained (not 
> self). There was no real good reason to have done that, using _delegate == 
> delegateArg is just as good, doesn't call the getter and doesn't 
> retain/autorelease the return value and if I hadn't factored the code out 
> into another method, but left it in the setter, I would have used the iVar 
> directly for that reason. 
> 
> I'm assuming ARC adds the retain/autorelease to stop the return value of the 
> getter being released before the caller gets it (section 3.2.3 of the ARC 
> spec). 
> 
> 
> 
> 
> 
> On Dec 25, 2011, at 2:19 AM, Matt Neuburg wrote:
> 
>> On Sat, 24 Dec 2011 13:35:07 +0800, Roland King  said:
>> object being dealloced. This line of code 
>>> 
>>>  return self.delegate == delegateArg
>>> 
>>> caused self to get a retain/autorelease, resurrecting the object. The 
>>> change to use the ivar directly fixed it
>> 
>> Using the ivar directly is also a way of using self (saying "delegate" is 
>> just a way of saying "self->delegate), so it isn't the mention of self 
>> that's the problem; it's probably that the delegate property has a custom 
>> getter doing some weird stuff. If so, that's a thing to beware of; getting 
>> sneaky with accessors is a way to trip oneself up later... I'd examine that 
>> getter if I were you. m.
>> 
>> --
>> matt neuburg, phd = m...@tidbits.com, 
>> A fool + a tool + an autorelease pool = cool!
>> Programming iOS 4!
>> http://www.apeth.net/matt/default.html#iosbook
> 
> ___
> 
> 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:
> http://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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Core Audio Help

2011-12-24 Thread Ravi Singh 
I have been eagerly waiting for Chris Adamson(sp) book or Core Audio, and my 
Amazon order I think is around 2 years old now. I would look for his site and 
talks at iDev360 and VTM because he is the best resource I found for 
interesting stuff.
On Dec 23, 2011, at 11:14 AM, Phil Hystad wrote:

> I have been reading the Core Audio documentation at the Apple Developer site 
> and I am not sure I know any more today then when I started.  Are there any 
> Core Audio programmers on this list or is there a better spot.
> 
> Basically, I am planning to experiment with various DSP filters on an input 
> audio signal.  So, take in the audio analog signal which then goes through 
> ADC via the hardware then I want the stream of numbers.  Of course, there are 
> a lot of details on the way.
> 
> What I need is help in pointing me in the right direction.  That is, what are 
> the important parts of Core Audio where I need to focus my attention.
> 
> Thanks,
> phil
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/ravisingh7%40me.com
> 
> This email sent to ravisin...@me.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Storyboard SplitViewController example

2011-12-24 Thread Jamie Daniel 
I am very new to Xcode and iPad development. I am trying to do the following:

I have an initial NavigationController and ViewController. I am trying to go 
from a button on the ViewController to a SplitViewController using Storyboards 
but I can't seem to get it to work. Does anyone have an example of how to do 
it? Or an example of how to hand code it?

Thanks,
Jamie
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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