date:20130912


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 can 
 barely forward a register in 1 CPU cycle. Getting out to L3 cache is often on 
 the order of 20-40 cycles depending on the part, and main memory can 
 literally be hundreds of cycles. Algorithms designed to work in an 
 environments with single cycle ram access simply don't hold up on modern 
 pipelined cache coherent multi-process systems where the processing logic 
 runs at significant multiples of the memory.

This is indeed true, but where there's a will there's a way and what we are 
talking about is relatively simple compared to some of the awesome hardware 
already out there. I don't think this is the reason it hasn't been done, I 
think it's more to do with what you'd have to do with the Unix Kernel and 
friends to make it work. It would make a lot of code incompatible which is bad 
news and it would also cost a fortune. 

Besides there are two ways (at least) of doing this, one is super fast and 
would be very difficult/impossible to implement as per your comment above. But 
there is another way that is not so fast, but would still be much faster then 
main CPU doing it and it would also have leak detection. But its not going to 
happen to pointless talking about it.

  If Apple were to implement something like this I think there would be a 
  massive increase in performance and reliability
 
  Nothing personal, but I think you’re falling into the common fallacy of 
  thinking that Apple engineers are naive and/or ignorant. It happens all the 
  time on these lists. In general, you should assume that the people working 
  on system software are pretty damn smart and experienced, and are aware of 
  all the techniques that an interested but non-expert outsider would know 
  of. If they’re not using them, there’s probably a good reason for it.
 
 I'm sure the engineers are a mixture of good, mediocre, and not so good the 
 same as any where else, why should Apple be different? But engineers don't 
 get much say on what projects/features are implemented (especially somewhere 
 like Apple, MS or any of the big 5 technology companies).
 
 If you mean user features then sure, often engineers have little say. If you 
 mean runtime and developer features then you are wrong, the developers at 
 Apple have a lot of say in how what happens. Tim Cook and Phil Schiller 
 didn't sit down in a meeting and say Let's implemented tagged pointers, 
 users will love those, and yet somehow we have them ;-)

This is true too, but only because they sold it to them and it just happened to 
fit in with what they wanted. I'm not saying the engineering department doesn't 
come up with wonderful features but I've seen really cool products dropped at 
Apple and other places simply because it wasn't in the direction the current 
upper management of the company wanted to go at the time and had nothing to do 
with how good or bad the underlying technology was.

Dave




___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 
 code that keeps tracks of the last notification send by notification name, 
 and have -addObserver:… (you'll have to find the one that actually is the 
 designated call, the one all the others expect) check that cache and issue a 
 -postNotification: call for that object only (you don't want to notify all 
 old objects, only the one that just registered).


I'd disagree with this - subclassing something like NSNotificationCenter is a 
sledgehammer to crack a nut, and don't forget about the potential side effects 
where it is used for lots of other unrelated notifications.

Why not just have a class method on the sender of the notification that stores 
the most recent data sent by an instance of that class? Then when a new 
instance of the notification receiver is inited, it can grab the latest data 
from the class method to set itself up? No hacks required.

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

2013-09-12 Thread Etienne Samson

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 quacks like it), wrap -postNotification: with some dictionary-munging 
 code that keeps tracks of the last notification send by notification name, 
 and have -addObserver:… (you'll have to find the one that actually is the 
 designated call, the one all the others expect) check that cache and issue a 
 -postNotification: call for that object only (you don't want to notify all 
 old objects, only the one that just registered).
 
 
 I'd disagree with this - subclassing something like NSNotificationCenter is a 
 sledgehammer to crack a nut, and don't forget about the potential side 
 effects where it is used for lots of other unrelated notifications.
 
 Why not just have a class method on the sender of the notification that 
 stores the most recent data sent by an instance of that class? Then when a 
 new instance of the notification receiver is inited, it can grab the latest 
 data from the class method to set itself up? No hacks required.

If there's 26 different objects that need that cache capacity, that's 26 
class methods — less if they happen to have a common ancestor, but I don't 
think the OP was having one. Also, IMHO that looses the loose coupling that 
exists when using notifications : your new receiver has to know which object(s) 
send which notifications to query for them (and if there are actually more than 
one, you now have to remember which is the latest one).

I might be wrong, but having that cache code centralized in one place with a 
well-known interface also allows the caller to either choose the caching 
notification center or the normal one (provided the caching one manages it's 
own singleton), and the rest of the code can change on-the-fly. If subclassing 
the NSNotificationCenter feels too heavyweight, create a Notification Cache 
object that observes all the wanted notifications in the framework and that the 
objects can call to get the latest value from.

Personally, I'd go the subclass route, because of the code-swappable capacity. 
But you're right that you better debug it well ;-).

Regards,
Etienne Samson
--
samson.etie...@gmail.com

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 - since it only stores 
one thing, it must be the latest, by definition.

It does not make any difference to the loose coupling, you're just substituting 
a different global class for NSNotificationCenter. It does require minor code 
changes to 26 different classes, but that's a small price to pay for 
correctness/simplicity/no side effects over a hack, in my opinion.

--Graham
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Analyser reports memory leak… where?

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*)eventTypes
{
if (eventTypes != mEventTypes)
{
[mEventTypes release];
mEventTypes = [eventTypes retain];
}
InitializePrefsForEventTypeNames();
}

- (NSDictionary*)eventTypes
{
if (mEventTypes == nil)
{
[self loadNib];

NSDictionary* eventTypes = [self newEventTypes];
[self setEventTypes:eventTypes];
[eventTypes release];
}

return mEventTypes; //- analyser complains here
}



- (NSDictionary*)newEventTypes
{
//[code deleted that presets contents of 'eventTypes']

// Method name begins with new; clients are responsible for releasing.
return [[NSDictionary alloc] initWithDictionary:eventTypes];
}



--Graham
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 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*)eventTypes
 {
   if (eventTypes != mEventTypes)
   {
   [mEventTypes release];
   mEventTypes = [eventTypes retain];
   }
   InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
   if (mEventTypes == nil)
   {
   [self loadNib];
   
   NSDictionary* eventTypes = [self newEventTypes];
   [self setEventTypes:eventTypes];
   [eventTypes release];
   }
   
   return mEventTypes; //- analyser complains here
 }
 
 
 
 - (NSDictionary*)newEventTypes
 {
   //[code deleted that presets contents of 'eventTypes']
 
   // Method name begins with new; clients are responsible for releasing.
   return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }
 
 
 
 --Graham
 ___
 
 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.com/mailman/options/cocoa-dev/rols%40rols.org
 
 This email sent to r...@rols.org

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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: 
http://apptree.net/images/leak.png

It seems to have simply ignored the call to -release. A bug in the analyser? 
Xcode 4.6.2

-Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 doesn't make sense either. Here's a screen shot from Xcode: 
 http://apptree.net/images/leak.png
 
 It seems to have simply ignored the call to -release. A bug in the analyser? 
 Xcode 4.6.2


I can't see anything wrong and you're right the graph makes no sense so I'd 
have to say bug in the analyser. I might try various voodoo like clean building 
etc incase it's got itself in a mess but that just looks wrong. 
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Simone Tellini


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Simone Tellini

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 '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*)eventTypes
 {
if (eventTypes != mEventTypes)
{
[mEventTypes release];
mEventTypes = [eventTypes retain];
}
InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
if (mEventTypes == nil)
{
[self loadNib];

NSDictionary* eventTypes = [self newEventTypes];
[self setEventTypes:eventTypes];
[eventTypes release];
}

return mEventTypes;//- analyser complains here
 }
 

is there a [mEventTypes release] in -dealloc?

Otherwise, this might be the potential problem it complains about: 
-eventTypes can create a new object which never goes away (since its name 
doesn't imply a +1 return, the caller is not supposed to release it).

-- 
Simone Tellini
http://tellini.info/
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 the 
enclosing object happens to leak? If so, that would mean thousands of false 
positives in most code, which doesn't appear to happen. This particular object 
is a singleton that is never deallocated explicitly in fact - is that it?

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 graham@bigpond.com wrote:

 
 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 the 
 enclosing object happens to leak? If so, that would mean thousands of false 
 positives in most code, which doesn't appear to happen. This particular 
 object is a singleton that is never deallocated explicitly in fact - is that 
 it?
 
 --Graham
 
 
 ___
 
 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.com/mailman/options/cocoa-dev/rols%40rols.org
 
 This email sent to r...@rols.org

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 about 
 the ivar.


So is it a leak or not? More confused than ever….

--Graham
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 properly releasing is being called out as a leak, it's not complaining 
 about the ivar.
 
 
 So is it a leak or not? More confused than ever….
 
 --Graham

No it's not a leak - I still think the analyser is lying. 

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 reported to 
you that the return of a retained object is an error. It is telling you that 
your code is wrong only in this very literal and simple-minded sense.

In fact, your comment in the last method, which does have new in its name, 
demonstrates that you are aware of the naming convention. Why did you not 
follow the convention in the other method? Add new or copy to the name and 
build it again. The Analyze error went away, right?

I figured this out a couple of years ago when I first applied Analyze to my own 
code. I spent hours parsing my memory management code and concluded that it was 
correct despite the Analyze errors. Then, on a whim, I added new and copy 
to several method names, and suddenly Analyze agreed that my code was correct. 
It is not smart enough to look ahead in the logic to see that -dealloc took 
care of the second retain. I'm not enough of a computer scientist to know if 
that is even possible without impractical levels of analysis.

At the time, the fact that Cocoa had started following a naming convention that 
had until then applied only to Core Foundation was documented exactly nowhere. 
I haven't looked since then, so I don't know whether it is now documented 
correctly.

Bill Cheeseman

On Sep 12, 2013, at 6:52 AM, Graham Cox graham@bigpond.com wrote:

 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 happens to leak? If so, that would mean thousands of false 
 positives in most code, which doesn't appear to happen. This particular 
 object is a singleton that is never deallocated explicitly in fact - is that 
 it?

-- 

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Fwd: Analyser reports memory leak… where?

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 graham@bigpond.com

 The -eventTypes method sends the -setEventTypes: message, which retains the 
 object and assigns it to the mEventTypes iVar. Then -eventTypes returns the 
 mEventTypes iVar without autoreleasing it, and -eventTypes doesn't have 
 new, copy, or whatever in its name. The release of the eventTypes local 
 variable in -eventTypes only offsets the first retain implicit in the -alloc 
 message in -newEventTypes. The retain count is still +1 at the point where 
 the error is reported.

 Bill Cheeseman

 On Sep 12, 2013, at 5: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 differently. mEventTypes is an ivar.

 - (void)setEventTypes:(NSDictionary*)eventTypes
 {
  if (eventTypes != mEventTypes)
  {
  [mEventTypes release];
  mEventTypes = [eventTypes retain];
  }
  InitializePrefsForEventTypeNames();
 }

 - (NSDictionary*)eventTypes
 {
  if (mEventTypes == nil)
  {
  [self loadNib];

  NSDictionary* eventTypes = [self newEventTypes];
  [self setEventTypes:eventTypes];
  [eventTypes release];
  }

  return mEventTypes; //- analyser complains here
 }

 - (NSDictionary*)newEventTypes
 {
  //[code deleted that presets contents of 'eventTypes']

  // Method name begins with new; clients are responsible for releasing.
  return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }

 --Graham
 ___

 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.com/mailman/options/cocoa-dev/wjcheeseman%40gmail.com

 This email sent to wjcheese...@gmail.com

 -- 

 Bill Cheeseman - b...@cheeseman.name

-- 

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 convention and 
 that your omission of new or copy was intentional. It therefore reported 
 to you that the return of a retained object is an error. It is telling you 
 that your code is wrong only in this very literal and simple-minded sense.


I do see this, but what I'm not quite getting is why this doesn't get reported 
for all sorts of other property getters that also correctly return retained 
objects (ivars, typically) that are not owned by the caller.

 In fact, your comment in the last method, which does have new in its name, 
 demonstrates that you are aware of the naming convention. Why did you not 
 follow the convention in the other method? Add new or copy to the name 
 and build it again. The Analyze error went away, right?


I didn't write this code, I wouldn't have done it this way - I generally avoid 
writing 'newXXX' methods to return objects that the caller has to release if I 
can help it. For some reason the author of this code did it this way.

In this case, -eventTypes is just a normal property getter which initializes 
the ivar lazily, using an internal 'new' method to do it. What's not clear to 
me is why it cares that the temporary variable, which is dealt with correctly, 
has a retain count of 1, having assigned to the property's ivar. How is that 
different to returning a retained property ivar at any other time? Changing the 
getter's name to include 'new' or 'copy' might shut up the analyser, but it's 
incorrect since a) the caller should NOT release the return value (that would 
leave the ivar dangling) and b) it breaks the convention for property getter 
names.


-

I've now slightly modified the code to do things a little more conventionally, 
refactoring the name of 'newEventTypes' to 'makeEventTypes' and returning an 
autoreleased object, which my -eventTypes getter no longer releases. The 
analyser is now happy, even though it is *still* returning the ivar with a +1 
retain count and nothing else has changed.

I guess it just isn't expecting code that follows a pattern that, while 
apparently legal, is not really commonly used.


--Graham



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 doesn't mention that method at all. 

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 
setEventTypes: is doing, it would complain about setEventTypes:, which it's not 
doing, it's complaining about a caller. That method doesn't return anything and 
has no special naming so the analyser will presume it correctly to do nothing 
net-net to its argument. 

-eventTypes doesn't need the new or copy because it does not return an object 
owned by the caller. Whether the object it returns is already owned by itself 
to be released later is irrelevant, the refcount has not been increased before 
return to the caller so the method is correctly named and the analyser can 
properly assume it to be a +0 method. And apart from that it's not even called 
in the piece of code in question so that's not really relevant. 

If what you wrote were true, and the analyser wandered into void returning 
methods like property setters which by necessity retain their arguments  then 
it would warn everyone constantly about every property setter and it doesn't. I 
don't even believe as of 4.6 the analyser does go into methods, I believe this 
was covered in WWDC 2013. 

That code still doesn't have a leak in it and I don't know what about it 
triggers an analyser bug, but the analyser is just wrong here and it's wrong in 
a very simple common case. What's possibly even stranger is that the error 
message about eventTypes not being referenced in that code path is outside the 
scope eventTypes is even defined, so the thing really is confused. 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 
eventTypes does [ eventTypes release ] refer to in that case). 




On 12 Sep, 2013, at 8:00 pm, Bill Cheeseman wjcheese...@gmail.com wrote:

 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 graham@bigpond.com
 
 The -eventTypes method sends the -setEventTypes: message, which retains the 
 object and assigns it to the mEventTypes iVar. Then -eventTypes returns the 
 mEventTypes iVar without autoreleasing it, and -eventTypes doesn't have 
 new, copy, or whatever in its name. The release of the eventTypes local 
 variable in -eventTypes only offsets the first retain implicit in the -alloc 
 message in -newEventTypes. The retain count is still +1 at the point where 
 the error is reported.
 
 Bill Cheeseman
 
 On Sep 12, 2013, at 5: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 differently. mEventTypes is an ivar.
 
 - (void)setEventTypes:(NSDictionary*)eventTypes
 {
 if (eventTypes != mEventTypes)
 {
 [mEventTypes release];
 mEventTypes = [eventTypes retain];
 }
 InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
 if (mEventTypes == nil)
 {
 [self loadNib];
 
 NSDictionary* eventTypes = [self newEventTypes];
 [self setEventTypes:eventTypes];
 [eventTypes release];
 }
 
 return mEventTypes; //- analyser complains here
 }
 
 
 
 - (NSDictionary*)newEventTypes
 {
 //[code deleted that presets contents of 'eventTypes']
 
 // Method name begins with new; clients are responsible for releasing.
 return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }
 
 
 
 --Graham
 ___
 
 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.com/mailman/options/cocoa-dev/wjcheeseman%40gmail.com
 
 This email sent to wjcheese...@gmail.com
 
 -- 
 
 Bill Cheeseman - b...@cheeseman.name
 
 
 -- 
 
 Bill Cheeseman - b...@cheeseman.name
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not

NSTabView

2013-09-12 Thread Joseph Ayers

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
East Point, Nahant, MA 01908
Phone (781) 581-7370 x309(office), x335(lab)
Boston: 444 Richards Hall (617) 373-4044
Cellular (617) 755-7523, FAX: (781) 581-6076
eMail: lobs...@neu.edu 
http://www.neurotechnology.neu.edu/
http://robobees.seas.harvard.edu/
http://cyberplasm.net/

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 
 (which eventTypes does [ eventTypes release ] refer to in that case). 


That did occur to me as well, and I went and looked - nothing found (apart from 
the method name itself). Just to be sure, I changed the temporary variable name 
(to 'et') and the analyser now complained about et.

*shrugs*

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 64-bit iOS

2013-09-12 Thread Scott Ribe

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





___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView

2013-09-12 Thread Mike Abdullah


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 in tab.


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView

2013-09-12 Thread Jerry Krinock


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 all under the hood.

In one of my projects, I wanted a tabless tab view that could be switched by 
and stay synced to buttons in a toolbar.  I subclassed NSTabView to provide 
notifications.  Also, NSTabView has fairly good bindings support which may be 
useful to you.

If you want a better answer, you should explain what you're trying to 
accomplish.


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Fritz Anderson

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 differently. mEventTypes is an ivar.
 
 - (void)setEventTypes:(NSDictionary*)eventTypes
 {
   if (eventTypes != mEventTypes)
   {
   [mEventTypes release];
   mEventTypes = [eventTypes retain];
   }
   InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
   if (mEventTypes == nil)
   {
   [self loadNib];
   
   NSDictionary* eventTypes = [self newEventTypes];
   [self setEventTypes:eventTypes];
   [eventTypes release];
   }
   return mEventTypes; //- analyser complains here
 }
 
 - (NSDictionary*)newEventTypes
 {
   //[code deleted that presets contents of 'eventTypes']
 
   // Method name begins with new; clients are responsible for releasing.
   return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }

I tried a Foundation-tool project that included a class with the methods you 
show, dummying the methods and functions not shown as empty 
void-returning-void, and dictionary data as one string-keying-string. ARC off.

Running this through a later version of clang showed no analyzer errors. I 
think it's a bug in the version of clang you're using. Or: clang does 
cross-function checks to one degree or another. Can you make a minimal example, 
and add the code you omitted here to see what makes the analyzer unhappy?

I assume you expanded the note and examined the code path on which the compiler 
saw a potential problem?

— F


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Alex Zavatone

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, 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 (which eventTypes does [ eventTypes release ] refer to in that 
 case). 
 
 
 That did occur to me as well, and I went and looked - nothing found (apart 
 from the method name itself). Just to be sure, I changed the temporary 
 variable name (to 'et') and the analyser now complained about et.
 
 *shrugs*
 
 --Graham
 
 
 ___
 
 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.com/mailman/options/cocoa-dev/zav%40mac.com
 
 This email sent to z...@mac.com


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 incorrect, because then it 
 isn't a valid getter name.
 
 If you did go ahead and name it thus, the caller would assume that it's their 
 job to release the returned value. If they did that, it would leave 
 mEventTypes dangling, and a later call to -release in -dealloc would crash 
 due to an overrelease. So renaming the method is wrong on both counts.


But -eventTypes is not in fact a valid getter because it returns the iVar 
retained but not autoreleased. The setter/getter convention requires getters to 
return autoreleased objects. So leaving it named according to the getter naming 
convention is wrong. Adding new would not only be correct but would also warn 
against using it as a getter. 

As written (no matter what it is named), it is in fact the caller's job to 
release it. That is presumably why you release it in -dealloc. If your class's 
-init method initially created the first object assigned to the iVar, whether 
by calling -eventTypes or by directly calling -newEventTypes and setting the 
iVar, then you are the owner and you must release it in -dealloc if not 
earlier. And if you call -eventTypes or -newEventTypes while substituting a new 
object for the old iVar object in midstream, you must release the old iVar 
object in midstream, too.

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.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 doesn't remember the last value of a notification, which is 
 what I would like.
 []
 
 Yes, I am removing myself as a receiver, but ideally I want to receive 
 these notification even if the object is dead. By this I mean, I want the 
 last known value of the notification restored when the Object in question 
 starts up again. At present I have to save this somewhere ugly and restore 
 it from somewhere ugly. I just thought it would be nice to be able to just 
 make a call something like:
 
 -(void) reissueLastNotificationName:@Note1 forClass:self
 
 Rather than save it somewhere ugly 26 more times!
 
 I  could maybe subclass NSNotificationCenter?
 
 
 There are a couple of statements here that don't make a huge amount of 
 sense. What do you mean by an object….starts up again?
 
 I mean when the object is created - at this point I want the latest version 
 of the Notification, not the Notification when the Object Died.
 
 Perhaps the problem is really that your object should not be being killed 
 until the final notification has been received? That's a different problem.
 
 No, there is no final notification, just one when the data associated with 
 it changes. 
 
 If you mean you want to save something between launches of your app so you 
 can restore state, that's easily done by the sender of the notification. 
 
 
 No, I just want the latest version of the notification when the object is 
 created. Yes, I could save it at the sender, but I'd still have the problem 
 of restoring it when the object is created and wants to set itself to the 
 current state. Basically, when it is created I want it to fetch the latest 
 update and apply it to itself data at init time. I don't want to store the 
 old value.
 
 Think like this:
 
 Object has not been created………..
 Send Notification A
 Send Notification B
 Send Notification C
 Send Notification D
 Send Notification E
 Object is Created……….. Set Data from Notification E
 Send Notification F
 Object is Alive……….. Set Data from Notification F
 Send Notification G
 Object is Alive……….. Set Data from Notification G
 Object is deleted/released.
 Send Notification H
 Send Notification I
 Send Notification J
 Object is Created……….. Set Data from Notification J
 
 Basically, there isn't enough detail in your question to advise, and what 
 you have given appears to smell a bit. Reissuing a notification sounds 
 like a band-aid for a problem that should be solved some other way, to me. 
 Subclassing NSNotificationCenter is presumably possible, but sounds like 
 the wrong way to do whatever it is you are really trying to do.
 
 I want the above, I thought subclassing NSNotificationCenter and adding a 
 memory would be quite a neat way of doing it - 27 times.
 
 All the Best
 Dave
 
 Sounds like all you really want is to save some state, specifically a 
 notification state.
 
 You just ivar/property/object somewhere that keeps track of the last sent 
 Notification.
 Put it in the most accessible place to each of the observer objects.
 It could simply be a property class NSNotification and it will have 
 everything it had before.
 Just keeps a reference.
 Update the reference as new notifications come.

Yes, but the problem with that is there is 26 of them and they will all be 
storing the same value. What I actually did was to subclass NSOperationCenter 
and add 3 class methods it and overrode postNotificationName and friends.

In the postNotificationName I have save the notification in a dictionary and 
then call super. 

I added:

+(void) enableRememberNotifications;
+(void) repostNotificationName:;
+(void) getNotificationInfoForNotificationName:;

I just call enableRememberNotifications, at App startup and then call 
repostNotificationName whenever I need an update - works a treat!

Thanks for your help
Dave


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 lazy initializer. Or perhaps I would factor out the common
 setter code to a private helper method.
 
 Indeed, I have changed the code to do just this, which is what I would have 
 written in the first place (honest!). I'm not sure why it wasn't and changing 
 it appears to have not caused any problems.
 
 Hopefully this has the side effect of shutting the analyzer up.
 
 
 It does.
 
 I guess the thread is now really about why the analyser was thrown off by 
 this. Academic? Perhaps, but here's the bigger picture: I want to gradually 
 move my codebase to ARC, so in preparation for that, I have been going 
 through and trying to ensure the analyser is happy, since my understanding is 
 that ARC relies on the same analysis to do its thing correctly, so if the 
 analyser is getting it wrong, converting to ARC might introduce a bug here.


No, I don't think this is academic. The analyzer appears to have a real problem 
with using a setter inside a getter (both as exhibited with your original 
example and my more minimal example). If it is going to be responsible for 
adding all the memory management code to our code, we need to know that it can 
handle this situation or that it will refuse to convert to ARC when this 
situation is present. I'll try to see how it handles converting my minimal 
example to ARC.

Aaron  
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView


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 == [[appDelegate graphicsWindowController] scopeItem]){
 NSLog(@Scope Item Selected);
 }
 else if (tabViewItem == [[appDelegate graphicsWindowController] 
 graphItem]){
 NSLog(@GraphItem Selected);
 }
 
 }
 That never gets called. Hence my question about the target action of the 
 tabs. When I first create the oscilloscope tab the oscilloscope gets drawn,
 but if I then create a graphViewItem it draws a blank screen. If I then click 
 on the oscilloscope tab, the oscilloscope image doesn't come back.
 


Are you sure it never gets called, or is it that neither statement is ever 
logged?

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 not 
appear to be setting the view - or I may have missed it, or it might be being 
done in a method not shown here.

I've done this sort of thing a few times and it's fairly straightforward. You 
appear to be making heavy weather of it. All you need to do is to call 
-setView: for each tab view item with the views you want to add to the tab. It 
should do the rest.


--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 change 
the sender, but I didn't because I have one method in the whole app that 
returns the default notification center, which is why I subclass it. I just 
changed this method to return the subclass instead and the whole App now uses 
the subclass, sorry, I should have explained that. I never call things like:

[NSNotificationCenter defaultCenter]  directly in an application if I can help 
it. It's much better to retrieve it from one place - the case in hand shows 
this because it made it sp easy to implement the subclass.

All the Best
Dave


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 the devil's advocate here Dave, but you'd have a more 
 fool-proof solution with the cache solution I described. You won't have the 
 problem pointed out by Kyle that you end up with 2 notification centers (and 
 can't cache Cocoa's own notifications unless you have the subclass register 
 with the default center). Maybe you'll have 26-or-more registerObserver: 
 calls to change (to add the then check cached notification call), but in 
 the end run, you've just removed a dependency on a subclass whose superclass 
 you know nothing about. Again (and I speak from experience), better be safe 
 than sorry if NSNotificationCenter semantics change and your app stop working.


The way this was setup before I added any of this was that the whole app calls 
a method called getNotificationCenter that returns [NSNotificationCenter 
defaultCenter], that's the only notification center the App knows about.

All I have done it make a subclass of NSNotificationCenter, called 
LTWCachedNotificationCenter and I return that instead of  [NSNotificationCenter 
defaultCenter] in the getNotificationCenter method. The rest of the app stays 
the same, apart from the places that call the new methods. 

All the Best
Dave


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Lee Ann Rucker


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 ObjC++ and C++ object lifetimes, resulting in an 
accessor that uses that pattern being called as a result of that object being 
in dealloc. By the time the autorelease pool pops the object it's trying to 
release is long gone. It's KVO unregistering, so there's not much we can do 
about it other than be smarter in our accessors.
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Lee Ann Rucker


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 preferring it. 
 
 Coincidentally enough, we've just hit a case where that's bad - it's a 
 complicated situation with ObjC++ and C++ object lifetimes, resulting in an 
 accessor that uses that pattern being called as a result of that object 
 being in dealloc. By the time the autorelease pool pops the object it's 
 trying to release is long gone. It's KVO unregistering, so there's not much 
 we can do about it other than be smarter in our accessors.
 
 In some cases you can add an @autoreleasepool inside the object's -dealloc 
 method to catch these.

Ooh, yes, that works great! 

So many new language features, so little time...
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Tom Davie


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 autorelease pool, I'll
 stand corrected, but that would be the first time I've ever heard that
 in 13 years of Cocoa programming!
 
 Even if there is such a rule:
 
 - (id) eventTypes
 {
// [self lazyInitEventTypes];
 
return [[mEventTypes retain] autorelease];
 }

It’s not a hard and fast rule, and in fact collection access does not do this, 
so it’s entirely possible to do things like:

id a = x[5];
[x removeObjectAtIndex:5];
[a crashMyProgram];

Tom Davie
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 
 responsible for releasing it. 
 
 There's an inherent contradiction in this statement. If it's a getter, then 
 the caller has no responsibility for ownership of the returned object. If the 
 caller does have that responsibility, then it's not a getter. In fact, 
 -eventTypes in this case *is* a getter, or is intended to be.


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 returned object.

You can take ownership of an object using retain
A received object is normally guaranteed to remain valid within the method it 
was received in, and that method may also safely return the object to its 
invoker. You use retain in two situations: (1) In the implementation of an 
accessor method or an init method, to take ownership of an object you want to 
store as a property value; and
I wonder if you are perhaps thinking of the Core Foundation Create Rule, which 
does say that a function named with get does not return a retained object (is 
returned by reference). If you can refer to any Cocoa documentation to the 
effect that getters never confer ownership in Cocoa, please pass it along.
-- 

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView

2013-09-12 Thread Joseph Ayers

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, should this be [myTabView setDelegate:self]; ?
 
 --Graham

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Marcel Weiher

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 comply 
 with this preference, and I also recall that some of the early documentation 
 about properties discussed this convention.

I think you meant the ‘atomic' property modifier.   Note that the iOS team did 
not agree with Ali on this, due to the ginormous performance penalties in both 
CPU and memory: they made ‘nonatomic’ the standard for iOS, despite the fact 
that the language defaults to ‘atomic' and you therefore have to type 
‘nonatomic' every time.

Now considering the relative installed bases...

Marcel
p.s.: If I understand it correctly, ARC’s magic un-autoreleaser largely 
ameliorates the perf. problems

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

2013-09-12 Thread Etienne Samson

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 NSNotificationCenter”, I recoil 
 in horror.

Have a look at Quicksilver's source code sometimes ;-). But yes, you're right, 
and maybe I haven't been clear enough but you have to have a decent usage 
hygiene for that to work.

 First, NSNotificationCenter is a singleton. If you subclass it, you now 
 must have two notification centers. 
 
 It has the facility to have different Centers (default etc.), so it's not
 a true singleton, although I  see what you mean. It doesn't have to be a
 subclass, just a class, but I think that either subclassing
 NSNotificationCenter or have a Category on it is better than having an
 anonymous object that calls [NSNotificationCenter defaultCenter], since
 at least it keeps all the notification code in one place.

You can't have a Category without reimplementing the whole methods you'll 
replace. Good luck providing adequate replacements for framework classes you 
only have the machine code for ;-).

 I'm not really sure what you're talking about with anonymous object
 that calls +defaultCenter. Every NSNotificationCenter call site gets a
 reference to the notification center by calling the class method.

I think it means any object. This describes the tight coupling between 
sender/notification center and notification center/receiver and the loose 
coupling between sender/receiver which is a thing to keep in mind, there is a 
strong coupling in the sender/NC/observer pattern : you're asking for another 
(hopefully common) object to receive and deliver messages on your behalf.

 Which one is the right one to subscribe to? Do you only move notifications 
 over to it that need to be cached? Or all related notifications as well?
 
 That problem exists anyway, you have to know it's the default center for
 instance. This is just using related ones by virtue of the fact that the
 rest of the code doesn't use the subclass, only those that need to.
 
 If you only ever use the default center, you never have to worry about
 which notification center to listen to.

The default center doesn't provide the automatic caching mechanism the OP 
wants. You, as the programmer of that horror, ought to know which notifications 
need to be cached or not. Standard framework notifications ? Use `[NSNC 
defaultCenter]`. Your own framework notifications ? Use the subclass. Need to 
cache standard notifications ? Observe the `defaultCenter` from the subclass.

 There is a very large gulf in software design between one and many.
 Every time you want to cross that gulf you have to make decisions. More
 decisions lead to more bugs.
 
 
 This decision needs to be made on both ends of the notification.

That's true, but again you as the programmer can decide which notifications 
needs caching and which do not.

 Congratulations, you have taken an object whose purpose is to promote 
 loose coupling, and successfully turned it into a tool that tightly 
 couples the sender and the listener.

I see your point, but IMHO it all fall apart if you can have more than one 
sender (which is as yet unspecified). And the sender/reciever (as explained 
above) are *already* tightly coupled with whatever notification center you've 
chosen because of the difference in behavior the OP wants. You can't have the 
receiver know where the notification came from and it ask for it's current 
value without killing that loose couple.

 The correct approach does not put the cache in the notification center, 
 but rather in the sender or the userInfo dictionary.
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 NSNotificationCenter”, I recoil 
 in horror.

Have a look at Quicksilver's source code sometimes ;-). But yes, you're right, 
and maybe I haven't been clear enough but you have to have a decent usage 
hygiene for that to work.

 First, NSNotificationCenter is a singleton. If you subclass it, you now 
 must have two notification centers. 
 
 It has the facility to have different Centers (default etc.), so it's not
 a true singleton, although I  see what you mean. It doesn't have to be a
 subclass, just a class, but I think that either subclassing
 NSNotificationCenter or have a Category on it is better than having an
 anonymous object that calls [NSNotificationCenter defaultCenter], since
 at least it keeps all the notification code in one place.

You can't have a Category without reimplementing the whole methods you'll 
replace. Good luck providing adequate replacements for framework classes you 
only

Re: Analyser reports memory leak… where?


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 owns it and is responsible for 
 releasing it. 

There's an inherent contradiction in this statement. If it's a getter, then the 
caller has no responsibility for ownership of the returned object. If the 
caller does have that responsibility, then it's not a getter. In fact, 
-eventTypes in this case *is* a getter, or is intended to be.

  If the behavior of Analyze in this connection does still in fact change 
 depending on whether you include new or similar terms in the method name, 
 consistently with at least part of the Cocoa rule, one proper way to make the 
 ownership of the object returned by -eventTypes clear would be to put new 
 in its name.

Which would make it not a getter.


I think other contributors have actually got closer to the heart of the matter, 
which is that the getter calls the associated setter. That's probably a bad 
idea in general (certainly considering KVO, as Kyle pointed out, is very likely 
to cause an infinite loop), and I'm thinking that it should be a rule, that one 
does not do this. It could be that it's already an unwritten rule, baked into 
the assumptions made when the analyser itself was coded, and that's what's 
throwing it off. (Commenting out the setter line does make the analyser error 
go away). Normal getters, however they are coded with respect to the returned 
object, synthesized or whatever, do not call the associated getter, but as I 
said, this wasn't code I wrote. In fact, this particular module has been a 
constant source of pain since it was forced on me, but its days are numbered 
anyway.


--Graham



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

@property and automatic synthesis of getters and setters.

2013-09-12 Thread Peter Teeson

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 = [super init];
if (self) {
protoCell = [[Cell alloc]init];
// Add your subclass-specific initialization here.
}
return self;
}
……
@end

but the compiler tells me
Use of undeclared identifier 'protoCell'; did you mean '_protoCell'?

If I do refer to the ivar using the internal reserved form _protoCell 
the compiler is happy.

What is my lack of understanding? Why am I not allowed to use
the getter protoCell as indicated in the documentation?

TIA

Peter
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

2013-09-12 Thread Kyle Sluder

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 notification centers. 
 
 It has the facility to have different Centers (default etc.), so it's not
 a true singleton, although I  see what you mean. It doesn't have to be a
 subclass, just a class, but I think that either subclassing
 NSNotificationCenter or have a Category on it is better than having an
 anonymous object that calls [NSNotificationCenter defaultCenter], since
 at least it keeps all the notification code in one place.

I'm not really sure what you're talking about with anonymous object
that calls +defaultCenter. Every NSNotificationCenter call site gets a
reference to the notification center by calling the class method.

 
  Which one is the right one to subscribe to? Do you only move notifications 
  over to it that need to be cached? Or all related notifications as well?
 
 
 That problem exists anyway, you have to know it's the default center for
 instance. This is just using related ones by virtue of the fact that the
 rest of the code doesn't use the subclass, only those that need to.

If you only ever use the default center, you never have to worry about
which notification center to listen to.

There is a very large gulf in software design between one and many.
Every time you want to cross that gulf you have to make decisions. More
decisions lead to more bugs.

 
  This decision needs to be made on both ends of the notification.
 
 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.

 
  Congratulations, you have taken an object whose purpose is to promote loose 
  coupling, and successfully turned it into a tool that tightly couples the 
  sender and the listener.
  
  The correct approach does not put the cache in the notification center, but 
  rather in the sender or the userInfo dictionary.
  
  --Kyle Sluder
 
 This is just not true! It's the opposite as far as I can see. If I hold
 the the data at the sender then from the receiver I have to know who
 sent the Notification in order to retrieve it,

You already know that information. It's in the object property of the
NSNotification object.

 also, there is more than
 one sender for the notification, so I would have add more code specific
 to a number of objects.

Then put it in the userInfo. That's what it's there for.

 This way the receiver is coupled to the subclass

No it's not.

 which is not a lot different that the base class, and it could be coupled
 to that anyway, so I don't see the problem.
 
 it works like a treat and is really easy to adapt so I'd say the proof is
 in the pudding!

And when you're scratching your head wondering why you're not getting
notifications delivered to your objects, because they're being sent to a
different notification center than the one you're listening to…

Either that or I'm sorely misunderstand how you propose to use
subclasses of NSNotificationCenter.

--Kyle Sluder

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: @property and automatic synthesis of getters and setters.

2013-09-12 Thread David Duncan


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 explicitly different from explicit synthesis.
--
David Duncan

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 64-bit iOS

2013-09-12 Thread Paul Franz

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 pointers are effectively double size, but 
 in Java, they are not.
 
 See “Compressed oops at 
 http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
  
 
 Le 11 sept. 2013 à 00:18, Paul Franz paul.p.fr...@gmail.com a écrit :
 
 Should be interesting to see how this plays out. When it comes to Java, when 
 you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing 
 so. The main reason has to do with pointers. All pointers double in size. 
 The effect might be less in a Objective-C program.
 
 Paul Franz
 
 On Sep 10, 2013, at 5:47 PM, Tom Davie tom.da...@gmail.com wrote:
 
 
 On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote:
 
 
 For ARM, 64 bit matters because the instruction set has been updated to 
 provider better performances.
 
 I just hope the performance boost provided by this architecture change 
 will be enough to balance the slow-down due to the increase of instruction 
 and pointer size.
 
 Note, this was actually more significant on x86, where most of the mess 
 caused by CISC (like having bugger all registers) got sorted out.
 
 Tom Davie
 ___
 
 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.com/mailman/options/cocoa-dev/paul.p.franz%40gmail.com
 
 This email sent to paul.p.fr...@gmail.com
 
 -- Jean-Daniel
 
 
 
 

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: @property and automatic synthesis of getters and setters.


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 (i.e. no need to @synthesize):
 
 @implementation Document
 - (id)init
 {
self = [super init];
if (self) {
protoCell = [[Cell alloc]init];
// Add your subclass-specific initialization here.
}
return self;
 }
 ……
 @end
 
 but the compiler tells me
 Use of undeclared identifier 'protoCell'; did you mean '_protoCell'?

I think it is either
_protoCell = [[Cell alloc] init];
or
self.protoCell = [[Cell alloc] init];


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

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:(NSString*) theName object:(id) theObject 
userInfo:(NSDictionary*) theUserInfoDictionary
{
[[NSNotificationCenter defaultCenter] postNotificationName:theName 
object:theObject userInfo:theUserInfoDictionary];

if (theUserInfoDictionary == nil)
return;

@synchronized (gNotificationClassDictionary)
{
[gNotificationClassDictionary setObject:theUserInfoDictionary 
forKey:theName];
}
}



+(void) repostNotiticationName:(NSString*) theName
{
NSDictionary*   myUserInfoDictionary;

@synchronized (gNotificationClassDictionary)
{
myUserInfoDictionary = [gNotificationClassDictionary 
objectForKey:theName];
}

if (myUserInfoDictionary != nil)
[[NSNotificationCenter defaultCenter] postNotificationName:theName 
object:nil userInfo:myUserInfoDictionary];
}


All the Best
Dave

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: @property and automatic synthesis of getters and setters.

2013-09-12 Thread John Pannell

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 alone is neither of the above, and you'll get the 
warning.  I seem to recall that best practice in an init method is to directly 
access the ivar.

HTH!

John

On Sep 12, 2013, at 3: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 (i.e. no need to @synthesize):
 
 @implementation Document
 - (id)init
 {
self = [super init];
if (self) {
protoCell = [[Cell alloc]init];
// Add your subclass-specific initialization here.
}
return self;
 }
 ……
 @end
 
 but the compiler tells me
 Use of undeclared identifier 'protoCell'; did you mean '_protoCell'?
 
 If I do refer to the ivar using the internal reserved form _protoCell 
 the compiler is happy.
 
 What is my lack of understanding? Why am I not allowed to use
 the getter protoCell as indicated in the documentation?
 
 TIA
 
 Peter
 ___
 
 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.com/mailman/options/cocoa-dev/john%40positivespinmedia.com
 
 This email sent to j...@positivespinmedia.com


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 64-bit iOS

2013-09-12 Thread Mark Munz

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 find a way to
take advantage of the new 64-bit power offered.

The arguments being made against 64-bit have been made (in varying degrees)
pretty much with every major Apple architectural change.
A switch to 64-bit doesn't happen overnight and my guess is that within 2-3
years, every competitive phone will be running some 64-bit chip.

And ultimately, I think Apple wants one underlying code-base for itself. OS
X is already 64-bit, dropping 32-bit system apps after 10.6. We've seen OS
X  iOS move ever so closer together and this is part of it. Will it lead
to a hybrid ARM-based MacBook Air Touch that can also run iPad apps (ie.
no emulation)? Who knows. But this opens up the possibility that didn't
exist before. I have no knowledge of that, it's pure speculation to just
point at the new possible in an all 64-bit Apple OS universe that
probably could not happen otherwise.

As for memory concerns (doubling pointer size), I think they could be
overblown. You assume more cache misses based on a 64-bit pointer in a
32-bit chip architecture. That's probably not the case. We don't know
enough about the A7, but I'd guess that a 64-bit chip architecture is
designed to address that. As for binary size increase, I think the big
binary increase when you had to include 2x artwork. Based on my experience
with OS X, there will be an increase, but it typically won't be huge unless
you're app is nothing *but* a list of pointers.

Perhaps a bigger hit comes when you've got 32-bit apps that require loading
the entire 32-bit system stack when everything else is 64-bit. You're
basically loading a 2nd copy of the frameworks for 32-bit apps. That's
especially true when you're the *last* 32-bit app on a 64-bit system.

And welcome to the world of Apple transitions. Long time Apple developers
are quite familiar with this: 24-bit-32-bit, 68K-PPC, Mac OS 8-OS X,
PPC-Intel, Carbon-Cocoa, 32bit-64-bit (on Intel), QuickTime -
AVFoundation. I'm sure I missed a few there. A few years from now you'll
wonder how we ever managed to write software in a tiny 32-bit world.

-- 
Mark Munz
unmarked software
http://www.unmarked.com/
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Steve Mills

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:

[object retain];
[_object release];
_object = object;

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157




___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Gary L. Wade

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-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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

quitting app running in status bar logs this message about some modal session

2013-09-12 Thread Nick Rogers

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:modalDelegate:didEndSelector:contextInfo:],
 /SourceCache/AppKit/AppKit-1187.39/AppKit.subproj/NSApplication.m:3919

[25025:303] Modal session cannot be run during application termination

I am not running any modal session at the time, nor the window is brought 
forward, still this error.

Please help.

Wishes,
Nick

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 brackets the assignment 
(again something I don't usually do unless the setter has side effects).

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView


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 difficult to read) does not 
 appear to be setting the view - or I may have missed it, or it might be being 
 done in a method not shown here.
 


Sorry, I mis-spoke. I didn't notice your outlets were for the tab view items, 
not the views…

I assumed they were the views without carefully reading because that's the 
obvious way to do it. I can't see a good reason to keep outlets to the tab view 
items, that seems to be an implementation detail that is clouding the bigger 
picture - how to know which view is being shown.

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Daniel Höpfl


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
-setEventTypes:, decreases its refcount by 1 to balance the second
increase, and returns it with a refcount of 1 without autoreleasing
it. It does own the new object, and the method should have new in
its name.


I agree with Graham that the method must not be named new...
(because the caller is not to release the returned value).

I think there might be two reasons for the warning:

a) (I guess that not the reason): The analyser gets confused by
   seeing -setEventTypes:.

@Graham: What happens when you comment out the call to setEventTypes:?

  NSDictionary* eventTypes = [self newEventTypes];
  // [self setEventTypes:eventTypes];
  [eventTypes release];

Do you still get the warning?


b) The if (mEventTypes == nil) {} return mEventTypes; confuses the 
analyser:


   if (mEventTypes == nil)   // OK, mEventTypes might be nil here.
   {
  [self loadNib];// Might do anything, but due to the 
name: +/-0


  NSDictionary* eventTypes = [self newEventTypes];  // +1 for 
eventTypes

  [self setEventTypes:eventTypes];// Might do anything,
  // but due to the name: +/-0 for 
everything.

  [eventTypes release];   // -1 for eventTypes, fine.
   }

   return mEventTypes;
   // Wait. Why is the coder returning mEventTypes instead of nil?
   // Nobody created an object, but the coder assumes that there is an 
object
   // in mEventTypes now. Where did it come from? It must not be 
autoreleased
   // because this would result in a dangling pointer, so it MUST be +1 
(or more).

   // Might be a leak. Lets warn the coder.

Reasonable?

@Graham: Could you try the following:

- (BOOL)isEventTypesAvailable
{
   return mEventTypes != nil;
}

...
   if (![self isEventTypesAvailable])
   {
...

Bye,
   Daniel

@Bill: Sorry for sending this mail to you directly instead of to the 
list before. %-)

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 perfectly valid. The rest of the code is just a lazy initialization 
for mEventTypes.


 The setter/getter convention requires getters to return autoreleased objects.

Not so, it requires that the returned object is not owned by the caller. That 
is all.


 So leaving it named according to the getter naming convention is wrong. 
 Adding new would not only be correct but would also warn against using it 
 as a getter. 

But it is a getter, no more or less. The lazy initialization is neither here 
nor there to the caller.

 As written (no matter what it is named), it is in fact the caller's job to 
 release it. That is presumably why you release it in -dealloc. If your 
 class's -init method initially created the first object assigned to the iVar, 
 whether by calling -eventTypes or by directly calling -newEventTypes and 
 setting the iVar, then you are the owner and you must release it in -dealloc 
 if not earlier. And if you call -eventTypes or -newEventTypes while 
 substituting a new object for the old iVar object in midstream, you must 
 release the old iVar object in midstream, too.


The object owns mEventTypes, so it is not the caller's job to release it. It is 
released in -dealloc because the object owns mEventTypes.

 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 documentation that states that the 
returned object must belong to an autorelease pool, I'll stand corrected, but 
that would be the first time I've ever heard that in 13 years of Cocoa 
programming!

--Graham




___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTabView


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 (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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Arraycontroller and CoreData

2013-09-12 Thread Keary Suska

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 don't have to make this fetch do I? I can tell 
 the array controller to fetch: ?

You don't even need to call -fetch: in most cases--the array controller can 
fetch itself when automaticallyPreparesContent is set.

 Next thing is, when new Items are added to the collection view, it should 
 automatically change.
 A binding of the collection view is enough? Something like [collectionview 
 bind: toObject:….]

Not in your case. There is no way I can think of via pure KVO that the array 
controller would know that its fetched set may have changed. It might if you 
use NSArrayController's methods to add/remove objects, and if so you would also 
get undo support for free, but I don't remember whether it works for fetched 
results (works really well for relationships).

 And, for now I add data to my core data database with 
 insertNewObjectForEntityForName. Is that okay or should I add it with the 
 array controller's add oder insertObject methods? The new entries have to 
 keep their relationships and I don't know how I can define them with the 
 array controller methods. 

You could try using NSArrayController's methods, and if that doesn't work, then 
you need to tell the array controller to refetch whenever items are 
added/removed, either in the add/remove methods or similar in an NSArray 
subclass.

HTH,

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 dictionary-munging 
 code that keeps tracks of the last notification send by notification name, 
 and have -addObserver:… (you'll have to find the one that actually is the 
 designated call, the one all the others expect) check that cache and issue a 
 -postNotification: call for that object only (you don't want to notify all 
 old objects, only the one that just registered).
 

Great minds and all that! This is more or less what I have, see earlier post 
for details if you are interested.

Thanks a lot
Dave
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 point to explicit documentation that states that the
returned object must belong to an autorelease pool, I'll stand corrected, but
that would be the first time I've ever heard that in 13 years of Cocoa
programming!

I participated in a lengthy online debate about this very subject in 2002 with
Apple's Ali Ozer and a bunch of other folks whose names are very familiar on
this list. Opinions were all over the map. Eventually, as I recall, Ali Ozer
won the debate by issuing a technote or QA about the proper way to write
getters and setters. I just spent a little time looking for it but have not yet
found it. As I recall, it 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
preference, and I also recall that some of the early documentation about
properties discussed this convention.

I did find a message from Ali dated July 31, 2002, at
http://www.cocoabuilder.com/archive/cocoa/50627-accessor-methods-and-auto-release-memory-trail.html
in which he states the autorelease preference. His message also said that a
faster alternative when speed is paramount is to return the variable without
retain or autorelease, and the code example he gave implied that the variable
was retained (it was retained or copied in the setter and returned in the
getter without modification). So I have to qualify what I said earlier today by
noting that, in appropriate circumstances, getters can return retained objects
instead of autoreleased objects, although the latter is preferred. 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.

By the way, anybody interested in reading Apple's autorelease pool patents can
go to the US Patent and Trademark Office Web site http://patft.uspto.gov and
search for patents nos. 5,687,370, 6,026,415, and 6,304,884. Ali Ozer is listed
as one of the inventors. Some of the historical and technical information in
the patents is really interesting.

The current statement of the Cocoa ownership rule is here:
https://developer.apple.com/library/ios/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmRules.html.
It notes at the end that the rule is similar to but a little different from
the Core Foundation Create Rule. That, and the text of the Cocoa document,
suggest that my assertion that the -eventTypes method we are discussing must be
named with new is overstated because the Cocoa rule is different from the
Create Rule. The Cocoa Rule says that you do own an object returned by a method
having “alloc”, “new”, “copy”, or “mutableCopy” in its name, but it also spells
out several other cases where methods without those names still make the caller
the owner -- namely, by retaining it. Since the -eventTypes method does retain
the object, the Cocoa document's statement of the Cocoa rule confirms that the
caller of -eventTypes is in fact the owner of the object and responsible for
releasing it. If the behavior of Analyze in this connection does still in fact
change depending on whether you include new or similar terms in the method
name, consistently with at least part of the Cocoa rule, one proper way to make
the ownership of the object returned by -eventTypes clear would be to put new
in its name. Alternatively, apparently, you could continue to name it like a
getter and simply document the method to indicate ownership. Either way,
Analyze should not base its error reporting on the name of the method alone,
because it is the Create Rule, not the Cocoa rule, that relies solely on names.
So I am now once again puzzled by my discovery a couple of years ago that
adding new to Cocoa method names removed the error reports. It appears that
Analyze is enforcing a slightly different rule from the Cocoa rule, one that is
more consistent with the Core Foundation Create Rule.

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

2013-09-12 Thread Kyle Sluder

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 cached? Or all related 
notifications as well?

This decision needs to be made on both ends of the notification. 
Congratulations, you have taken an object whose purpose is to promote loose 
coupling, and successfully turned it into a tool that tightly couples the 
sender and the listener.

The correct approach does not put the cache in the notification center, but 
rather in the sender or the userInfo dictionary.

--Kyle Sluder
(Sent from the road)

On Sep 12, 2013, at 9:40 AM, Dave d...@looktowindward.com wrote:

 
 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 dictionary-munging 
 code that keeps tracks of the last notification send by notification name, 
 and have -addObserver:… (you'll have to find the one that actually is the 
 designated call, the one all the others expect) check that cache and issue a 
 -postNotification: call for that object only (you don't want to notify all 
 old objects, only the one that just registered).
 
 Great minds and all that! This is more or less what I have, see earlier post 
 for details if you are interested.
 
 Thanks a lot
 Dave
 ___
 
 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.com/mailman/options/cocoa-dev/kyle%40ksluder.com
 
 This email sent to k...@ksluder.com

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Greg Parker

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 just hit a case where that's bad - it's a 
 complicated situation with ObjC++ and C++ object lifetimes, resulting in an 
 accessor that uses that pattern being called as a result of that object being 
 in dealloc. By the time the autorelease pool pops the object it's trying to 
 release is long gone. It's KVO unregistering, so there's not much we can do 
 about it other than be smarter in our accessors.

In some cases you can add an @autoreleasepool inside the object's -dealloc 
method to catch these.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName

2013-09-12 Thread Manoah F. Adams



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 alive, but  
the logical object does ... like the 'Bob' account, and the 'Lisa'  
account, serialized, stored, then new programmatic object equivalent  
recreated. Do I understand you right?


You also mentioned 'getting last notification'.

I don't understand what you really want...
Notifications are a broadcast communication, and the 'last'  
notification is going to be quite disconnected (logically) from the  
receiving object.


You seem to want the re-incarnated object to pick up where it left off,
but with the Notification model you're using, you've still missed the  
train car you wanted, and getting next car in front of the current  
car is still no good.


I seems to me that what you want is nothing to do with the  
NSNotification model of communication but traditional message  
passing, buffered by a persistent message que between objects.


Maybe have a central Que/Proxy object that:
- holds a dictionary of ques (each an array of Notification objects),  
identified by the unique identifier of your receiving object (like  
Bob's account number);

- registers itself for the Notification;
- for each receiving object:
- if 'alive'/exists: send notification
- else: add to que for that object
then when each object comes 'alive' it pulls from the Center's que  
until empty, then rests.



As you can see I've sort of come full circle to what you (Dave) have  
now implemented, but with 2 final comments:
(1) I agree with the others that you should make you own notification  
center *without* subclassing.
(2) I still think there is something wrong with this design  
pattern ... there must be some better/more normal way to keep the  
data synchronized.
Maybe the data manager (whatever object is responsible for the  
persistence and management of the receiver objects) should lookup the  
relevant data when instantiating the data object, or the data object  
needs to lazy-load the updated information from the data source.



P.S.: The other posters are right about the Notification model being  
'loose-coupling':
At times, this tight coupling of two objects is undesirable—most  
notably because it would join together two otherwise independent  
subsystems. For these cases, a broadcast model is introduced --  
Notification Programming Topics, page 4 https:// 
developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/ 
Notifications/Notifications.pdf
I, personally, have always considered Notifications to be for non- 
essential, run-time only communication.



Manoah F. Adams
 https://federaladamsfamily.com/developer

===



On Sep 11, 2013, at 04:35 , Dave wrote:


Hi,

Sorry for the lack of data in my original post! I Found the problem  
it was a Notification being sent to a dead object, it didn't happen  
very often, one crash after over an hour running continuously. I  
was more worried about the data I was passing not belonging to same  
thread (I recently added this code) rather than one the object  
being dead. I thought my modifications had caused the crash, but  
actually it was there all along hiding!


Is there any problem with having all notifications handled by one  
object that doesn't go away, and have this ship the notificationa  
off to the correct object as long as it is still alive? The way  
this App is designed is I can tell if the object is allocated or  
not and if it is allocated, then I want it to receive notifications  
(In fact I ideally want it to get the last notifications sent  
regardless of if the receiver was dead or alive when the event  
occurred). At the moment I listen for the notification when the  
object is born and stop it listening when it dies. But when it it  
dies I have to save the data from the last notification somewhere  
and restore it when it is reincarnated. This is common to around 26  
classes and I don't want to change all 26 to do the above, I'd  
rather the last value was remembered by the source of the  
notification and resent somehow on request.


Any ideas?

Cheers
Dave


On 10 Sep 2013, at 12:08, Dave d...@looktowindward.com wrote:


Hi,

I have a crashing problem when calling postNotificationName, the  
following method is called from an Operation Queue method/thread.  
It is called on the Main Thread (the operation queue method, uses  
performSelectorOnMainThread which calls parseOperationCompleted  
below. I've tried copying theResultDictionary or just passing it  
in the dictionary as is, same result.


Any ideas what could be causing the crash?

-(void) parseOperationComplete:(NSDictionary*) theResultDictionary
{
myUserInfoDictionary = [[NSMutableDictionary alloc] init];
[myUserInfoDictionary setObject:self.pUpdateString

Re: @property and automatic synthesis of getters and setters.

2013-09-12 Thread Lee Ann Rucker


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. 

@property (readwrite, retain) protoCell;

_protoCell = [[Cell alloc] init];
self.protoCell = [[[Cell alloc] init] autorelease];
self.protoCell = [foo somethingThatReturnsAProtoCell]; // since getters 
generally do not provide a retained object; see earlier discussions today :)

self.protoCell = nil;
[_protoCell release]; _protoCell = nil;
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: @property and automatic synthesis of getters and setters.


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 usually is not 
 what you want for object instvars that you intend to own. 
 
 @property (readwrite, retain) protoCell;
 
 _protoCell = [[Cell alloc] init];
 self.protoCell = [[[Cell alloc] init] autorelease];
 self.protoCell = [foo somethingThatReturnsAProtoCell]; // since getters 
 generally do not provide a retained object; see earlier discussions today :)
 
 self.protoCell = nil;
 [_protoCell release]; _protoCell = nil;

Right, the original poster will need to decide which one has appropriate 
semantics for his situation. Just providing him with his two syntactic options. 
Since he is doing this work in an initializer, I suspect he will want direct 
ivar access. If he wants to use the property access and isn't using ARC, he 
will need the autorelease.

Aaron



___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashing Problem calling postNotificationName


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 is a singleton. If you subclass it, you now 
 must have two notification centers. 
 
 It has the facility to have different Centers (default etc.), so it's not
 a true singleton, although I  see what you mean. It doesn't have to be a
 subclass, just a class, but I think that either subclassing
 NSNotificationCenter or have a Category on it is better than having an
 anonymous object that calls [NSNotificationCenter defaultCenter], since
 at least it keeps all the notification code in one place.
 
 I'm not really sure what you're talking about with anonymous object
 that calls +defaultCenter. Every NSNotificationCenter call site gets a
 reference to the notification center by calling the class method.
 
 
 Which one is the right one to subscribe to? Do you only move notifications 
 over to it that need to be cached? Or all related notifications as well?
 
 
 That problem exists anyway, you have to know it's the default center for
 instance. This is just using related ones by virtue of the fact that the
 rest of the code doesn't use the subclass, only those that need to.
 
 If you only ever use the default center, you never have to worry about
 which notification center to listen to.
 
 There is a very large gulf in software design between one and many.
 Every time you want to cross that gulf you have to make decisions. More
 decisions lead to more bugs.
 
 
 This decision needs to be made on both ends of the notification.
 
 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.

No, I just remember the last value of the notification in my Center subclass, 
it doesn't go near the sender or care who the send is or was.

 Congratulations, you have taken an object whose purpose is to promote loose 
 coupling, and successfully turned it into a tool that tightly couples the 
 sender and the listener.
 
 The correct approach does not put the cache in the notification center, but 
 rather in the sender or the userInfo dictionary.
 
 --Kyle Sluder
 
 This is just not true! It's the opposite as far as I can see. If I hold
 the the data at the sender then from the receiver I have to know who
 sent the Notification in order to retrieve it,
 
 You already know that information. It's in the object property of the
 NSNotification object.

But I don't have the last NSNotification object, so where do I get it from? I 
get it from my Center Subclass or rather I get it's contents.

 also, there is more than
 one sender for the notification, so I would have add more code specific
 to a number of objects.
 
 Then put it in the userInfo. That's what it's there for.

But that's what I am retrieving!! I want the last UserInfo dict for the the 
notification. That is what I am storing in the Subclass.

 This way the receiver is coupled to the subclass
 
 No it's not.

Of course it is What else is it coupled to? It asks the subclass to send to 
provide the last value of the notification, so in my world it's coupled to that 
subclass which is a very slim wrapper around [NSNotificationCenter 
defaultCenter], so it coupled to that too, but it was anyway!

 which is not a lot different that the base class, and it could be coupled
 to that anyway, so I don't see the problem.
 
 it works like a treat and is really easy to adapt so I'd say the proof is
 in the pudding!
 
 And when you're scratching your head wondering why you're not getting
 notifications delivered to your objects, because they're being sent to a
 different notification center than the one you're listening to…

But I am getting notifications delivered to me! And they get sent to the same 
Notification Center, there is only one OS level Center used - the default.

 Either that or I'm sorely misunderstand how you propose to use
 subclasses of NSNotificationCenter.

All I have done is this:

(Copied from earlier email)

The only impact on NSNotificationCenter to the rest of the App is that in my 
subclass, I have overridden

- (void)postNotificationName:(NSString*) theName object:(id) theObject 
userInfo:(NSDictionary*) theUserInfoDictionary;

Which just stores the notification name and the User Info dictionary in a 
private dictionary and then call Super.



And added these two methods. plus another one that just enables the remember 
function. In fact I don't need to add the code to the receivers at all! I can 
just call repostNotiticationName once and it will fire off to all the receivers 
in one go!!! How about that for a bonus?!?

+(void) repostNotiticationName:(NSString*) theName; 
 // Reposts the  UserInfo stored the private dict

Re: NSTabView


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 managed and operates purely internally.

What are you trying to do? There may be another way, e.g. override [NSTabView 
selectTabViewItem:] though that particular case is better handled by using a 
delegate.

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: 64-bit iOS

2013-09-12 Thread Charles Srstka

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 such as ARC, the non-fragile ABI, 
etc. that only work in 64-bit have pretty much led to most new development 
being for 64-bit only.

Charles

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 what 
 setEventTypes: is doing, it would complain about setEventTypes:, which it's 
 not doing, it's complaining about a caller. That method doesn't return 
 anything and has no special naming so the analyser will presume it correctly 
 to do nothing net-net to its argument. 
 
 -eventTypes doesn't need the new or copy because it does not return an object 
 owned by the caller. Whether the object it returns is already owned by itself 
 to be released later is irrelevant, the refcount has not been increased 
 before return to the caller so the method is correctly named and the analyser 
 can properly assume it to be a +0 method. And apart from that it's not even 
 called in the piece of code in question so that's not really relevant.


I don't follow you. -setEventTypes: is properly named and properly written. It 
is (except for the last statement) standard setter code. One would not expect 
an error here. It increases the refcount of the newly created object passed in 
the parameter and assigned to the iVar by calling -retain on it. The object 
that is released in -setEventTypes: is a different object, the old iVar. For 
code that refers to an iVar without regard to what object is assigned to it, 
you are correct that the net effect on the iVar's refcount is 0. This is a 
great convenience for most code. But for unusual code like the example given, 
where a new object is being created to replace the object currently assigned to 
iVar, care must be taken to distinguish between the different objects.

-eventTypes creates the new object with a refcount of 1 by calling 
-newEventTypes, and then it increments its refcount by 1 by calling 
-setEventTypes:. The new object now has a refcount of 2. The release of the new 
object at the end of -eventTypes drops it back to 1. That is 1 more than it was 
before -eventTypes was called, because the new object didn't exist before 
-eventTypes was called.

-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 -setEventTypes:, decreases its refcount by 1 to balance the 
second increase, and returns it with a refcount of 1 without autoreleasing it. 
It does own the new object, and the method should have new in its name.

The fact that -setEventTypes: releases the old object that was formerly held by 
the iVar isn't relevant to the Analyzer. It's the new object created in 
-eventTypes by the call to -newEventTypes that the Analyzer cares about. It is 
doing nothing more nor less than enforcing a naming convention. Fix the name 
and the Analyzer is happy. No need to change the code, because the code is 
correct.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Arraycontroller and CoreData

2013-09-12 Thread Benjamin Rindt

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 array controller to fetch: ?

Next thing is, when new Items are added to the collection view, it should 
automatically change.
A binding of the collection view is enough? Something like [collectionview 
bind: toObject:….]

And, for now I add data to my core data database with 
insertNewObjectForEntityForName. Is that okay or should I add it with the array 
controller's add oder insertObject methods? The new entries have to keep their 
relationships and I don't know how I can define them with the array controller 
methods. 


Thanks in advance!
Benjamin
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?


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 and name it thus, the caller would assume that it's their 
job to release the returned value. If they did that, it would leave mEventTypes 
dangling, and a later call to -release in -dealloc would crash due to an 
overrelease. So renaming the method is wrong on both counts.

--Graham


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

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 : NSObject
@property (nonatomic, strong) NSObject* object;
- (NSObject*)newObject;
@end

@implementation MWObject

@synthesize object=_object;

- (void)dealloc
{
[super dealloc];
[_object release];
}

- (NSObject*)newObject
{
return [[NSObject alloc] init];
}

- (void)setObject:(NSObject *)object
{
[_object release];
_object = [object retain];//3
}

- (NSObject*)object
{
NSObject* theObject = [self newObject];
[self setObject:theObject];//2
[theObject release];//1

return _object;
}

@end

Version 0: as above and we do not get a warning (I believe the memory 
management is correct even if the semantics may be a little odd).
Version 1: Comment out line 1 and we do not get a warning (I would have 
suspected a leak of the theObject).
Version 2: Comment out lines 1 and 2 and we now get a warning (expected).
Version 3: Comment out lines 1 and 3 and we now get a warning (expected).

So somehow the retain call in the setObject: method is causing the release 
call in the object method to be ignored. As long as the compiler sees the 
retain on line 3, the inclusion or exclusion of the release on line 1 doesn't 
seem to matter. Something is pretty clearly confused because Version 0 and 
Version 1 cannot both have correct memory management.

Aaron

On Sep 12, 2013, at 7:42 AM, Fritz Anderson anderson.fr...@gmail.com wrote:

 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 differently. mEventTypes is an ivar.
 
 - (void)setEventTypes:(NSDictionary*)eventTypes
 {
  if (eventTypes != mEventTypes)
  {
  [mEventTypes release];
  mEventTypes = [eventTypes retain];
  }
  InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
  if (mEventTypes == nil)
  {
  [self loadNib];
  
  NSDictionary* eventTypes = [self newEventTypes];
  [self setEventTypes:eventTypes];
  [eventTypes release];
  }
  return mEventTypes; //- analyser complains here
 }
 
 - (NSDictionary*)newEventTypes
 {
  //[code deleted that presets contents of 'eventTypes']
 
  // Method name begins with new; clients are responsible for releasing.
  return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }
 
 I tried a Foundation-tool project that included a class with the methods you 
 show, dummying the methods and functions not shown as empty 
 void-returning-void, and dictionary data as one string-keying-string. ARC off.
 
 Running this through a later version of clang showed no analyzer errors. I 
 think it's a bug in the version of clang you're using. Or: clang does 
 cross-function checks to one degree or another. Can you make a minimal 
 example, and add the code you omitted here to see what makes the analyzer 
 unhappy?
 
 I assume you expanded the note and examined the code path on which the 
 compiler saw a potential problem?
 
   — F
 
 
 ___
 
 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.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
 
 This email sent to eey...@monsterworks.com


___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?

2013-09-12 Thread Kyle Sluder

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. mEventTypes is an ivar.
 
 - (void)setEventTypes:(NSDictionary*)eventTypes
 {
   if (eventTypes != mEventTypes)
   {
   [mEventTypes release];
   mEventTypes = [eventTypes retain];
   }
   InitializePrefsForEventTypeNames();
 }
 
 - (NSDictionary*)eventTypes
 {
   if (mEventTypes == nil)
   {
   [self loadNib];
   
   NSDictionary* eventTypes = [self newEventTypes];
   [self setEventTypes:eventTypes];
   [eventTypes release];
   }
   
   return mEventTypes; //- analyser complains here
 }
 
 
 
 - (NSDictionary*)newEventTypes
 {
   //[code deleted that presets contents of 'eventTypes']
 
   // Method name begins with new; clients are responsible for releasing.
   return [[NSDictionary alloc] initWithDictionary:eventTypes];
 }

Looks like an analyzer bug. Your code is correct, but I bet the call to
-setEventTypes from within -eventTypes is throwing it off.

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 I would factor out the common
setter code to a private helper method.

Hopefully this has the side effect of shutting the analyzer up.

--Kyle Sluder
___

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.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Analyser reports memory leak… where?