Re: malloc(0) returns a pointer, not NULL
On May 5, 2015, at 14:19, Michael David Crawford mdcrawf...@gmail.com wrote: This came as news to me. The C spec says this is implementation-definited; malloc(0 may return either NULL or it may return a pointer that can subsequently be passed to free(). Note that even when it does return NULL, that is still a “pointer that can subsequently be passed to free()” (i.e. free(NULL) is perfectly well-defined). In the case of the bug I'm looking at just now, it's an error in my code, so I now have: assert( 0 != bytes ); ptr = malloc( bytes ); Just thought you'd like to know, -- Clark Smith Cox III clark@apple.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: NSNotification coalescing - which one gets through?
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 jonathan.tay...@glasgow.ac.uk 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
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
NSNotification coalescing - which one gets through?
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: Grabbing window - The contents of this window cannot be shared
On 06 May 2015, at 14:09, Andreas Höschler ahoe...@smartsoft.de 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
iOS firing an event in the future when an app is in the background
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: static analyzers says I'm leaking, I _think_ I'm not
On May 6, 2015, at 4:40 PM, Aaron Montgomery eey...@monsterworks.com 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
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 k...@codeweavers.com wrote:
On May 6, 2015, at 4:40 PM, Aaron Montgomery eey...@monsterworks.com 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
static analyzers says I'm leaking, I _think_ I'm not
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
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 rjmcc...@apple.com wrote: On May 6, 2015, at 1:57 PM, Michael David Crawford mdcrawf...@gmail.com 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
On May 6, 2015, at 1:57 PM, Michael David Crawford mdcrawf...@gmail.com 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
On May 6, 2015, at 3:57 PM, Michael David Crawford mdcrawf...@gmail.com 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
On May 6, 2015, at 2:17 PM, Michael David Crawford mdcrawf...@gmail.com 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
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 gpar...@apple.com wrote: On May 6, 2015, at 1:57 PM, Michael David Crawford mdcrawf...@gmail.com 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
On May 6, 2015, at 1:57 PM, Michael David Crawford mdcrawf...@gmail.com 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
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 mdcrawf...@gmail.com 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 eey...@monsterworks.com 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 mdcrawf...@gmail.com 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: Help: NSScrollView is resizing its documentView down to (0, 0)
On May 6, 2015, at 8:36 AM, Uli Kusterer witness.of.teacht...@gmx.net 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
On 7 May 2015, at 00:08, Alex Zavatone z...@mac.com 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: iOS firing an event in the future when an app is in the background
On May 6, 2015, at 9:08 AM, Alex Zavatone z...@mac.com 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?
On May 6, 2015, at 3:54 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk 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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On Wed, May 6, 2015 at 11:54 AM, Jens Alfke j...@mooseyard.com wrote: On May 6, 2015, at 8:36 AM, Uli Kusterer witness.of.teacht...@gmx.net 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
Re: Help: NSScrollView is resizing its documentView down to (0, 0)
On 05 May 2015, at 18:26, Jens Alfke j...@mooseyard.com 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)
On 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com 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)
On 6 May 2015, at 23:39, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com 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)
On 06 May 2015, at 17:41, Roland King r...@rols.org wrote: On 6 May 2015, at 23:39, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 06 May 2015, at 03:21, Jens Alfke j...@mooseyard.com mailto:j...@mooseyard.com 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
