On 22/02/21 15:34, David Matthews wrote:
I've pushed some changes which should have fixed most of these issues.
Thanks for reporting them.
Thanks for the updates. I have been testing the Poly/ML variants (see
below) and that fixes callbacks within callbacks on x86_64 provided
compact32bit is disabled. When compact32bit is enabled, I find that any
use of a callback seg. faults, not just nested use. The previous
examples call_c_test_15 and call_c_test_16 still demonstrate this.
(Observed on both Linux and macOS.)
The following cause callbacks to seg. fault:
--enable-shared=yes --enable-compact32bit=yes --enable-intinf-as-int=no
--enable-shared=yes --enable-compact32bit=yes --enable-intinf-as-int=yes
The following work fine:
--enable-shared=yes --enable-compact32bit=no --enable-intinf-as-int=no
--enable-shared=yes --enable-compact32bit=no --enable-intinf-as-int=yes
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?
The store of cPointer doesn't return a function that touches the
pointer. Although that wouldn't matter for my current uses, where there
is always a persistent reference to a closure, I would like the
interface to work if there isn't a persistent reference. It's probably
not worth changing anything though as we're talking about a few lines of
code.
I note that the low-level interface provided by Foreign has changed in a
way that is not compatible with the previous version [1]. Clearly some
break in interface is unavoidable. Given this, could you confirm that
the next version will be 5.8.2? (It seems reasonable not to consider
the low-level interface part of the stable API.)
Regards,
Phil
1. The low-level interface in Foreign has the following changes:
- type LowLevel.ctype has become LowLevel.cType
- type LibFFI.abi has become LowLevel.abi
- the voidStar arguments of cFunction[WithAbi] and call[WithAbi] have
a different representation
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
