On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
> Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in
> horror.
>
> First, NSNotificationCenter is a singleton. If you subclass it, you now must
> have two notification centers.
It has the facility to have different Cent
On 12/09/2013, at 10:31 PM, Bill Cheeseman wrote:
> The Advanced Memory Management Programming Guide I cited earlier says this
> about the Cocoa ownership rules, which I can't reconcile with your assertion
> that getters always leave the caller with no responsibility for ownership of
> the re
On 12 Sep 2013, at 09:54, Graham Cox wrote:
>
> On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
>
>> I think the best way for what you're trying to do is to subclass
>> NSNotificationCenter (or at least provide your own framework-wide singleton
>> that quacks like it), wrap -postNotificati
On Sep 12, 2013, at 9:52 AM, Graham Cox wrote:
>> At it's core, that's what is really "odd" about the code. It uses a getter
>> that does not comply with the getter convention.
>
> I believe it does. I think your reading of the getter convention may be
> incorrect. If you can point to explicit
Right, sorry, threw it together too quickly and have been living too long in
the land of ARC. Correcting the setter, fixing the dealloc method and removing
the "newObject" method (see below):
@interface MWObject : NSObject
@property (nonatomic, strong) NSObject* object;
@end
@implementation MWO
On Thu, Sep 12, 2013, at 02:35 AM, Graham Cox wrote:
> Here's some code for which the Analyser reports "potential leak of an
> object stored into 'eventTypes'". I don't see it.
>
> I didn't write this code, so I'm reluctant to change it even though I
> would have written it a bit differently. mEve
I've been trying to reproduce this problem, but haven't been able to get the
warning on a minimal example. However, I noticed something unusual trying to
build a minimal example to play with. Here's a stripped down example (Xcode
4.6.3):
#import
@interface MWObject : NSObject
@property (nonat
On 12/09/2013, at 5:00 PM, Bill Cheeseman wrote:
> Fix the name and the Analyzer is happy. No need to change the code, because
> the code is correct
Except that 'fixing' the name would make the code incorrect, because then it
isn't a valid getter name.
If you did go ahead and name it thus, t
Hey guys,
I'm really confused with the array controller and core data. I don't know what
I have to use to get what I want.
My program has for now a CollectionView which is populated by a core data fetch
request.
If I use an arrayController, I don't have to make this fetch do I? I can tell
the
On Sep 12, 2013, at 9:16 AM, Roland King wrote:
> setEventTypes: takes a parameter and returns nothing. What it does with that
> parameter is entirely up to it, it may retain it if it wishes to be released
> later, or do any other thing it wants. If the analyser doesn't much like what
> setEv
On Sep 10, 2013, at 3:19 PM, Fábio Bernardo wrote:
> Most OSX code works on 32 as well as 64bits. I can't say the same for some
> opensource (Linux) frameworks. And will enlarge the binary size, in my
> opinion, without any gains.
Not anymore, really; the advent of features such as ARC, the no
On 12/09/2013, at 3:22 PM, Joseph Ayers wrote:
> When you click on a tab in a NSTabView, what action gets sent to what target?
> Where can I find this information?
I don't think actions or targets are involved. The NSTabViewItem clickable
button row appears to be privately managed and operate
On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
> On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>>
>> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>>
>>> Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
>>> in horror.
>>>
>>> First, NSNotificationCenter is a singleto
On Sep 12, 2013, at 3:02 PM, Lee Ann Rucker wrote:
>
> On Sep 12, 2013, at 2:52 PM, Aaron Montgomery wrote:
>>
>> I think it is either
>> _protoCell = [[Cell alloc] init];
>> or
>> self.protoCell = [[Cell alloc] init];
>
> These aren't equivalent unless the @property is assign, which usually
On Sep 12, 2013, at 2:52 PM, Aaron Montgomery wrote:
>
> I think it is either
> _protoCell = [[Cell alloc] init];
> or
> self.protoCell = [[Cell alloc] init];
These aren't equivalent unless the @property is assign, which usually is not
what you want for object instvars that you intend to own.
Hi Dave,
With all the top coders getting fired-up/tangled up over this thread,
I'm thinking we should get a better idea of the original situation
you are dealing with.
You talked in terms of when the object comes back 'alive'
obviously the same programmatic object doesn't come back ali
On Sep 12, 2013, at 1:45 PM, Lee Ann Rucker wrote:
> On Sep 12, 2013, at 9:57 AM, Bill Cheeseman wrote:
>> As I recall, it stated that the "return [[x retain] autorelease]" pattern is
>> preferred for getters and gave many reasons for preferring it.
>
> Coincidentally enough, we've just hit a c
Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in
horror.
First, NSNotificationCenter is a singleton. If you subclass it, you now must
have two notification centers. Which one is the right one to subscribe to? Do
you only move notifications over to it that need to be
On Sep 12, 2013, at 11:52 AM, Graham Cox wrote:
>> At it's core, that's what is really "odd" about the code. It uses a getter
>> that does not comply with the getter convention.
>
> I believe it does. I think your reading of the getter convention may be
> incorrect. If you can point to explic
On 11 Sep 2013, at 16:33, Etienne Samson wrote:
> Hi !
>
> I think the best way for what you're trying to do is to subclass
> NSNotificationCenter (or at least provide your own framework-wide singleton
> that quacks like it), wrap -postNotification: with some dictionary-munging
> code that k
On Sep 12, 2013, at 9:11 AM, Benjamin Rindt wrote:
> I'm really confused with the array controller and core data. I don't know
> what I have to use to get what I want.
> My program has for now a CollectionView which is populated by a core data
> fetch request.
>
> If I use an arrayController, I
On 12/09/2013, at 5:25 PM, Joseph Ayers wrote:
> -(void) awakeFromNib
> {
> [self setDelegate:self];
>
> }
>
More obvious problem, should this be [myTabView setDelegate:self]; ?
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
On 12/09/2013, at 5:40 PM, Bill Cheeseman wrote:
> But -eventTypes is not in fact a valid getter because it returns the iVar
> retained but not autoreleased.
How is it not valid?
A simple version of it would be:
- (id) eventTypes
{
return mEventTypes;
}
which is perfectly valid. The r
On 2013-09-12 17:00, Bill Cheeseman wrote:
-eventTypes: is, in fact, a classic "new" method, though a bit oddly
written. All in the one method (by calls to utility methods), it
creates a new object with a refcount of 1 by calling +alloc
indirectly, increases its refcount by 1 more by calling
-set
On 12/09/2013, at 5:35 PM, Graham Cox wrote:
> The NSTabViewItem is NOT the same object as the view it hosts, so your
> conditionals will always return false. [NSTabViewItem view] is the object
> you're looking for.
>
> That said, the rest of your code (which is rather difficult to read) does
On 12/09/2013, at 5:27 PM, Steve Mills wrote:
> It might be that setObject: is not safe if object is the same as _object. The
> correct way to do this is:
>
> [object retain];
> [_object release];
> _object = object;
Yep, though in the original code a test for equality brackets the assignmen
Hi,
My app runs in status bar from where I can bring about its window and quit from
the menu as well.
The following msg is logged in Xcode console (when doing [NSApp
terminate:self],):
[25025:303] *** Assertion failure in -[NSApplication
_commonBeginModalSessionForWindow:relativeToWindow:moda
In your dealloc, you should release ivars before calling super dealloc. Ideally
a crash will tell you that quickly; otherwise things could be very bad.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/
___
Cocoa-dev mailing list (Cocoa-de
On Sep 12, 2013, at 10:19:22, Aaron Montgomery wrote:
> - (void)setObject:(NSObject *)object
> {
> [_object release];
> _object = [object retain];//3
> }
It might be that setObject: is not safe if object is the same as _object. The
correct way to do this is:
[object retain];
[_obje
I really don't get why people are freaking out about this. Apple is
continually evolving its OS architecture. That's a good thing.
This isn't about Apple only meeting today's needs. This is about Apple
preparing to meet tomorrow's needs.
I believe we'll start to see a new crop of apps that will
Hi Peter-
For the declared property "protoCell", automatic synthesis is going to make an
instance variable named "_protoCell". You can then refer to it in an instance
method as either:
1. _protoCell - direct ivar access.
2. self.protoCell - access through the getter.
The reference to protoC
Hi,
Something that may be confusing people is that although
LTWCachedNotificationCenter is defined as Sublass of NSNotificationCenter, it
does NOT allocate itself as an object and it does not call Super, instead it
calls [NSNotificationCenter defaultCenter] as in:
- (void)postNotificationName:
On Sep 12, 2013, at 2:45 PM, Peter Teeson wrote:
> Xcode 4.6.2 Lion 10.7.5
> Programming with Objective-C seems to indicate I can do this:
> #import
> #import "Cell.h" //My sub-class
>
> @interface Document : NSDocument
> @property Cell *protoCell;
> @end
>
> and this (i.e. no need to @synt
Note: this was just added 2 years ago. So it is relatively a recent change.
Yes, most java developers in the enterprise are still using Java 6 or earlier.
Sent from my iPad
On Sep 11, 2013, at 2:44 AM, Jean-Daniel Dupas wrote:
> This is the contrary. In Obj-c all pointers are effectively doub
On Sep 12, 2013, at 2:45 PM, Peter Teeson wrote:
> What is my lack of understanding? Why am I not allowed to use the getter
> protoCell as indicated in the documentation?
Autosynthesis back @property foo with ivar _foo. Thats why using the underscore
works. This is explicitly different from
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>
> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>
> > Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
> > in horror.
> >
> > First, NSNotificationCenter is a singleton. If you subclass it, you now
> > must have two not
Xcode 4.6.2 Lion 10.7.5
Programming with Objective-C seems to indicate I can do this:
#import
#import "Cell.h" //My sub-class
@interface Document : NSDocument
@property Cell *protoCell;
@end
and this (i.e. no need to @synthesize):
@implementation Document
- (id)init
{
self = [super init];
On 12/09/2013, at 6:57 PM, Bill Cheeseman wrote:
I appreciate your taking an interest Bill, it's always interesting to get a
range of views. But:
> The point remains, however, that the getter that started this thread returned
> an object retained, and the caller therefore owns it and is respo
Le 12 sept. 2013 à 20:11, Dave a écrit :
> On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
>
>> On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>>>
>>> On 12 Sep 2013, at 17:58, Kyle Sluder wrote:
>>>
Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
in horror
Hi Bill,
On Sep 12, 2013, at 18:57 , Bill Cheeseman wrote:
> As I recall, [Ali’s technote] stated that the "return [[x retain]
> autorelease]" pattern is preferred for getters and gave many reasons for
> preferring it. I understand that @synchronize generates getters that comply
> with this p
That got the delegate proc working.
Onward and thanks,
Joseph
On Sep 12, 2013, at 11:54 AM, Graham Cox wrote:
>
> On 12/09/2013, at 5:25 PM, Joseph Ayers wrote:
>
>> -(void) awakeFromNib
>> {
>> [self setDelegate:self];
>>
>> }
>>
>
>
> More obvious problem, should this be [myTabVie
On Sep 12, 2013, at 1:41 PM, Graham Cox wrote:
> On 12/09/2013, at 6:57 PM, Bill Cheeseman wrote:
>
>
>
>> The point remains, however, that the getter that started this thread
>> returned an object retained, and the caller therefore owns it and is
>> responsible for releasing it.
>
>
On 12 Sep 2013, at 18:15, Daniel Höpfl wrote:
> On 2013-09-12 17:52, Graham Cox wrote:
>> I believe it does. I think your reading of the getter convention may
>> be incorrect. If you can point to explicit documentation that states
>> that the returned object must belong to an autorelease pool, I
On Sep 12, 2013, at 1:49 PM, Greg Parker wrote:
> On Sep 12, 2013, at 1:45 PM, Lee Ann Rucker wrote:
>> On Sep 12, 2013, at 9:57 AM, Bill Cheeseman wrote:
>>> As I recall, it stated that the "return [[x retain] autorelease]" pattern
>>> is preferred for getters and gave many reasons for preferr
On Sep 12, 2013, at 9:57 AM, Bill Cheeseman wrote:
> As I recall, it stated that the "return [[x retain] autorelease]" pattern is
> preferred for getters and gave many reasons for preferring it.
Coincidentally enough, we've just hit a case where that's bad - it's a
complicated situation with
On 12 Sep 2013, at 20:24, Etienne Samson wrote:
>
> That's not true : you won't get notifications sent by the Cocoa framework,
> because it will use `[NSNotificationCenter defaultCenter]` and you have
> (obviously) no way to change the sender.
>
> I feel like I'm playing the devil's advocate
On 12 Sep 2013, at 18:45, Kyle Sluder wrote:
>>
>> No, just at the receiver, the sender need do nothing, in fact its
>> unchanged.
>
> How? You need to update the sender to send to the correct notification
> center.
Sorry, I mis-read this, I see what you mean now, I might have had to change
On 12/09/2013, at 5:25 PM, Joseph Ayers wrote:
> I created a delegate procedure in the window controller
>
> - (void)tabView:(NSTabView *)tabView didSelectTabViewItem:(NSTabViewItem
> *)tabViewItem
> {
> AppDelegate *appDelegate = [NSApp delegate];
> if (tabViewItem == [[appDelegate gr
On Sep 12, 2013, at 9:17 AM, Graham Cox wrote:
>
> On 12/09/2013, at 6:07 PM, Kyle Sluder wrote:
>
>> Personally, I would avoid doing this, as it could cause reentrancy among
>> KVO observers of eventTypes. Instead, I'd assign to mEventTypes directly
>> from your lazy initializer. Or perhaps
On 11 Sep 2013, at 15:11, dangerwillrobinsondan...@gmail.com wrote:
>
> On Sep 11, 2013, at 10:52 PM, Dave wrote:
>
>>
>> On 11 Sep 2013, at 14:22, Graham Cox wrote:
>>
>>>
>>> On 11/09/2013, at 3:13 PM, Dave wrote:
>>>
Yes, but it doesn't remember the last value of a notification,
On Sep 12, 2013, at 11:11 AM, Graham Cox wrote:
> On 12/09/2013, at 5:00 PM, Bill Cheeseman wrote:
>
>> Fix the name and the Analyzer is happy. No need to change the code, because
>> the code is correct
>
> Except that 'fixing' the name would make the code incorrect, because then it
> isn't
Is there any reference on the methods used for how the analyzer does its leak
detection/identification? If we had access to that, it should be really easy
to pinpoint why the code is causing that error.
Cheers.
On Sep 12, 2013, at 9:57 AM, Graham Cox wrote:
>
> On 12/09/2013, at 3:16 PM, Rol
On 12 Sep 2013, at 4:35 AM, Graham Cox wrote:
> Here's some code for which the Analyser reports "potential leak of an object
> stored into 'eventTypes'". I don't see it.
>
> I didn't write this code, so I'm reluctant to change it even though I would
> have written it a bit differently. mEventT
On 2013 Sep 12, at 06:22, Joseph Ayers wrote:
> When you click on a tab in a NSTabView, what action gets sent to what target?
> Where can I find this information?
If I recall correctly, and, presuming that you looked for some time before
posting your question, I think that it's all under the h
On 12 Sep 2013, at 14:22, Joseph Ayers wrote:
> When you click on a tab in a NSTabView, what action gets sent to what target?
> Where can I find this information?
NSTabView is not a subclass of NSControl so it has no target or action.
Instead, its delegate is informed of changes in tab.
On Sep 10, 2013, at 2:19 PM, Fábio Bernardo wrote:
> without any gains
Unless, of course, you discuss apps that actually need it ;-)
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
___
Cocoa-dev maili
On 12/09/2013, at 3:16 PM, Roland King wrote:
> Which leads to one question, there isn't another in-scope variable called
> eventTypes is there? Static, another iVar, from a superclass, synthethized in
> some way .. something? If there were then that might explain the confusion
> (which event
When you click on a tab in a NSTabView, what action gets sent to what target?
Where can I find this information?
Thanks,
Joseph
Joseph Ayers, Professor
Departments of Marine and Environmental Science
Biology, Civil and Environmental Engineering
and Marine Science Center
Northeastern University
E
Creative but no I don't think so.
For a start that's not what the error says, if it cared less what the property
setter setEventTypes: did then it would point out that increased the refcount
by 1, the release decremented it by 1 and thus there was a net +1 in there. It
doesn't do that, it does
On 12/09/2013, at 1:59 PM, Bill Cheeseman wrote:
> In my understanding, Analyze is meant to be very literal, even simple-minded.
> Your method returns a retained object but you did not put "new" or "copy" in
> the method name. It assumes that you were following the naming convention and
> tha
I neglected to send this to the list. It's important enough that I think I
should.
Bill Cheeseman
Begin forwarded message:
> From: Bill Cheeseman
> Subject: Re: Analyser reports memory leak… where?
> Date: September 12, 2013 6:34:05 AM EDT
> To: Graham Cox
>
> The -eventTypes method sends th
In my understanding, Analyze is meant to be very literal, even simple-minded.
Your method returns a retained object but you did not put "new" or "copy" in
the method name. It assumes that you were following the naming convention and
that your omission of "new" or "copy" was intentional. It there
On 12 Sep, 2013, at 7:07 pm, Graham Cox wrote:
>
> On 12/09/2013, at 12:56 PM, Roland King wrote:
>
>> That's not even what the error message is saying, it's trying to tell you,
>> as you summarized earlier, that the temporary variable you are assigning to
>> and properly releasing is being
On 12/09/2013, at 12:56 PM, Roland King wrote:
> That's not even what the error message is saying, it's trying to tell you, as
> you summarized earlier, that the temporary variable you are assigning to and
> properly releasing is being called out as a leak, it's not complaining about
> the iv
That's not even what the error message is saying, it's trying to tell you, as
you summarized earlier, that the temporary variable you are assigning to and
properly releasing is being called out as a leak, it's not complaining about
the ivar.
On 12 Sep, 2013, at 6:52 pm, Graham Cox wrote:
>
On 12/09/2013, at 12:34 PM, Bill Cheeseman wrote:
> The retain count is still +1 at the point where the error is reported.
But shouldn't it take into account that it was assigned to an ivar that is
retained until -dealloc? Or is it trying to tell me that it will leak if the
enclosing object
On 12/09/2013, at 12:20 PM, Simone Tellini wrote:
> s there a [mEventTypes release] in -dealloc?
Yes there is.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Con
I hate it when Thunderbird manages to throw away the content of the mails I
send to the list! Let's try again...
Il giorno 12/set/2013, alle ore 11:35, Graham Cox ha
scritto:
> Here's some code for which the Analyser reports "potential leak of an object
> stored into 'eventTypes'". I don't se
___
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.co
On 12 Sep, 2013, at 5:50 pm, Graham Cox wrote:
>
> On 12/09/2013, at 11:43 AM, Roland King wrote:
>
>> I don't see it either, if you click on the error doesn't it give you a
>> diagram with arrows telling you how it arrives at that conclusion?
>
>
> Yes, but that doesn't make sense either
On 12/09/2013, at 11:43 AM, Roland King wrote:
> I don't see it either, if you click on the error doesn't it give you a
> diagram with arrows telling you how it arrives at that conclusion?
Yes, but that doesn't make sense either. Here's a screen shot from Xcode:
http://apptree.net/images/le
I don't see it either, if you click on the error doesn't it give you a diagram
with arrows telling you how it arrives at that conclusion?
On 12 Sep, 2013, at 5:35 pm, Graham Cox wrote:
> Here's some code for which the Analyser reports "potential leak of an object
> stored into 'eventTypes'".
Here's some code for which the Analyser reports "potential leak of an object
stored into 'eventTypes'". I don't see it.
I didn't write this code, so I'm reluctant to change it even though I would
have written it a bit differently. mEventTypes is an ivar.
- (void)setEventTypes:(NSDictionary*)eve
On 12/09/2013, at 11:17 AM, Etienne Samson wrote:
> If there's 26 different objects that need that "cache" capacity, that's 26
> class methods
So just make a tiny class for the sole purpose of storing the latest data
state. All 26 different sender classes can then use it - since it only stor
Le 12 sept. 2013 à 10:54, Graham Cox a écrit :
> On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
>
>> I think the best way for what you're trying to do is to subclass
>> NSNotificationCenter (or at least provide your own framework-wide singleton
>> that quacks like it), wrap -postNotificatio
On 11/09/2013, at 5:33 PM, Etienne Samson wrote:
> I think the best way for what you're trying to do is to subclass
> NSNotificationCenter (or at least provide your own framework-wide singleton
> that quacks like it), wrap -postNotification: with some dictionary-munging
> code that keeps trac
On 11 Sep 2013, at 19:59, Louis Gerbarg wrote:
>
> The world is a very different place than it was then, in the 80s RAM was a
> lot faster relative to the CPU. There is absolutely no way something like you
> describe today could be done today, most deeply pipelined OoOE CPUs can
> barely for
Hi !
I think the best way for what you're trying to do is to subclass
NSNotificationCenter (or at least provide your own framework-wide singleton
that quacks like it), wrap -postNotification: with some dictionary-munging code
that keeps tracks of the last notification send by notification name,
Most OSX code works on 32 as well as 64bits. I can't say the same for some
opensource (Linux) frameworks. And will enlarge the binary size, in my opinion,
without any gains.
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 9:11 PM, Sean McBride
wrote:
> On Tue, 10 Sep 2013 20:01:36 +, Abdul S
I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe
wrote:
> Well, since nobody else has commented, let me be the first to say:
> YES! YES! YES! THANK YOU APPLE!!
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-
80 matches
Mail list logo
