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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
