This is getting interesting.
I added your suggested test code (set to execute once):
class FontSelectorDialog : UITableViewController {
static let chooser : ColorChooser = ColorChooser()
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(a
> On 28 Mar 2017, at 05:41, Rick Aurbach wrote:
>
> That wouldn’t work directly. The “leak” occurs when processing a segue called
> in response to a user button push. (I suppose I could attempt to wire up a UI
> Test, but would rather not go down that route.)
>
> What I can try is to see if I
That wouldn’t work directly. The “leak” occurs when processing a segue called
in response to a user button push. (I suppose I could attempt to wire up a UI
Test, but would rather not go down that route.)
What I can try is to see if I can create a simple, artificial example. If it
also reports a
Could you call the supposedly leaky code a few million times and look at memory
usage to see if there's actually a leak?
- Dave Sweeris
> On Mar 27, 2017, at 13:31, Rick Aurbach via swift-users
> wrote:
>
> Okay, I downloaded the latest Xcode from the developer site. (The download
> page sa
Okay, I downloaded the latest Xcode from the developer site. (The download page
said it was 8.3beta5, but the version info called it 8.3 (8E161).)
So I put the use of the enum back into my code and profiled it again. (Please
refer to my original post for the Case 1 code that I’m testing here.)
> On 26 Mar 2017, at 18:43, Rick Aurbach via swift-users
> wrote:
>
> I have a situation where I have a leak that I do not understand. I would be
> very grateful if someone could explain it to me and offer an idea of how I
> can make the pattern work without leaking:
How are you determining
I have a situation where I have a leak that I do not understand. I would be
very grateful if someone could explain it to me and offer an idea of how I can
make the pattern work without leaking:
Consider two code snippets, the first of which leaks, while the second does not.
Case 1: This example
