I've pushed some changes which should have fixed most of these issues. Thanks for reporting them.
On 22/02/2021 09:40, Phil Clayton wrote:
I hacked PolyFFICallbackException to print the exception (see attached) and found that it was ? Foreign "Cannot return a closure" It's now obvious what's going wrong now in call_c_test_15.? The load function for a closure conversion raises the exception to prevent a call to C returning a closure (hence the wording in the exception) but it also prevents a callback function taking a closure as an argument.
It would be useful if PolyFFICallbackException printed the exception before aborting.
I actually found this earlier this morning just before your message arrived. I've added the exception message string to the abort message.
Also, I have some minor observations about the interface.? I note that the signature FOREIGN specifies: ???? val touchClosure: 'a -> unit I wondered whether that should be ???? val touchClosure: 'a closure -> unit
That seems like a good idea so I've changed it.
In both the old and new Foreign modules, the type `'a Foreign.closure` is abstract.? Giraffe Library uses `Foreign.LowLevel.cFunctionWithAbi` define its own function for creating a closure but there is no way to create a `'a Foreign.closure` value from a `Memory.voidStar` value. This is easily worked around by copying the type declaration and definition of `Foreign.cFunction` but I wondered if there could be a way to avoid this copying.
Can't you just use the cPointer conversion instead of cFunction?
Regards, David