PyObjC

On 12 Jan, 2010, at 22:36, Aahz wrote:

> I'm building an app on 10.5, trying to support Intel 10.4, 10.5, 10.6.
> Currently I'm using a combination of PyObjC 1.4 (originally to support
> PPC 10.4) and PyObjC 2.2b2 to capture FSEvents in a subprocess.  When
> 10.6 was released, my app crashed.  Then Apple delivered some updates and
> my app started working in mid-November.  Now apparently Apple has put out
> new updates and my app is crashing again.
> 
> I am moderately sure that I can fix this with some combination of build
> changes, but I'd like some guidance to avoid thrashing around.  I'm
> using the python.org build for Python 2.6.4.  I've tried upgrading to
> PyObjC 2.2, but that breaks on 10.5 with
> 
> ImportError: dlopen(/Users/aahz/Library/Python/2.6/site-packages/pyobjc_core-2.2-py2.6-macosx-10.3-fat.egg/objc/_objc.so, 2): Library not loaded: /usr/lib/libxml2.2.dylib
>  Reason: Incompatible library version: _objc.so requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0
> 
> Should I try just building PyObjC 2.2 from source?  I tried updating
> macports before I realized that this was the system libxml.

Rebuilding pyobjc-core from source should fix the libxml issues, I created those binaries on 10.6 and that version of libxml is not compatible with the one on 10.5.

I've added removal of the libxml dependency to my todo-list, but haven't decided yet on how to do so. I use libxml to parse the bridgesupport files, which are XML files with additional meta data.  I currently use libxml for that because it is an efficient C-based parser and want to investigate two replacement strategies: (1) use ElementTree to do the parsing in Python and (2) "compile" the XML files into some other format when building framework wrappers (either to a python file or a C extension).

> 
> AFAICT, PyObjC 2.2b2 is crashing on 
> 
> from Foundation import NSAutoreleasePool, NSMutableArray, NSString
> 
> in objc._bridgesupport._parseBridgeSupport() with "ValueError: Unknown
> typestr".  Assuming the line number matches the source, that's
> 
>            objc.parseBridgeSupport(data, globals, frameworkName, *args, **kwds)

Is this using /usr/bin/python?

> 
> OTOH, the app built with PyObjC 1.4 is crashing with
> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
> and I'm not sure where.  Any clues?

Do you use os.fork in your program?  Apple's frameworks do not support calling fork without calling exec right after that, especially (but not limited to) frameworks that have a connection to the window server.   AFAIK that includes the CoreFoundation framework.

Ronald

On Thu, Jan 14, 2010, Ronald Oussoren wrote:
> On 12 Jan, 2010, at 22:36, Aahz wrote:
>> 
>> Should I try just building PyObjC 2.2 from source?  I tried updating
>> macports before I realized that this was the system libxml.
> 
> Rebuilding pyobjc-core from source should fix the libxml issues, I
> created those binaries on 10.6 and that version of libxml is not
> compatible with the one on 10.5.

Okie-doke.

>> AFAICT, PyObjC 2.2b2 is crashing on 
>> 
>> from Foundation import NSAutoreleasePool, NSMutableArray, NSString
>> 
>> in objc._bridgesupport._parseBridgeSupport() with "ValueError: Unknown
>> typestr".  Assuming the line number matches the source, that's
>> 
>>            objc.parseBridgeSupport(data, globals, frameworkName, *args, **kwds)
> 
> Is this using /usr/bin/python?

Nope, still Python 2.6.4 from python.org, building on 10.5, running on
10.6.

>> OTOH, the app built with PyObjC 1.4 is crashing with
>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
>> and I'm not sure where.  Any clues?
> 
> Do you use os.fork in your program?  Apple's frameworks do not support
> calling fork without calling exec right after that, especially (but
> not limited to) frameworks that have a connection to the window
> server.  AFAIK that includes the CoreFoundation framework.

Which is stupid, bone-headed, and wrong.

Repeating from pythonmac-sig:

After a lot of poking around, it appears that platform.mac_ver() is
broken in 10.6 (Snow Leopard) because the gestalt module calls fork(),
which causes a crash with
USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER.  This seems to
only happen with py2app builds; I have not been able to reproduce using
strict command-line testing, and I haven't had time to create a
stripped-down app to test with.

I'd appreciate if someone else could verify before I file a bug.  (It's
possible that the multiprocessing module is involved if a simple test
fails to reproduce -- my AppDelegate starts another process for the main
code that then calls mac_ver() to log the current OS version.)  I'm using
os.uname() instead for now.
-- 
Aahz (aahz@...)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

Hi all,

I have a project in which an OSX machine renders images in response to  
http calls. It runs the python.org 2.6.4, pyobjc 2.2, twisted 9.0.0.
I can use Quartz to make a drawing context, draw simple paths, export  
as PNG. This works.

I also need to draw a couple bitmap images, so I want to use more  
functionality from Quartz. The enclosed test script works when  
executed in the terminal. Exactly the same script crashes hard when  
called as part of a twisted process.

> [eBook:trunk/lettersetter/Quartz LS Debug] erik% python /usr/bin/ 
> twistd -y twisted.quartz.test.py --pidfile quartztestpid.txt -- 
> logfile quartztest.log
> versions:
> python version: 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
> [GCC 4.0.1 (Apple Inc. build 5493)]
> pyobjc version: 2.2
> twisted.web version: 9.0.0
>
> dry run:
> saved test image at /Users/erik/Develop/lettersetter/trunk/ 
> lettersetter/Quartz LS Debug/test.png
>
> booting twisted app
> done

Then I open a browser at http://127.0.0.1:8081/ 		kerboom!

My test script requires a png file to be nearby.
Any  help or pointers are kindly appreciated.
Erik

On Fri, Jan 15, 2010, Erik van Blokland wrote:
>
> I also need to draw a couple bitmap images, so I want to use more  
> functionality from Quartz. The enclosed test script works when executed 
> in the terminal. Exactly the same script crashes hard when called as part 
> of a twisted process.

Can you search the twisted codebase to find out if they're using
platform.mac_ver()?  If yes, that's exactly the same problem I reported
here yesterday.  If not, it's almost certainly something similar.

Critical bit of the logs:

> Application Specific Information:
> abort() called
> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER

BTW, it would have helped if you had specified what "boom" means (i.e.
explained that you were getting an OS crash rather than a Python
traceback).  I was looking for this in particular, so it was easy to
find, but someone else might well have not bothered.

Ronald, I looked in gestaltmodule.c, and it's not doing a fork(), so it
must be buried in the Gestalt() call itself.  Which really makes this
Apple's bug unless Gestalt() is completely deprecated.  However, I don't
have enough Mac experience to make that certain.
-- 
Aahz (aahz@...)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair

On 15 jan 2010, at 15:09, Aahz wrote:

> Can you search the twisted codebase to find out if they're using
> platform.mac_ver()?  If yes, that's exactly the same problem I reported
> here yesterday.  If not, it's almost certainly something similar.

I can't find the literal string platform.mac_ver (nor mac_ver) in my twisted-9.0.0 sources.

> Critical bit of the logs:
> 
>> Application Specific Information:
>> abort() called
>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
> 
> BTW, it would have helped if you had specified what "boom" means (i.e.
> explained that you were getting an OS crash rather than a Python
> traceback).  I was looking for this in particular, so it was easy to
> find, but someone else might well have not bothered.

Ah, sorry, "boom" meant a python crashing hard and OSX returning the included crash report. Not a traceback.


Erik