Re: [Pyobjc-dev] PyObjC 2.2b1 CoreVideo problem

[Ronald O. <ron...@ma...>]

On 13 Apr, 2009, at 16:10, Orestis Markou wrote:

> Thanks - is that something you are going to do for b2 or is it  
> something we should patch ourselves?

This will be fixed by the time 2.2b2 is released.  I have no timeline  
for when 2.2b2 will be released, may plan's for the near future:

* 2.2b2: all examples have been verified to work correctly with 2.2 on  
Leopard, unittests for frameworks are complete and pass

* 2.2b3: fix a number of issues on my private bugtracker, check for  
memoryleaks, check with Shark if there are obvious performance issues,  
test with 64-bit builds.

* 2.2: migrate PyObjC website to Trac

Somewhere in between I want to finish work I did during the sprints at  
PyCon: I have at 90% of the code that's needed to properly support  
eggs in py2app, but need to properly integrate that code. The hard  
part is reverse engeneering py2app & friends to find the right way to  
do that integration without completely rewriting py2app.

BTW. In the long run you should use "from Quartz import *" rather than  
from "Quartz.QuartzCore import *", the latter are there as a grouping  
mechanism for PyObjC itself while the former better reflects the  
official name.

Ronald

> --
> or...@or...
> http://orestis.gr/
>
>
>
>
> On 8 Apr 2009, at 08:46, Ronald Oussoren wrote:
>
>> I had noticed the issue with CoreVideo, but haven't had time yet to  
>> do anything about it.
>>
>> The easiest workaround for the QuartzCore issue is to remove the  
>> import of CoreVideo from its __init__.py file.
>>
>> Ronald
>>
>> On 8 Apr, 2009, at 1:16, Orestis Markou wrote:
>>
>>> Just easy_installed PyObjC 2.2b1 into a fresh virtualenv.
>>>
>>> Other than the issue that 'from Quartz import *' that I know is  
>>> fixed
>>> in trunk, CoreVideo seems to be broken:
>>>
>>>>>> from Quartz.CoreVideo import *
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in <module>
>>> File "/Users/orestis/Developer/virtualenvs/edm/lib/python2.5/site-
>>> packages/pyobjc_framework_Quartz-2.2b1-py2.5-macosx-10.5-i386.egg/
>>> Quartz/CoreVideo/__init__.py", line 17, in <module>
>>>   scan_classes=False)
>>> File "/Users/orestis/Developer/virtualenvs/edm/lib/python2.5/site-
>>> packages/pyobjc_core-2.2b1-py2.5-macosx-10.5-i386.egg/objc/
>>> _bridgesupport.py", line 144, in initFrameworkWrapper
>>>   _parseBridgeSupport(data, globals, frameworkName,
>>> inlineTab=inlineTab)
>>> File "/Users/orestis/Developer/virtualenvs/edm/lib/python2.5/site-
>>> packages/pyobjc_core-2.2b1-py2.5-macosx-10.5-i386.egg/objc/
>>> _bridgesupport.py", line 57, in _parseBridgeSupport
>>>   objc.parseBridgeSupport(data, globals, frameworkName, *args,
>>> **kwds)
>>> objc.internal_error: PyObjCRT_SkipTypeSpec: Unhandled type '65'
>>> encode(CVTimeStamp*)
>>>
>>> This also breaks QuartzCore (which imports CoreVideo), which  
>>> contains
>>> a lot of CoreAnimation constants, and it's a showstopper for our
>>> adoption of PyObjC 2.2 (we'd quite like to use it, we're using the
>>> Leopard version currently).
>>>
>>> Not sure if this is fixed on the trunk - didn't see anything  
>>> relevant
>>> in the commit logs. Any documentation on building from trunk so we  
>>> can
>>> help with bug reports? With virtualenv it's very easy to run an
>>> application on both 2.0 and 2.2 and report breakage.
>>>
>>> Orestis
>>> --
>>> or...@or...
>>> http://orestis.gr/
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> High Quality Requirements in a Collaborative Environment.
>>> Download a free trial of Rational Requirements Composer Now!
>>> http://p.sf.net/sfu/www-ibm-com
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>