Latest revision as of 23:40, 15 January 2006

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