NSNotification coalescing - which one gets through?

[Jonathan Taylor]

I am trying to work out whether there are any rules that define which of 
multiple NSNotifications combined using coalescing actually get through to the 
receivers, and preferably a way of controlling that behaviour. This becomes 
relevant if for example there is different UserInfo associated with each 
object. I can’t find any specific statement about what the behaviour is under 
these circumstances.

A concrete example: frames are received from a video camera, and a notification 
(with coalescing) is sent when each one arrives (with a pointer to the actual 
frame object in the user data of the NSNotification). Listeners may wish to 
update their own displayed image if spare cycles are available. However a quick 
experiment suggests that the EARLIEST-posted notification is the one that 
survives coalescing. That means that receivers are acting on stale information. 
No doubt there are some different circumstances where it might make sense to 
keep the earliest-posted notification, but in this case I’d definitely like the 
most-recently posted to make it through. 

I can think of several ways of achieving what I want with the help of 
additional code, but is there any way I can get the NSNotification 
infrastructure to behave the way I want (coalescing keeps the most 
recently-posted notification and discards older ones)?

Thanks for any suggestions!
Jonny.
___

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: NSNotification coalescing - which one gets through?

[Jonathan Taylor]

Actually I think I may have answered my own question: calling 
dequeueNotificationsMatching immediately before posting a new notification 
seems to do the trick. This seems like a reasonable and logical way of 
achieving what I want. Can anyone see any problem with doing that?

On 6 May 2015, at 11:54, Jonathan Taylor  wrote:

> I am trying to work out whether there are any rules that define which of 
> multiple NSNotifications combined using coalescing actually get through to 
> the receivers, and preferably a way of controlling that behaviour. This 
> becomes relevant if for example there is different UserInfo associated with 
> each object. I can’t find any specific statement about what the behaviour is 
> under these circumstances.
> 
> A concrete example: frames are received from a video camera, and a 
> notification (with coalescing) is sent when each one arrives (with a pointer 
> to the actual frame object in the user data of the NSNotification). Listeners 
> may wish to update their own displayed image if spare cycles are available. 
> However a quick experiment suggests that the EARLIEST-posted notification is 
> the one that survives coalescing. That means that receivers are acting on 
> stale information. No doubt there are some different circumstances where it 
> might make sense to keep the earliest-posted notification, but in this case 
> I’d definitely like the most-recently posted to make it through. 
> 
> I can think of several ways of achieving what I want with the help of 
> additional code, but is there any way I can get the NSNotification 
> infrastructure to behave the way I want (coalescing keeps the most 
> recently-posted notification and discards older ones)?
> 
> Thanks for any suggestions!
> Jonny.

___

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

Grabbing window - The contents of this window cannot be shared

[Andreas Höschler]

Hi all,

I have developed an app with an NSWindow containing a NSScrollView subclass for 
the document window. When I ry to grab this window with Grab.app for 
documentation purposes, Grab.app tells me

The window could not be captured
The contents of this window cannot be shared

I get this when grabbing this special window of my app only. All others windows 
in my app and other apps work. Any idea what is blocking Grab.app from taking a 
picture of my window? This works on MacOSX 10.6 but on Yosemite I get the above 
error message. This must be some recently invented security mechanism (delegate 
method of NSWindow or who knows what). 

I goggled for the above error message but found nothing helpful. Any idea?

Thanks a lot,

 Andreas




___

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: Grabbing window - The contents of this window cannot be shared

[Uli Kusterer]

On 06 May 2015, at 14:09, Andreas Höschler  wrote:
> Hi all,
> 
> I have developed an app with an NSWindow containing a NSScrollView subclass 
> for the document window. When I ry to grab this window with Grab.app for 
> documentation purposes, Grab.app tells me
> 
>   The window could not be captured
>   The contents of this window cannot be shared
> 
> I get this when grabbing this special window of my app only. All others 
> windows in my app and other apps work. Any idea what is blocking Grab.app 
> from taking a picture of my window? This works on MacOSX 10.6 but on Yosemite 
> I get the above error message. This must be some recently invented security 
> mechanism (delegate method of NSWindow or who knows what). 
> 
> I goggled for the above error message but found nothing helpful. Any idea?
> 
> Thanks a lot,

 This is usually controlled by NSWindow's sharingType property. Are you perhaps 
setting this somewhere in your code by accident? I don't see a way to set it 
from a XIB, but maybe the property is written anyway and you have a corrupted 
XIB?

-- Uli
http://stacksmith.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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Uli Kusterer]

On 05 May 2015, at 18:26, Jens Alfke  wrote:
> I haven't done much AppKit work in a while. Right now I have a small app 
> where I'm trying to do something very simple: put a custom NSView in a window 
> and make it scrollable. The view determines its own frame size based on the 
> content it needs to display. So all I did was create a new window in IB, add 
> an instance of my view, embed it in an NSScrollView, and set up default 
> constraints for the scroll view so it'll track the window size.

 So you're not setting a constraint on the *document* view? How do you expect 
it to know how to constrain that view otherwise? Have you tried doing that? 
IIRC you need to implement updateConstraints to create proper constraints, or 
intrinsicContentSize, or maybe both.
___

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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Uli Kusterer]

On 06 May 2015, at 03:21, Jens Alfke  wrote:
>> Constrain your view to the top, right and left of the clipview but not the 
>> bottom. 

 I have never had to do this. What are you trying to fix with this?
___

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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Roland King]

> On 6 May 2015, at 23:39, Uli Kusterer  wrote:
> 
> On 06 May 2015, at 03:21, Jens Alfke  > wrote:
>>> Constrain your view to the top, right and left of the clipview but not the 
>>> bottom. 
> 
>  I have never had to do this. What are you trying to fix with this?

The fact that IB adds no constraints to NSScrollViews at all so the completely 
and totally do not work in any way whatsoever unless you add the constraints. 
___

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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Uli Kusterer]

> On 06 May 2015, at 17:41, Roland King  wrote:
> 
> 
>> On 6 May 2015, at 23:39, Uli Kusterer  wrote:
>> 
>> On 06 May 2015, at 03:21, Jens Alfke > > wrote:
 Constrain your view to the top, right and left of the clipview but not the 
 bottom. 
>> 
>> I have never had to do this. What are you trying to fix with this?
> 
> The fact that IB adds no constraints to NSScrollViews at all so the 
> completely and totally do not work in any way whatsoever unless you add the 
> constraints. 

 To the scroll view and content view I understand. But the clip view?


___

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

iOS firing an event in the future when an app is in the background

[Alex Zavatone]

iOS 7/8, Xcode 6.2

I'm looking into performing an event in the future on iOS very likely when the 
app may be in the background, possibly up to 24 hours in the future.

I'm looking at using an NSTimer, performSelectorAfterDelay, or GDC's 
dispatch_after.

Looking at all the caveats for background modes, I'm not sure the best path to 
proceed that will waste the least of my time in getting this to work reliably.

The requirement is to call one selector with one NSString parameter.

If the app is getting CLLocation updates in the background, is it safer to 
manually perform a check within locationManager:didUpdateLocations even n 
seconds than to expect a background event to fire up to 24 hours in the future?

Thanks in advance,
Alex Zavatone



___

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: iOS firing an event in the future when an app is in the background

[Roland King]

> On 7 May 2015, at 00:08, Alex Zavatone  wrote:
> 
> iOS 7/8, Xcode 6.2
> 
> I'm looking into performing an event in the future on iOS very likely when 
> the app may be in the background, possibly up to 24 hours in the future.
> 
> I'm looking at using an NSTimer, performSelectorAfterDelay, or GDC's 
> dispatch_after.
> 
> Looking at all the caveats for background modes, I'm not sure the best path 
> to proceed that will waste the least of my time in getting this to work 
> reliably.
> 
> The requirement is to call one selector with one NSString parameter.
> 
> If the app is getting CLLocation updates in the background, is it safer to 
> manually perform a check within locationManager:didUpdateLocations even n 
> seconds than to expect a background event to fire up to 24 hours in the 
> future?
> 
> Thanks in advance,
> Alex Zavatone

Not wishing to waste your time. There is no background mode which gives you 
NSTimer or dispatch_after() firings when backgrounded. This is why writing 
standalone alarmclock apps in iOS isn’t really possible. If you want someone to 
be alerted at a given time, set a notification to alert them at that time. If 
you want to check when the app comes back in the foreground that they should 
know something happened, check it then. If you want to check something at a 
given time and decide whether or not to alert .. I think you are SOL. 

If you are getting CLLocation updates and the randomness of those is fine 
enough grained to do what you want, use that, be aware that using background 
location is subject to app review and the primary use of background location 
must be because you need location in the background. I suspect in your case it 
is. 
___

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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Jens Alfke]

> On May 6, 2015, at 8:36 AM, Uli Kusterer  wrote:
> 
> So you're not setting a constraint on the *document* view? How do you expect 
> it to know how to constrain that view otherwise?

The size of the document view is fundamentally unrelated to the size of the 
clip or scroll view — the whole point of having a scroll view is that you have 
an arbitrarily large document! So I wouldn’t expect the scroll view to be 
trying to constrain the size of the document view at all. The app code is in 
charge of deciding how big the document view is, based on the content it 
displays.

[OK, in some cases the width of the content view is limited to the width of the 
clip view. Not in my case though; it scrolls horizontally as well as 
vertically.]

> IIRC you need to implement updateConstraints to create proper constraints, or 
> intrinsicContentSize, or maybe both.

I’ve never seen the intrinsicContentSize property before (partly because it’s 
not defined in NSView.h.) Reading the docs for it, it makes sense that I’d 
override it. And searching the docs for that name I found the “Auto Layout 
Guide”, which looks very useful but which I wouldn’t have found otherwise 
because I didn’t know to look for the keyword “auto layout” (everywhere else 
it’s called “constraints”…)

—Jens
___

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: iOS firing an event in the future when an app is in the background

[Jens Alfke]

> On May 6, 2015, at 9:08 AM, Alex Zavatone  wrote:
> 
> I'm looking into performing an event in the future on iOS very likely when 
> the app may be in the background, possibly up to 24 hours in the future.

Keep in mind that your app isn’t even running when it’s in the background on 
iOS. It’s not just that it’s threads are idle — the process is literally not 
being scheduled by the kernel to get any CPU time. That’s why in-process 
triggers like delayed-perform or dispatch_after are useless. The only things 
that will wake your app up in this state are _external_ events like local 
notifications or CoreLocation events, which will get the OS to unfreeze your 
process.

—Jens
___

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: NSNotification coalescing - which one gets through?

[Seth Willits]

On May 6, 2015, at 3:54 AM, Jonathan Taylor  
wrote:

> I am trying to work out whether there are any rules that define which of 
> multiple NSNotifications combined using coalescing actually get through to 
> the receivers, and preferably a way of controlling that behaviour. This 
> becomes relevant if for example there is different UserInfo associated with 
> each object. I can’t find any specific statement about what the behaviour is 
> under these circumstances.

My interpretation of the API is that user info should either be consistent or 
not used in coalescing scenarios, though the documentation never discusses this.


> Actually I think I may have answered my own question: calling 
> dequeueNotificationsMatching immediately before posting a new notification 
> seems to do the trick. This seems like a reasonable and logical way of 
> achieving what I want. Can anyone see any problem with doing that?

Nope. Seems fine to me.

The other way to accomplish is this is to have the data stored outside of the 
notification and accessible to the receivers, and just let the notifications 
coalesce as normal. Instead of looking in userInfo, the receivers would go pull 
the data from the other source. But whether that's a better fit is questionable 
based on circumstances.



--
Seth Willits





--
Seth Willits




___

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

static analyzers says I'm leaking, I _think_ I'm not

[Michael David Crawford]

I've had problems in the past where I failed to understand the Cocoa
ownership conventions, I'm willing to grant that could be the case.

I know for sure that the analyzer enforces the naming conventions,
that is, the exact same function names in C or C++ won't yield that
same warnings as "alloc", "new" or "copy" would in Objective-C.

I'm reluctant to use ARC because in my honest opinion, ARC will get
the leaks and most out of the crashes out of skanky code.  If you
don't use ARC, you get them out by fixing the skank:

  "Dave, why do you add twelve extra bytes to all of Spellswell's allocations?"

  "That was so Spellswell would stop crashing."  Facepalm.

// LifeGrid.h
@property (assign, nonatomic) GridCycler *cycler;

// Lifegrid.m - init
 self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
leak of an object
 if ( nil == self.cycler ) goto cycler_failed;

// dealloc
[self.cycler release];

Expanding the "potential leak" message yields:

1. assuming 'self' is not nil

2. method returns Objective-C object with +1 retain count

3. Object leaked: allocated object is not references later in this
execution path and has a retain count of +1.

Isn't that what I want?  I should be taking ownership of it with
"alloc/initWithGrid".

(initWithGrid doesn't do a cyclic retain.)

Thanks,

Mike

Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.
___

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: static analyzers says I'm leaking, I _think_ I'm not

[Greg Parker]

> On May 6, 2015, at 1:57 PM, Michael David Crawford  
> wrote:
> 
> // LifeGrid.h
> @property (assign, nonatomic) GridCycler *cycler;
> 
> // Lifegrid.m - init
> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
> leak of an object
> if ( nil == self.cycler ) goto cycler_failed;
> 
> // dealloc
> [self.cycler release];
> 
> Expanding the "potential leak" message yields:
> 
> 1. assuming 'self' is not nil
> 
> 2. method returns Objective-C object with +1 retain count
> 
> 3. Object leaked: allocated object is not references later in this
> execution path and has a retain count of +1.
> 
> Isn't that what I want?  I should be taking ownership of it with
> "alloc/initWithGrid".
> 
> (initWithGrid doesn't do a cyclic retain.)

Which version of Xcode are you using? The static analyzer in Xcode 6.3 has 
several bugs in retain count analysis and not all of them are fixed in Xcode 
6.3.1.


-- 
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: static analyzers says I'm leaking, I _think_ I'm not

[Michael David Crawford]

This is 6.2.  I speculated a different diagnostic was a bug; were it
correct, I would have seen that same diagnostic on some other code.

I'll file a radar with a minimal test case if you'd like me to.

I'll download 6.3.1 right now.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, May 6, 2015 at 2:12 PM, Greg Parker  wrote:
>
>> On May 6, 2015, at 1:57 PM, Michael David Crawford  
>> wrote:
>>
>> // LifeGrid.h
>> @property (assign, nonatomic) GridCycler *cycler;
>>
>> // Lifegrid.m - init
>> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
>> leak of an object
>> if ( nil == self.cycler ) goto cycler_failed;
>>
>> // dealloc
>> [self.cycler release];
>>
>> Expanding the "potential leak" message yields:
>>
>> 1. assuming 'self' is not nil
>>
>> 2. method returns Objective-C object with +1 retain count
>>
>> 3. Object leaked: allocated object is not references later in this
>> execution path and has a retain count of +1.
>>
>> Isn't that what I want?  I should be taking ownership of it with
>> "alloc/initWithGrid".
>>
>> (initWithGrid doesn't do a cyclic retain.)
>
> Which version of Xcode are you using? The static analyzer in Xcode 6.3 has 
> several bugs in retain count analysis and not all of them are fixed in Xcode 
> 6.3.1.
>
>
> --
> 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: static analyzers says I'm leaking, I _think_ I'm not

[Greg Parker]

> On May 6, 2015, at 2:17 PM, Michael David Crawford  
> wrote:
> 
> This is 6.2.  I speculated a different diagnostic was a bug; were it
> correct, I would have seen that same diagnostic on some other code.
> 
> I'll file a radar with a minimal test case if you'd like me to.
> 
> I'll download 6.3.1 right now.

Try Xcode 6.3.1 first. If that still fails then please file a bug report with a 
sample project that demonstrates the failure.


-- 
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: static analyzers says I'm leaking, I _think_ I'm not

[Ken Thomases]

On May 6, 2015, at 3:57 PM, Michael David Crawford  wrote:

> // LifeGrid.h
> @property (assign, nonatomic) GridCycler *cycler;
> 
> // Lifegrid.m - init
> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
> leak of an object
> if ( nil == self.cycler ) goto cycler_failed;
> 
> // dealloc
> [self.cycler release];
> 
> Expanding the "potential leak" message yields:
> 
> 1. assuming 'self' is not nil
> 
> 2. method returns Objective-C object with +1 retain count
> 
> 3. Object leaked: allocated object is not references later in this
> execution path and has a retain count of +1.
> 
> Isn't that what I want?  I should be taking ownership of it with
> "alloc/initWithGrid".
> 
> (initWithGrid doesn't do a cyclic retain.)

You are probably also getting an analyzer warning in -dealloc saying the getter 
of self.cycler returns an object you don't own so you're not entitled to 
release it.

What you're doing will not be a leak if the cycler property is implemented in 
the "normal" way.  But what if -setCycler: stores something derived from but 
not the same as what was passed in?  Then, you would fail to release what was 
passed in (the leak) and you'd be releasing something which you don't own in 
-dealloc.

Now, you may be thinking that the code for the cycler property is all right in 
this same class.  It's likely even auto-synthesized by the compiler so you have 
no hand in it.  But what if there were a subclass which overrides the 
accessors?  What if the subclass's -setCycler: took the passed-in object, 
created a new object that was a tweaked version of it, and passed the new 
object to the superclass's -setCycler:?

If you're looking to make this code better, change the property to be strong.  
Change this line:

self.cycler = [[GridCycler alloc] initWithGrid: self];

to

self.cycler = [[[GridCycler alloc] initWithGrid: self] autorelease];

and, in -dealloc, release the instance variable, not the result of the getter.

Regards,
Ken


___

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: static analyzers says I'm leaking, I _think_ I'm not

[John McCall]

> On May 6, 2015, at 1:57 PM, Michael David Crawford  
> wrote:
> I've had problems in the past where I failed to understand the Cocoa
> ownership conventions, I'm willing to grant that could be the case.
> 
> I know for sure that the analyzer enforces the naming conventions,
> that is, the exact same function names in C or C++ won't yield that
> same warnings as "alloc", "new" or "copy" would in Objective-C.
> 
> I'm reluctant to use ARC because in my honest opinion, ARC will get
> the leaks and most out of the crashes out of skanky code.  If you
> don't use ARC, you get them out by fixing the skank:
> 
>  "Dave, why do you add twelve extra bytes to all of Spellswell's allocations?"
> 
>  "That was so Spellswell would stop crashing."  Facepalm.
> 
> // LifeGrid.h
> @property (assign, nonatomic) GridCycler *cycler;
> 
> // Lifegrid.m - init
> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
> leak of an object
> if ( nil == self.cycler ) goto cycler_failed;
> 
> // dealloc
> [self.cycler release];
> 
> Expanding the "potential leak" message yields:
> 
> 1. assuming 'self' is not nil
> 
> 2. method returns Objective-C object with +1 retain count
> 
> 3. Object leaked: allocated object is not references later in this
> execution path and has a retain count of +1.
> 
> Isn't that what I want?  I should be taking ownership of it with
> "alloc/initWithGrid".
> 
> (initWithGrid doesn't do a cyclic retain.)

“cycler” is really a strong property (because you release its value in 
-dealloc), but you’ve declared it as assign, which means the synthesized setter 
won’t retain the new value or release the old value.  One way of looking at 
this is that the setter takes its argument at +1 and has a precondition that 
the property is currently set to nil.  Another way of looking at it is that the 
setter is buggy.

You should probably make the property readonly and just directly assign to the 
ivar in -init.

John.
___

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: static analyzers says I'm leaking, I _think_ I'm not

[Michael David Crawford]

John McCall wrote:

> You should probably make the property readonly and just directly assign to 
> the ivar in -init.

That works.

In this particular case, it might make more sense for my property to
be just a regular ivar, without a getter and setter.  That is, my grid
object owns a cycler object, client code turns the cycler on and off,
adjusts its speed and so on.  My code might be easier to maintain if
the grid exposed an interface to do all that.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, May 6, 2015 at 2:21 PM, John McCall  wrote:
>> On May 6, 2015, at 1:57 PM, Michael David Crawford  
>> wrote:
>> I've had problems in the past where I failed to understand the Cocoa
>> ownership conventions, I'm willing to grant that could be the case.
>>
>> I know for sure that the analyzer enforces the naming conventions,
>> that is, the exact same function names in C or C++ won't yield that
>> same warnings as "alloc", "new" or "copy" would in Objective-C.
>>
>> I'm reluctant to use ARC because in my honest opinion, ARC will get
>> the leaks and most out of the crashes out of skanky code.  If you
>> don't use ARC, you get them out by fixing the skank:
>>
>>  "Dave, why do you add twelve extra bytes to all of Spellswell's 
>> allocations?"
>>
>>  "That was so Spellswell would stop crashing."  Facepalm.
>>
>> // LifeGrid.h
>> @property (assign, nonatomic) GridCycler *cycler;
>>
>> // Lifegrid.m - init
>> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
>> leak of an object
>> if ( nil == self.cycler ) goto cycler_failed;
>>
>> // dealloc
>> [self.cycler release];
>>
>> Expanding the "potential leak" message yields:
>>
>> 1. assuming 'self' is not nil
>>
>> 2. method returns Objective-C object with +1 retain count
>>
>> 3. Object leaked: allocated object is not references later in this
>> execution path and has a retain count of +1.
>>
>> Isn't that what I want?  I should be taking ownership of it with
>> "alloc/initWithGrid".
>>
>> (initWithGrid doesn't do a cyclic retain.)
>
> "cycler" is really a strong property (because you release its value in 
> -dealloc), but you've declared it as assign, which means the synthesized 
> setter won't retain the new value or release the old value.  One way of 
> looking at this is that the setter takes its argument at +1 and has a 
> precondition that the property is currently set to nil.  Another way of 
> looking at it is that the setter is buggy.
>
> You should probably make the property readonly and just directly assign to 
> the ivar in -init.
>
> John.

___

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: static analyzers says I'm leaking, I _think_ I'm not

[Aaron Montgomery]

If the property is set to "retain", then the line

self.cycler = [[[….initWithGrid:self] autorelease]

will cause the setter to retain the passed in object, so after this line, 
_cycler will have a (heuristic) retain count of 2 (an alloc and a retain).

After this, when the autorelease pool is drained, reducing the (heuristic) 
retain count by 1: you've still got a hold of it in the property.

Then in dealloc, you release the object in dealloc to reduce the (heuristic) 
retain count to 0.

To release the object, you can use

[_cycler release];

or

self.cycler = nil;

or you may be able to not even bother if you won't create a cycle, I haven't 
done manual memory in a while, but I think retained properties are released at 
destruction automatically.

Aaron

> On May 6, 2015, at 2:30 PM, Michael David Crawford  
> wrote:
> 
> Am I correct that autoreleased objects are released after each round
> of even processing?
> 
> In this case my cycler needs to hang around for the life of the whole program.
> 
> Thanks,
> 
> Mike
> Michael David Crawford, Consulting Software Engineer
> mdcrawf...@gmail.com
> http://www.warplife.com/mdc/
> 
>   Available for Software Development in the Portland, Oregon Metropolitan
> Area.
> 
> 
> On Wed, May 6, 2015 at 2:25 PM, Aaron Montgomery
>  wrote:
>> Having cycler set to "assign" and then releasing it in dealloc doesn't feel 
>> right. Why not set cycler to "retain", add an autorelease in init then 
>> release _cycler in dealloc?
>> 
>> Aaron
>> 
>> 
>>> On May 6, 2015, at 1:57 PM, Michael David Crawford  
>>> wrote:
>>> 
>>> I've had problems in the past where I failed to understand the Cocoa
>>> ownership conventions, I'm willing to grant that could be the case.
>>> 
>>> I know for sure that the analyzer enforces the naming conventions,
>>> that is, the exact same function names in C or C++ won't yield that
>>> same warnings as "alloc", "new" or "copy" would in Objective-C.
>>> 
>>> I'm reluctant to use ARC because in my honest opinion, ARC will get
>>> the leaks and most out of the crashes out of skanky code.  If you
>>> don't use ARC, you get them out by fixing the skank:
>>> 
>>> "Dave, why do you add twelve extra bytes to all of Spellswell's 
>>> allocations?"
>>> 
>>> "That was so Spellswell would stop crashing."  Facepalm.
>>> 
>>> // LifeGrid.h
>>> @property (assign, nonatomic) GridCycler *cycler;
>>> 
>>> // Lifegrid.m - init
>>> self.cycler = [[GridCycler alloc] initWithGrid: self];  // Potential
>>> leak of an object
>>> if ( nil == self.cycler ) goto cycler_failed;
>>> 
>>> // dealloc
>>> [self.cycler release];
>>> 
>>> Expanding the "potential leak" message yields:
>>> 
>>> 1. assuming 'self' is not nil
>>> 
>>> 2. method returns Objective-C object with +1 retain count
>>> 
>>> 3. Object leaked: allocated object is not references later in this
>>> execution path and has a retain count of +1.
>>> 
>>> Isn't that what I want?  I should be taking ownership of it with
>>> "alloc/initWithGrid".
>>> 
>>> (initWithGrid doesn't do a cyclic retain.)
>>> 
>>> Thanks,
>>> 
>>> Mike
>>> 
>>> Michael David Crawford, Consulting Software Engineer
>>> mdcrawf...@gmail.com
>>> http://www.warplife.com/mdc/
>>> 
>>>  Available for Software Development in the Portland, Oregon Metropolitan
>>> Area.
>>> ___
>>> 
>>> 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: static analyzers says I'm leaking, I _think_ I'm not

[Ken Thomases]

On May 6, 2015, at 4:40 PM, Aaron Montgomery  wrote:

> If the property is set to "retain", then the line
> 
> self.cycler = [[[….initWithGrid:self] autorelease]
> 
> will cause the setter to retain the passed in object, so after this line, 
> _cycler will have a (heuristic) retain count of 2 (an alloc and a retain).
> 
> After this, when the autorelease pool is drained, reducing the (heuristic) 
> retain count by 1: you've still got a hold of it in the property.
> 
> Then in dealloc, you release the object in dealloc to reduce the (heuristic) 
> retain count to 0.

Or, in other words, sending an object -autorelease is just like sending it a 
-release only the effect is delayed.

A combined alloc/init/autorelease balances itself.  A strong (or "retain") 
property will be balanced if the setter is written properly (which a 
synthesized setter will be) and you release in -dealloc.

> To release the object, you can use
> 
> [_cycler release];
> 
> or
> 
> self.cycler = nil;

Better to use the former in case the setter (in this class or a subclass) does 
extra work that wouldn't be appropriate during deallocation.

> or you may be able to not even bother if you won't create a cycle, I haven't 
> done manual memory in a while, but I think retained properties are released 
> at destruction automatically.

No, in manual retain-release, nothing is released automatically.  In -dealloc, 
you have to explicitly release the objects you own.

Regards,
Ken


___

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: static analyzers says I'm leaking, I _think_ I'm not

[Michael David Crawford]

I agree that it's inappropriate to expect that the analyzer will
assume that the getters and setters work the way they conventionally
do.  One reason we have properties is so that, when required, they can
do other things:

- (void) setAdversary: (int)enemy
{
_enemy = enemy;

[_enemy setUpTheBomb];
}


Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/

   Available for Software Development in the Portland, Oregon Metropolitan
Area.


On Wed, May 6, 2015 at 2:54 PM, Ken Thomases  wrote:
> On May 6, 2015, at 4:40 PM, Aaron Montgomery  wrote:
>
>> If the property is set to "retain", then the line
>>
>> self.cycler = [[[initWithGrid:self] autorelease]
>>
>> will cause the setter to retain the passed in object, so after this line, 
>> _cycler will have a (heuristic) retain count of 2 (an alloc and a retain).
>>
>> After this, when the autorelease pool is drained, reducing the (heuristic) 
>> retain count by 1: you've still got a hold of it in the property.
>>
>> Then in dealloc, you release the object in dealloc to reduce the (heuristic) 
>> retain count to 0.
>
> Or, in other words, sending an object -autorelease is just like sending it a 
> -release only the effect is delayed.
>
> A combined alloc/init/autorelease balances itself.  A strong (or "retain") 
> property will be balanced if the setter is written properly (which a 
> synthesized setter will be) and you release in -dealloc.
>
>> To release the object, you can use
>>
>> [_cycler release];
>>
>> or
>>
>> self.cycler = nil;
>
> Better to use the former in case the setter (in this class or a subclass) 
> does extra work that wouldn't be appropriate during deallocation.
>
>> or you may be able to not even bother if you won't create a cycle, I haven't 
>> done manual memory in a while, but I think retained properties are released 
>> at destruction automatically.
>
> No, in manual retain-release, nothing is released automatically.  In 
> -dealloc, you have to explicitly release the objects you own.
>
> Regards,
> Ken
>
___

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: Help: NSScrollView is resizing its documentView down to (0, 0)

[Luther Baker]

On Wed, May 6, 2015 at 11:54 AM, Jens Alfke  wrote:

>
> > On May 6, 2015, at 8:36 AM, Uli Kusterer 
> wrote:
> >
> > So you're not setting a constraint on the *document* view? How do you
> expect it to know how to constrain that view otherwise?
>
> The size of the document view is fundamentally unrelated to the size of
> the clip or scroll view — the whole point of having a scroll view is that
> you have an arbitrarily large document! So I wouldn’t expect the scroll
> view to be trying to constrain the size of the document view at all. The
> app code is in charge of deciding how big the document view is, based on
> the content it displays.
>

I'm probably missing something ... but fundamentally, the whole point of
constraints between the scrollview and its children is so that the
scrollview knows how big to make its contentSize. It sounds like you've got
this flipped ... the scrollview is not trying to constrain the size of the
document at all - when using autolayout, the scrollview is dynamically
trying to determine it's *own* contentSize. I know you skipped that report
I sent you - but by doing so, I think you're missing some helpful insight.
You post sounds like you're just frustrated it didn't just work in IB ...
and you're upset you've finally got to actually learn about this
new-fangled layout paradigm.


> > IIRC you need to implement updateConstraints to create proper
> constraints, or intrinsicContentSize, or maybe both.
>
> I’ve never seen the intrinsicContentSize property before (partly because
> it’s not defined in NSView.h.)


This is Autolayout 101 stuff. 2013. Admittedly, maybe you're not doing much
iOS work ... but this was all part of the replacement for the UIView
sizeThatFits frame stuff. There an ecosystem here of how all this works
together.


> Reading the docs for it, it makes sense that I’d override it. And
> searching the docs for that name I found the “Auto Layout Guide”, which
> looks very useful but which I wouldn’t have found otherwise because I
> didn’t know to look for the keyword “auto layout” (everywhere else it’s
> called “constraints”…


"Autolayout" is not a new term :-) ... What do you mean "everywhere" ...
and what is "its"?

Take heart Jens! I'd suggest that it isn't quite as difficult as your
thread alludes to. It isn't an old timer thing either ... but it does take
some understanding and experimentation. Its an abstraction over frames. Its
a level of indirection ... and I'm am sorry that IB doesn't just handle it
automatically. Indeed there will be much gnashing of teeth going forward if
you really decide to dig in ... it is much more nuanced than literally
setting and tracking frames.

Just my $0.02. I thoroughly enjoy your contributions to this group and I'll
just say that this entire thread really surprised me. Hang in there! It
isn't that difficult!

Thanks,
-Luther



> —Jens
> ___
>
> 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/lutherbaker%40gmail.com
>
> This email sent to lutherba...@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