- C2hs - Haskell.org

Re: [C2hs] Looking for a new maintainer
by Ian Ross 02 Apr '16

02 Apr '16

Hi Benedikt, Thanks for the response. And I think the response times for language-c issues have been completely fine. I have no complaints there at all! It's interesting what you say about the other C parsing libraries. It sounds as though I'd got the wrong impression of them. Perhaps we would be better off trying to persuade any new C2HS maintainer to join in on the maintenance of language-c as well. That would definitely involve a smaller workload than switching C2HS over to a different parsing library. There are a few other reverse dependencies of language-c as well as C2HS ( http://packdeps.haskellers.com/reverse/language-c) but only about half a dozen of those seem to be active, so coordinating changes to language-c for C2HS that wouldn't break the other dependencies might not be so hard. I have some "tentative" interest from someone in taking over C2HS maintenance, but they're wary of being the only maintainer, so I'm trying to persuade someone else as well. If they do agree, then maybe we could get them set up with write access to language-c as well. Cheers, Ian. On 3 March 2016 at 17:13, Benedikt Huber <benedikt.huber(a)gmail.com> wrote: > Hi Ian, > I do appreciate your maintainance of c2hs in the past, and also do > understand that response times concerning language-c extensions are not > exactly short (much better now that I received an email concerning the > problem, though). > > However, I strongly disagree that lacking support for new C features (C11 > is really not the point, because all issues so far were vendor-specific > extensions) will be less of a problem if you switch to one of the other > libraries you mentioned. These libraries might be the far better match for > c2hs, I do not know, but you shouldn't create the illusion that they > support a larger subset of C11 + gcc extensions. According to their pages, > Language.C.Quote support C99 (and several interesting extensions concerning > CUDA), but as far as I can see not the int128 type, for example. > language-c-inline uses language-c-quote. If you could leverage clang that > would be another story, but not an easy task either... > > Anyways, if someone wants write access to language-c or is seriously > interested in improving and maintaining it, please go ahead! Maybe it would > help to move development to github - there is already a mirror anyway ( > https://github.com/visq/language-c) > > Best, Benedikt > > > Ian Ross <ian(a)skybluetrades.net> schrieb am Do., 3. März 2016 um > 12:40 Uhr: > >> Dear all, >> >> I've been maintaining C2HS since July 2013, and I'd now like to spend my >> "Haskell time" on something else. That means that I'm looking for someone >> to take over C2HS maintenance. >> >> The project is mature, the code is pretty clean (especially where I've >> not touched it!) and has relatively infrequent issues arising, but there is >> one *big* job that needs to be done to make C2HS viable in the long term, >> and anyone who takes over maintenance needs to know about this. >> >> Bug reports for C2HS mostly fall into three categories: feature requests, >> "real" bugs in the logic of C2HS (fixing these varies in difficulty a lot), >> and finally problems caused by the C compilers and associated header files >> moving ahead of the language-c library that C2HS uses for parsing C >> headers. This third class of issues is the problem. We have been making >> piecemeal fixes to language-c to deal with some of these issues, but >> language-c was only ever intended as a parser for C99 (plus some GNU >> extensions), so it's falling over more and more often on C11 features that >> are cropping up. It's also not actively maintained, although the >> maintainer (Benedikt Huber) is happy to accept patches. >> >> The solution to this problem is to move C2HS over to using one of the >> other C parsing libraries that are actively maintained and that support >> more recent C dialects -- language-c-quote or language-c-inline, for >> example. This is the "big job": all the AST types are different between >> the different parsing libraries, and language-c contains some syntactic and >> type analysis features used by C2HS that would need to be ported to >> whatever new parsing library was used. We have some ideas how to do this >> in a minimally painful way, but it's still going to be a bit of a slog. >> >> On the positive side, although it's a big job, C2HS has reasonable test >> infrastructure in place to help -- there's a pretty extensive test suite, >> and a VM-based regression suite that does test builds of a number of >> packages that use C2HS (some of these run on Travis too). >> >> If you're interested in taking over maintenance of C2HS, feel free to >> drop me a line with any questions. >> >> Cheers, >> >> Ian. >> >> -- >> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >> www.skybluetrades.net >> PGP Key: 0x04490CC0/F4D6 027F 2661 745C 83A5 297D FCCC 0AE6 0449 0CC0 >> >> _______________________________________________ >> C2hs mailing list >> C2hs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/c2hs >> > -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net PGP Key: 0x04490CC0/F4D6 027F 2661 745C 83A5 297D FCCC 0AE6 0449 0CC0

2 1

Looking for a new maintainer
by Ian Ross 03 Mar '16

03 Mar '16

Dear all, I've been maintaining C2HS since July 2013, and I'd now like to spend my "Haskell time" on something else. That means that I'm looking for someone to take over C2HS maintenance. The project is mature, the code is pretty clean (especially where I've not touched it!) and has relatively infrequent issues arising, but there is one *big* job that needs to be done to make C2HS viable in the long term, and anyone who takes over maintenance needs to know about this. Bug reports for C2HS mostly fall into three categories: feature requests, "real" bugs in the logic of C2HS (fixing these varies in difficulty a lot), and finally problems caused by the C compilers and associated header files moving ahead of the language-c library that C2HS uses for parsing C headers. This third class of issues is the problem. We have been making piecemeal fixes to language-c to deal with some of these issues, but language-c was only ever intended as a parser for C99 (plus some GNU extensions), so it's falling over more and more often on C11 features that are cropping up. It's also not actively maintained, although the maintainer (Benedikt Huber) is happy to accept patches. The solution to this problem is to move C2HS over to using one of the other C parsing libraries that are actively maintained and that support more recent C dialects -- language-c-quote or language-c-inline, for example. This is the "big job": all the AST types are different between the different parsing libraries, and language-c contains some syntactic and type analysis features used by C2HS that would need to be ported to whatever new parsing library was used. We have some ideas how to do this in a minimally painful way, but it's still going to be a bit of a slog. On the positive side, although it's a big job, C2HS has reasonable test infrastructure in place to help -- there's a pretty extensive test suite, and a VM-based regression suite that does test builds of a number of packages that use C2HS (some of these run on Travis too). If you're interested in taking over maintenance of C2HS, feel free to drop me a line with any questions. Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net PGP Key: 0x04490CC0/F4D6 027F 2661 745C 83A5 297D FCCC 0AE6 0449 0CC0

1 0

Possible breaking changes to C2HS
by Ian Ross 22 Jun '15

22 Jun '15

Dear All, The next release of C2HS (version 0.26.1) will have some changes that could conceivably cause problems in some rare cases. To summarise: C2HS will now manage imports of Haskell library modules that it needs for marshalling functions itself, rather than relying on the user writing "import Foreign.C.Types" everywhere... You can read about the details of the changes and the potential problems here: https://github.com/haskell/c2hs/blob/master/import-handling.md I'm not going to release this to Hackage for a couple of weeks to allow people to try the new version in advance, in case there are problems. Let me know if you do find any problems so that I can fix them before releasing this. Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

1 0

Tutorial Ideas?
by Ian Ross 27 Apr '15

27 Apr '15

Dear All, One of the things that C2HS is lacking is a good tutorial. So I’m going to write one (or try to, anyway). To make this as useful as possible, I’d like to base a large part of the tutorial on a realistic case study of producing Haskell bindings to a C library. My current plan is to break the tutorial into three parts: the basics, the case study and “everything else”, for C2HS features that don’t get covered in the first two parts. To make this even more useful, I’d like to base the case study on a C library that someone actually cares about and wants Haskell bindings for. So, this is an open offer to anyone who has a suitable C library they'd like Haskell bindings for -- let me know, I'll pick one to use and the lucky winner will end up with Haskell bindings for at least a "useful" portion of the library in question. Some requirements are listed here: http://www.skybluetrades.net/blog/posts/2015/04/27/c2hs-tutorial-request.ht… Also, if you have any topics you'd particularly like to have covered in a tutorial, let me know about that too! Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

2 1

Orphan Trac ticket
by Ian Ross 07 Dec '14

07 Dec '14

Dear all, When I transferred tickets from the old C2HS Trac to GitHub, the information about the original raisers of these issues was lost. I'm now trying to work out the best way to implement the feature requested in https://github.com/haskell/c2hs/issues/46 (No way to create a foreign pointer for input and have it as an out parameter), but I have no idea who it was that requested it. It would be useful to have a review of what I'm proposing from any interested parties, and especially useful to have some input from whoever originally raised that ticket! Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

1 0

How to marshall variable length out array
by Michael Jones 06 Aug '14

06 Aug '14

I have an almost working marshaling of a C function and need help. The problem is the resulting hs does not pass the length to allocaArray and peekArray. What I want to happen is to use data_in_length to control the size of data created and peeked from. I am providing a hand adjusted hs to show what I want it to do, and asking if anyone knows how to write the hook to generate the small change. Note that the C is a wrapper around another library, so I can adjust the C signature if there is an easier signature structure to hook. Also note that data_in means data in from an I2C device. From the function point of view, it is really data being returned to the caller, where the caller specifies the amount of data requested. The C: int32_t ww_i2c_read_ext ( int32_t aardvark, uint16_t slave_addr, I2cFlags flags, uint8_t *data_in, uint16_t data_in_length, uint16_t *num_read The hook that is almost correct: {#fun unsafe ww_i2c_read as i2cRead {`Int', fromIntegral `CUShort', fromI2cFlags `I2cFlags', allocaArray- `[CUChar]' peekArray*, fromIntegral `CUShort'} -> `Int’#} The incorrect result: i2cRead :: Int -> CUShort -> I2cFlags -> CUShort -> IO (Int, [CUChar]) i2cRead a1 a2 a3 a5 = let {a1' = fromIntegral a1} in let {a2' = fromIntegral a2} in let {a3' = fromI2cFlags a3} in allocaArray $ \a4' -> let {a5' = fromIntegral a5} in i2cRead'_ a1' a2' a3' a4' a5' >>= \res -> peekArray a4'>>= \a4'' -> let {res' = fromIntegral res} in return (res', a4’') The manually fixed result that I want the hook to produce: i2cRead :: Int -> CUShort -> I2cFlags -> CUShort -> IO (Int, [CUChar]) i2cRead a1 a2 a3 a5 = let {a1' = fromIntegral a1} in let {a2' = fromIntegral a2} in let {a3' = fromI2cFlags a3} in allocaArray (fromIntegral a5) $ \a4' -> <<———————————— pass size let {a5' = fromIntegral a5} in i2cRead'_ a1' a2' a3' a4' a5' >>= \res -> peekArray (fromIntegral a5) a4'>>= \a4'' -> << —————————————— pass size let {res' = fromIntegral res} in return (res', a4'')

1 0

Re: [C2hs] Request to C2HS users
by Ian Ross 22 May '14

22 May '14

No, nothing as clever as that. I took the strictly low-rent route of only testing that the regression suite packages successfully build. I don't run the package test suites, so I don't need to run any CUDA code. What I'd been finding was that most of the problems I'd been seeing with C2HS were things that would be picked up just by trying to build the packages -- out of all the problems I've seen recently, all of them were either related to problems parsing C headers or the CHS files themselves, or to generating invalid Haskell code. I've yet to see a single problem where C2HS generates Haskell code that compiles but doesn't work. Also, I didn't even know that such a thing as a CUDA emulator existed! Now that I do, maybe I'll experiment a bit when I have time and see if I can run the regression suite package test cases as well... On 19 May 2014 17:15, Ryan Newton <rrnewton(a)gmail.com> wrote: > Oh, did you use a CUDA emulator on Travis? (What is the best one these > days?) > > > > On Sat, May 17, 2014 at 12:55 AM, Ian Ross <ian(a)skybluetrades.net> wrote: > >> Thanks Ryan, >> >> I got the cuda package (and cufft and OpenCL) building on Travis without >> too much trouble, after a bit of experimentation on an EC2 instance with >> the same Linux build as Travis uses. It was easier than I thought it would >> be, and the CUDA installation process seems to be getting easier over time, >> so supporting this sort of thing for newer versions of CUDA should be easy. >> >> Cheers, >> >> Ian. >> >> >> >> On 16 May 2014 07:59, Ryan Newton <rrnewton(a)gmail.com> wrote: >> >>> Hi all, >>> >>> Sorry for long-delayed response. >>> >>> Yes, some of our jobs do happen to install accelerate-cuda (like this >>> one<http://tester-lin.soic.indiana.edu:8080/job/accelerate-multidev/229/>, >>> and this one<http://tester-lin.soic.indiana.edu:8080/job/HackageReleased_meta-par-accele…>). >>> We don't have a dedicated set of tests for accelerate-cuda itself. (But >>> we should soon. I hope to test all backend ends uniformly.) >>> >>> We have a pretty heterogeneous config in terms of cuda installs. Most >>> of our tests run on a set of machines that still have CUDA 4.2, but my own >>> work-station and laptop have 5.5. >>> >>> Cheers, >>> -Ryan >>> >>> >>> >>> On Tue, Apr 15, 2014 at 12:22 AM, Manuel M T Chakravarty < >>> chak(a)cse.unsw.edu.au> wrote: >>> >>>> Hi Ian, >>>> >>>> We haven’t build the cuda package in a CI environment, but Ryan Newton >>>> has Accelerate in on a CI server. >>>> >>>> Ryan, are you building with the CUDA backend? >>>> >>>> Ian, I’m not sure what you mean by CUDA version 6. I believe the latest >>>> CUDA release from NVIDIA is 5.5. >>>> >>>> Cheers, >>>> Manuel >>>> >>>> Ian Ross <ian(a)skybluetrades.net>: >>>> >>>> Hi Manuel (and/or Trevor!), >>>> >>>> Have you had any luck in building CUDA on Travis or any other CI >>>> environment? I've not managed to build it on my desktop machine, but >>>> that's mostly due to not having an NVIDIA card and to being on Arch Linux, >>>> where the current CUDA install is version 6 instead of 5... This C2HS >>>> regression suite idea has already turned out to be useful, catching a >>>> couple of silly little bugs I'd introduced, and I'd really like to include >>>> as many packages as possible, and to have it run as a CI test. >>>> >>>> I'll have a try on Travis myself, but it would be useful to know if >>>> you've already figured out what's needed. >>>> >>>> Thanks, >>>> >>>> Ian. >>>> >>>> >>>> >>>> On 2 April 2014 06:43, Manuel M T Chakravarty <chak(a)cse.unsw.edu.au>wrote: >>>> >>>>> Good plan! Please include >>>>> >>>>> http://hackage.haskell.org/package/cuda >>>>> >>>>> Manuel >>>>> >>>>> Ian Ross <ian(a)skybluetrades.net>: >>>>> >>>>> Dear All, >>>>> >>>>> I'm trying to make a list of packages that depend on C2HS, in order to >>>>> make a regression suite to test new releases. I slightly broke things in >>>>> the last release and only found out about it when people started reporting >>>>> regressions when trying to build packages that use C2HS. The number of >>>>> moving parts involved make it difficult to write a test suite with full >>>>> coverage, so the best approach seems to be to make a list of packages and >>>>> make sure that these all build before doing a release. >>>>> >>>>> I've not been able to figure out a way to do reverse dependency >>>>> searches on Hackage for build tools, hence the email. >>>>> >>>>> If you have a package that uses C2HS that you'd like added to the >>>>> regression suite, let me know. >>>>> >>>>> Cheers, >>>>> >>>>> Ian. >>>>> >>>>> -- >>>>> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >>>>> www.skybluetrades.net >>>>> _______________________________________________ >>>>> C2hs mailing list >>>>> C2hs(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/c2hs >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >>>> www.skybluetrades.net >>>> _______________________________________________ >>>> C2hs mailing list >>>> C2hs(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/c2hs >>>> >>>> >>>> >>> >> >> >> -- >> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >> www.skybluetrades.net >> > > -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

2 3

Re: [C2hs] Request to C2HS users
by Ian Ross 17 May '14

17 May '14

Thanks Ryan, I got the cuda package (and cufft and OpenCL) building on Travis without too much trouble, after a bit of experimentation on an EC2 instance with the same Linux build as Travis uses. It was easier than I thought it would be, and the CUDA installation process seems to be getting easier over time, so supporting this sort of thing for newer versions of CUDA should be easy. Cheers, Ian. On 16 May 2014 07:59, Ryan Newton <rrnewton(a)gmail.com> wrote: > Hi all, > > Sorry for long-delayed response. > > Yes, some of our jobs do happen to install accelerate-cuda (like this one<http://tester-lin.soic.indiana.edu:8080/job/accelerate-multidev/229/>, > and this one<http://tester-lin.soic.indiana.edu:8080/job/HackageReleased_meta-par-accele…>). > We don't have a dedicated set of tests for accelerate-cuda itself. (But > we should soon. I hope to test all backend ends uniformly.) > > We have a pretty heterogeneous config in terms of cuda installs. Most of > our tests run on a set of machines that still have CUDA 4.2, but my own > work-station and laptop have 5.5. > > Cheers, > -Ryan > > > > On Tue, Apr 15, 2014 at 12:22 AM, Manuel M T Chakravarty < > chak(a)cse.unsw.edu.au> wrote: > >> Hi Ian, >> >> We haven’t build the cuda package in a CI environment, but Ryan Newton >> has Accelerate in on a CI server. >> >> Ryan, are you building with the CUDA backend? >> >> Ian, I’m not sure what you mean by CUDA version 6. I believe the latest >> CUDA release from NVIDIA is 5.5. >> >> Cheers, >> Manuel >> >> Ian Ross <ian(a)skybluetrades.net>: >> >> Hi Manuel (and/or Trevor!), >> >> Have you had any luck in building CUDA on Travis or any other CI >> environment? I've not managed to build it on my desktop machine, but >> that's mostly due to not having an NVIDIA card and to being on Arch Linux, >> where the current CUDA install is version 6 instead of 5... This C2HS >> regression suite idea has already turned out to be useful, catching a >> couple of silly little bugs I'd introduced, and I'd really like to include >> as many packages as possible, and to have it run as a CI test. >> >> I'll have a try on Travis myself, but it would be useful to know if >> you've already figured out what's needed. >> >> Thanks, >> >> Ian. >> >> >> >> On 2 April 2014 06:43, Manuel M T Chakravarty <chak(a)cse.unsw.edu.au>wrote: >> >>> Good plan! Please include >>> >>> http://hackage.haskell.org/package/cuda >>> >>> Manuel >>> >>> Ian Ross <ian(a)skybluetrades.net>: >>> >>> Dear All, >>> >>> I'm trying to make a list of packages that depend on C2HS, in order to >>> make a regression suite to test new releases. I slightly broke things in >>> the last release and only found out about it when people started reporting >>> regressions when trying to build packages that use C2HS. The number of >>> moving parts involved make it difficult to write a test suite with full >>> coverage, so the best approach seems to be to make a list of packages and >>> make sure that these all build before doing a release. >>> >>> I've not been able to figure out a way to do reverse dependency searches >>> on Hackage for build tools, hence the email. >>> >>> If you have a package that uses C2HS that you'd like added to the >>> regression suite, let me know. >>> >>> Cheers, >>> >>> Ian. >>> >>> -- >>> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >>> www.skybluetrades.net >>> _______________________________________________ >>> C2hs mailing list >>> C2hs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/c2hs >>> >>> >>> >> >> >> -- >> Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net >> www.skybluetrades.net >> _______________________________________________ >> C2hs mailing list >> C2hs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/c2hs >> >> >> > -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

1 0

Version 0.17.2 and Regression Suite
by Ian Ross 19 Apr '14

19 Apr '14

Dear All, I've just released version 0.17.2 of C2HS to Hackage. This fixes a number of regressions that were introduced in the last couple of releases. In particular, the cuda and hsndfile packages should now build correctly. To follow up on my recent request for packages for a regression suite for C2HS, I've now implemented this, so that on every commit Travis builds C2HS then tries to install a set of "typical" packages (see below). This should hopefully help to reduce the chances of these kinds of regressions in future. The regression suite is driven off a little YAML configuration file and can perform various setup steps before building the regression packages (mostly installing packages using apt-get, although the setup for CUDA is a little more complicated). Note that the regression suite only installs these test packages -- it doesn't run their tests -- and so far, this is for Linux packages only. Someone asked me about a MacOS package, and I presume that it ought to be possible to set up a multi-platform regression suite, but I have no MacOS machine to test these things on myself and I don't know how to force Travis to use a MacOS host for Haskell builds. I'd be happy to hear any ideas, and I'd also be happy to hear of any other candidate packages for regression testing. Cheers, Ian. Current regression suite packages: CV, gnome-keyring, hnetcdf, hpuz, hsndfile, hsqml, igraph, cuda, cufft, OpenCL -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

1 0

Request to C2HS users
by Ian Ross 15 Apr '14

15 Apr '14

Dear All, I'm trying to make a list of packages that depend on C2HS, in order to make a regression suite to test new releases. I slightly broke things in the last release and only found out about it when people started reporting regressions when trying to build packages that use C2HS. The number of moving parts involved make it difficult to write a test suite with full coverage, so the best approach seems to be to make a list of packages and make sure that these all build before doing a release. I've not been able to figure out a way to do reverse dependency searches on Hackage for build tools, hence the email. If you have a package that uses C2HS that you'd like added to the regression suite, let me know. Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

2 3