On Sep 5, 2009, at 20:37, Roland King wrote:
Following up on this thread from a week ago. Singapore did stop
being sold out of Snow Leopard and I compiled a little test project
under 10.6 to see what happened. Here's what I found.
1) If you recall the original thread, the error message
On 06-Sep-2009, at 2:22 PM, Quincey Morris wrote:
I haven't tried to evaluate the GC side of this under 10.6, but I
can't imagine that the basic rule has (or could be changed) under
GC: that cleanup relating to the relationships between objects needs
to be done prior to entry to
On Sep 6, 2009, at 05:46, Roland King wrote:
The note however says that in order to reduce the amount of
finalizer methods written just to do KVO registration removal, the
runtime now does it for you automatically in 10.6. So if you're
observing something and are collected, the
On 30-Aug-2009, at 5:53 PM, Roland King wrote:
On 30-Aug-2009, at 17:46, Andreas Grosam agro...@onlinehome.de
wrote:
b. The release notes say that it was wrong for this message to
appear when an object observed by a second object was
deallocated, its deallocation caused the
On 30/08/2009, at 7:46 PM, Andreas Grosam wrote:
This is not exactly what I got in the console. Actually it is:
An instance 0xd21b60 of class MyObservee is being deallocated while
key value observers are still registered with it.
Notice: is being deallocated
This is also **exactly**
On 8/29/09 10:28 AM, Quincey Morris said:
The second is that one of the behaviors he doesn't control --
unregistration of observers -- is not permitted during the 'dealloc'
of the observed object, and must be done before that.
Note that the wonderful AnalysisTool can catch this through static
On Aug 30, 2009, at 7:12 AM, Quincey Morris wrote:
On Aug 29, 2009, at 20:43, Roland King wrote:
Here are the release notes on this by the way. I note they only
talk about running in non-GC mode. However in both cases mentioned
an object has unregistered as an observer of an observed
On 30-Aug-2009, at 17:46, Andreas Grosam agro...@onlinehome.de wrote:
b. The release notes say that it was wrong for this message to
appear when an object observed by a second object was deallocated,
its deallocation caused the release of the second object, and the
second object
On Aug 28, 2009, at 5:32 PM, Roland King wrote:
Thank you Roland for your reply.
I think this is one of those unfortunate messages which comes out
before the dealloc method even runs, just entering the dealloc
method with registered observers logs it. It's possible it would be
better if
On Aug 29, 2009, at 2:29 AM, Graham Cox wrote:
Thank you Graham for your reply.
Hi Andreas,
There is a strong code smell here.
How does your observee know who its observers are?
Actually, it does not. My example code is an oversimplification to
show the actual issue. Often, things are
Le 29 août 2009 à 14:08, Andreas Grosam a écrit :
On Aug 29, 2009, at 2:29 AM, Graham Cox wrote:
Thank you Graham for your reply.
Hi Andreas,
There is a strong code smell here.
How does your observee know who its observers are?
Actually, it does not. My example code is an
Well first off you're not really, really doing anything wrong, that
message is in the wrong place (in my opinion), it should only come up
when the NSObject dealloc is called if things haven't been unobserved.
There's a comment in this thread about this having been fixed,
hopefully it is.
On Aug 29, 2009, at 06:00, Roland King wrote:
Well first off you're not really, really doing anything wrong, that
message is in the wrong place (in my opinion), it should only come
up when the NSObject dealloc is called if things haven't been
unobserved. There's a comment in this thread
On Aug 29, 2009, at 7:28 PM, Quincey Morris wrote:
On Aug 29, 2009, at 06:00, Roland King wrote:
Well first off you're not really, really doing anything wrong, that
message is in the wrong place (in my opinion), it should only come
up when the NSObject dealloc is called if things haven't
On Aug 29, 2009, at 12:26, Andreas Grosam wrote:
Just to be clear, the code is running on the iPhone, hence there is
no GC. Secondly, there is no issue with release or retain. If I
invoke release from within a dealloc in order to release a certain
object, I have to do it exactly the same
On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:
On Aug 29, 2009, at 06:00, Roland King wrote:
If I understand what's been said in this thread, Andreas *is* doing
something wrong. He's in good company, though, because the retain/
release mechanism has traditionally allowed many Cocoa
On 30/08/2009, at 12:35 PM, Roland King wrote:
Now this I don't understand. If you enter your dealloc method with
observers registered on yourself and do have a *safe* mechanism of
ensuring they are completely removed before ending the dealloc
routine (or calling [ super dealloc ] ) I
On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:
The second is that one of the behaviors he doesn't control --
unregistration of observers -- is not permitted during the 'dealloc'
of the observed object, and must be done before that. That's what
the log message is trying to say. The bug
On 30-Aug-2009, at 11:24, Graham Cox graham@bigpond.com wrote:
I believe the issue lies in the fact that an object that has KVO
observers registered on it is not the object you think it is. It's
in fact a sort of proxy for the real object that has been swizzled
(you can see
On Aug 29, 2009, at 20:43, Roland King wrote:
Here are the release notes on this by the way. I note they only talk
about running in non-GC mode. However in both cases mentioned an
object has unregistered as an observer of an observed object during
the dealloc of that observed object and
I'm using key-value-observing where an instance of class MyObservee
has been registered for KVO with other objects which observe a value
in a key path (e.g.: @drives.model.port):
The observee itself unregisters all observers in its dealloc method:
@implementation MyObservee
- (void) dealloc
It simply tells you, that if you have removed observation for an
instance of your class MYObservee somewhere in your code, so it can't
remove observation again. I would try remove observation for the
mentioned key path only, just to see if happens with that again.
That's what I read from
I think this is one of those unfortunate messages which comes out
before the dealloc method even runs, just entering the dealloc method
with registered observers logs it. It's possible it would be better if
it was only logged at the point say NSObject dealloc was called, but
it's not, it's
Hi Andreas,
There is a strong code smell here.
How does your observee know who its observers are? Since KVO doesn't
normally provide that knowledge to the observee, you must have
arranged this yourself, possibly going considerably out of your way to
do so. Whenever you find yourself
24 matches
Mail list logo
