[squeak-dev] Another FFI challenge
marcel.taeumel at hpi.de
Wed Jun 17 18:08:17 UTC 2020
> 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". :-)
Am 17.06.2020 19:58:02 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Well, I think you can just use ExternalData and set the #size to 1. ExternalAddress are all reset on image startup. :-)
externalGlobal := (ExternalData
size: 1. "Optional."
value := externalGlobal at: 1.
The main question is how to acquire that "anExternalAddressToVariable". :-)
Am 17.06.2020 17:34:25 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
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 <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :
> 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.
Am 17.06.2020 14:11:14 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]>:
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 <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :
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.
Am 17.06.2020 12:50:24 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com [mailto:nicolas.cellier.aka.nice at gmail.com]>:
Hi all, Marcel,
yet another basic requirement:
I did not even try to inquire the implementation...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev