Yhc/Gtk2Hs
< Yhc
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.
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