From: John V. <ve...@co...> - 2005-01-29 00:30:29
|
I've been trying to decide on a GUI interface to use for a project I'm working on as my first "real" Haskell application (-- a simple one for my own use, but if it works out I'll be willing to make it available.) I've been working with wxHaskell. On seeing the availability of GTK2HS on the Haskell mailing list, I thought I'd give it a try. Configure seems to work OK, and make compiles quite a bit, but ends up with: ---- make[2]: Entering directory `/home/jr/downloads/gtk2hs-0.9.7' /home/jr/downloads/gtk2hs-0.9.7/tools/c2hs/c2hsLocal +RTS -H400m -M650m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' --precomp=glib/glib.precomp glib-object.h elapsed time: 0.00 (start) elapsed time: 0.00 (about to parse headder) elapsed time: 3.90 (about to serialise header) make[2]: *** [glib/glib.precomp] Killed make[2]: Leaving directory `/home/jr/downloads/gtk2hs-0.9.7' make[1]: *** [glib/System/Glib/Types.hs] Error 2 make[1]: Leaving directory `/home/jr/downloads/gtk2hs-0.9.7' ghc-6.2.2: file `glib/System/Glib/Types.hs' does not exist make: *** [glib/libHSglib_a.deps] Error 1 make: *** Deleting file `glib/libHSglib_a.deps' bash-2.05b$ ls ----- I decided to try version 0.9.6 fo gtk2hs, and configure failed this time: ----- checking for libglade-2.0 >= 2.0.0... yes checking LIBGLADE_CFLAGS... -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking LIBGLADE_LIBS... -Wl,--export-dynamic -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lpthread -lz -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for gconf-2.0 >= 2.0.0... Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found configure: error: Library requirements (gconf-2.0 >= 2.0.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. bash-2.05b$ ---- I installed the slackware package gconf-2.4.0.1-i486-1.tgz, and now have gconf-2.0.pc in /usr/lib/pkgconfig which I wouldn't have thought to be non-standard. Got the same result. I did an export of $PKG_CONFIG_PATH, and still get the same thing" ----- configure: error: Library requirements (gconf-2.0 >= 2.0.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. bash-2.05b$ echo $PKG_CONFIG_PATH /usr/lib/pkgconfig/ bash-2.05b$ ----- I'd prefer to get 0.9.7 going, but now that my appetite is whetted, I'd be interested in getting either version working! I'm running Linux Slackware 9.1, GHC 6.2.2. (Both wxGTK and wxHaskell compiled :-) Thanks, John Velman |
From: Duncan C. <dun...@wo...> - 2005-01-29 14:33:30
|
On Fri, 2005-01-28 at 16:34 -0800, John Velman wrote: > I've been trying to decide on a GUI interface to use for a project I'm > working on as my first "real" Haskell application (-- a simple one for my > own use, but if it works out I'll be willing to make it available.) I've > been working with wxHaskell. > > On seeing the availability of GTK2HS on the Haskell mailing list, I thought > I'd give it a try. > > Configure seems to work OK, and make compiles quite a bit, but ends up > with: > > ---- > make[2]: Entering directory `/home/jr/downloads/gtk2hs-0.9.7' > /home/jr/downloads/gtk2hs-0.9.7/tools/c2hs/c2hsLocal +RTS -H400m -M650m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' --precomp=glib/glib.precomp glib-object.h > elapsed time: 0.00 (start) > elapsed time: 0.00 (about to parse headder) > elapsed time: 3.90 (about to serialise header) > make[2]: *** [glib/glib.precomp] Killed The short answer is: ./configure --whatever-options-you-normally-use make HSTOOLFLAGS="-H300m -M350m" make install The long answer is: This is a tiresome problem. c2hs requires vast amounts of memory. In the makefile by default we allow it to use up to 650m of heap space. Since your machine has less than this amount the linux kernel kills the process when it eventually takes up to much address space. The flags I suggest above (HSTOOLFLAGS="-H300m -M350m") tells c2hs to limit the amount of memory it uses. This will make it take much longer to run since it will have to do more garbage collection. If you have much less memory than 400m RAM you might be out of luck. You can experiment with a lower -Mxxxm value but if you set it too low the the program will also fail (it will give an error about running out of heap space). I would guess a machine with 256Mb would not be enough. :-( We could try distributing a version with the .precomp c2hs files already generated (though it would be specific to the minor version of Gtk+ you have installed - ie only 2.4.x or only 2.2.x for example). Let us know how you get on. Duncan |
From: Axel S. <A....@ke...> - 2005-01-29 16:58:34
|
On Sat, 2005-01-29 at 14:34, Duncan Coutts wrote: > On Fri, 2005-01-28 at 16:34 -0800, John Velman wrote: > > I've been trying to decide on a GUI interface to use for a project I'm > > working on as my first "real" Haskell application (-- a simple one for my > > own use, but if it works out I'll be willing to make it available.) I've > > been working with wxHaskell. > > > > On seeing the availability of GTK2HS on the Haskell mailing list, I thought > > I'd give it a try. > > > > Configure seems to work OK, and make compiles quite a bit, but ends up > > with: > > > > ---- > > make[2]: Entering directory `/home/jr/downloads/gtk2hs-0.9.7' > > /home/jr/downloads/gtk2hs-0.9.7/tools/c2hs/c2hsLocal +RTS -H400m -M650m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' --precomp=glib/glib.precomp glib-object.h > > elapsed time: 0.00 (start) > > elapsed time: 0.00 (about to parse headder) > > elapsed time: 3.90 (about to serialise header) > > make[2]: *** [glib/glib.precomp] Killed > > The short answer is: > > ./configure --whatever-options-you-normally-use > make HSTOOLFLAGS="-H300m -M350m" > make install > > The long answer is: > > This is a tiresome problem. c2hs requires vast amounts of memory. In the > makefile by default we allow it to use up to 650m of heap space. Since > your machine has less than this amount the linux kernel kills the > process when it eventually takes up to much address space. I'm just wondering: Could this be a ulimit problem rather than the amount of physical memory? John, could you check that as well? You should certainly stick to 0.9.7 even though c2hs' memory usage is really bad. We are still trying to understand what is happening here. Axel. |
From: Duncan C. <dun...@wo...> - 2005-01-29 17:48:12
|
On Sat, 2005-01-29 at 16:57 +0000, Axel Simon wrote: > I'm just wondering: Could this be a ulimit problem rather than the > amount of physical memory? John, could you check that as well? It is possible. My guess was based on the likelihood of the OOM killer deciding to kill the process since the kernel had over-committed memory and c2hs being the culprit of the high VM pressure. > You should certainly stick to 0.9.7 even though c2hs' memory usage is > really bad. We are still trying to understand what is happening here. Part of the problem is the binary serialisation patch but it's more than that. The binary serialisation generates vast amounts of garbage but doesn't really retain much memory. That is to say if you set -Hxxxm quite low but just high enough for the parsing & name analysis to complete then it is enough for the binary serialisation. That said, with a low heap limit the serialisation takes much longer because it has to garbage collect so frequently. In a bit of testing myself I found that the minimum heap limit that would still work is -H350m. -H340m died due to heap exhaustion. The real memory culprit is the c2hs model. It accumulates everything into these big maps. There are really three phases: 1. parsing - this just builds the maps without looking anything up 2. name analysis - this does lots of lookups in the AST and builds 4 other maps 3. code generation - does just a few lookups in the 4 maps The precomp patch does the serialisation after step 2. The memory use for step 3 is low since only a few things get looked up (and lazily deserialised). The first step is not inherently memory hungry. It could operate in (more-or-less) constant space by serialising AST declarations as it goes. The second step is the worst from a memory consumption point of view. It does lots of lookups and sticks modified references to AST elements in these other maps. The module is: c2hs/c/CNames.hs which exports just nameAnalysis. I have not yet looked at it in enough detail to really understand it. It shouldn't be too hard however, there's only about 100 lines of code. I think what we would want to figure out is whether this name analysis algorithm really requires everything to be kept in memory or whether it could be changed to work in a mode where it deserialises a bit of AST from one file and writes out a bit of a map into another file, using very little memory in between. Even if it has to keep a record of which names it has seen before (to detect name clashes), that would be an improvement since the names are pretty small compared to the values to which they are the keys. Duncan |
From: John V. <ve...@co...> - 2005-01-29 22:17:25
|
On Sat, Jan 29, 2005 at 04:57:33PM +0000, Axel Simon wrote: > On Sat, 2005-01-29 at 14:34, Duncan Coutts wrote: > > On Fri, 2005-01-28 at 16:34 -0800, John Velman wrote: > > > I've been trying to decide on a GUI interface to use for a project I'm [snip] > > I'm just wondering: Could this be a ulimit problem rather than the > amount of physical memory? John, could you check that as well? > > You should certainly stick to 0.9.7 even though c2hs' memory usage is > really bad. We are still trying to understand what is happening here. > > Axel. > > > Thanks Duncan and Axel -- I'm afraid I'm a bit out of my depth here (see below on ulimit). Also, from everything said it looks like I should give up on this until I bring my machine into the 21st century -- currently 400Mhz, 128Mb RAM. (Progress boggles the mind. The first computer I worked with had real magnetic cores, 32K of 36bit 'words' and when we got a hard drive it was taller than a person and held something like a million of those words.) If it is worth trying something with ulimit on this machine I'll be more than happy to, but would need a word of guidance. There is a man3 page for ulimit related to glibc, but that says it is obsolete so I don't suppose thats the ulimit you mean. My bash ulimit -a says: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1023 virtual memory (kbytes, -v) unlimited Thanks again, Best, John Velman |
From: Duncan C. <dun...@wo...> - 2005-01-29 23:21:55
|
On Sat, 2005-01-29 at 14:22 -0800, John Velman wrote: > Thanks Duncan and Axel -- > > I'm afraid I'm a bit out of my depth here (see below on ulimit). Also, > from everything said it looks like I should give up on this until I bring > my machine into the 21st century -- currently 400Mhz, 128Mb RAM. Sadly with the current memory greed of c2hs 128Mb or RAM is well short, even with the wonders of virtual memory. There are two options, one of us could build a binary distribution or we could try and improve c2hs. The former is the easier short term solution and the latter a better long term solution. > (Progress > boggles the mind. The first computer I worked with had real magnetic > cores, 32K of 36bit 'words' and when we got a hard drive it was taller than > a person and held something like a million of those words.) The other day I went to Bletchley Park where they did the code breaking during WWII. They have a reconstruction of the first programmable computer. I was amused to see in their old computer exhibit a machine that we had in our university lab when I arrived a few years ago. In a couple years I bet they'll have the one I've got on my office desk now. > If it is worth trying something with ulimit on this machine I'll be more > than happy to, but would need a word of guidance. There is a man3 page for > ulimit related to glibc, but that says it is obsolete so I don't suppose > thats the ulimit you mean. The ulimit wont help. :-( * What version of ghc are you using? * What kind of processor? (ie generic intel compatible or something more exotic?) * what version of gtk+ do you have? The easiest way to answer is send the result of these commands: $ ghc --version $ uname -a $ pkg-config --modversion gtk+-2.0 libglade-2.0 If I have something compatible, I'll do a binary build for you. Duncan |