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
Duncan Coutts (duncan.coutts@worc.ox.ac.uk) wrote:
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.
Great. Go ahead.
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.
Nice.
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.
At least, fixing (potential) bugs will be easier than non-compile ;)
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.
Two flies in one hit :-)
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. :-)
OK. Give us some input for testing ;) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Sounds good to me. Manuel Duncan Coutts:
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
_______________________________________________ C2hs mailing list C2hs@haskell.org http://www.haskell.org/mailman/listinfo/c2hs
On Wed, 2005-06-01 at 22:16 +1000, Manuel M T Chakravarty wrote:
Sounds good to me.
You can review the cleaned up versions of the lexer and parser here: http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CLexer2.x?only_with_tag=branch-0-9-8&view=markup http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CParser2.y?only_with_tag=branch-0-9-8&view=markup And they are in the version of c2hs included in the Gtk2Hs 0.9.8 release candidate: http://sourceforge.net/mailarchive/message.php?msg_id=11998853 for easy comparison it includes both the old and new parser (selectable with --old-parser) and an extra --dump type "ast" which dumps the AST after parsing (but before the name analysis). Duncan
Duncan Coutts:
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 Coutts:
On Wed, 2005-06-01 at 22:16 +1000, Manuel M T Chakravarty wrote:
Sounds good to me.
You can review the cleaned up versions of the lexer and parser here: http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CLexer2.x?only_with_tag=branch-0-9-8&view=markup http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CParser2.y?only_with_tag=branch-0-9-8&view=markup
Looks great! Just two minor points: * In CLexer2.idkwtok, why didn't you use string literals (but explicit lists of characters instead)? * I also prefer lines with max. 80 characters (I usually work on my laptop and its screen is not that big). I take it that the new version works fine on the whole of gtk2hs. So, if you would prepare a patch against the mainline c2hs in the darcs repo, I'd be more than happy to replace the existing lexer and parser with your new version. Thanks, Manuel
On Wed, 2005-06-08 at 21:12 +1000, Manuel M T Chakravarty wrote:
Duncan Coutts:
On Wed, 2005-06-01 at 22:16 +1000, Manuel M T Chakravarty wrote:
Sounds good to me.
You can review the cleaned up versions of the lexer and parser here: http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CLexer2.x?only_with_tag=branch-0-9-8&view=markup http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CParser2.y?only_with_tag=branch-0-9-8&view=markup
Looks great! Just two minor points:
* In CLexer2.idkwtok, why didn't you use string literals (but explicit lists of characters instead)?
Because GHC translates the former into a sequence of string comparisons, but the latter using its effecient pattern matching algorithm. So the former is a linear search, the latter is more like a trie. It makes a significant difference to the speed of the lexer. We could of course use an explicit trie data structure if we had one to hand.
* I also prefer lines with max. 80 characters (I usually work on my laptop and its screen is not that big).
Ok, I'll see if I can reformat it before submitting it.
I take it that the new version works fine on the whole of gtk2hs.
Yes it works for me and Axel on a number of platforms (Linux, Solaris, Windows). The Gtk2Hs release candidate uses it.
So, if you would prepare a patch against the mainline c2hs in the darcs repo, I'd be more than happy to replace the existing lexer and parser with your new version.
Great! I fear I may have to leave the required build system changes to you. We're using a different build system. Duncan
On 08/06/2005, at 9:15 AM, Duncan Coutts wrote:
Great! I fear I may have to leave the required build system changes to you. We're using a different build system.
Considering that this change will require build system changes, would it be worthwhile rewriting the C2HS build system to use Cabal now, rather than later? -- % Andre Pang : trust.in.love.to.save http://www.algorithm.com.au/
Andre Pang:
On 08/06/2005, at 9:15 AM, Duncan Coutts wrote:
Great! I fear I may have to leave the required build system changes to you. We're using a different build system.
Considering that this change will require build system changes, would it be worthwhile rewriting the C2HS build system to use Cabal now, rather than later?
Certainly. Do you volunteer? ;) BTW, there is one other change that I would like to do at the same time. It's rather inconvenient that the c2hs libs need to be installed by anybody using an app using a c2hs-generated binding. So, I like the c2hs support code to go into a plain .hs file that c2hs spits out on command (together with the generated binding). It can then be linked into the generated binding and application users don't get a c2hs dependence. As a side benefit that will make it easier to generate bindings for nhc plus we are getting close to supporting cross compilation (which Tony Sloane likes to have). Manuel PS: Elimination of the libc2hs will make building w/ cabal actually easier; hence, that change should happen at the same time.
On 09/06/2005, at 1:30 AM, Manuel M T Chakravarty wrote:
Considering that this change will require build system changes, would it be worthwhile rewriting the C2HS build system to use Cabal now, rather than later?
Certainly. Do you volunteer? ;)
Well, I don't think I said that ... :)
BTW, there is one other change that I would like to do at the same time. It's rather inconvenient that the c2hs libs need to be installed by anybody using an app using a c2hs-generated binding. So, I like the c2hs support code to go into a plain .hs file that c2hs spits out on command (together with the generated binding). It can then be linked into the generated binding and application users don't get a c2hs dependence.
Right, that makes sense. I'm not up for doing this anytime soon, but I'm sure one of the others here will be more keen ;) -- % Andre Pang : trust.in.love.to.save http://www.algorithm.com.au/
Duncan Coutts:
On Wed, 2005-06-08 at 21:12 +1000, Manuel M T Chakravarty wrote:
Duncan Coutts:
On Wed, 2005-06-01 at 22:16 +1000, Manuel M T Chakravarty wrote:
Sounds good to me.
You can review the cleaned up versions of the lexer and parser here: http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CLexer2.x?only_with_tag=branch-0-9-8&view=markup http://cvs.sourceforge.net/viewcvs.py/gtk2hs/gtk2hs/tools/c2hs/c/CParser2.y?only_with_tag=branch-0-9-8&view=markup
Looks great! Just two minor points:
* In CLexer2.idkwtok, why didn't you use string literals (but explicit lists of characters instead)?
Because GHC translates the former into a sequence of string comparisons, but the latter using its effecient pattern matching algorithm. So the former is a linear search, the latter is more like a trie. It makes a significant difference to the speed of the lexer. We could of course use an explicit trie data structure if we had one to hand.
Ah! Bad GHC...
* I also prefer lines with max. 80 characters (I usually work on my laptop and its screen is not that big).
Ok, I'll see if I can reformat it before submitting it.
Thanks!
So, if you would prepare a patch against the mainline c2hs in the darcs repo, I'd be more than happy to replace the existing lexer and parser with your new version.
Great! I fear I may have to leave the required build system changes to you. We're using a different build system.
No problem. I am grateful for the effort you made to implement this in the first place. Manuel
participants (4)
-
Andre Pang -
Duncan Coutts -
Gour -
Manuel M T Chakravarty