Hi Manuel, We could probably do a new release soonish. The main thing is testing. Two of the c2hs/tests/ are not working. In test/Calls.chs there's a slightly weird issue with C/Haskell name aliases. In the .chs file we've got: {#call fun MyString as myString#} but it generates: foreign import ccall safe "calls.h MyString" MyString :: (Ptr CChar) when it obviously should be: foreign import ccall safe "calls.h MyString" myString :: (Ptr CChar) It seems to me the wrong thing is happening when we parse the .chs file, we call (normAP apath oalias) which returns Nothing in this case: normAP :: CHSAPath -> Maybe Ident -> Maybe Ident normAP ide Nothing = Nothing normAP ide (Just ide') | apathToIdent ide == ide' = Nothing | otherwise = Just ide' and: apathToIdent (CHSRoot ide) = let lowerFirst (c:cs) = toLower c : cs in onlyPosIdent (posOf ide) (lowerFirst $ identToLexeme ide) For reasons I don't quite understand, it's comparing case insensitively on the first char and then because they appear to be equal it drops the alias and then end up using the original C name which was not a valid Haskell identifier. I've not looked at this code carefully enough to understand what's supposed to be happening. The structs test also fails, though I've not investigated why yet: c2hs structs.h Structs.chs c2hs: Errors during expansion of binding hooks: Structs.chs:32: (column 60) [ERROR]

...

...

Expected a pointer object! Attempt to dereference a non-pointer object or to use it in a `pointer' hook.

The failing line is: val4 <- liftM cIntConv $ {#get weird->nested.pnt->y#} weird and the C types were: typedef struct _point *point; struct _point { int x, y; }; typedef struct { bool b; int x; struct { int y, z; point pnt; } nested; } *weird; Presumably the problem is with the nested.pnt part. Other things I'd like to do, not related to a release: * eliminate the C2HS.hs source module and the corresponding --copy-library flag. * use the MTL rather than the current StateTrans, StateBase, State * use bytestrings in the C lexer * add pre-compiled header support It turns out very few things in C2HS.hs are actually used by generated code, and the ones that are used are either just aliases of standard library functions or simple compositions of library functions. The remaining functions are presumably there to be used by the programmer in .chs modules. I'm not sure that we need to provide this, especially since most of them are duplicates of things in the standard lib. The main difficulty with this change is that currently the marshalers are just a single Ident identifier where as for simple compositions we need code fragments like "fmap fromIntegral . peek". Perhaps we should just replace it with a String. For pre-compiled headers, I think this can be done and be compatible with the #cppery we currently allow in .chs files. C translation units have the nice suffix extension property. Declarations added later cannot change the meaning of earlier declarations. So it'd be possible to precompile a common header and so long as that appears before any per-file custom stuff that all works out fine, we just extend the info from the pre-compiled header. For example: Foo.chs: #include <gtk/gtk.h> #c blah #endc Bar.chs: #include <gtk/gtk.h> #include "something-else.h" So these generate different .chs.h header files, but they share a common prefix. This will be very common when using cabal which passes on the command line all the .h files in the 'includes:', and these headers are considered to be #included before any other directives in the .chs files. So a simple scheme would be to just allow pre-compilation of those headers passed on the command line. To actually do this we have to keep track of some info so we can pick up extending the header where we left off. At a pure parsing level all we need is the current set of typedef identifiers. We can reasonably assume that the header defines a number of complete external declarations so we don't need to preserve the list of nested scopes, that list should always be empty. However we would want to have the pre-compiled header file contain not the C AST but the maps that c2hs generates. This would involve adjusting name analysis phase a bit so that it can work incrementally, one external declaration at a time. So the info kept in the pre-compiled header file would be the 4 maps and the set of typeidents along with various bits of meta data for sanity checking. To have cpp only produce the suffix of a translation unit it's possible to use: -imacros file Exactly like -include, except that any output produced by scanning file is thrown away. Macros it defines remain defined. This allows you to acquire all the macros from a header without also processing its declarations. So in the above example we'd use that flag with a .chs.h file containing just the #includes of the headers passed on the command line. As for the UI, this should be a bit easier these days since Cabal can automate things. We needn't try and make it totally transparent at the c2hs level, since we can get Cabal to make it transparent at the user level. The simplest thing I can think of is to have Cabal pass a precomp flag that tells c2hs to generate or use the given precomp file. Cabal would put this file in the dist/build dir so it'd be cleaned automatically. If the file didn't exist yet, c2hs would generate it based just on the headers passed on the command line, and without examining the .chs file. If the precomp file did exist, c2hs would use it and check that the list of headers (and other -C flags) passed were exactly the same as for the previous invocation when the file was generated. I'm not sure if it should be c2hs or Cabal's responsibility to re-generate the precomp file if a header file in the local source tree changed. All this assumes of course that actually using pre-compiled headers is really significantly faster. That has yet to be properly demonstrated but my expectation is that it will be much faster. I'll probably be doing this demo as part of the Data.Binary optimisation work. Duncan