On Thu, 2005-05-19 at 16:26 +1000, André Pang wrote:
On 19/05/2005, at 12:15 AM, Gour wrote:
btw, gtk2hs devs have problem with space leaks in c2hs, ie. one requires over 1GB of RAM to process gtk2 headers.
I think Duncan Coutts was working on this; I don't know any of the details, so we'll have to wait for his reply ...
Well... Our considered opinion (Axel and myself) is that c2hs's memory consumption is a very difficult thing to fix and any fix we might be able to come up with would likely be very invasive and so Manuel would not be very keen on the idea. One approach I havn't tried but might bear some fruit is to check that c2hs is actually using all the data it collects, or if in fact much of the AST goes unused in which case it could be eliminated. However I don't imagine that this would give any enourmous savings (ie enough to process the Gtk 2.x headers on a machine with 256Mb or RAM). I do have another idea however which I would like to get some feedback upon... Basically the idea is that we want to to only run c2hs on the developers machine and distribute the resulting .hs files. That way only the developers machines need 1Gb of RAM. But we also want the resulting .hs files to be portable. Portable both between architectures and between different versions of Gtk+. For the architecture independence all we have to do is make sure we are not using the c2hs {# get #} {# set #} features since they embed field offsets into the .hs file which is not portable. This is not a great hardship for us since we mostly use hsc2hs for doing structure access and c2hs for calling functions. Having the .hs files work with different Gtk+ versions is more tricky. The idea here is to run cpp on the .hs files after running c2hs, so we distribute the .hs files output from c2hs and run cpp over them on the target machine when we know what version of Gtk+ we are targeting. For this to work we need to run c2hs with the latest version of Gtk+ (since it has to be a superset of all versions we intend the .hs files to support) and we need to have c2hs pass the preprocessor directives through to the .hs files. In fact it is slightly more complicated that this. We can't just have c2hs ignore the cpp directives since then the problem would be that the foriegn import declarations that c2hs adds at the end of the .hs file would not be in the context of the cpp directives where the {# call #} was used. So to fix this problem I have hacked up a patch such that the cpp context is output along with the foreign import declarations. This takes advantage of the existing feature in c2hs where it interprets the cpp directives, but this uses it for a different purpose. I don't think this approach is too invasive, it is cartainly much less so than our existing precompiled headers patch or any proposed heap reduction strategy. I do not yet know if this approach will work fully, I'm still asessing its feasability. If it does turn out to be a workable approach, I'd be keen to discuss with Manuel wether he might accept such a feature (controlled by some command line flag) into the main c2hs. Duncan