September 2002 - FFI - Haskell.org

Kanser Tedavisi
by carctol＠yahoo.com 25 Sep '02

25 Sep '02

charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII"; charset="US-ASCII" Reply-To: carctol(a)yahoo.com Date: Wed, 25 Sep 2002 00:12:48 +0300 X-Priority: 3 X-Library: Indy 9.00.10 X-Mailer: Foxmail Kemoterapinin yan etkileri nedeniyle yorgun ve bitkin d�sm�s bir yakininiz mi var? Yanitiniz evetse vakit kaybetmeyin ve CARCTOL'u denemesini saglayin. Genelde ancak klasik tedavinin ise yaramadiginin anlasilmasi, insanlari baska se�enekler aramaya itmektedir, ancak o durumda maalesef yapacak fazla birsey kalmamaktadir. Ayni hatanin yapilmasina izin vermeyin ve hi�bir yan etkisi olmayan, Himalaya Dagi bitkilerinden �retilen Carctol'u denemesini saglayin. CARCTOL, birka� bin yillik, alternatif Hint Tibbinin (Ayuverda'nin) insanliga sundugu bir umut isigidir. �nceleri v�cudu takviye edici tonik olarak kullanilan bu �r�n simdi yeni form�l�yle kansere karsi etkili bir ila�tir L�tfen asagidaki siteye ugrayin ve Carctol'u yakindan taniyin. http://www.kanser-tedavisi.com esenlikler dileriz. Listeden adinizin silinmesini istiyorsaniz a_cengiz2002(a)yahoo.com a bos e posta yollayin. Tesekk�rler

1 0

RE: addForeignPtrFinalizer
by Simon Marlow 24 Sep '02

24 Sep '02

> The spec says there are no guarantees on the order in which > the finalizers > are run. Doesn't this make this function almost impossible to use? > Suppose one finalizer frees the storage and the other cleans > up something > it refers to. I'd suggest running the finalizers in the reverse order > to the order they were added, i.e. the new finalizer will be > run before > any existing ones. Now that finalizers are FunPtrs, there should be > fewer semantics problems. Ordering of finalizers is not usually well-specified - I realise this case is special (the finalizers are attached to the same object), but it would still be quite tricky to implement in GHC. The reason is that for each finalizer we create a new, independent, weak pointer that points to the target object. (that's probably how we came to have addForeignPtrFinalizer in the first place; it's a natural generalisation in GHC, but perhaps not if you use a different implementation of ForeignPtr. ) Cheers, Simon

1 0

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 7
by Simon Marlow 20 Sep '02

20 Sep '02

> > > RC 7 of the FFI Addendum is now available from > > > > In adding mallocForeignPtr and friends to Hugs, I found > that I needed > > the address of free to pass as a parameter. > > > > There's no suitable way to generate &free from > MarshalAlloc.free (the > > obvious use of a Haskell wrapper would break the whole > reason for the > > recent change to ForeignPtrs). > > > > Could we add &free to the export list of MarshalAlloc? > > > > foreign import ccall unsafe "stdlib.h &free" ptr_free :: > FunPtr (Ptr a -> IO ()) > > > > I am currently using 'ptr_free' as the Haskell name for this pointer > > but I expect that a better name could be found with little effort. > > So far, we never explicitly say (I believe) that `malloc' > corresponds to C's `malloc()'; ie, that C's `free()' (and > hence, `ptr_free') may actually be used to free storage that > has been allocated by `malloc'. > > We might define the CAF > > cfree :: FunPtr (Ptr a -> IO ()) > > as a pointer to a C function that free's storage allocated > with `malloc' from C without entering Haskell land and > explicitly note that this is useful as a finalizer. > > The construction still seems pretty awkward to me. I hope > the change to ForeignPtr doesn't entail any more nasty > suprises like this. ... maybe I'm being stupid, but I don't see what the problem is. Why can't mallocForeignPtr be implemented as: mallocForeignPtrBytes size = do r <- c_malloc (fromIntegral size) newForeignPtr r ptr_c_free foreign import ccall unsafe "malloc" c_malloc :: CInt -> Ptr a foreign import ccall unsafe "&free" ptr_c_free :: ForeignPtr (Ptr a -> IO ()) i.e. it's completely independent of MarshalAlloc.malloc. If you happen to know that MarshalAlloc.malloc is the same as C's malloc, then you could use that instead, but you don't have to. A separate issue is whether MarshalAlloc.malloc *should* be specified as being an interface to C's malloc(). I hadn't noticed that it currently wasn't. I don't think I have any code that relies on it, and I can't think of any strong arguments one way or the other, apart from the fact that MarshalAlloc is not part of the C-specific marshalling library. Cheers, Simon

2 1

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7
by Alastair Reid 19 Sep '02

19 Sep '02

> RC 7 of the FFI Addendum is now available from In adding mallocForeignPtr and friends to Hugs, I found that I needed the address of free to pass as a parameter. There's no suitable way to generate &free from MarshalAlloc.free (the obvious use of a Haskell wrapper would break the whole reason for the recent change to ForeignPtrs). Could we add &free to the export list of MarshalAlloc? foreign import ccall unsafe "stdlib.h &free" ptr_free :: FunPtr (Ptr a -> IO ()) I am currently using 'ptr_free' as the Haskell name for this pointer but I expect that a better name could be found with little effort. -- Alastair

2 1

RE: lightweight struct handling in FFI?
by Simon Marlow 19 Sep '02

19 Sep '02

> From: Antony Courtney [mailto:antony@apocalypse.org] > > While the FFI spec. is excellent, I'd really like to see a companion > document with real examples of how to use the FFI for the > easy, obvious > kinds of library interfacing tasks that are likely to arise > in practice. There are quite a few examples in fptools/libraries in the CVS repository. These libraries all use the FFI: IO, Time, Directory, CPUTime, Network.Socket, Text.Regex.Posix, and the new System.Posix stuff. I agree, it would be nice to have some introductory material on programming the FFI "for real", though. > Such examples would hopefully help answer things like the following > rather naieve question that I have: > > Is there a particular "best" way to deal with C functions that take > "lightweight" struct values (or pointers to such structs), To answer your question, there are several choices, each with its own advantages and disadvantages. You'll find examples of these in the libraries I mentioned above. I'm assuming that you want to use the FFI directly (possibly with help from c2hs or hsc2hs), rather than use one of the higher level tools. 1. Fully marshal the structure to/from Haskell. The best way to do this is to write a Haskell datatype for the structure, and define a Storable instance for it. You can use a tool to help you write the Storable instance in a portable way: hsc2hs and c2hs are good for this. Full marshalling is likely to be a good choice when you want to do lots of manipulation of the structure on the Haskell side. 2. Keep the structure in its C representation, and manipulate the structure using peek/poke in Haskell. This is a good choice if manipulation on the Haskell side is limited, for example if a single field is required to be extracted, and you don't want to marshal the entire struct into Haskell. Also, sometimes the representation is partially abstract on the C side (many C structs in POSIX for example are only partially specified by the standard), so fully marshalling it is not an option. If the lifetime of the struct is well-known and scoped (such as across a single call to a foreign function), then the MarshalAlloc.alloca family of functions can be used to allocate it. Again, to portably peek/poke individual fields, you'll probably find that hsc2hs or c2hs are useful. If the lifetime of the structure does not work well with alloca, or you want it to be garbage collected, then use a ForeignPtr instead. The new functions mallocForeignPtr and mallocForeignPtrBytes provide for this kind of allocation, and will perform better in GHC than using explicit malloc/free. Hope this helps, Simon

1 0

lightweight struct handling in FFI?
by Antony Courtney 19 Sep '02

19 Sep '02

Hello FFI-ers, While the FFI spec. is excellent, I'd really like to see a companion document with real examples of how to use the FFI for the easy, obvious kinds of library interfacing tasks that are likely to arise in practice. Such examples would hopefully help answer things like the following rather naieve question that I have: Is there a particular "best" way to deal with C functions that take "lightweight" struct values (or pointers to such structs), such as the classic: struct point { float x, y; }; ? Should I treat this is an opaque ForeignPtr, use heap allocation everywhere, and abandon pattern matching on the Haskell side? Or should I create a data type on the Haskell side, and marshall and un-marshall this to the C side as necessary (perhaps by writing wrapper routines that take x and y as separate arguments)? Or can I use Storable in some way to do better than either of the above options? It's just not clear to me from the specification. Any help would be appreciated. Thanks, -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony

2 1

hi
by Bety Lora 16 Sep '02

16 Sep '02

http://www.geocities.com/alikahomapage/alika http://www.lizaclub.da.ru http://www.sokarim.tk

1 0

Re: Updates to FFI spec
by Marcin 'Qrczak' Kowalczyk 13 Sep '02

13 Sep '02

12 Aug 2002 11:33:41 +0100, Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> pisze: > (In the image processing example, images were megabytes and an > expression like (x + (y * mask)) would generate 2 intermediate images > (several megabytes) while doing just 2 reductions in Haskell.) OCaml allows the programmer to specify an approximate amount of foreign memory in its wrapped C pointers. Maybe it's a good idea? -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

2 1

Re: Updates to FFI spec: performGC
by George Russell 13 Sep '02

13 Sep '02

Alastair wrote about performGC (snipped) > It'd be nice to say that it has to be a full GC - but I've no idea how > to specify that in a non-operational (i.e., implementation dependent) > way. I certainly don't think you should constrain implementations to be able to perform a "full GC" in any sense. It is possible if unlikely that someone will get along to implementing the "HaskellKit", where GC is entirely dispensed with and replaced by region analysis. Even if that's not the case, I certainly hope that one of these days someone will get along to implementing a Haskell compiler that does at least some easy region analysis. Also there are probably hard-real-time GC algorithms (like Baker's treadmill) or algorithms which are close to being hard-real-time (like the train algorithm) where doing a "full GC" would be a major pain.

3 4

ANN: H98 FFI Addendum 1.0, Release Candidate 6
by Manuel M T Chakravarty 12 Sep '02

12 Sep '02

Please review RC 6 available at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ A change log is appended. This version features a rather large number of changes over the last version, which is making me a bit uneasy, as I hoped that the spec would converge soon. But many of these changes have been prompted by Alastair and Malcolm bringing their systems in line, which is probably the most effective way of debugging the spec. Cheers, Manuel -=- * Author list: changed Alastair Reid's institution * 1.4: Clarified the wording * 4.1: Explicitly stated that access to pre-processor symbols is not provided by the FFI * 4.1.1: Removed [lib] from impent syntax and discussion * 4.1.3: Added parentheses round FunPtr ft to make it easier to understand a tolerably complex type. * 4.1.4: Removed all mention of library objects; clarified that header files do not impact the semantics of foreign calls, but may be required for correct code generation by some systems * 5.2: Clarified that all operations in Bits are member functions of the type class. Reverse the meaning of the sign of the second argument for `rotate' and `shift' (this makes it the same as GHC used all the time). `bitSize' on `Integer' etc is now undefined. * 5.5: Finalisers must be external functions to facilitate the implementation on Haskell systems that do not support pre-emptive concurrency. Added mallocForeignPtr and mallocForeignPtrBytes. * 6: Specified that HsBool==int in table2 Relabelled column 1 in table 3 (C symbol -> CPP symbol) Replaced 0 and 1 with HS_BOOL_FALSE/TRUE * 6.1: Clarified that nullPtr (nullFunPtr) coincides with (HsPtr) NULL and (HsFunPtr) NULL, respectively. Allowing multiple calls to hs_init() and clarified the constraints on the relative timing between hs_set_argv() and getProgName/getArgs. Added hs_perform_gc().

1 0