On Sun, Feb 26, 2012 at 4:10 AM, Jeffrey Van Voorst <[email protected]> wrote: > Any comment on how problematic this is? (in the pythonwebkit build) > > Parsing ../WebCore/storage/StorageEvent.idl > <argtypes.ObjectArg instance at 0x10063a248> > Could not write getter for Event.timeStamp: DOMTimeStamp* > <argtypes.ObjectArg instance at 0x10063a248> > Traceback (most recent call last): > File "/Users/jvanvoorst/code/pythonwebkit/pywebkitgtk/wkcodegen/codegen.py", > line 579, in write_methods exception_needed=meth.raises) > File "/Users/jvanvoorst/code/pythonwebkit/pywebkitgtk/wkcodegen/codegen.py", > line 397, in write_function_wrapper handler = > argtypes.matcher.get(param.ptype) > File "/Users/jvanvoorst/code/pythonwebkit/pywebkitgtk/wkcodegen/argtypes.py", > line 982, in get raise ArgTypeNotFoundError(ptype) > ArgTypeNotFoundError: DOMObject*declaration of type needed > CustomEvent.initCustomEvent: DOMObject*
not at all. i was using that debugging information in order to double-check which object types were being properly translated. so for example, you can see above that i've not added support for DOMTimeStamp. any functions therefore which have DOMTimeStamp will simply be inaccessible. then i evaluated what file they were in - in this case StorageEvent.idl. i considered the StorageEvent to be low-priority, so did not put the time and effort into creating a object-mapping between Event.timestamp's type (DOMTimeStamp) and the python equivalent. capiche design strategy? :) l.
