pyobjc

pyobjc copied to clipboard

Describe the bug

There are quite a few APIs that raise/warn about pointers that don't seem to be a problem beyond perhaps a discrepency in metadata. For example:

host_clock = CoreMedia.CMClockGetHostTimeClock()

results in:

ObjCPointerWarning: PyObjCPointer created: at 0x600001ea8270 of type ^{OpaqueCMClock=}
  host_clock = CoreMedia.CMClockGetHostTimeClock()

When I look at the relevant compiled _metadata.py I find a discrepency in definitions: https://github.com/ronaldoussoren/pyobjc/blob/5bc7a29ce8e31fd858c1f1b2796f051a0470d24c/pyobjc-framework-CoreMedia/Lib/CoreMedia/_metadata.py#L1024 https://github.com/ronaldoussoren/pyobjc/blob/5bc7a29ce8e31fd858c1f1b2796f051a0470d24c/pyobjc-framework-CoreMedia/Lib/CoreMedia/_metadata.py#L1577 One is lowercase opaque, the other is uppercase Opaque.

To validate my hypothesis:

• I installed pyobjc from its repo using develop.py (pip install -e)
• When I alter either definition to change the capitalization of opaque to match:
  • the pointer warning goes away
  • instead, I get rich type information (ie CMClock instead of an opaque pointer)

Is this indeed just an issue with metadata? If so, should I go about fixing the metadata (exceptions file?) that feeds into objective.metadata and results in _metadata.py? Is this an across the board fix for all definitions of opaqueX? I'm happy to help fix these as I come across them.

Also is there any way I can patch these discrepencies without modifying the _metadata.py compiled files in pyobjc's source? Might be nice to one-off, temporarily "patch" funtion metadata in my downstream codebase like I did with objc.registerMetadataForSelector and the _Tundra classes... of course, this time it's functions which I haven't found a way to change metadata one-off. I did find objc.loadFunctionList, is that the right direction?

Thanks!

Platform information

• Python version 3.9.13
• How was python installed (python.org, anaconda, homebrew, ...) homebrew
• macOS version 13.0 beta

As a workaround the following should work:

objc.registerCFSignature("dummy", b"^{OpaqueCMClock=}", None, "NSObject")

This registers b"^{OpaqueCMClock=}" as the type signature for a type that's toll free bridged to NSObject. That itself is incorrect, but ensures the pointer is treated like a CFTypeRef/id and that is enough to trigger the correct code path.

I'll have to investigate why I've ended up with inconsistent metadata here. Probably a copy/paste error on my end, or the type encoding has changed over time and I didn't notice this at first.

Thanks!

deja vu! I was just typing up a note about stumbling on objc.registerCFSignature (after looking into the classclones fix you put out and realizing I never searched the repo for cftypes)...

I got this working... (so far in my testing)

objc.registerCFSignature("CMClockRef", b"^{OpaqueCMClock=}", CoreMedia.CMClockGetTypeID())

FYI for anyone curious:

• objc.registerCFSignature docs
• __load_cftypes has several usages of objc.registerCFSignature that are used to parse the initial registrations in module metadata's cftypes entry:

https://github.com/ronaldoussoren/pyobjc/blob/01d06bd729b537ca03de88e6159b5bb5c5ad978e/pyobjc-core/Lib/objc/_lazyimport.py#L469-L511

The CoreMedia bindings in the 8.5 branch should have this fixed (likewise for the master branch, but that's fairly unstable at this point in time). My plan is to push out a release over the weekend.

FYI, Apple's docs are inconsistent with regards to o/Opaque capitalization.

For example:

• opaqueCMSampleBuffer https://developer.apple.com/documentation/coremedia/cmsamplebufferref?language=objc
• OpaqueCMClock: https://developer.apple.com/documentation/coremedia/cmclockref?language=objc

Just checked the bridgesupport files for these two types have the same inconsistency...

Perhaps the casing has changed over time and that combined with manual overrides / exceptions led to the discrepancy?

This is fixed in both the 8.x maintenance branch and the upcoming 9.0 release (master branch). I have planned some test suite enhancements to guard against issues like this, that's tracked in #495.

Thank you!

On Fri, Oct 21, 2022 at 7:05 AM Ronald Oussoren @.***> wrote:

Closed #493 https://github.com/ronaldoussoren/pyobjc/issues/493 as completed.

— Reply to this email directly, view it on GitHub https://github.com/ronaldoussoren/pyobjc/issues/493#event-7640054958, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABL7XJQVRE3ZONUXTUKN33WEKBIJANCNFSM6AAAAAAQMXPR44 . You are receiving this because you authored the thread.Message ID: @.***>

-- Wes Higbee