I don't get the advantage... What I am missing?
—
Fábio Bernardo
On Tue, Sep 10, 2013 at 8:45 PM, Scott Ribe scott_r...@elevated-dev.com
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
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 s...@rogue-research.com
wrote:
On Tue, 10 Sep 2013
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
On 11 Sep 2013, at 19:59, Louis Gerbarg lgerb...@gmail.com 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
On 11/09/2013, at 5:33 PM, Etienne Samson samson.etie...@gmail.com 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
Le 12 sept. 2013 à 10:54, Graham Cox graham@bigpond.com a écrit :
On 11/09/2013, at 5:33 PM, Etienne Samson samson.etie...@gmail.com 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
On 12/09/2013, at 11:17 AM, Etienne Samson samson.etie...@gmail.com 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
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.
-
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 graham@bigpond.com wrote:
Here's some code for which the Analyser reports potential leak of an object
stored
On 12/09/2013, at 11:43 AM, Roland King r...@rols.org 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:
On 12 Sep, 2013, at 5:50 pm, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 11:43 AM, Roland King r...@rols.org 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
___
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:
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 graham@bigpond.com ha
scritto:
Here's some code for which the Analyser reports potential leak of an object
stored into
On 12/09/2013, at 12:20 PM, Simone Tellini cocoa-...@tellini.info 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
On 12/09/2013, at 12:34 PM, Bill Cheeseman wjcheese...@gmail.com 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
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
On 12/09/2013, at 12:56 PM, Roland King r...@rols.org 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
On 12 Sep, 2013, at 7:07 pm, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 12:56 PM, Roland King r...@rols.org 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
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 therefore
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 wjcheese...@gmail.com
Subject: Re: Analyser reports memory leak… where?
Date: September 12, 2013 6:34:05 AM EDT
To: Graham Cox
On 12/09/2013, at 1:59 PM, Bill Cheeseman wjcheese...@gmail.com 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
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
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
On 12/09/2013, at 3:16 PM, Roland King r...@rols.org 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
On Sep 10, 2013, at 2:19 PM, Fábio Bernardo m...@fbernardo.org 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
On 12 Sep 2013, at 14:22, Joseph Ayers j.ay...@neu.edu 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
On 2013 Sep 12, at 06:22, Joseph Ayers j.ay...@neu.edu 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
On 12 Sep 2013, at 4:35 AM, Graham Cox graham@bigpond.com 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
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,
On Sep 12, 2013, at 11:11 AM, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 5:00 PM, Bill Cheeseman wjcheese...@gmail.com 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
On 11 Sep 2013, at 15:11, dangerwillrobinsondan...@gmail.com wrote:
On Sep 11, 2013, at 10:52 PM, Dave d...@looktowindward.com wrote:
On 11 Sep 2013, at 14:22, Graham Cox graham@bigpond.com wrote:
On 11/09/2013, at 3:13 PM, Dave d...@looktowindward.com wrote:
Yes, but it
On Sep 12, 2013, at 9:17 AM, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 6:07 PM, Kyle Sluder k...@ksluder.com 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
On 12/09/2013, at 5:25 PM, Joseph Ayers j.ay...@neu.edu wrote:
I created a delegate procedure in the window controller
- (void)tabView:(NSTabView *)tabView didSelectTabViewItem:(NSTabViewItem
*)tabViewItem
{
AppDelegate *appDelegate = [NSApp delegate];
if (tabViewItem ==
On 12 Sep 2013, at 18:45, Kyle Sluder k...@ksluder.com 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
On 12 Sep 2013, at 20:24, Etienne Samson samson.etie...@gmail.com 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
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 Sep 12, 2013, at 1:49 PM, Greg Parker wrote:
On Sep 12, 2013, at 1:45 PM, Lee Ann Rucker lruc...@vmware.com 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
On 12 Sep 2013, at 18:15, Daniel Höpfl ap...@hoepfl.de 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
On Sep 12, 2013, at 1:41 PM, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 6:57 PM, Bill Cheeseman wjcheese...@gmail.com wrote:
The point remains, however, that the getter that started this thread
returned an object retained, and the caller therefore owns it and is
That got the delegate proc working.
Onward and thanks,
Joseph
On Sep 12, 2013, at 11:54 AM, Graham Cox graham@bigpond.com wrote:
On 12/09/2013, at 5:25 PM, Joseph Ayers j.ay...@neu.edu wrote:
-(void) awakeFromNib
{
[self setDelegate:self];
}
More obvious problem,
Hi Bill,
On Sep 12, 2013, at 18:57 , Bill Cheeseman wjcheese...@gmail.com 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
Le 12 sept. 2013 à 20:11, Dave d...@looktowindward.com a écrit :
On 12 Sep 2013, at 18:45, Kyle Sluder k...@ksluder.com wrote:
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
On 12 Sep 2013, at 17:58, Kyle Sluder k...@ksluder.com wrote:
Whenever I see a suggestion like “subclass
On 12/09/2013, at 6:57 PM, Bill Cheeseman wjcheese...@gmail.com 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
Xcode 4.6.2 Lion 10.7.5
Programming with Objective-C seems to indicate I can do this:
#import Cocoa/Cocoa.h
#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 =
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
On 12 Sep 2013, at 17:58, Kyle Sluder k...@ksluder.com 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
On Sep 12, 2013, at 2:45 PM, Peter Teeson ptee...@icloud.com 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
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 devli...@shadowlab.org wrote:
This is the contrary. In Obj-c all
On Sep 12, 2013, at 2:45 PM, Peter Teeson ptee...@icloud.com wrote:
Xcode 4.6.2 Lion 10.7.5
Programming with Objective-C seems to indicate I can do this:
#import Cocoa/Cocoa.h
#import Cell.h //My sub-class
@interface Document : NSDocument
@property Cell *protoCell;
@end
and this
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:
-
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 protoCell
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
On Sep 12, 2013, at 10:19:22, Aaron Montgomery eey...@monsterworks.com 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:
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
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
On 12/09/2013, at 5:27 PM, Steve Mills smi...@makemusic.com 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
On 12/09/2013, at 5:35 PM, Graham Cox graham@bigpond.com 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
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
On 12/09/2013, at 5:40 PM, Bill Cheeseman wjcheese...@gmail.com 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
On 12/09/2013, at 5:25 PM, Joseph Ayers j.ay...@neu.edu wrote:
-(void) awakeFromNib
{
[self setDelegate:self];
}
More obvious problem, should this be [myTabView setDelegate:self]; ?
--Graham
___
Cocoa-dev mailing list
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 11 Sep 2013, at 16:33, Etienne Samson samson.etie...@gmail.com 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
On Sep 12, 2013, at 11:52 AM, Graham Cox graham@bigpond.com 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
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
On Sep 12, 2013, at 1:45 PM, Lee Ann Rucker lruc...@vmware.com 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
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
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.
On Sep 12, 2013, at 3:02 PM, Lee Ann Rucker lruc...@vmware.com 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
On 12 Sep 2013, at 18:45, Kyle Sluder k...@ksluder.com wrote:
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
On 12 Sep 2013, at 17:58, Kyle Sluder k...@ksluder.com wrote:
Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil
in horror.
First, NSNotificationCenter
On 12/09/2013, at 3:22 PM, Joseph Ayers j.ay...@neu.edu 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
On Sep 10, 2013, at 3:19 PM, Fábio Bernardo m...@fbernardo.org 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
On Sep 12, 2013, at 9:16 AM, Roland King r...@rols.org 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
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 12/09/2013, at 5:00 PM, Bill Cheeseman wjcheese...@gmail.com 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
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 Foundation/Foundation.h
@interface MWObject :
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.
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
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
77 matches
Mail list logo
