Yhc/Gtk2Hs

From HaskellWiki
< Yhc
Revision as of 23:40, 15 January 2006 by NeilMitchell (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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