You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although we can introspect various Obj-C symbols via the Obj-C runtime helpers e.g. objc_getClass, C functions, enums, and other symbols are not introspectable at runtime, as I found in #43 (you can see in the comments various symbol lookups that failed - NSTitledWindowMask is one of them).
I believe the root of the problem is that bundle.load(), used here:
... does not load any C symbols for the dynamic linker to find. Well, my reasoning may be wrong, but either way, they're not being found in this call (we're throwing an error):
I believe we'd have more success by adopting the approach used by NodObjc to look up symbols, which involves loading the BridgeSupport files, which were specifically designed for use by Objective-C bridges like RubyCocoa and PyObjC.
Alternatively, we may be able to get further on the back of the existing approach by importing Core Foundation and introducing calls to CFBundleGetDataPointerForName and CFBundleGetFunctionPointerForName, but this would turn things into an O(2N) lookup as more and more frameworks are imported (check the data pointer and then the function pointer for each framework we've imported during the app's lifespan), and unlike the BridgeSupport approach, it's not yet tried-and-tested.
The text was updated successfully, but these errors were encountered:
Although we can introspect various Obj-C symbols via the Obj-C runtime helpers e.g.
objc_getClass
, C functions, enums, and other symbols are not introspectable at runtime, as I found in #43 (you can see in the comments various symbol lookups that failed -NSTitledWindowMask
is one of them).I believe the root of the problem is that bundle.load(), used here:
objc/src/util.js
Line 28 in cc4d6f0
... does not load any C symbols for the dynamic linker to find. Well, my reasoning may be wrong, but either way, they're not being found in this call (we're throwing an error):
objc/src/runtime.js
Lines 48 to 58 in cc4d6f0
I believe we'd have more success by adopting the approach used by NodObjc to look up symbols, which involves loading the BridgeSupport files, which were specifically designed for use by Objective-C bridges like RubyCocoa and PyObjC.
Alternatively, we may be able to get further on the back of the existing approach by importing Core Foundation and introducing calls to CFBundleGetDataPointerForName and CFBundleGetFunctionPointerForName, but this would turn things into an O(2N) lookup as more and more frameworks are imported (check the data pointer and then the function pointer for each framework we've imported during the app's lifespan), and unlike the BridgeSupport approach, it's not yet tried-and-tested.
The text was updated successfully, but these errors were encountered: