On Tue, 2005-05-31 at 12:13 +0200, Gour wrote:
Duncan Coutts (duncan.coutts@worc.ox.ac.uk) wrote:
So I think it's worth trying to get this done for the 0.9.8 gtk2hs release. That should provide reasonable testing and then we can create patches for the mainline c2hs.
Definitely. This would greatly improve usability of the library 'cause it will be possible to actually build it without enormous amounts of memory and fiddling with the precomp files.
Ok, how about this for a plan: I'll integrate the new parser into the gtk2hs fork of c2hs. I'll keep both versions of the lexer & parser in it with the choice selectable by a command line switch. This will allow us to test that the new parser is producing exactly the same output as the old parser. We can ask gtk2hs-0.9.8 release candidate testers to run a few checks to make sure that this is indeed the case for the header files on their platform. The basic check is to see that the precomp files produced by each method is the same but I'll add another couple dump options to allow the C AST and the result of the name analysis to be dumped. If we can do this test at least once on each supported platform (Linux, Solaris, FreeBSD, Windows, MacOS X?) then I think we can be quite confident that the new parser is not going to introduce subtle bugs. After all that when we're confident it's working correctly, we can tidy our c2hs fork up be removing the old lexer & parser and send patches for the mainline c2hs. Currently, on my machine the two variants: $ c2hs +RTS -M380m -RTS --precomp=gtk.precomp.old-parser --old-parser gtk/gtk.h $ c2hs +RTS -M80m -RTS --precomp=gtk.precomp.new-parser gtk/gtk.h produce exactly the same output. :-) Duncan