Yhc/Gtk2Hs
| Part of Yhc |
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