From: Duncan C. <dun...@wo...> - 2005-04-06 17:14:00
|
On Wed, 2005-04-06 at 19:00 +0200, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > No, that's not necessary. It's fine to test with a smaller example, like > > running c2hs to generate glib.precomp. That follows the same pattern but > > is much quicker to profile. > > So, it is still an open issue and could be worth to do some profiling on > smaller sample? Yep. Have fun! Read the GHC docs on heap profiling. Seriously, it's a difficult issue. And the c2hs code is not so easy to read. > > FFI suport is in GHC CVS now. > > Is it complete? Yes. As far as I know. > > It should be easy to backport to 6.4. > So, it should appear in 6.4.1? Right. > > But yes, gclosure should make it unnecessary in most cases (for all > > signals, but there are a few other non GClosure-callbacks in other > > Gtk+ modules). > > But they can be converted to GClosure callbacks? No, there are several callbacks in Gtk+ that do not support GClosures, but even for these it's probably possible to avoid dynamic / "wrapper" export. It's not a high priority for me since very few programs use these functions. Even without full amd64 FFI support the GClosures for signals support would be ok. I doubt you'd ever come across one of the other ones. Duncan |