From translation2@eyou.com Fri Aug 12 17:01:53 2005 From: translation2@eyou.com (Beijing Chinese Translation) Date: Sat, 13 Aug 2005 00:01:53 +0800 Subject: [C2hs] Beijing Chinese Translation Message-ID: <20030806160014.0EADB421F04@www.haskell.org> Cost

Cost-Effective Solutions for Global Translations!
Beijing Expert Translation Co., Ltd.

Dear International Manager:

The Beijing Expert Translation Co., Ltd. is based in Beijing, China, providing high quality translation services in most of the world¡¯s commercially significant languages. In addition to considerable expertise English translations, we offer translation services in the following languages-pairs:

French-Chinese, Chinese-French, German-Chinese, Chinese-German, Japanese-Chinese, Chinese-Japanese, Russian-Chinese, Chinese-Russian, Korean-Chinese, and Chinese-Korean.

We have proven proficiency in large-scale projects and excellent continuing relationships with recognized multinational corporations such as P&G, the Delaware Corporation, Multiling Corporation and many of China¡¯s governmental organizations and publishing houses. Our service offering extends from technical and marking materials to over 30 published works of literature. We have in-depth experience in the areas of :

Medicine and Medical Instrumentation

Mechanics and Materials Engineering

Architecture

Software & IT

Automotive and Railway

Cultural and Social Sciences

Chemistry and Chemical Engineering

Finance and Economics

Geology and Environment Protection

Biology

Corporate Management

Commerce

Law and Legal Documentation

 Insurance

Education

With a staff of eight full-time employees and 1,500 staff translators, we are fully able to deal with the most challenging of projects, regardless of size or complexity. A majority of our managers and full-time employees have doctoral or master¡¯s degrees in science, law or other specialties and have considerable knowledge of our client's areas of business activity. 

We translate both in the traditional way, by human professionals, and by computer-aided translation software. We use industry-standard software such as Star Transit and TermStar. The combination of translation professionals and advanced software technology produces higher quality and elevated productivity.

We would greatly appreciate any opportunity to find cost-effective and professional solutions to your company¡¯s translations needs. Our management and staff look forward to hearing from you soon!

Dr. Wei Zhen

General Manager
Beijing Expert Translation Co., Ltd.

Tel: 0086-10-82115891 82115892  Fax: 0086-10-82115893
E-mail: bjctn@163.com

Rates: 

English-Chinese: US$0.045-0.05/English word
Chinese-English: US$0.065-0.08/English word
French-Chinese:  US$0.055-0.06/French word
Chinese-French:  US$0.065-0.08/French word
German-Chinese: US$0.055-0.06 per German word
Chinese-German: US$0.065-0.08 per German word
Japanese-Chinese: US$0.035-0.05 /Japanese Character
Chinese-Japanese: US$0.04-0.06 /Japanese Character
Russian-Chinese: US$0.03-0.035/Chinese Character
Chinese-Russian: US$0.04-0.045 /Chinese Character
Korean-Chinese:  US$0.03-0.035/Chinese Character
Chinese-Korean:  US$0.040-0.045/ Chinese Character.

Please accept my apologies if this message is an intrusion.  You can e-mail me at: translation18@sohu.com and I will remove your address from our lists.

From chak at cse.unsw.edu.au Fri Aug 5 01:05:11 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Aug 5 00:43:51 2005 Subject: [C2hs] Only members can post Message-ID: <1123218312.2807.67.camel@JustTesting.localdomain> This is an administrative message. I recently switched c2hs@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 From chak at cse.unsw.edu.au Fri Aug 5 01:06:43 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Aug 5 00:45:21 2005 Subject: [C2hs] Re: [Gtk2hs-devel] hsffig & c2hs Message-ID: <1123218403.2807.68.camel@JustTesting.localdomain> [Forwarded by list administrator.] -------- Forwarded Message -------- From: Axel Simon To: c2hs@haskell.org, Gtk2Hs-devel List 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. From p.martini at neuralnoise.com Sun Aug 7 04:58:19 2005 From: p.martini at neuralnoise.com (Paolo Martini) Date: Sun Aug 7 04:37:38 2005 Subject: [C2hs] Questions Message-ID: <42F5CD2B.4080405@neuralnoise.com> Hello, First of all, thanks much for the good tool you're providing :-) I have some questions. Why doesn't {#enum ..#} hooks define the default marshallers to be cFromEnum/cToEnum? Furthermore, is it possible to define the marshallers functions for a give type? (IMO it would make the .chs files more readable) If not, would it be possible to extend the syntax, maybe adding "... inmarsh outmarsh#}" at the end of the hooks? For example I'm using "id" as the marshaller for {#pointer ..#} hooks, (in {#fun name {id `pointer'} -> `pointer' id#}) is it correct, or am I missing something? I can't find an example of a C struct type which isn't defined as a pointer. How should one go to bind structures like this? typedef struct { unsigned long index; double x; double y; } cairo_glyph_t; And then, how to pass them to functions getting a *cairo_glyph_t? Moreover, what if they are getting an array of them? (e.g. void cairo_show_glyphs (cairo_t *cr, cairo_glyph_t *glyphs, int num_glyphs); Thank you, Paolo. -- From chak at cse.unsw.edu.au Sun Aug 7 08:06:02 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 7 07:44:40 2005 Subject: [C2hs] Re: [Gtk2hs-devel] hsffig & c2hs In-Reply-To: <1123218403.2807.68.camel@JustTesting.localdomain> References: <1123218403.2807.68.camel@JustTesting.localdomain> Message-ID: <1123416362.24235.68.camel@JustTesting.localdomain> > -------- Forwarded Message -------- > From: Axel Simon > To: c2hs@haskell.org, Gtk2Hs-devel List devel@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. I think, this should be easy to solve fairly soon. The next feature that I want to add to c2hs is support for cross compilation. (Tony Sloane needs this to produces bindings for Palm OS.) My plan is this: * By default, c2hs will use the conventions re bitfields as those of the C compiler used to compile the .c files in c2hs' source tree. * There will be a command line option that permits to override that choice and to explicitly specify the platform for which bindings are generated. C2hs will have a database of platforms it knows about and all we need to do is to ensure that Visual-C gets an entry in that database. > >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. All I need is a for somebody to compile and run the attached C functions in Visual C and let me know the results. Will that not solve the issue? Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: c2hs_config.c Type: text/x-csrc Size: 3061 bytes Desc: not available Url : http://www.haskell.org//pipermail/c2hs/attachments/20050807/88865976/c2hs_config.bin From chak at cse.unsw.edu.au Sun Aug 7 08:59:57 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 7 08:38:42 2005 Subject: [C2hs] Re: patch to c2hs to support asm constructs In-Reply-To: <1122598683.11027.91.camel@localhost> References: <1122597573.11027.75.camel@localhost> <1122598683.11027.91.camel@localhost> Message-ID: <1123419597.24235.81.camel@JustTesting.localdomain> 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 From chak at cse.unsw.edu.au Sun Aug 7 09:07:26 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 7 08:46:34 2005 Subject: [C2hs] Re: patch to c2hs to add support for hierarchical modules in {# import #} hooks In-Reply-To: <1122661144.11027.153.camel@localhost> References: <1122661144.11027.153.camel@localhost> Message-ID: <1123420046.24235.83.camel@JustTesting.localdomain> > 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 From chak at cse.unsw.edu.au Sun Aug 7 09:49:32 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 7 09:28:47 2005 Subject: [C2hs] ANN: C->Haskell 0.14.2 Message-ID: <1123422572.24235.93.camel@JustTesting.localdomain> 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 From chak at cse.unsw.edu.au Wed Aug 10 02:12:25 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 10 01:52:34 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" Message-ID: <1123654345.2872.55.camel@JustTesting.localdomain> 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.) From list at atmarama.org Wed Aug 10 05:05:31 2005 From: list at atmarama.org (Gour) Date: Wed Aug 10 04:46:35 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <1123654345.2872.55.camel@JustTesting.localdomain> References: <1123654345.2872.55.camel@JustTesting.localdomain> Message-ID: <20050810090531.GA22992@mail.inet.hr> Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote: Hi Manuel! > Happy Hacking, Attempt to build c2hs on amd64 gives: gour@gaura-nitai ~/tmp/c2hs-0.14.3 $ ./Setup.hs configure Configuring c2hs-0.14.3... configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1.20050801 configure: Using package tool: /usr/bin/ghc-pkg configure: Using haddock: /usr/bin/haddock configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using c2hs: /usr/bin/c2hs configure: No cpphs found configure: No greencard found gour@gaura-nitai ~/tmp/c2hs-0.14.3 $ ./Setup.hs build Preprocessing executables for c2hs-0.14.3... Setup.hs: can't find source for C2HSConfig in ["base/admin","base/errors","base/general","base/graphs","base/state","base/syms","base/syntax","c2hs/c","c2hs/chs","c2hs/gen","c2hs/state","c2hs/toplevel"] Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD From chak at cse.unsw.edu.au Wed Aug 10 22:32:03 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 10 22:12:10 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <20050810090531.GA22992@mail.inet.hr> References: <1123654345.2872.55.camel@JustTesting.localdomain> <20050810090531.GA22992@mail.inet.hr> Message-ID: <1123727524.2808.50.camel@JustTesting.localdomain> Gour: > Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote: > > Hi Manuel! > > > Happy Hacking, > > Attempt to build c2hs on amd64 gives: > > gour@gaura-nitai ~/tmp/c2hs-0.14.3 $ ./Setup.hs configure > Configuring c2hs-0.14.3... > configure: Using install prefix: /usr/local > configure: Using compiler: /usr/bin/ghc > configure: Compiler flavor: GHC > configure: Compiler version: 6.4.1.20050801 > configure: Using package tool: /usr/bin/ghc-pkg > configure: Using haddock: /usr/bin/haddock > configure: Using happy: /usr/bin/happy > configure: Using alex: /usr/bin/alex > configure: Using hsc2hs: /usr/bin/hsc2hs > configure: Using c2hs: /usr/bin/c2hs > configure: No cpphs found > configure: No greencard found > gour@gaura-nitai ~/tmp/c2hs-0.14.3 $ ./Setup.hs build > Preprocessing executables for c2hs-0.14.3... > Setup.hs: can't find source for C2HSConfig in ["base/admin","base/errors","base/general","base/graphs","base/state","base/syms","base/syntax","c2hs/c","c2hs/chs","c2hs/gen","c2hs/state","c2hs/toplevel"] It appears as if you got the sources via Dracs and forgot to run "autoconf" (which means that there woulnd't be a "configure") script in the toplevel directory. (See also the INSTALL file.) Manuel From list at atmarama.org Thu Aug 11 01:01:44 2005 From: list at atmarama.org (Gour) Date: Thu Aug 11 00:44:36 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <1123727524.2808.50.camel@JustTesting.localdomain> References: <1123654345.2872.55.camel@JustTesting.localdomain> <20050810090531.GA22992@mail.inet.hr> <1123727524.2808.50.camel@JustTesting.localdomain> Message-ID: <20050811050143.GA12911@mail.inet.hr> Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote: > It appears as if you got the sources via Dracs and forgot to run > "autoconf" (which means that there woulnd't be a "configure") script in > the toplevel directory. (See also the INSTALL file.) True. At 1?t I attempted to build via ebuild script bit ebuild looked for a c2hs-1.0.0 tarball (automatically built with cabal2ebuild program). Then I produced tarball from the darcs repo. However, there is still a problem: [...] config.status: creating c2hs/toplevel/Version.hs config.status: creating c2hs/toplevel/C2HSConfig.hs config.status: creating c2hs/c2hs-inplace config.status: creating c2hs/c2hs config.status: creating postInst.sh config.status: creating c2hs.spec config.status: creating doc/c2hs/Makefile config.status: executing default commands Preprocessing executables for c2hs-0.14.3... Building c2hs-0.14.3... hsSourceDirs: ["base/admin","base/errors","base/general","base/graphs","base/state","base/syms","base/syntax","c2hs/c","c2hs/chs","c2hs/gen","c2hs/state","c2hs/toplevel"] Chasing modules from: c2hs/toplevel/Main.hs Could not find module `CForeign': use -v to see a list of the files searched for (imported from c2hs/toplevel/C2HSConfig.hs) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD From chak at cse.unsw.edu.au Thu Aug 11 11:28:34 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 11 11:08:43 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <20050811050143.GA12911@mail.inet.hr> References: <1123654345.2872.55.camel@JustTesting.localdomain> <20050810090531.GA22992@mail.inet.hr> <1123727524.2808.50.camel@JustTesting.localdomain> <20050811050143.GA12911@mail.inet.hr> Message-ID: <1123774114.2808.14.camel@JustTesting.localdomain> Gour: > Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote: > However, there is still a problem: > > [...] > config.status: creating c2hs/toplevel/Version.hs > config.status: creating c2hs/toplevel/C2HSConfig.hs > config.status: creating c2hs/c2hs-inplace > config.status: creating c2hs/c2hs > config.status: creating postInst.sh > config.status: creating c2hs.spec > config.status: creating doc/c2hs/Makefile > config.status: executing default commands > Preprocessing executables for c2hs-0.14.3... > Building c2hs-0.14.3... > hsSourceDirs: ["base/admin","base/errors","base/general","base/graphs","base/state","base/syms","base/syntax","c2hs/c","c2hs/chs","c2hs/gen","c2hs/state","c2hs/toplevel"] > Chasing modules from: c2hs/toplevel/Main.hs > Could not find module `CForeign': > use -v to see a list of the files searched for > (imported from c2hs/toplevel/C2HSConfig.hs) CForeign is a module from the FFI standard. What version of GHC are you using? Manuel From list at atmarama.org Thu Aug 11 12:05:19 2005 From: list at atmarama.org (Gour) Date: Thu Aug 11 11:46:17 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <1123774114.2808.14.camel@JustTesting.localdomain> References: <1123654345.2872.55.camel@JustTesting.localdomain> <20050810090531.GA22992@mail.inet.hr> <1123727524.2808.50.camel@JustTesting.localdomain> <20050811050143.GA12911@mail.inet.hr> <1123774114.2808.14.camel@JustTesting.localdomain> Message-ID: <20050811160519.GA12052@mail.inet.hr> Manuel M T Chakravarty (chak@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 Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD From chak at cse.unsw.edu.au Fri Aug 12 11:06:13 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Fri Aug 12 10:46:25 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <20050811160519.GA12052@mail.inet.hr> References: <1123654345.2872.55.camel@JustTesting.localdomain> <20050810090531.GA22992@mail.inet.hr> <1123727524.2808.50.camel@JustTesting.localdomain> <20050811050143.GA12911@mail.inet.hr> <1123774114.2808.14.camel@JustTesting.localdomain> <20050811160519.GA12052@mail.inet.hr> Message-ID: <1123859173.2848.28.camel@JustTesting.localdomain> Gour: > Manuel M T Chakravarty (chak@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? Manuel From simonmar at microsoft.com Fri Aug 12 11:19:40 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Fri Aug 12 11:00:29 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" Message-ID: <3429668D0E777A499EE74A7952C382D1043695DD@EUR-MSG-01.europe.corp.microsoft.com> On 12 August 2005 16:06, Manuel M T Chakravarty wrote: > Gour: >> Manuel M T Chakravarty (chak@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 From p.martini at neuralnoise.com Sun Aug 14 09:53:15 2005 From: p.martini at neuralnoise.com (Paolo Martini) Date: Sun Aug 14 09:36:32 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <3429668D0E777A499EE74A7952C382D1043695DD@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D1043695DD@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <42FF4CCB.3040804@neuralnoise.com> Simon Marlow wrote: > On 12 August 2005 16:06, Manuel M T Chakravarty wrote: > > >>Gour: >> >>>Manuel M T Chakravarty (chak@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 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 :-) Best, Paolo From simonmar at microsoft.com Sun Aug 14 10:20:53 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Sun Aug 14 10:01:35 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" Message-ID: <3429668D0E777A499EE74A7952C382D104369732@EUR-MSG-01.europe.corp.microsoft.com> 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 From chak at cse.unsw.edu.au Sun Aug 14 11:21:10 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 14 11:01:14 2005 Subject: [C2hs] ANN: C->Haskell version 0.14.3 "Travelling Lightly" In-Reply-To: <3429668D0E777A499EE74A7952C382D104369732@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104369732@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <1124032870.2848.63.camel@JustTesting.localdomain> Simon Marlow: > 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 - will change that. Manuel From p.martini at neuralnoise.com Sun Aug 14 17:11:38 2005 From: p.martini at neuralnoise.com (Paolo Martini) Date: Sun Aug 14 16:55:20 2005 Subject: [C2hs] c2hs-config Message-ID: <42FFB38A.5060601@neuralnoise.com> There seem to be no c2hs-config in the source package, is the documentation[1] outdated, and it isn't needed anymore for some reason, or its missing have some other meaning? Also, I can't find how to register the c2hs package into GHC, any clue? Thank you, Paolo From chak at cse.unsw.edu.au Sun Aug 14 21:05:44 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 14 20:45:40 2005 Subject: [C2hs] c2hs-config In-Reply-To: <42FFB38A.5060601@neuralnoise.com> References: <42FFB38A.5060601@neuralnoise.com> Message-ID: <1124067945.2807.4.camel@JustTesting.localdomain> Paolo Martini: > There seem to be no c2hs-config in the source package, is the > documentation[1] outdated, and it isn't needed anymore for some reason, > or its missing have some other meaning? c2hs-config is not needed anymore. I thought, I removed all traces from the documentation, but obviously I overlooked something. Where did you see it? In the HTML documentation? (Earlier version of c2hs produced binding code that needed a separately installed library, but that's not the case anymore. Now the library code to include with the generate program is produced in source form by "--copy-library".) > Also, I can't find how to register the c2hs package into GHC, any clue? That's done by Cabal; ie, in the root of c2hs source directory use ./Setup.hs register You can get a list of all Cabal commands with ./Setup.hs --help Manuel PS: I will answer to your earlier email with some questions soon - just didn't find the time yet. From chak at cse.unsw.edu.au Mon Aug 15 02:24:00 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 15 02:03:52 2005 Subject: [C2hs] Questions In-Reply-To: <42F5CD2B.4080405@neuralnoise.com> References: <42F5CD2B.4080405@neuralnoise.com> Message-ID: <1124087041.2807.36.camel@JustTesting.localdomain> Paolo Martini: > Why doesn't {#enum ..#} hooks define the default marshallers to be > cFromEnum/cToEnum? This would certainly be a useful feature. (In fact, a FIXME comment at GenBind.lookupDftMarshIn suggests just that.) I'll implement it when I find the time; otherwise, feel free to give it a try yourself if you like. > Furthermore, is it possible to define the > marshallers functions for a give type? (IMO it would make the .chs files > more readable) Not at the moment. The internal functionality needed to support this is similar to that for default marshaller from enum hooks. Basically, the default marshaller table is currently static. It cannot be extended at runtime. As soon as there is a dynamic table, much of what you want should be easy to realise. > If not, would it be possible to extend the syntax, maybe > adding "... inmarsh outmarsh#}" at the end of the hooks? Which hooks do you want this for? > For example I'm using "id" as the marshaller for {#pointer ..#} hooks, > (in {#fun name {id `pointer'} -> `pointer' id#}) is it correct, or am I > missing something? > > I can't find an example of a C struct type which isn't defined as a > pointer. How should one go to bind structures like this? > > typedef struct { > unsigned long index; > double x; > double y; > } cairo_glyph_t; > > And then, how to pass them to functions getting a *cairo_glyph_t? > Moreover, what if they are getting an array of them? (e.g. > > void cairo_show_glyphs (cairo_t *cr, > cairo_glyph_t *glyphs, > int num_glyphs); I don't quite understand this. You are using a pointer to cairo_glyph_t here. Look at http://www.cse.unsw.edu.au/~chak/repos/c2hs/c2hs/tests/pointer.h http://www.cse.unsw.edu.au/~chak/repos/c2hs/c2hs/tests/Pointer.chs the struct Point is used in the same way in this example. (Well, only one point is passed in the example, where as you pass a whole lot of glyhs, but the C type still has the same structure.) Or are you asking how to do the same with fun hooks? Arrays are generally best marshalled with the functions from http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign.Marshal.Array.html Manuel From chak at cse.unsw.edu.au Mon Aug 15 21:59:26 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 15 21:39:18 2005 Subject: [C2hs] Re: [Gtk2hs-devel] hsffig & c2hs In-Reply-To: <1124103615.10959.85.camel@localhost> References: <1123218403.2807.68.camel@JustTesting.localdomain> <1123416362.24235.68.camel@JustTesting.localdomain> <1124103615.10959.85.camel@localhost> Message-ID: <1124157566.2810.17.camel@JustTesting.localdomain> Duncan Coutts: > On Sun, 2005-08-07 at 22:06 +1000, Manuel M T Chakravarty wrote: > > > * There will be a command line option that permits to override that > > choice and to explicitly specify the platform for which bindings are > > generated. C2hs will have a database of platforms it knows about and > > all we need to do is to ensure that Visual-C gets an entry in that > > database. > > That sounds like a sensible approach. The latest release already has that database in "C2HSConfig.hs.in". > > All I need is a for somebody to compile and run the attached C functions > > in Visual C and let me know the results. > > I'll try and give that a go some time. (And then check to see if it > passes the Gtk+ ABI init check) Great - thanks! Manuel From p.martini at neuralnoise.com Thu Aug 18 08:35:27 2005 From: p.martini at neuralnoise.com (Paolo Martini) Date: Thu Aug 18 08:15:38 2005 Subject: [C2hs] Gtk+cairo working :-) Message-ID: <4304808F.8090807@neuralnoise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello, I'm proud to announce that we got Gtk integration initially working :-) I don't know if you follow the site/blog[1] but there we go: http://haskell.org/gtk2hs/archives/2005/08/17/code/#comment-35 Thanks much people, you guys rock. Cheers, Paolo. P.S. the cairobindings darcs repo is now ``outdated'' by the gtk2hs one I'm setting up as soon as an issue with Gtk2Hs's version of c2hs will be resolved. I'll blog-post about that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDBICPotUQQOWB3WQRA8SlAJ0d4mecBKH5JJH2ch6IT1/4fExK0ACeK4E+ WW6WDY1kk3qeqcT0fgsPh38= =4oRp -----END PGP SIGNATURE----- From p.martini at neuralnoise.com Thu Aug 18 08:37:00 2005 From: p.martini at neuralnoise.com (Paolo Martini) Date: Thu Aug 18 08:17:11 2005 Subject: [C2hs] Gtk+cairo working :-) In-Reply-To: <4304808F.8090807@neuralnoise.com> References: <4304808F.8090807@neuralnoise.com> Message-ID: <430480EC.2070109@neuralnoise.com> Paolo Martini wrote: > Hello, > > I'm proud to announce that we got Gtk integration initially working :-) > > I don't know if you follow the site/blog[1] but there we go: > > http://haskell.org/gtk2hs/archives/2005/08/17/code/#comment-35 > > Thanks much people, you guys rock. > > Cheers, > Paolo. > > P.S. the cairobindings darcs repo is now ``outdated'' by the gtk2hs one > I'm setting up as soon as an issue with Gtk2Hs's version of c2hs will be > resolved. I'll blog-post about that. I sent it to the wrong mailing list... I'm _really_ sorry. :-| Erhm.. enjoy the announce anyway :-) Paolo. From chak at cse.unsw.edu.au Sun Aug 21 07:14:34 2005 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 21 07:29:24 2005 Subject: [C2hs] Re: c2hs feature request: {# alignof #} hook In-Reply-To: <1124556922.829.92.camel@localhost> References: <1124556922.829.92.camel@localhost> Message-ID: <1124622875.3336.122.camel@JustTesting.localdomain> Duncan Coutts: > Writing Storable instances would be more convenient if c2hs supported an > {# alignof #} hook, just like it currently supports the {# sizeof #} > hook. > > I think the syntax would be exactly the same, ie it'd just take a C type > name. Good idea. Manuel