Re: [Caml-list] SDL2 bindings, testers and feedback welcome

[Florent Monnier <monnier.florent@gmail.com>]

2013/12/18, Erkki Seppala wrote:
> Florent Monnier wrote not only:
>
>> More precisely I found very interesting several initiatives available
>> around, like for example the idea behind the XML description of the
>> API of the XCB C library.
>>
>> http://xcb.freedesktop.org/dist/xcb-proto-1.9.tar.gz
>
> I suppose it doesn't detract your point, but xcb-proto actually
> describes the line protocol of X, not the X library interface or XCB
> library interface though the latter can be inferred from it based on the
> fact it's generated. So the new XCB-based libraries for interacting with
> the X server then are generated from those (but Xlib is not related to
> this). They are not very useful for binding per se.
>
> But they could be used for generating XCB-based OCaml library
> interacting directly with X. (I have actually written a tool based on
> those that decodes live X traffic, but it was in Python (for code
> generation) and C (for doing the work).)

What I meant is that annotate the C headers, or similar approaches are
limited if it's about to make a generic way that could be used in most
(or maybe almost all) cases.

A proper description of the APIs would make it possible to divert to
different languages (and maybe even other kind of applications).

XcbProto is designed for our best friend Python, but its upstream
immediatly proposed to complete it with additional elements that we
would need for our programming language of choice.

> Well, I think that it may be a bit unrealistic to expect this kind of
> fork to get very popular. I think in most common SDL use cases people
> just don't care much about errors :(. (Ie. games: either work or they
> don't.)

Sorry it was just ironic :)
Sam already does quite a lot enough. We should not ask too much, or if
we do we should just do ourself what we request from someone else.

> But a documentation effort or a tool for extracting thrown error strings
> and then building towards more consistent error management, that I think
> would easily be upstreamable.

Then please try!

-- 
Best regards
Florent