From jwlato at gmail.com Fri Aug 1 19:20:11 2008 From: jwlato at gmail.com (John Lato) Date: Fri Aug 1 19:20:03 2008 Subject: [C2hs] other c2hs patches Message-ID: <9979e72e0808011620k35620d8j92e1ddc9d9aaef34@mail.gmail.com> Duncan, thanks for all your help recently. I've got another question that depends a bit on the recent patch I submitted. The file Config.hs defines a value for cppopts that is something like "-x c", varying on the platform. If cpp is called using runProcess, then (at least on Windows), those need to be passed as separate arguments (i.e. ["-x", "c"]) in order for cpp to understand them. Although it's a pretty simple change, is this true for other platforms (e.g. Linux) as well? Thanks, John From benjovi at gmx.net Tue Aug 5 20:57:26 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Tue Aug 5 20:57:09 2008 Subject: [C2hs] Intented meaning of CDeclr References: <8E8937BE-3827-44ED-93A9-BB38E93ED385@gmail.com> Message-ID: Hello, I've been trying to fix some bugs in c2hs, which all seem related to the definition of CDeclr. I'm not quite sure what the actual problem is, so maybe someone can help me out here. I'm referring to the lasted revision from darcs (0.15.2): The problem is that the Parser assumes that the leftmost indirection is represented outermost in the chain of CDeclrs. To illustrate, consider > char * x[]; "x is an array of pointers to char". The parser returns (simplified): > CPtrDeclr (CArrDeclr (CVarDeclr "x")) I'm not sure if this is an accidental mistake, but in the analysis code, it is assumed that the above declarator is represented as > CArrDeclr (CPtrDeclr (CVarDeclr "x")) which seems more plausible in my opinion. Should this be fixed in the parser ? Another confusing part: In src/C2HS/C/AST.hs, we find 424: -- * The qualifiers list in a `CPtrDeclr' may not be empty 437: CPtrDeclr [CTypeQual] -- indirections This sounds as if the type qualifiers (const,restrict,volatile) model indirections of pointers, which isn't true of course. This assumption apparently is used in src/C2HS/Gen/Bind.hs: 1066ff: > case declr of > (Just (CPtrDeclr [_] declr at), oinit, oexpr) -> > return $ CDecl specs [(Just declr, oinit, oexpr)] at > (Just (CPtrDeclr (_:quals) declr at), oinit, oexpr) -> > return $ > CDecl specs [(Just (CPtrDeclr quals declr at), oinit, oexpr)] at This is just an accidental mistake, I suppose ? best regards, benedikt From benjovi at gmx.net Wed Aug 20 14:49:01 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Wed Aug 20 14:47:56 2008 Subject: [C2hs] c2hs + language.c References: Message-ID: <5F9E416E-B78F-485B-91C5-56881F5994CA@gmx.net> Hello ! I've set up a branch of c2hs using Language.C's parser and pretty printer. > http://code.haskell.org/~bhuber/c2hs The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as a small bonus, implements "enum define" hooks (Bug #5). best regards, benedikt From gour at mail.inet.hr Wed Aug 20 15:33:16 2008 From: gour at mail.inet.hr (Gour) Date: Wed Aug 20 15:32:39 2008 Subject: [C2hs] Re: c2hs + language.c References: <5F9E416E-B78F-485B-91C5-56881F5994CA@gmx.net> Message-ID: <87d4k3h477.fsf@gaura-nitai.no-ip.org> >>>>> "Benedikt" == Benedikt Huber writes: Benedikt> Hello ! I've set up a branch of c2hs using Language.C's Benedikt> parser and pretty printer. >> http://code.haskell.org/~bhuber/c2hs Benedikt> The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as Benedikt> a small bonus, implements "enum define" hooks (Bug #5). Thanks a lot. I already lost faith "enum define" hooks will be ever implemented :-) Any chance to incorporate it into mainstream? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/c2hs/attachments/20080820/f74cfa69/attachment.bin From duncan.coutts at worc.ox.ac.uk Wed Aug 20 18:49:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 20 18:48:08 2008 Subject: [C2hs] Re: c2hs + language.c In-Reply-To: References: Message-ID: <1219272561.13639.301.camel@localhost> On Wed, 2008-08-20 at 18:36 +0200, Benedikt Huber wrote: > Hello ! > > I've set up a branch of c2hs using Language.C's parser and pretty > printer. > > http://code.haskell.org/~bhuber/c2hs > The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as a small > bonus, implements enum define hooks (Bug #5). Woo hoo! When you're happy we should merge this into mainline c2hs. Which reminds me, I should fix #11. Duncan From chak at cse.unsw.edu.au Wed Aug 20 21:18:50 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 20 21:17:49 2008 Subject: [C2hs] Re: c2hs + language.c In-Reply-To: <1219272561.13639.301.camel@localhost> References: <1219272561.13639.301.camel@localhost> Message-ID: <8984009B-38A9-4526-A54D-2BCEF4AD958F@cse.unsw.edu.au> Duncan Coutts: > On Wed, 2008-08-20 at 18:36 +0200, Benedikt Huber wrote: >> Hello ! >> >> I've set up a branch of c2hs using Language.C's parser and pretty >> printer. >>> http://code.haskell.org/~bhuber/c2hs >> The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as a small >> bonus, implements enum define hooks (Bug #5). Wow, great! Good work! > Woo hoo! > > When you're happy we should merge this into mainline c2hs. Yes, that would be great. Manuel From benjovi at gmx.net Thu Aug 21 09:09:44 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Thu Aug 21 09:08:37 2008 Subject: [C2hs] Re: c2hs + language.c In-Reply-To: <8984009B-38A9-4526-A54D-2BCEF4AD958F@cse.unsw.edu.au> References: <1219272561.13639.301.camel@localhost> <8984009B-38A9-4526-A54D-2BCEF4AD958F@cse.unsw.edu.au> Message-ID: On 21.08.2008, at 03:18, Manuel M T Chakravarty wrote: > Duncan Coutts: >> On Wed, 2008-08-20 at 18:36 +0200, Benedikt Huber wrote: >>> Hello ! >>> >>> I've set up a branch of c2hs using Language.C's parser and pretty >>> printer. >>>> http://code.haskell.org/~bhuber/c2hs >>> The branch also fixes a couple of bugs (#6,#8,#9,#12) and, as a >>> small >>> bonus, implements enum define hooks (Bug #5). > > Wow, great! Good work! thank you ! The latest language-c (0.3.1), which is needed for this branch, is now on hackage. >> Woo hoo! >> >> When you're happy we should merge this into mainline c2hs. > > Yes, that would be great. I'm happy to help out, so just tell me if you want any additional changes or just a subset of the current ones. If possible, I'd like to add a few more tests (against known/fixed bugs). -- benedikt From benjovi at gmx.net Fri Aug 22 13:39:42 2008 From: benjovi at gmx.net (Benedikt Huber) Date: Fri Aug 22 13:38:32 2008 Subject: [C2hs] Default Marshallers / Arbitrary expressions as marshallers Message-ID: <929F99F4-C208-4B02-B1C1-3ABDB7B1BB05@gmx.net> Hi again, I noted Gour filed a ticket for 'allowing arbitrary expressions as marshallers'. > http://hackage.haskell.org/trac/c2hs/ticket/13 This sounds interesting, but I wonder which would be the most sensible implementation strategy. Do you suggest to implement hs98 expressions using the existing framework ? Is there some existing code that could be reused ? Apart from that, I think the following additional default marshallers would make sense: a) If the hs type is defined in an {# enum ... #} hook and the C type is integral, use (fromEnum/toEnum . cIntConv) as default. b) If the hs type and C type match, and are of the form (Ptr a), use 'id' as default. This is really useful when working with opaque pointers, but maybe there are type-safety related reasons why this shouldn't be done. c) Additionally, we could allow the user to add other default marshallers, depending on the combination of hs/C type. If I recall correctly, Duncan had some ideas for this one ? best regards, benedikt