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
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
