Please, all involved, take this off-list.
This is a list for civil discussion and it’s clear this has passed that.
Scott
[moderator]___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the l
On Apr 28, 2010, at 12:51 AM, Uli Kusterer wrote:
> On 28.04.2010, at 07:50, Charles Srstka wrote:
>> On Apr 28, 2010, at 12:39 AM, Chris Hanson wrote:
>>
>>> Since NSViewController was introduced in 10.5, I would generally assume any
>>> Cocoa nibs these days should have a subclass of one of th
On 28.04.2010, at 07:50, Charles Srstka wrote:
> On Apr 28, 2010, at 12:39 AM, Chris Hanson wrote:
>
>> Since NSViewController was introduced in 10.5, I would generally assume any
>> Cocoa nibs these days should have a subclass of one of those two classes (or
>> NSApplication, in the case of the
On Apr 28, 2010, at 12:39 AM, Chris Hanson wrote:
> Since NSViewController was introduced in 10.5, I would generally assume any
> Cocoa nibs these days should have a subclass of one of those two classes (or
> NSApplication, in the case of the main nib file) as its File’s Owner.
What about NSDoc
On Apr 27, 2010, at 3:27 PM, Shawn Erickson wrote:
> On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
> wrote:
>
>> For example, bindings were notorious for causing retain circles when you
>> bound to File's Owner in a NIB, and that was fixed in 10.5, IIRC.
>
> Fairly sure it is still an issue un
On 28.04.2010, at 00:27, Shawn Erickson wrote:
> On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
> wrote:
>> For example, bindings were notorious for causing retain circles when you
>> bound to File's Owner in a NIB, and that was fixed in 10.5, IIRC.
>
> Fairly sure it is still an issue unless you
On Apr 27, 2010, at 3:49 PM, Bill Appleton wrote:
> if i add a submenu to an item then it is retained by the menu
>
> but then if i then set that submenu to nil is it still retained?
>
> if retained count was accurate you could test it on final release, etc
Well, the direct answer is no, since
Bill Appleton wrote:
3) when i set the menus i have created for NSApp using setMainMenu
then...
what? who owns them? how do i set more menus for NSApp? how do i
get NSApp
to release the current set?
You are not responsible for NSApplication's retention or release of
menus. It alone is
On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
wrote:
>For example, bindings were notorious for causing retain circles when you bound
>to File's Owner in a NIB, and that was fixed in 10.5, IIRC.
Fairly sure it is still an issue unless you are using a
NSWindowController subclass as the File's Own
On 27.04.2010, at 22:49, Bill Appleton wrote:
> an object should be able to return this info
>
> and it isn't simple, it gets convoluted in process
Let me exaggerate for a paragraph to hopefully bring across a point:
The main objective of Cocoa's design is not to produce the most efficient cod
On Apr 27, 2010, at 3:05 PM, Uli Kusterer wrote:
> On 27.04.2010, at 23:22, Gary L. Wade wrote:
>> Calling -retainCount
>> immediately before and after the -setDelegate call is pretty much the only
>> way.
>
> Nope. It'll only lead to pain and suffering. And false positives. What if
> setDelegat
Can you guys maybe agree that you disagree and put it to rest?
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin
http://nemesys.dyndns.org
Logiciels Nemesys Software
laurent.daude...@gmail.com
Photo Gallery
On Tue, Apr 27, 2010 at 2:56 PM, Gary L. Wade
wrote:
> On 04/27/2010 2:46 PM, "Shawn Erickson" wrote:
>
> [ removed lots of bad assumptions by Shawn ]
>
> Shawn, it is apparent your understanding of reality is flawed when it comes
> to my efforts to track down the bug in Apple's code, so please g
On 27.04.2010, at 23:22, Gary L. Wade wrote:
> Calling -retainCount
> immediately before and after the -setDelegate call is pretty much the only
> way.
Nope. It'll only lead to pain and suffering. And false positives. What if
setDelegate was implemented thus:
-(void) setDelegate: (id)dele
{
On 04/27/2010 2:46 PM, "Shawn Erickson" wrote:
[ removed lots of bad assumptions by Shawn ]
Shawn, it is apparent your understanding of reality is flawed when it comes
to my efforts to track down the bug in Apple's code, so please go away.
This thread is over.
_
On Tue, Apr 27, 2010 at 2:32 PM, Gary L. Wade
wrote:
> On 04/27/2010 2:27 PM, "Shawn Erickson" wrote:
>
>> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
>> wrote:
>>
>>> Yes, but how would you use those to determine why an Apple framework now
>>> chooses to retain a delegate (I'm referring to on
On Apr 27, 2010, at 2:49 PM, Bill Appleton wrote:
> and it isn't simple, it gets convoluted in process
It is simple. It is very, very simple. You're over-thinking it.
You are responsible for your references to the submenu. The menu is responsible
for managing its references to its submenus. You
On 04/27/2010 2:27 PM, "Shawn Erickson" wrote:
> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
> wrote:
>
>> Yes, but how would you use those to determine why an Apple framework now
>> chooses to retain a delegate (I'm referring to one particular one I
>> discovered), thereby causing a retain c
ObjectAlloc instrument is your friend. Configure it to record retains
and releases. Much more accurate, much easier to understand what's
going on.
On Tuesday, April 27, 2010, Gary L. Wade wrote:
> On 04/27/2010 2:12 PM, "Bill Bumgarner" wrote:
>
>>
>> On Apr 27, 2010, at 2:09 PM, Gary L. Wade wr
On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
wrote:
> Yes, but how would you use those to determine why an Apple framework now
> chooses to retain a delegate (I'm referring to one particular one I
> discovered), thereby causing a retain cycle? It's not a memory leak in the
> sense that Instrume
On 27.04.2010, at 17:28, Bill Appleton wrote:
> 1) after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it
Depends on how you create the item. If you create them in a way that you have
On Tue, Apr 27, 2010 at 11:12 PM, Bill Bumgarner wrote:
>
> The combination of leaks, zombies, heap, and malloc stack logging are much
> *much* more powerful and effective than trying to debug a leak, over-retain
> or under-retain with -retainCount.
>
> b.bum
Hear, hear. I haven't called retai
On 04/27/2010 2:12 PM, "Bill Bumgarner" wrote:
>
> On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
>
>> On 04/27/2010 1:58 PM, "Bill Bumgarner" wrote:
>>
>>> Frankly, the -retainCount method should be deprecated and, eventually,
>>> removed.
>>
>> I wouldn't go THAT far; after all, when you
On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
> On 04/27/2010 1:58 PM, "Bill Bumgarner" wrote:
>
>> Frankly, the -retainCount method should be deprecated and, eventually,
>> removed.
>
> I wouldn't go THAT far; after all, when you're tracking a memory leak,
> checking your influence on the
On 04/27/2010 1:58 PM, "Bill Bumgarner" wrote:
> Frankly, the -retainCount method should be deprecated and, eventually,
> removed.
I wouldn't go THAT far; after all, when you're tracking a memory leak,
checking your influence on the retain count is important to your
investigation. Hopefully tha
On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
wrote:
>>> Over the years, I think that looking at the retain count is the #1 cause
> of hairpulling on this list.
>
>
> it's too bad this is unreliable
>
> an object should be able to return this info
>
> and it isn't simple, it gets convoluted in pr
On Apr 27, 2010, at 1:49 PM, Bill Appleton wrote:
> it's too bad this is unreliable
>
> an object should be able to return this info
An object does return this info, the problem is that the # is a meaningless
internal implementation detail of the Cocoa frameworks.
For example, if you create a
On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
wrote:
>>> Over the years, I think that looking at the retain count is the #1 cause
> of hairpulling on this list.
>
>
> it's too bad this is unreliable
>
> an object should be able to return this info
Why? It serves you no purpose. Once you hand an
>> Over the years, I think that looking at the retain count is the #1 cause
of hairpulling on this list.
it's too bad this is unreliable
an object should be able to return this info
and it isn't simple, it gets convoluted in process
if i add a submenu to an item then it is retained by the menu
On Apr 27, 2010, at 1:57 PM, Jens Alfke wrote:
> That sounds like an optimization in the runtime to avoid a couple of
> message-sends. You shouldn't override -retain or -release or make assumptions
> about how many times they're called; those are implementation details.
Actually, you can overri
On Apr 27, 2010, at 1:38 PM, vincent habchi wrote:
> Because earlier in this afternoon I decided to trace the retain/release
> messages sent to an object by overriding the respective methods and have them
> write the retain count before calling super methods. I registered most
> curious behavi
Le 27 avr. 2010 à 21:57, Jens Alfke a écrit :
>> I registered most curious behaviors, for example objects released while the
>> last time their retain count was printed it was equal to 2. No 1, no 0.
>> That's why I asked, just to know if autorelease does not short-circuit the
>> traditional re
On Apr 27, 2010, at 12:38 PM, vincent habchi wrote:
I registered most curious behaviors, for example objects released
while the last time their retain count was printed it was equal to
2. No 1, no 0. That's why I asked, just to know if autorelease does
not short-circuit the traditional rel
On Apr 27, 2010, at 3:38 PM, vincent habchi wrote:
> Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :
>
>>> By the way, how are exactly multiple calls to [object autorelease] handled
>>> by the pool? Does this give rise to as many calls to release: as they are
>>> autorelease references stored, o
Le 27 avr. 2010 à 21:17, Jens Alfke a écrit :
> Remember that in a ref-counted (or GC'd) system you can't force an object to
> deallocate (even 'self'.) The deallocation is under control of all the other
> objects that have references, and the runtime itself. So you should never put
> any code
On 27 Apr 2010, at 21:38, vincent habchi wrote:
Because earlier in this afternoon I decided to trace the retain/
release messages sent to an object by overriding the respective
methods and have them write the retain count before calling super
methods. I registered most curious behaviors, fo
Le 27 avr. 2010 à 21:21, Scott Ribe a écrit :
>> By the way, how are exactly multiple calls to [object autorelease] handled
>> by the pool? Does this give rise to as many calls to release: as they are
>> autorelease references stored, or does the pool directly adjust the retain
>> count?
>
> W
On Apr 27, 2010, at 12:58 PM, vincent habchi wrote:
> Yet, at the same time, you may want the dealloc: method to trigger some
> events. For example, if you have a CALayer that holds various sublayers, and
> that CALayer goes away, you may want all the sublayers to go away at the same
> time. Y
On Apr 27, 2010, at 11:58 AM, vincent habchi wrote:
Yet, at the same time, you may want the dealloc: method to trigger
some events. For example, if you have a CALayer that holds various
sublayers, and that CALayer goes away, you may want all the
sublayers to go away at the same time. Yet,
Le 27 avr. 2010 à 20:42, Jens Alfke a écrit :
> What you "own" are references. If you call a method that creates a reference,
> like +alloc, -retain or -copy, then you now own a reference to that object.
> For as long as you own that reference, the object will stay around. When you
> don't need
On Apr 27, 2010, at 8:28 AM, Bill Appleton wrote:
1) after i append an item i have created to a menu i have created,
and i
don't want to own the menu item any more, i should release the item
so that
the menu owns it
Don't think of who "owns" an object. The memory model doesn't work
that
On Apr 27, 2010, at 9:28 AM, Bill Appleton wrote:
> after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it
Probably not, but it depends on how you created it. If you created it with a
On 27 Apr 2010, at 10:28 AM, Bill Appleton wrote:
> 1) after i append an item i have created to a menu i have created, and i
> don't want to own the menu item any more, i should release the item so that
> the menu owns it
>
> 2) when i add a submenu i have created to a menu i have created, and i
hi all,
i have read the memory rules a few times now, so does this sound right?
1) after i append an item i have created to a menu i have created, and i
don't want to own the menu item any more, i should release the item so that
the menu owns it
2) when i add a submenu i have created to a menu i
Bill, you need to learn about the concept of object ownership within Cocoa.
Ownership is the model for memory management, retain count merely an
implementation detail which can tell you nothing useful.
Menus own their submenus, so if you delete a menu with submenus, you don't need
to also delet
On Apr 27, 2010, at 7:46 AM, Bill Appleton wrote:
> i like to create some menus, set them as the main menu bar, then maybe
> delete them, and create some more menus, use them, etc.
>
> but i can't find any way to do this with cocoa
>
> here is the problem
>
> when you add a submenu (setSubMenu:
hi all,
i like to create some menus, set them as the main menu bar, then maybe
delete them, and create some more menus, use them, etc.
but i can't find any way to do this with cocoa
here is the problem
when you add a submenu (setSubMenu:forItem) the retain count on the submenu
goes up by one
b
47 matches
Mail list logo
