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

[Vu Ngoc San <san.vu-ngoc@laposte.net>]

Hi Kakadu

I think you just forgot TTF_Init.

I have added a couple of functions (see below), and it works very well.

Best wishes
San

module TTF = struct
   type _font
   type font_struct = _font structure
   let font_struct : font_struct typ = structure "TTF_Font"
   type font = font_struct ptr
   let font_opt : font option typ = ptr_opt font_struct
   let font : font typ = ptr font_struct
   let init =
     foreign "TTF_Init"
       (void @-> returning zero_to_ok)
   let was_init =
     foreign "TTF_WasInit"
       (void @-> returning bool)
   let open_font =
     foreign "TTF_OpenFont"
       (string @-> int @-> returning (some_to_ok font_opt) )
   let close_font =
     foreign "TTF_CloseFont"
       (font @-> returning void)
   let render_text_blended =
     foreign "TTF_RenderText_Blended"
       (font @-> string @-> color @-> returning (some_to_ok surface_opt))
   let render_utf8_blended =
     foreign "TTF_RenderUTF8_Blended"
       (font @-> string @-> color @-> returning (some_to_ok surface_opt))
   let render_unicode_blended =
     foreign "TTF_RenderUNICODE_Blended"
       (font @-> string @-> color @-> returning (some_to_ok surface_opt))
   let size_utf8 =
     foreign "TTF_SizeUTF8"
       (font @-> string @-> ptr int @-> ptr int @-> returning zero_to_ok)
   let size_utf8 f s =
     let w = allocate int 0 in
     let h = allocate int 0 in
     match size_utf8 f s w h with
       | `Ok () -> `Ok (!@ w, !@ h) | `Error -> `Error
end


Le 22/12/2013 11:01, Kakadu a écrit :
> 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