I am passing the correct number of arguments, however stilling hitting "takes 7 arguments, but got 5 arguments"

[sramij-code]

I am trying to invoke Objc from python; something which normally works for me. so I do the following: (stageA is an instance object)
err = stageA.runWithInputTex_inputROI_inputMetadata_first_layout_output_outputROI_(inputTex, inputROI, metadatadict, first, layout, outTex, outputROI)
or:
err = demosaicStage.runWithInputTex( inputTex, inputROI=inputROI, inputMetadata=metadatadict, first=first, layout=layout, output=outTex, outputROI=outputROI)
In both cases, I am hitting the following error:
TypeError: Method b'runWithInputTex:inputROI:inputMetadata:first:layout:output:outputROI:' takes 7 arguments, but got 5 arguments
And I don’t get it; since I am literally passing 7 arguments. looks like rubicon correctly identifies that there should be 7 arguments, but somehow it ignores 2 that I am passing in.
I am also sure it is calling my code, since If I rename any of the arguments, I start getting a different error:
No method was found starting with...
Any thoughts how can I debug whats going on here?

[sramij-code]

Just saw this from pyobjc [https://pyobjc.readthedocs.io/en/latest/core/vector-types.html]
Is it possible this is the problem as well here as 2 arguments in this signature are simd_uint2?

[freakboy3742]

That seems very likely. I was going to ask if you could provide the full prototype of runWithInputTex:inputROI:inputMetadata:first:layout:output:outputROI:. The way it's failing to find a match suggests that either ObjC is returning a misleading function signature, or Rubicon is interpreting that signature incorrectly.

PyObjC and Rubicon use a slightly different approach to wrapping - PyObjC uses metadata provided by header files, whereas Rubicon doesn't; but we definitely don't have explicit support for simd_uint2 datatypes, and if there's libFFI difficulties representing those types (I have no idea about the this statement, but it seems plausible), then it's entirely possible Rubicon will have the same limitation.

If you're up for some debugging, the code in question is around lines 92-97 of rubicon/objc/api.py (the __init__ method of ObjCMethod). If you can report what encoding, restype and imp_argtypes are being returned, that will help narrow down the problem.

[sramij-code]

Thanks @freakboy3742 ; sure, I will be happy to dig in on the weekend in this area. By the way, do we have a way to teach rubicon about the encoding of some of the arguments (or the full signature) ?

[freakboy3742]

There are ways to teach Rubicon about unknown types (see register_ctype_for_type()); but that won't help if (as the PyObjC document suggests) the Objective C runtime isn't giving a complete list of the actual types themselves. There isn't any way to override the full signature if it's fundamentally "wrong" as reported; it might be possible to add such a feature, but you're very much in experimental territory at this point.

[dgelessus]

I also ran into problems with SIMD vector types in Objective-C methods a while back, and from what I remember the problems were the same as what PyObjC describes: ctypes/libffi has no support for SIMD types, and the Objective-C type signatures don't contain accurate information about vector arguments (they were either incomplete and unparseable, or completely missing from the encoding).

To bypass rubicon-objc's automatic method signature parsing, you can use the lower-level send_message function, which requires you to set the return type and all argument types manually. That still won't help here though because of the missing support for SIMD types in ctypes.

For now, the only possible workaround would be to define a helper method in Objective-C that takes all arguments as regular integers/floats/structs and converts them to vector types before passing them to the real method.