Yhc/Gtk2Hs

Part of Yhc (Download)

dcoutts is the person to help with this :)

FFI Requirements:

it's FFI 4.1.1, http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise4.html#x7-160004.1

dcoutts__	ndm|bristol: btw about the C interface, this is what we do for ghc at the moment:  http://haskell.org/gtk2hs/darcs/gtk2hs/glib/System/Glib/hsgclosure.c
dcoutts__	ndm|bristol: rather than export "wrapper"
dcoutts__: i guessed, but it will be worth it
ndm|bristol	the hope is to get all libraries in a yhc'able state
dcoutts__	basti_: oh I see what you mean. If we could make ghc packages into .so dynamic libs then linking would be quicker. Yeah.
dcoutts__	ndm|bristol: tell me when you start on that, I'd like to help.
dcoutts__	ndm|bristol: probably wait 'til we've got our darcs going
ndm|bristol	dcoutts__, will do, we'll have to wait til we have debugging and 100% haskell98 conformance first
dcoutts__	ndm|bristol: right, and full(ish) FFI support
basti_	xerox: are you there?
dcoutts__	ndm|bristol: in the mean time I can try and make all modules build without -fglasgow-exts
ndm|bristol	dcoutts__, ffi support is mainly done, just not checked in
ndm|bristol	not requiring -fglasgow would be a very good first step
dcoutts__	ndm|bristol: how about the export "wrapper" stuff?
ndm|bristol	but if there are any extensions you really can't live without, let us know
ndm|bristol	export wrapper? i'm not that well up on how gtk2hs works
dcoutts__	ndm|bristol: the fglasgow-exts is mostly for unsafeCoerce# which is only for an optimisation
dcoutts__	ndm|bristol: export "wrapper" is part of the FFI spec
dcoutts__	looks it up
ndm|bristol	if its part of the FFI spec, we'll implement it fully
dcoutts__	it used to be known as dynamc export
ndm|bristol	exporting functions back to C?
dcoutts__	right
ski	closures
ndm|bristol	that might be tricky
dcoutts__	yes, closures
ndm|bristol	i'm sure it can be done
ndm|bristol	Tom has FFI under control, he says
dcoutts__	ndm|bristol: that was my suggestion about libffi
ndm|bristol	i saw some initial demos of the FFI, seemed to be pretty flawless
ndm|bristol	dcoutts__, yes, libffi has been investigated
dcoutts__	the lib that allows one to construct C calls dynamically at runtime
ndm|bristol	looks like it might not work on windows with visual studio
dcoutts__	ndm|bristol: oh, and?
dcoutts__	hmm
dcoutts__	possible
ndm|bristol	yhc builds natively, and happily, using visual studio
dcoutts__	it's quite possibly GNU C only
ndm|bristol	it does seem to be
dcoutts__	wonders how python does foreign calls
ndm|bristol	i'll make sure tom is aware that closures are required
dcoutts__	ndm|bristol: actually most gtk2hs stuff does not  strictly need dynamic export
dcoutts__	the other alternative is a C api to make calls to Haskell
ndm|bristol	if its in the FFI spec, we should implement it
dcoutts__	that's actually what we do now with ghc
ndm|bristol	dcoutts__, we will have a C api for haskell soon
dcoutts__	and signal/event callbacks
ndm|bristol	thats pretty easy with our implementation
dcoutts__	that allows you to build and execute calls?
dcoutts__	eg mkHsChar, mkHsInt, mkHsApp etc?
ndm|bristol	probably, yes