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

[Kakadu <kakadu.hafanana@gmail.com>]

Fellas,

I have added [1] function TTF_openFont but when I use it I receive
`Error and don't know why. Do you know how to debug it? Maybe I did
something wrong in OCaml definitions?

Kakadu

[1] https://github.com/Kakadu/tsdl/commit/44115cbdee92911eae9b1d51ce33da86392da965#diff-844c2aaff3869f0a29cc34c69b019276R824



On Wed, Dec 18, 2013 at 12:18 PM, Florent Monnier
<monnier.florent@gmail.com> wrote:
> 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
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs