March 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

haskell.cs.yale.edu
by TrafficMagnet Reseller 31 Mar '03

31 Mar '03

Become a TrafficMagnet Reseller Today! ------------------------------------------------------------------------ It's Free! Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000022127.1920.9.RwhwytxY2BieyC to Sign Up now! ------------------------------------------------------------------------ - Place any of these banners on your website, and you will earn $10 every time you refer a sale to TrafficMagnet! - Start making more money from your web space by reselling TrafficMagnet to your own customers and site visitors. - Get the HTML code for our banners and text links by signing up as a Reseller today! Visit http://www.trafficmagnet.com to find out more! Not interested in becoming a CoolStats Reseller? To be taken off our mailing list, please follow the instructions here: http://p1j2m3a4.pdhost.com/pdsvr/www/optoutredirect?UC=Lead&UI=14656144

1 0

RE: ForeignPtr naming
by Simon Marlow 26 Mar '03

26 Mar '03

> As Haskell finalizers need pre-emptive concurrency, maybe > they should go somewhere related to concurrency. Or we > could have a "Foreign.Concurrent". Ok, how about Foreign.Concurrent.newForeignPtr and Foreign.Concurrent.addForeignPtrFinalizer? i.e. dodging the naming issue by using the module system. It also means that code which uses GHC's existing versions of these functions can be fixed by changing imports only. Cheers, Simon

2 1

RE: Bound Threads
by Simon Peyton-Jones 21 Mar '03

21 Mar '03

| I think the essence of Daan's proposal was that the goals we hope to | achieve using 'bound', 'threadsafe', and other ffi annotations could | be achieved by adding a small amount of additional functionality | and wrappers and that benefits of doing this are: That all sounds splendid. If only I understood what the proposal actually was. (Precisely; I do have a vague understanding of it, but it's a slippery topic.) Simon

1 0

RE: Bound Threads
by Simon Peyton-Jones 21 Mar '03

21 Mar '03

| However, my proposal is not anywhere fundamentally difficult -- in its essence, I just | propose to move the implementation of the thread allocation strategy from the RTS/C | code, to a Haskell library. This gives programmers both a low-level interface for | explicit access and a high-level interface as it is now. It may well not be difficult, but nevertheless I am having difficulty understanding it. I'll have to wait till you have time to explain it. | What I mostly wanted to ensure is that people have really thought about this carefully | and that they could give strong reasons for choosing a particular design over another. The difficulty is that I can't give strong reasons for choosing X over Y when I don't understand what Y is. Next week is ok though. Good luck with thesis writing! Simon

2 1

RE: Bound Threads
by Simon Peyton-Jones 21 Mar '03

21 Mar '03

Daan I think everyone is keen to make progress on this bound-threads stuff. You have an alternative idea which we are trying to understand. Do you plan to have a go at the operational semantics, as a way of explaining it? At the moment we're a bit stuck: no one wants to move on before we have some kind of consensus, but you're the only one who can help us understand your proposal. Simon | -----Original Message----- | From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] | Sent: 17 March 2003 22:06 | To: Daan Leijen; Wolfgang Thaller; ffi(a)haskell.org | Subject: RE: Bound Threads | | | | | Maybe, the forkOS/forkIO approach is flawed, but I think we | | should only rule it out when we can provide a convincing | | example where only the keyword approach would work, and where | | we can't use combinators to achieve the same effect. | | | Daan, | | There has been extended discussion on this stuff, which Wolfgang and | Simon and I tried to boil out into a document. It's hard to say exactly | what 'safe' or 'bound' exports, or whatever, might mean, so we give a | little operational semantics. | | My hope is that the very same operational-semantic framework would serve | to describe your system. Would you like to write its transition rules, | in the same style? Then we could compare the two more easily. Without | that, I am hard pressed to understand the implications of what you | suggest, just as I was hard pressed to understand Wolfgang's proposal | till we had it specified. | | You can find the document in the CVS respository in | haskell-report/ffi/threads.tex | | Simon

2 1

RE: ForeignPtr naming
by Simon Marlow 21 Mar '03

21 Mar '03

> > This is all fine, except that implementing finalizer ordering slows > > down ForeignPtrs quite a bit, in particular mallocForeignPtr takes a > > 20% hit just allocating the IORef needed to store the list of > > finalizers. Ideas for a better implementation are welcome. > > Having obviously optimized the hell out of mallocForeignPtr, it sounds > like it's time to optimize the hell out of IORef. :-) > > Or, on the assumption that the slowdown comes from splitting what was > a single object into 2 or even three separate objects, do what it > takes to turn it back into a single object - i.e., put a mutable > field directly in the MFP object. > > Best of all, do as CAML has done and add the machinery (and semantics > changes) necessary so that whenever you have a tuple with a mutable > field in it, GHC will implement it without adding an indirection > through a separate IORef object. Highly worthwhile and might possibly > help with your MFP problem :-) I already optimised away one level of indirection by using a strict field and -funbox-strict-fields (standard practice when putting an IORef in a constructor :-), but there is still a separate object for the primitive mutable variable. Folding this into the constructor is an interesting idea - I'll muse on it. > > Anyway, this message is really about what names we should use for > > the old Haskell-finalizer versions of newForeignPtr and > > addForeignPtrFinalizer (and as such it doesn't have any bearing on > > the FFI spec 1.0). > > I'm rather taken by 'oldNewForeignPtr'. That implies the functionality is deprecated, rather than just non-portable, which is not the case at all. > > I'm assuming that we want to keep these functions in some form in > > GHC - where to put them is one issue; Foreign.ForeignPtr is a > > possibility (but not ForeignPtr), or GHC.ForeignPtr. > > I'd put them in GHC.ForeignPtr and make no other change in their name. One vote for GHC.ForeignPtr then. Any others? > Easy for people to transition, easy for people to see non-portable > code, probably little risk of collision with the ffi-mandated FunPtr > versions. On the subject of non-portability: the hierarchy is scattered with non-portable libraries, because the decision was taken a while back not to use the hierarchy to indicate portability, but to use it to guide programmers towards *functionality*. There are exceptions - eg. for extensions which are likely to remain compiler-specific. I don't think Haskell finalizers are necessarily GHC-specific, so putting them under GHC doesn't seem right in the long term. Cheers, Simon

2 1

ForeignPtr naming
by Simon Marlow 20 Mar '03

20 Mar '03

I'm just getting around to converting GHC's ForeignPtr to match the spec once more. This is all fine, except that implementing finalizer ordering slows down ForeignPtrs quite a bit, in particular mallocForeignPtr takes a 20% hit just allocating the IORef needed to store the list of finalizers. Ideas for a better implementation are welcome. Anyway, this message is really about what names we should use for the old Haskell-finalizer versions of newForeignPtr and addForeignPtrFinalizer (and as such it doesn't have any bearing on the FFI spec 1.0). I'm assuming that we want to keep these functions in some form in GHC - where to put them is one issue; Foreign.ForeignPtr is a possibility (but not ForeignPtr), or GHC.ForeignPtr. I looked back through old mail and couldn't find any suggestions for names. Nothing springs immediately to mind - newHaskellFinalizerForeignObj is clearly horrible. Ideas? Cheers, Simon

2 1

Re: [GUI] Another call for votes
by Axel Simon 19 Mar '03

19 Mar '03

Cross-posting this to FFI(a)haskell.org. On Mon, Mar 17, 2003 at 10:45:07PM +0100, Wolfgang Thaller wrote: > 4c) CGA functions may be called from everywhere, at any time. > Calling CGA functions should not block other concurrent Haskell threads > (except if the function is guaranteed to finish in a short time). > > 4d) First wait and see if 4c is implementable; if not, fall back to > 4b. I vote for 4c but I have a question which probably belongs to the FFI list. Maybe I am just not understanding the intentions of the FFI but I believe that I cannot make Gtk calls threadsafe from within Haskell. Gtk's thread issues are shortly explained at: http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html The issue seems to be that every call to Gtk has to be surrounded by a call to gdk_threads_enter and gdk_threads_leave. How am I supposed to bind these functions if I don't have any control about which thread executes a call? Suppose a) I do foreign import ccall unsafe "gdk_threads_enter" enter :: IO () foreign import ccall threadsafe "gtk_function" function :: IO () foreign import ccall unsafe "gdk_threads_leave" leave :: IO () and execute "enter >> function >> leave" is giving me unique access to the Gtk toolkit if every Gtk function call is surrounded by the "enter" and "leave" statements. Disadvantage: calling "enter" will block the whole Haskell system if there is another (OS) thread executing in Gtk. b) I change foreign import ccall unsafe "gdk_threads_enter" enter :: IO () to foreign import ccall threadsafe "gdk_threads_enter" enter :: IO () and loose safety: All "enter" calls hijack an OS thread and wait for the lock to be available. Meanwhile in Haskell, the Gtk function is called. It seems that it is necessary to state that these three functions all execute in the same thread. I don't want to write C wrappers for all Gtk functions! I hope I am missing something here. Axel.

2 1

RE: Bound Threads
by Simon Peyton-Jones 18 Mar '03

18 Mar '03

| Maybe, the forkOS/forkIO approach is flawed, but I think we | should only rule it out when we can provide a convincing | example where only the keyword approach would work, and where | we can't use combinators to achieve the same effect. Daan, There has been extended discussion on this stuff, which Wolfgang and Simon and I tried to boil out into a document. It's hard to say exactly what 'safe' or 'bound' exports, or whatever, might mean, so we give a little operational semantics. My hope is that the very same operational-semantic framework would serve to describe your system. Would you like to write its transition rules, in the same style? Then we could compare the two more easily. Without that, I am hard pressed to understand the implications of what you suggest, just as I was hard pressed to understand Wolfgang's proposal till we had it specified. You can find the document in the CVS respository in haskell-report/ffi/threads.tex Simon

1 0