1. part of this BDD library uses ints (not pointers) to identify garbage-collectable objects. there's nothing in the FFI to cope with this AFAICS. i could:
- hack the library (but would prefer not to).
- say the functions in question deal with Ptr CInt, and hope sizeof(int) == sizeof(int *) on all platforms i need to run this on (yuk).
- plead for a general "stick this arbitrary (small) C object in an optimiser-impervious box" generalisation of ForeignPtr.
There was a proposal for such a thing kicking around recently, and I think there's no real problems with it. Although you're the first person to come along with a real application, to my knowledge. Please feel free to mail ffi@haskell.org and make a case, I'd say there's a pretty good chance it'll get adopted.
2. how do i import a function pointer under ghc5.02? in 5.04 i say:
foreign import ccall "&bdd_reorder_stable_window3" bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())
and that works (i.e. i can treat it like any other Haskell function).
5.02 had something called 'foreign label', which does the same thing. Check the docs for details.
3. i'd like to see some array marshalling code that copes with lists of ForeignPtrs, such as:
-- | Marshall a list of ForeignPtrs. Same structure as withArray0. withForeignArray0 :: Ptr a -> [ForeignPtr a] -> (Ptr (Ptr a) -> IO b) -> IO b withForeignArray0 marker vals f = allocaArray0 len (\ptr -> do pokeArray0 marker ptr $ map foreignPtrToPtr vals res <- f ptr mapM touchForeignPtr vals return res) where len = length vals
ITYM: withForeignArray0 fps io = withMany withForeignPtr fps $ \ps -> withArray0 nullPtr ps io
the problem is it isn't as usefully polymorphic as the corresponding withArray0 function (e.g. consider [(ForeignPtr a, ForeignPtr a)]). ideas?
What type do you want for it? Cheers, Simon
"Peter Gammie" <peteg@cse.unsw.EDU.AU> wants:
a general "stick this arbitrary (small) C object in an optimiser-impervious box" generalisation of ForeignPtr.
Simon Marlow writes:
There was a proposal for such a thing kicking around recently, and I think there's no real problems with it.
The discussion was in the 'ForeignPtr' thread back in November: http://haskell.org/pipermail/ffi/2002-November/thread.html There's several designs that are variants on: data ForeignObj a -- abstract instance Eq (ForeignObj a) type Finalizer a = FunPtr (a -> IO ()) newForeignObj :: a -> Finalizer a -> IO (ForeignObj a) addFinalizer :: ForeignObj a -> Finalizer a -> IO () withForeignObj :: ForeignObj a -> (a -> IO b) -> IO b touchForeignObj :: ForeignObj a -> IO () [A variant on this is to have a 'Finalizable' constraint on the type variable 'a' but I'm not sure why we need this. Also, I'm not sure what the status of the 'touch' operations is these days - IIRC, the GHC folk say it is hard for them to implement correctly.] I think it makes sense to do this or something very like it. We really ought to have done this when we switched from 'Addr' to 'Ptr a' but we misgeneralized. -- Alastair Reid ps Note that the Eq instance I wrote is for equality of the ForeignObj container, not the contents.
participants (2)
-
Alastair Reid -
Simon Marlow