From: Salil <hel...@gm...> - 2009-12-10 12:52:11
|
I tried compiling the darcs version of gtk2hs with ghc 6.12 rc2. First, the each package.conf needs an id, which it doesn't currrently have. Also, in c2hs, there is no CLDouble anymore, so you need to replace it with CDouble (http://hackage.haskell.org/trac/ghc/ticket/2793). After doing that things seemed to be working until c2hsLocal starting working on gtk/Graphics/UI/Gtk/Selectors/FileChooser.chs. At this point, memory usage kept climbing, and the process was eventually killed (I have only 1gb ram). The strange thing is this only happens with ghc 6.12. With ghc 6,10,4, everything works (I did not see exactly how much memory was used in that case). Any ideas? What if I were to compile c2hsLocal with ghc 6.10.4 and then compile the rest of gtk2hs with ghc6.12? Any reason this wouldn't work? Also, has anyone succesfully compiled gtk2hs with ghc 6.12? I don't want to spend more time on this only to find it is impossible. |
From: Duncan C. <dun...@go...> - 2009-12-10 15:58:31
|
On Thu, 2009-12-10 at 18:21 +0530, Salil wrote: > I tried compiling the darcs version of gtk2hs with ghc 6.12 rc2. Oh, I've also been trying that yesterday and today. I've just managed to get it installed. However it'll need a bit of cleaning up before sending in patches. > First, the each package.conf needs an id, which it doesn't currrently > have. Yes. For the inplace registration I've been using things like: id: gtk-@PACKAGE_VERSION@-inplace However, for the installed registration we need to generate the appropriate ABI hash by calling ghc. I've not done that bit yet, I've just registered them with the inplace names. Also, installed packages (like base, mtl etc) now have to be identified by their full installed package id, rather than the source package id. I've changed acinclude, configure and the package.conf.in files to do this. > Also, in c2hs, there is no CLDouble anymore, so you need to replace it > with CDouble (http://hackage.haskell.org/trac/ghc/ticket/2793). Yes, though that's not quite the right fix. I've been looking at the fix for the upstream c2hs. We want it to fail if it has to generate marshaling code for long double. Silently using the wrong type would be bad. Gtk+ doesn't use long double so that's ok. > After doing that things seemed to be working until c2hsLocal starting > working on gtk/Graphics/UI/Gtk/Selectors/FileChooser.chs. At this > point, memory usage kept climbing, and the process was eventually > killed (I have only 1gb ram). The strange thing is this only happens > with ghc 6.12. With ghc 6,10,4, everything works (I did not see > exactly how much memory was used in that case). I got the same. I've not tracked it down yet. I got round it for the moment by building c2hsLocal with ghc-6.10. Duncan |
From: Duncan C. <dun...@go...> - 2009-12-10 16:32:51
|
On Thu, 2009-12-10 at 18:21 +0530, Salil wrote: > I tried compiling the darcs version of gtk2hs with ghc 6.12 rc2. > > After doing that things seemed to be working until c2hsLocal starting > working on gtk/Graphics/UI/Gtk/Selectors/FileChooser.chs. At this > point, memory usage kept climbing, and the process was eventually > killed (I have only 1gb ram). The strange thing is this only happens > with ghc 6.12. With ghc 6,10,4, everything works (I did not see > exactly how much memory was used in that case). > > Any ideas? After a little more investigation I found that the file in question contains the UTF8 encoding of Unicode characters with code points > 255. My suspicion is that the c2hs lexer for .chs files goes into an infinite loop in this case since it assumes that all characters are 0..255: anySet = ['\0'..'\255'] The fix will either be to rewrite the chs lexer or to read the file in ASCII rather than the default locale encoding. Duncan |