[Pythonmac-SIG] PyObjC ScreenSaver on 10.7

[Ronald Oussoren]

On 26 Dec, 2012, at 21:01, "Berg, Stuart" <bergs at janelia.hhmi.org> wrote:

> One more note.  I came across this link yesterday:
> http://developer.apple.com/library/mac/#qa/qa1666/_index.html
> 
> How do I make sure that the ScreenSaver bundle I've created with py2app uses the correct garbage collection setting?  Is there a way to specify GCC_ENABLE_OBJC_GC=required from setup.py?  Also, is there a way to inspect a binary to see if this setting was used to build it?

You would have to enable GC for PyObjC, but that will likely cause problems. The codebase of PyObjC currently uses the CoreFoundation refcount APIs to ensure that Python has strong references to objects even when GC is enabled, but the code likely isn't completely GC-safe yet (I've never audited it for GC-safeness and know that a number of classes have a dealloc method but not finalize method). 

You can check the GC awareness of binaries with:

$ otool -vo /Applications/Xcode.app/Contents/MacOS/Xcode
...
Contents of (__DATA,__objc_imageinfo) section
  version 0
    flags 0x6 OBJC_IMAGE_SUPPORTS_GC


I don't know the path to the screen saver engine (the binary that will actually load the screensaver). 

BTW. This might explain why the Screen Saver example works for me, but not for you: Apple is clearly moving away from GC and I'm running a newer OS release where Apple might have migrated the Screen Saver engine back to manual reference counting.

It is extermely annoying that the need for GC is buried in a technote and isn't mentioned in the Screen Saver framework documentation at all. 

Ronald 
> 
> Sorry for my ignorance….
> 
> Thanks again,
> Stuart
> 
> On Dec 26, 2012, at 12:08 PM, Stuart Berg wrote:
> 
>> Hi Ronald,
>> 
>>> The screensaver framework should work just fine, but only if the bundle contains 64-bit code.
>>> 
>>> What is the output of 'file SillyBalls.saver/Contents/MacOS/SillyBalls' ?
>> 
>> I have two versions of python, so I'll try this twice.  First with the built-in version:
>> $ which python
>> /usr/local/bin/python
>> 
>> $ python --version
>> Python 2.7.2
>> 
>> $ python setup.py py2app
>> ……..
>> 
>> $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls 
>> dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O universal binary with 2 architectures
>> dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture i386):	Mach-O bundle i386
>> dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture x86_64):	Mach-O 64-bit bundle x86_64
>> 
>> $ file dist/SillyBalls.saver/Contents/MacOS/python 
>> dist/SillyBalls.saver/Contents/MacOS/python: Mach-O universal binary with 2 architectures
>> dist/SillyBalls.saver/Contents/MacOS/python (for architecture i386):	Mach-O executable i386
>> dist/SillyBalls.saver/Contents/MacOS/python (for architecture x86_64):	Mach-O 64-bit executable x86_64
>> 
>> And with my own build of python:
>> 
>> $ rm -rf build dist
>> 
>> $ which python
>> /Users/bergs/special-build/Frameworks/Python.framework/Versions/2.7/bin/python
>> 
>> $ python --version
>> Python 2.7.3rc2
>> 
>> $ python setup.py py2app
>> …….
>> 
>> $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls 
>> dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O 64-bit bundle x86_64
>> 
>> $ file dist/SillyBalls.saver/Contents/MacOS/python 
>> dist/SillyBalls.saver/Contents/MacOS/python: Mach-O 64-bit executable x86_64
>> 
>> 
>>> Which versions of python, pyobjc, and py2app do you use (and for the python versions, is this the apple provided one or some other install)?
>> 
>> 
>> I installed the same version of pyobjc to each python install:
>> 
>> $ python -c "import objc; print objc.__version__"
>> 2.4
>> 
>> $ python -c "import py2app; print py2app.__version__"
>> 0.7.2
>> 
>> The System Preferences app doesn't give a very useful error message ("Contact the developer of this screen saver for a newer version.").  Do you know if there's any way to get a better idea of what's going wrong?  As far as I can tell, Console.app doesn't have any useful output on this problem.
>> 
>> Thanks,
>> Stuart
>> 
>> 
>> 
>