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 those two
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
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
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
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
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
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
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 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
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 the
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,
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. Yet,
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?
Why would
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,
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 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, or does the
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
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 release:
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
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 override
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 Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
billapple...@dreamfactory.com 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
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 an
On Tue, Apr 27, 2010 at 1:49 PM, Bill Appleton
billapple...@dreamfactory.com 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
On 04/27/2010 1:58 PM, Bill Bumgarner b...@mac.com 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.
On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
On 04/27/2010 1:58 PM, Bill Bumgarner b...@mac.com 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
On 04/27/2010 2:12 PM, Bill Bumgarner b...@mac.com wrote:
On Apr 27, 2010, at 2:09 PM, Gary L. Wade wrote:
On 04/27/2010 1:58 PM, Bill Bumgarner b...@mac.com wrote:
Frankly, the -retainCount method should be deprecated and, eventually,
removed.
I wouldn't go THAT far; after all, when
On Tue, Apr 27, 2010 at 11:12 PM, Bill Bumgarner b...@mac.com 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
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
to
On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
garyw...@desisoftsystems.com 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
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 garyw...@desisoftsystems.com wrote:
On 04/27/2010 2:12 PM, Bill Bumgarner b...@mac.com wrote:
On Apr 27,
On 04/27/2010 2:27 PM, Shawn Erickson shaw...@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
garyw...@desisoftsystems.com 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
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.
On Tue, Apr 27, 2010 at 2:32 PM, Gary L. Wade
garyw...@desisoftsystems.com wrote:
On 04/27/2010 2:27 PM, Shawn Erickson shaw...@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
garyw...@desisoftsystems.com wrote:
Yes, but how would you use those to determine why an Apple
On 04/27/2010 2:46 PM, Shawn Erickson shaw...@gmail.com 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 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 Tue, Apr 27, 2010 at 2:56 PM, Gary L. Wade
garyw...@desisoftsystems.com wrote:
On 04/27/2010 2:46 PM, Shawn Erickson shaw...@gmail.com 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
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
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
setDelegate was
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 code
On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
witness.of.teacht...@gmx.net 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
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 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
On 28.04.2010, at 00:27, Shawn Erickson wrote:
On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
witness.of.teacht...@gmx.net 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
On Apr 27, 2010, at 3:27 PM, Shawn Erickson wrote:
On Tue, Apr 27, 2010 at 3:22 PM, Uli Kusterer
witness.of.teacht...@gmx.net 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
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
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 main
47 matches
Mail list logo
