June 2003 - FFI - Haskell.org

Example: Binding C++ to Haskell using the ffi
by David Sankel 13 Dec '03

13 Dec '03

Sorry, forgot attachment . . . again. :-P -- Here is some example code doing just that. It uses ghc. Questions: Can one think of better ways to interface generic c++ libraries to Haskell? What do you think of the ->> member function operator? for the ffi people: Has any though gone into cplusplus? If so, how would it interface? Would stubs on the c++ side be generated or would it use the code directly. Later, David J. Sankel

2 1

new ForeignPtr without finalizers
by Ashley Yakeley 07 Jul '03

07 Jul '03

OK, I just upgraded to GHC 6.0. How do I create a new ForeignPtr that doesn't have any finalizers? newSimpleForeignPtr :: Ptr a -> IO (ForeignPtr a) newSimpleForeignPtr ptr = ?? -- Ashley Yakeley, Seattle WA

7 19

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Ross Paterson 04 Jul '03

04 Jul '03

The new wording: \code{unsafePerformIO} may compromise typing; to avoid this, the programmer should ensure that the result of \code{unsafePerformIO} has a monomorphic type. rules out the following: my_hash :: Storable a => a -> Int my_hash a = fromIntegral $ unsafePerformIO $ allocaBytes (sizeof a) $ \p -> do let size = fromIntegral (sizeOf a) c_memset p 0 size poke p a hash_bytes p size foreign import ccall unsafe "memset" c_memset :: Ptr a -> CInt -> CSize -> IO () foreign import ccall unsafe hash_bytes :: Ptr a -> CSize -> IO CInt I still claim that the problem isn't polymorphism itself, but creating polymorphic references, and that is always environment dependent. Manuel writes: > However, it is possible to construct examples that are deterministic, > but still dubious from a typing perspective. Let's assume a C routine > > void *foo(); > > that *always returns the same pointer* to a buffer area. To > bind this in Haskell as > > foreign import ccall foo :: Ptr a > > is problematic[1]. (a) It's constant across a run of the program, but its value still depends on the environment, and (b) the declaration contains incorrect type information.

2 3

Bom dia ffi
by Marta 29 Jun '03

29 Jun '03

1 0

ANI TOUR YAZ-2003 Katalogu
by ANI TOUR 29 Jun '03

29 Jun '03

1 0

RE: exercising the storage manager
by Simon Marlow 10 Jun '03

10 Jun '03

> g'day everyone, > > I'm getting segv's from a program using the FFI (ghc5.0x) on > MacOS X only, > i.e. not on Linux, my primary development platform. > > So... does anyone have any tips for showing up dodgy uses of > the FFI wrt > memory handling? What settings for GHC's garbage collector > will create the > most pathological situations? > > Also, I have some qualms about foreignPtrToPtr; by it's type, > it seems to > be exactly what you want most of the time, but due to the "if > this is the > last reference, the finalizers may run" caveat it almost always isn't. > I note that it already has some warnings attached to it, but... Most of the time you should be using 'withForeignPtr'. I don't think there can be any legitimate uses for foreignPtrToPtr unless there is a touchForeignPtr that is guaranteed to happen later. And that's a tricky guarantee, because it involves reasoning about strictness. Does anyone else think that foreignPtrToPtr should really be called unsafeForeignPtrToPtr? > - does anyone have a safe use for it that doesn't involve > touchForeignPtr? > > - can the FFI spec somehow group together all functions that > may introduce memory leaks or unsafety? Unsafety is normally indicated with an 'unsafe' prefix on the function name. Memory leaks are a different matter - since malloc on its own can introduce a memory leak, I'm not sure how you'd indicate that. Cheers, Simon

4 4

Bom dia ffi
by kandrak 10 Jun '03

10 Jun '03

Message to ffi(a)haskell.org Ola!!!! ffi GANHAMOS O PRÊMIO DE MELHOR SITE DO RAMO ======Estamos operando em Novo Formato====== Confira em: escuta21.kit.net ou http://www.escuta21.kit.net ei.... ffi Cuidado com o que fala ao Celular... ele tb tem ouvidos... para remover o ffi(a)haskell.org de nossa lista responda este e-mail e coloque remover nos perdoe o transtorno...ok? kandrak

1 0

exercising the storage manager
by Peter Gammie 10 Jun '03

10 Jun '03

g'day everyone, I'm getting segv's from a program using the FFI (ghc5.0x) on MacOS X only, i.e. not on Linux, my primary development platform. So... does anyone have any tips for showing up dodgy uses of the FFI wrt memory handling? What settings for GHC's garbage collector will create the most pathological situations? Also, I have some qualms about foreignPtrToPtr; by it's type, it seems to be exactly what you want most of the time, but due to the "if this is the last reference, the finalizers may run" caveat it almost always isn't. I note that it already has some warnings attached to it, but... - does anyone have a safe use for it that doesn't involve touchForeignPtr? - can the FFI spec somehow group together all functions that may introduce memory leaks or unsafety? cheers peter

1 0

ANN: H98 FFI Addendum 1.0, Release Candidate 9
by Manuel M T Chakravarty 10 Jun '03

10 Jun '03

RC 9 of the FFI Addendum is now at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The addendum seems to be stable and I like to close Version 1.0. There is only one open question: What to do about "threadsafe"? In the threads discussion, there seemed to be a tendency to not distinguish between "threadsafe" and "safe" after all. Shall we remove "threadsafe" from 1.0? That's what I tend to and will do unless there are strong arguments to retain "threadsafe". Cheers, Manuel -=- Changes since RC 8 * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory allocated with `alloca' or `allocaBytes'. * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by (re)initialisation with `hs_init()' must be supported.

5 12

RE: FFI Help
by Simon Peyton-Jones 09 Jun '03

09 Jun '03

Manuel Would it be worth mentioning or amplifying this point in the FFI spec, or perhaps in an accompanying Appendix/Commentary of examples and FAQs? Else someone else is going to trip over it sooner rather than later. Simon | -----Original Message----- | From: haskell-cafe-admin(a)haskell.org [mailto:haskell-cafe-admin@haskell.org] On Behalf Of Glynn | Clements | Sent: 04 June 2003 08:32 | To: Matthew Donadio | Cc: haskell-cafe(a)haskell.org | Subject: Re: FFI Help | | | Matthew Donadio wrote: | | > I am just starting to experiment with FFI, and am running into a | > problem. I was to create an FFI to the lgamma(3) found in many of the | > newer libm implementations. My code follows the sig. | > | > The lgamma function works. The gamma function core dumps (I am using | > ghc 5.04.3) on me. gdb reports a SIGSEGV in signgam(), but I'm not sure | > why. I believe that I need to use the monad because signgam is only | > valid after lgamma returns. | > | > Does anyone have an idea what I am doing wrong? | > | > Thanks. | > | > -- | > Matthew Donadio <m.p.donadio(a)ieee.org> | > | > > module Gamma (gamma, lgamma) where | > | > > import System.IO.Unsafe | > | > > foreign import ccall "math.h lgamma" lgammaC :: Double -> IO Double | > > foreign import ccall "math.h signgam" signgamC :: IO Int | | signgam is an "int" variable, but this assumes that it is a function | of type "int signgam(void)". | | Write a C wrapper "int get_signgam(void) { return signgam; }" and | import that. | | -- | Glynn Clements <glynn.clements(a)virgin.net> | Or alternatively, foreign import the address of the int and read it | directly with 'peek'. | | import Foreign | ... | foreign import ccall "math.h &signgam" signgamC :: Ptr Int32 | ... | gammaIO :: Double -> IO Double | gammaIO x = do lg <- lgammaC x | s <- peek signgamC | return $ fromIntegral s * exp lg | | | Regards, | Malcolm

2 1