- C2hs - Haskell.org

[c2hs] #43: Please support anonymous enums
by c2hs 05 Jul '12

05 Jul '12

#43: Please support anonymous enums --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.0 | Keywords: --------------------+------------------------------------------------------- c2hs doesn't currently support anonymous enums. Please consider supporting them. Ideally, a single name from the enum should suffice to identify it, and the enum declaration could supply a Haskell name for the enum. -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/43> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 1

[c2hs] #44: Foreign pointer declaration produces helper function without type signature, producing warning with -Wall
by c2hs 04 Jul '12

04 Jul '12

#44: Foreign pointer declaration produces helper function without type signature, producing warning with -Wall --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.0 | Keywords: --------------------+------------------------------------------------------- When given a pointer declaration for a foreign pointer, such as: {{{ {# pointer *foo as ^ foreign newtype #} }}} c2hs produces a helper function withFoo, without a type signature. This causes GHC with -Wall to produce a warning message, "Warning: Top-level binding with no type signature". -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/44> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

Re: [C2hs] [c2hs] #7: compile gtk2hs failed under locale zh_CN.utf8
by c2hs 16 May '12

16 May '12

#7: compile gtk2hs failed under locale zh_CN.utf8 ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: general | Version: 0.15.1 Keywords: | ---------------------+------------------------------------------------------ Comment(by guest): Replying to [ticket:7 duncan]: > Bug previously reported in the [http://hackage.haskell.org/trac/ghc/ticket/2384 ghc trac] > > ---- > > when compile gtk2hs under locale zh_CN.utf8, I got: > {{{ > c2hsLocal: Error in C header file. <built-in>:1: (column 0) [FATAL] > Lexical error! > The character '#' does not fit here. > }}} > when I compile it using locale POSIX, it succeed. I can confirm c2hs fails like this with Serbian locale (sr_RS.UTF8) as well. I suppose c2hs fails to read unicode characters. To fix that I added a small wrapper script arount c2hs (just "LANG=C c2hs-bin $*") and moved the real c2hs to c2hs-bin. Maybe that could be included in c2hs as a quick fix until this is properly handled? Best regards & keep up the good work Filip Brcic (brcha AT gna DOT org) -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/7#comment:1> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

[c2hs] #41: Build errors
by c2hs 02 Mar '12

02 Mar '12

#41: Build errors --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.0 | Keywords: --------------------+------------------------------------------------------- A suitable c2hs version is available on Hackage, but Cabal doesn't see it when it tries to install CV. {{{ $ cabal install CV ... cabal: The program c2hs version >=0.16.0 is required but it could not be found. }}} Even after manually installing c2hs version 0.16.3, CV still doesn't see it. {{{ $ cabal install c2hs $ cabal install CV ... cabal: The program c2hs version >=0.16.0 is required but it could not be found. }}} Specs: Mac OS X 10.7.3 {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.3 $ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library }}} -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/41> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

[c2hs] #40: c2hs: fails reading its own intermediate representation (.chi)
by c2hs 19 Dec '11

19 Dec '11

#40: c2hs: fails reading its own intermediate representation (.chi) --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: new | Priority: normal Milestone: | Component: general Version: 0.16.2 | Keywords: --------------------+------------------------------------------------------- This bug was reported against the Debian package of c2hs, at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652507 c2hs uses shown Language.C data structures as an intermediate representation (the .chi files), and has its own code for parsing them. It seems that Language.C has changed its Show instance for lexemes, and c2hs can no longer parse its own .chi files. The symptom for me is that "cabal build" fails with the following error message: c2hs: Prelude.read: no parse Patch attached. (Patch at http://bugs.debian.org/cgi- bin/bugreport.cgi?msg=5;filename=c2hs.diff;att=1;bug=652507) Greetings, Joachim -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/40> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0

Re: [C2hs] stdcall vs ccall
by Duncan Coutts 05 Oct '11

05 Oct '11

On Tue, 2011-10-04 at 16:48 -0700, Jason Dagit wrote: > On Tue, Oct 4, 2011 at 4:26 PM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: > > On Tue, 2011-10-04 at 12:56 -0700, Jason Dagit wrote: > >> On Tue, Oct 4, 2011 at 11:36 AM, Duncan Coutts > >> <duncan.coutts(a)googlemail.com> wrote: > >> > On Tue, 2011-10-04 at 10:48 -0700, Jason Dagit wrote: > >> >> On Tue, Oct 4, 2011 at 7:54 AM, Duncan Coutts > >> >> <duncan.coutts(a)googlemail.com> wrote: > >> >> > On Mon, 2011-10-03 at 22:15 -0700, Jason Dagit wrote: > >> >> >> I have a library that uses stdcall on windows and ccall on other > >> >> >> platforms. I found this bug report: > >> >> >> http://hackage.haskell.org/trac/c2hs/ticket/17 > >> >> >> > >> >> >> Does c2hs handle this case correctly yet? The bug has not been close > >> >> >> although a patch was submitted. I'm not sure how to interpret that. > >> >> >> > >> I'd prefer to stick to things that are cabal installable, so if you > >> don't mind making a new release that would be my preferred solution. > > > > > > By the way, do let us know if the current version actually works now for > > your use case. > > Will do. I told the author of the OpenCL bindings that I would try > his bindings (hopefully) by this weekend. I know he uses c2hs but I > don't know if he uses the fun macro. Judah also has a binding > (hsOpenCL) that does use the fun macro. So even if the bindings I > plan on trying out do not make use of this feature, I can try Judah's > bindings and report back. Great thanks. BTW, it should not matter whether you uses 'fun' or 'call' hooks. What is important is that the C header file declare the calling convention using GNU C attribute syntax. Duncan

1 0

Re: [C2hs] stdcall vs ccall
by Duncan Coutts 05 Oct '11

05 Oct '11

On Tue, 2011-10-04 at 12:56 -0700, Jason Dagit wrote: > On Tue, Oct 4, 2011 at 11:36 AM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: > > On Tue, 2011-10-04 at 10:48 -0700, Jason Dagit wrote: > >> On Tue, Oct 4, 2011 at 7:54 AM, Duncan Coutts > >> <duncan.coutts(a)googlemail.com> wrote: > >> > On Mon, 2011-10-03 at 22:15 -0700, Jason Dagit wrote: > >> >> I have a library that uses stdcall on windows and ccall on other > >> >> platforms. I found this bug report: > >> >> http://hackage.haskell.org/trac/c2hs/ticket/17 > >> >> > >> >> Does c2hs handle this case correctly yet? The bug has not been close > >> >> although a patch was submitted. I'm not sure how to interpret that. > >> >> > I'd prefer to stick to things that are cabal installable, so if you > don't mind making a new release that would be my preferred solution. By the way, do let us know if the current version actually works now for your use case. Duncan

1 0

Re: [C2hs] stdcall vs ccall
by Duncan Coutts 05 Oct '11

05 Oct '11

On Tue, 2011-10-04 at 10:48 -0700, Jason Dagit wrote: > On Tue, Oct 4, 2011 at 7:54 AM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: > > On Mon, 2011-10-03 at 22:15 -0700, Jason Dagit wrote: > >> I have a library that uses stdcall on windows and ccall on other > >> platforms. I found this bug report: > >> http://hackage.haskell.org/trac/c2hs/ticket/17 > >> > >> Does c2hs handle this case correctly yet? The bug has not been close > >> although a patch was submitted. I'm not sure how to interpret that. > >> > >> Please advise :) > > > > The patch is in the darcs repo, currently version 0.16.4. > > Does this mean I need at least version 0.16.4? The version on hackage > is 0.16.3, so does that mean I would need to run a development > version? > http://hackage.haskell.org/package/c2hs That's right. Sorry if it wasn't clear. My intention was to point you to the darcs repo. If that's a major problem then say so. I don't think there's anything in particular holding back a release. Duncan

1 0

Re: [C2hs] stdcall vs ccall
by Duncan Coutts 05 Oct '11

05 Oct '11

On Mon, 2011-10-03 at 22:15 -0700, Jason Dagit wrote: > I have a library that uses stdcall on windows and ccall on other > platforms. I found this bug report: > http://hackage.haskell.org/trac/c2hs/ticket/17 > > Does c2hs handle this case correctly yet? The bug has not been close > although a patch was submitted. I'm not sure how to interpret that. > > Please advise :) The patch is in the darcs repo, currently version 0.16.4. darcs get http://code.haskell.org/c2hs/ Thanks for pointing out the ticket was still open, I've closed it. Duncan

1 0

Re: [C2hs] [c2hs] #17: c2hs assumes ccall when it should automagically support stdcall for ffi imports
by c2hs 05 Oct '11

05 Oct '11

#17: c2hs assumes ccall when it should automagically support stdcall for ffi imports --------------------+------------------------------------------------------- Reporter: guest | Type: defect Status: closed | Priority: normal Milestone: | Component: general Version: 0.15.1 | Resolution: fixed Keywords: | --------------------+------------------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Applied, will be in version 0.16.4 {{{ Mon Jun 14 15:12:13 BST 2010 Duncan Coutts <duncan(a)haskell.org> * Consider trailing stdcall attributes For example: void foo() __attribute__((stdcall)); As well as: void __attribute__((stdcall)) foo(); Allow the stdcall as well as __stdcall__ attribute keyword, all such gnu C attribute keywords exist in both forms. Mon Jun 14 09:58:17 BST 2010 Jonathan Rockway <jon(a)jrock.us> * automagically support stdcall calling convention when the header file specifies it }}} -- Ticket URL: <http://hackage.haskell.org/trac/c2hs/ticket/17#comment:4> c2hs <http://www.cse.unsw.edu.au/~chak/haskell/c2hs/> C->Haskell, An Interface Generator for Haskell

1 0