- C2hs - Haskell.org

RE: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly"
by Simon Marlow 14 Aug '05

14 Aug '05

On 14 August 2005 14:53, Paolo Martini wrote: > The problem is that c2hs.cabal is missing the field: "Build-Depends: > base,haskell98" (right after "Category:", preserving the newline > before "Executables:") > > I don't exacly know if it is a workaround or a solution to a bug, but > it does make c2hs compile -- hooray :-) That's the right solution. Cheers, Simon

2 1

RE: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly"
by Simon Marlow 14 Aug '05

14 Aug '05

On 12 August 2005 16:06, Manuel M T Chakravarty wrote: > Gour: >> Manuel M T Chakravarty (chak(a)cse.unsw.edu.au) wrote: >> >>> CForeign is a module from the FFI standard. What version of GHC >>> are you using? >> >> The Glorious Glasgow Haskell Compilation System, version >> 6.4.1.20050801 > > This must be a 6.4.1 issue. In 6.4, CForeign is visible, but in > 6.4.1. it doesn't seem to be visible anymore. Hmm, shoudln't > patchlevel releases not change the interface? CForeign is still in 6.4.1. What problem are you having? Cheers, Simon

2 1

Beijing Chinese Translation
by Beijing Chinese Translation 12 Aug '05

12 Aug '05

1 0

ANN: C->Haskell version 0.14.3 "Travelling Lightly"
by Manuel M T Chakravarty 12 Aug '05

12 Aug '05

I like to announce version 0.14.3 of C->Haskell, which brings the following advances over 0.14.1: * gcc's asm construct is supported, which is apparently important for some libraries on Mac OS X (thanks to Duncan Coutts for the patch); * C->Haskell supports cross compilation (see details below); [NB: C->Haskell now generates completely portable Haskell code (needs only H98 + FFI) and can target C compilers on platforms that cannot build C->Haskell itself; eg, PalmOS. In particular, C->Haskell generated bindings are suitable for nhc98 and Hugs, too.] * hierarchical modules syntax can be used in import hooks (again thanks to Duncan for the patch); and * two new built-in translation functions "upcaseFirstLetter" and "downcaseFirstLetter" are supported to generated suitable Haskell names from C names (eg, for variants of enums). Source code is available as a tar ball from http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ or via Darcs (binary packages may appear later). Happy Hacking, Manuel -=- Cross compilation -=- C->Haskell needs to take system-specific parameters of the C compiler used to compile the libraries for which an interface is generated into account (most notably when bitfields are used in this library). By default C->Haskell uses the conventions of the C compiler that was used to build C->Haskell itself. From this version, C->Haskell accepts the --platform=PLATFORM flag that enables the explicit specification of the target platform. This works only for platforms that are in C->Haskell's platform specification database. At the moment, that's only i686-pc-linux-gnu and m68k-palmos. However, it is very easy to determine the platform specification for any platform on which you can build C->Haskell: Just invoke it as `c2hs --version' and it will tell you. If you send me the output of `c2hs --version', I'll happily add it to the database. (If you'd like to target a platform on which you cannot build C->Haskell, such as an embedded system, let me know.)

2 6

ANN: C->Haskell 0.14.2
by Manuel M T Chakravarty 07 Aug '05

07 Aug '05

I just put version 0.14.2 of C->Haskell at http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ It includes Duncan Coutts' asm and hierarchical module patch and also fixes the way the new shell wrappers pass command line arguments. Manuel

1 0

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

C2HS Failure on stdio.h on Mac OS X 10.4
by Matthew Cox 18 Jul '05

18 Jul '05

I was trying to get gtk2hs into darwinports. The build was going fine until it errored out with this failure: > ./tools/c2hs/c2hsLocal +RTS -H50m -M80m -RTS -C-I/opt/local/include/ > glib-2.0 -C-I/opt/local/lib/glib-2.0/include -C-DXTHREADS -C-I/opt/ > local/include/gtk-2.0 -C-I/opt/local/lib/gtk-2.0/include -C-I/usr/ > X11R6/include -C-I/opt/local/include/pango-1.0 -C-I/opt/local/ > include/freetype2 -C-I/opt/local/include/atk-1.0 --cppopts='- > include "gtk2hs-config.h"' --precomp=gtk/gtk.precomp gtk/gtk.h > elapsed time: 0.02 (start) > elapsed time: 0.02 (about to parse headder) > c2hsLocal: Error in C header file. > > /usr/include/stdio.h:258: (column 42) [FATAL] > >>> Syntax error! > The symbol `__asm' does not fit here. > > make[2]: *** [gtk/gtk.precomp] Error 1 > I know that the gtk2hs guys built a new parser/lexer, and it appears indeed to be a parse error. C

3 4