Another FFI challenge
Locked
 
|
Hi all, Marcel, yet another basic requirement: I did not even try to inquire the implementation... |
|
Hi Nicolas, that's like to already be covered by ExternalPool. :-) I tried to write a lot of documentation on how to use it in the class comment. Best, Marcel
|
|
|
Hi Marcel, I'm not so sure. It does not look like a constant, but rather a variable. The type of this variable is a hid_t, but the content can change at runtime (I believe once at HDF5 initialisation). So what is needed is to get the address of the variable (exactly like we lookup address of a function), then dereference it to get the contents... Le mer. 17 juin 2020 à 12:52, Marcel Taeumel <[hidden email]> a écrit :
|
|
|
Hi Nicolas. > So what is needed is to get the address of the variable (exactly like we lookup address of a function), then dereference it to get the contents... Since I am in the process of shrinking "Alien-Core" into "FFI-Callback" ... could this be implemented with a new interface to the FFI plugin? Maybe not. Unless you can provide an exported call that the plugin can intercept to copy the address for you? If it is not already exposed in another call. Then it would be easy. Best, Marcel
|
|
|
I have sketched an application specific answer on SO. The plugin has minimal support (a primitive) to retrieve the address of a given symbol from a given library. Normally, we should create an ExternalData with such address and variable type asPointerType. Then we can pass either the variable by reference (just pass the ExternalData) or by value (I don't know who will dereference the address...). Of course, those ExternalAddress shall be cleared upon image resumption, etc... All this handling might deserve a specific subclass of ExternalObject, I don't know... (subclass of ExternalData so as to not have to modify the plugin?) For HDF5, I'm going to assume that those hid_t never change after HDF5 library initialization, and that such initialisation happens at time of dynamic linking/loading. Le mer. 17 juin 2020 à 14:56, Marcel Taeumel <[hidden email]> a écrit :
|
|
|
Well, I think you can just use ExternalData and set the #size to 1. ExternalAddress are all reset on image startup. :-) externalGlobal := (ExternalData fromHandle: anExternalAddressToVariable type: pointerTypeOfVariable) size: 1. "Optional." ... value := externalGlobal at: 1. The main question is how to acquire that "anExternalAddressToVariable". :-) Best, Marcel
|
|
|
> All this handling might deserve a specific subclass of ExternalObject, I don't know... As long as it is just that #value/#value: on the instance side, a new subclass might not be required. Only if you want to get rid of that #fromHandle:type: call in your bridge code, I would suggest a compilation approach like ExternalStructure class >> #fields... Ah! A type alias to the pointer type might be enough: MyExternalGlobal class >> #fields ^ #(value 'int*') "pointer type of variable type" externalGlobal := MyExternalGlobal fromHandle: anExternalAddressToVariable. externalGlobal value "answers external data" at: 1 "see previous example" So, you can then add code manually to improve this access to that global variable. Or change the accessor-generation code to do that ... if it finds a "is global variable" pragma in #fields ... :-D Anyway ... the main question remains ... How to acquire that "anExternalAddressToVariable". :-) Best,
Marcel
|
|
|
Uh! You can also think about making such a "MyExternalGlobal" (type alias to pointer type) a singleton object. So you could generate #value/#value: on the class-side. And #uniqueInstance. And add a classVar ... Anyway ... How to acquire that "anExternalAddressToVariable". :-D Best, Marcel
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |