Notes on a PyClock Mac app memory leak (or... How "batteries included" 
and open-source  "software stacks" can lead to programming nightmares). 
This was resolved prior to release, per the Workarounds below

------------------------------------------------------------------------------
Symptoms
------------------------------------------------------------------------------

Linear expansion of app's memory space, per Activity Monitor and Terminal
"ps -axl | fgrep -i pygadgets".  On Mac OS Sierra, computer eventually ran
out of app memory entirely, with ~36G for a PyClock app left open for a day.  
Growth is less dramatic but still present on El Capitan for PyClock app.  

------------------------------------------------------------------------------
Findings
------------------------------------------------------------------------------

Sierra is *much* worse
	just 10M/hour on El Capitan, *much* worse on Sierra: ~1G in a few minutes
	but still a minor issue on el capitan too: linear growth of memory
	sierra also displays tiff images better in tk; new llibtiff, and others?
	**this is the most curious finding**

Not App only
	there *is* minor (very) growth when running as source-code too, on both computers
        this is true even with no photo
	(no growth if run as source with analog+photo and same Python+Tk?)
	this may rule out mac app context

Not Photo only
        there *is* (very) minor growth with no photo too, on both computers
	(no growth in analog if no photo used?)
	this rules out pillow

Not Displayed only
	there *is* (very) minor growth when minimized too 
	(no growth if window minimized?)
	this may rule out mac screen buffering

Analog only
	*no* growth if 'x' to digital display mode

Not timer-related
	PyMailGui shows no linear growth

Not image-type-related
	same growth if use gif instead of png

Mac only
	not an issue on Windows
	no growth even with photo under either Tk 8.5 or 8.6 (py 3.3 or 3.5)
        but only tested as source so far, and exes differ from apps

PyPhoto renders tiffs better on sierra: new shared libtiff? 
	may suggest radical lib changeson sierra

------------------------------------------------------------------------------
Causes
------------------------------------------------------------------------------

Could be tkinter, Tk 8.5, PIL PhotoImage(), py2exe, or Sierra C lib or App 
runtime context change (e.g., C libs used, or Gatekeeper constraints).

Most likely related to Tk or C lib when managing clock-hands overlay buffers.
The original code redrew just the clock hands each second for speed (not the
full face) and _did_ .delete() the prior hands from the canvas explicitly
first, but memory still leaked in Mac apps.

Udate: totally destroying and redrawing the clockface Canvas on each timer
update had no effect; the leak seems to be elsewhere.

------------------------------------------------------------------------------
Workaround ideas
------------------------------------------------------------------------------

Try recoding to avoid buffering of photo pixels under hands 
	might be a tk or pillow issue
	appears to be holding on image content buffers of prior hand lines after deleted
	original ran Canvas.delete() calls for hand lines only
	first: recoded to delete('all') and redraw entire face on each update
	second: recoded to .destroy() and del entire clock canvas too
	see clock.py here for the attempted fix code
		==> NO EFFECT: apps still leaking badly on Sierra, slowly on El Capitan
		this also used more CPU (but just 1.X%), didn't redraw during resize
		drags, and seemed to change size on Windows

Try installing latest Pillow
	might be a pillow issue, and tiff files look better on sierra as it is
		==> NO EFFECT: still leaks, and tiffs no better on el capitan

Try launching MacOS/ exes instead of script.py
	might be a py2exe issue, or a sierra issue
	worse on Sierra and only as app, seems to imply a change in app context
		==> but no leaks under Tk 85 or 8.6 on Windows

Try running with python gc module tools to isolate leak
	seems unlikely to help: leak is likely in a C lib below py code level
		==> but no leaks under Tk 85 or 8.6 on Windows
		gc.collect() on timer updates had no effect (and used more cpu)

Try building clock as separate app, launch with 'open'
	might be a sierra issue
	worse on Sierra and only as app, seems to imply a change in app context
		==> but leaks when run as source too

Try installing new Tk 8.6 via homebrew python
	mightbe a Tk issue, or Tk 8.5 in Sierra issue

Give up: this is just a minor toy program, unlikely to be left open anyhow
	popup warning box on Mac OS about 
		'x'ing to digital or periodically closing
	also document issue in Readme
	Tk may just be unusable for some programs on Mac...