August 2005 - C2hs - Haskell.org

Re: patch to c2hs to add support for hierarchical modules in {# import #} hooks
by Manuel M T Chakravarty 07 Aug '05

07 Aug '05

> Here is another patch to c2hs. This one is for supporting hierarchical > modules in {# import #} hooks. This feature has been in the Gtk2Hs fork > of c2hs for probably over a year so it probably works ok. Sorry about > not sending it sooner, I rather forgot about it. Thanks, Duncan. This patch is now also in the public repo. Manuel

1 0

Re: patch to c2hs to support asm constructs
by Manuel M T Chakravarty 07 Aug '05

07 Aug '05

Duncan Coutts: > On Fri, 2005-07-29 at 01:39 +0100, Duncan Coutts wrote: > > Hi Manuel, > > > > Attached is a darcs patch to c2hs to add support to the lexer and parser > > for asm statements and annotations. It also adds support for the string > > literal concatenation feature of C. > > Sorry I messed up the patch slightly and missed a bit out. Attached is > the correct patch. > > Note that this is a replacement patch, it's not cumulative. Thanks! Your patch is in the public repo now. > BTW, we've still got another patch that's we probably need before we can > use the mainline c2hs again. However I don't understand it! I'll have to > get Axel to look into that one. :-) It's something in the GenBind > module. As I recall it was something to do with foreign pointers. How big is the change? > I was experimenting with using your mainline c2hs to build Gtk2Hs. It > generates lots of little .h files and uses them in the foriegn import > declerations. The behaviour of our c2hs fork (at least when using the > precompiled headers feature) was not to mention any .h file in the > foreign import decleration. That way we only have to mention the .h > files that we pass to c2hs in the ghc package files and more importantly > we do not need to distribute all the .h files. Indeed these .h files are > always trivial, they just #include the main .h file we passed to c2hs in > the frist place. So is there a way to avoid generating the .h files if > they are trivial? Not including any .h in foreign imports is not a portable way of using the FFI. The only feasible "optimisation" for c2hs seems to be that if it generates a "foo.h" with only #include "lib.h" then it could drop "foo.h" and put "lib.h" into the foreign import declaration. That'd be a reasonable, generally useful feature, which I'd be happy to include. I'd prefer not applying this "optimisation" by default, though, but only when requested via a command line option. That is as some people may rely on the .h generated by c2hs in their packages. Is that a reasonable compromise? > I note that with c2hs now using cabal that it requires at least ghc 6.2. > In that case would patches that depend on library updates that come with > ghc 6.2 be ok? I'm thinking of the finite map libraries since the ghc > ones are rather faster. I recall there being a measurable speedup when I > switched them in the Gtk2Hs fork of c2hs. I am happy to rely on anything that is in the hierarchical libraries of GHC 6.2 *and* of nhc98 and Hugs. I'd like to keep the code base portable. AFAIK, Data.Map is portable. Thanks again for the patch, Manuel

1 0

Re: [Gtk2hs-devel] hsffig & c2hs
by Manuel M T Chakravarty 07 Aug '05

07 Aug '05

[Forwarded by list administrator.] -------- Forwarded Message -------- From: Axel Simon <A.Simon(a)kent.ac.uk> To: c2hs(a)haskell.org, Gtk2Hs-devel List <gtk2hs- devel(a)lists.sourceforge.net> Subject: Re: [Gtk2hs-devel] hsffig & c2hs Date: Wed, 03 Aug 2005 10:18:43 +0100 On Wed, 2005-08-03 at 00:26 +0100, Duncan Coutts wrote: > It might be interesting to see if we can use c2hs completely rather than hsc2hs > in places. c2hs development has picked up recently (yes, partly due to moving to > darcs) so if there are any lurking offset/sizeof bugs I'm sure we can get them > fixed. I don't think there there are any more bugs in c2hs as such. The main problem is building on windows, where Gtk+ is built with Visual-C-style bitfields and padding of structs. The reason I used hsc2hs is that I can explicitly pass the -mms-bitfields flag to hsc2hs on Windows which ensures that the header files are interpreted in Microsoft-style. Note that using -mms-bitfields is not a Microsoft thing, it's a compiler issue. At configure time, c2hs checks the platform to decide how fields are laid out, but, in fact, the layout depends on how the library was compiled. So to use c2hs we need to add a flag to c2hs that tells it to use Visual-C struct layout rather than gcc-style layout. >From the internal gcc docs: ...following the rules of Microsoft Visual C/C++, namely: (i) a bit- field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole enclosing structure, even if it is unnamed; except that (iii) a zero-sized bit-field will be disregarded unless it follows another bit-field of nonzero size. In other words: it's a bit complicated. Axel.

1 1

Only members can post
by Manuel M T Chakravarty 05 Aug '05

05 Aug '05

This is an administrative message. I recently switched c2hs(a)haskell.org to members-only posts to reduce spam (in fact, that is now the setting for all haskell.org lists). Some people found their messages where rejected by the list software. That is because they were not subscribed with the email address from which their posts originated. If you encounter similar problems, please double check your subscription. I am sorry for the inconvenience, but I am sure you appreciate to get less spam, too. Cheers, Manuel

1 0