Re: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7
On 26 Dec, 2012, at 5:33, "Berg, Stuart" wrote: > Greetings, > > I'm new to PyObjC, but it looks great. I can run basic examples, but the > ScreenSaver example in the docs doesn't seem to work on 10.7: > http://packages.python.org/pyobjc/examples/ScreenSaver/SillyBallsSaver/index.html > > Someone on stack overflow seems to be having the same trouble as me: > http://stackoverflow.com/questions/7821589/compile-64-bit-mac-app-with-py2app > > But I don't think that 32-bit vs. 64-bit is the issue. (I'm able to run > non-screensaver examples…) > > Does anyone know if the ScreenSaver framework pyobjc wrappers are still > supported for OS 10.7? 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' ? On my (OSX 10.8) machine this says: $ 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 This binary also works when I load it in System Preferences (at least, the preview does, I haven't waited long enough yet to check if it also works when the screensaver kicks in). > > By the way, I'm using Xcode 4.5.2. I know that Xcode 4 threw a wrench in > some aspects of pyobjc. Is this an example of that? I don't think so. This is most likely a 32-bit vs. 64-bit issue. I'm using a custom 32-bit/64-bit build of Python 2.7 (from the python.org repository), pyobjc from the pyobjc repository and the most recent release of py2app, all of this running on OSX 10.8. 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)? Ronald > > Thanks, > Stuart > > > ___ > Pythonmac-SIG maillist - [email protected] > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] pyobjc status and future
Hi, Early november I finally got a new release of PyObjC out (version 2.4), and unless an unexpected problem crops up there will be another release (2.5) next Sunday. Version 2.5 will re-add some functionality that accidently got dropped in the 2.4 release (in particular the support for BridgeSupport files), and improves testing (which led to a number of bugfixes). I've also migrated the website to http://packages.python.org/pyobjc, the old URL (http://pyobjc.sf.net/) is now just a redirect to the new location. The website is once again generated from the PyObjC source tree, the old one hadn't been updated in a long while because the scripts generating that site didn't work anymore due to restructuring of the pyobjc repository and documentation files. I'd like to replace the current sphinx theme by something less generic, and that should happen sometime next year.The same is true for the examples: that code needs to be cleaned up and updated. I'll try to get on a more regular release pattern next year, with some luck leading up to a 3.0 release during the summer. That release would then feature a cleaned up core bridge, removing some cruft that was needed to support Python release before 2.6 and that cleanup should improve the performance of all of PyObjC. The major stumbling block w.r.t. getting to 3.0 is time: I know what I want to do and how to get there, but expect to need a couple of days to work on this; my regular development pattern of doing a couple of hours development during the evening or in the weekend will probably be too inefficient to make serious progres. Before 3.0 is out there should be at least a 2.6 release, and possibly other point releases, with improved framework coverage (not all system frameworks are available through PyObjC at the moment), other minor feature updates and bugfixes. One thing I'm not sure about is Xcode support, in particular support for designing GUI using the Interface Builder tool embedded in Xcode. I don't like Xcode as a Python editor (which is why the xcode templates are basicly dead at the moment), and haven't made my mind up on how to proceed here. Two major options are to either generate an Xcode project when needed (just to enough to let Xcode know where to find resource files and source code), and to just ignore Xcode completely but design the UI in Xcode. That last option should be a lot easier with autolayout (introduced in OSX 10.7), but might need a helper library to keep code readable (I've noticed with other toolkits that it is very easy to end up with long blocks of code that create UI elements and have no useful structure). Happy holidays, Ronald ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7
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
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7
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?
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
>
>
>
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7
Hi Ronald, Still trying to crack this nut…. If I open the screensaver from the command line using the System Preferences app, I get this error. It doesn't seem to happen with other screensavers (e.g. if I build the original (objective-c) SillyBalls screensaver, there are no errors. $ /Applications/System\ Preferences.app/Contents/MacOS/System\ Preferences dist/SillyBalls.saver System Preferences(7983,0x7fff7e816960) malloc: reference count underflow for 0x4003b38e0, break on auto_refcount_underflow_error to debug. System Preferences(7983,0x7fff7e816960) malloc: reference count underflow for 0x400352b80, break on auto_refcount_underflow_error to debug. Unfortunately, I'm a little out of my comfort-zone here. Could this error be causing my problem? Here's a log of a gdb session showing the backtrace at the site of the refcount error. (Note the "br" command before the "run" command.) (By the way, if you try this yourself, ignore any "invalid frame buffer operation" errors you may see, which are probably coming from the built-in "Flurry" screensaver.) Thanks again for any ideas you've got… Stuart $ gdb --args /Applications/System\ Preferences.app/Contents/MacOS/System\ Preferences dist/SillyBalls.saver GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries . done (gdb) br auto_refcount_underflow_error Function "auto_refcount_underflow_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (auto_refcount_underflow_error) pending. (gdb) run Starting program: /Applications/System Preferences.app/Contents/MacOS/System Preferences dist/SillyBalls.saver Reading symbols for shared libraries done Breakpoint 1 at 0x7fff9766d0c4 Pending breakpoint 1 - "auto_refcount_underflow_error" resolved Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries .. done Reading symbols for shared libraries .. done Reading symbols for shared libraries ... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done System Preferences(8058,0x7fff7e816960) malloc: reference count underflow for 0x4003b8a20, break on auto_refcount_underflow_error to debug. Breakpoint 1, 0x7fff9766d0c4 in auto_refcount_underflow_error () (gdb) backtrace #0 0x7fff9766d0c4 in auto_refcount_underflow_error () #1 0x7fff976a19c7 in Auto::SubzoneBlockRef::dec_refcount_no_lock () #2 0x7fff976a19fa in Auto::SubzoneBlockRef::dec_refcount () #3 0x7fff9766821e in Auto::sieve_base::sieve_base_pointer > () #4 0x7fff9766474c in auto_zone_release () #5 0x7fff8d86ea9a in CFRelease () #6 0x7fff8ffd91c7 in -[NSWindow _cancelPerformSelectors] () #7 0x7fff9043e716 in -[NSWindow finalize] () #8 0x7fff9464c57c in finalizeOneObject () #9 0x7fff9767a07e in Auto::foreach_block_do () #10 0x7fff9464c4ac in batchFinalize () #11 0x7fff9464b219 in batchFinalizeOnMainThread () #12 0x7fff9464afdc in objc_collect () #13 0x7fff8d901d65 in __NSArrayEnumerate () #14 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #15 0x7fff8d901cee in __NSArrayEnumerate () #16 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #17 0x7fff8d901cee in __NSArrayEnumerate () #18 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #19 0x7fff8d901cee in __NSArrayEnumerate () #20 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #21 0x7fff8d901cee in __NSArrayEnumerate () #22 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #23 0x7fff8d901cee in __NSArrayEnumerate () #24 0x7fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #25 0x7fff8d901cee in __NSArrayEnumerate () #26 0x7fff8fe67aeb in -[NSView(NSI
