From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id EF1EB7EC6E for ; Mon, 30 Dec 2013 14:29:03 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of san.vu-ngoc@laposte.net) identity=pra; client-ip=193.253.67.230; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="san.vu-ngoc@laposte.net"; x-sender="san.vu-ngoc@laposte.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of san.vu-ngoc@laposte.net designates 193.253.67.230 as permitted sender) identity=mailfrom; client-ip=193.253.67.230; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="san.vu-ngoc@laposte.net"; x-sender="san.vu-ngoc@laposte.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtpout.laposte.net) identity=helo; client-ip=193.253.67.230; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="san.vu-ngoc@laposte.net"; x-sender="postmaster@smtpout.laposte.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8DANR0wVLB/UPmlWdsb2JhbABYg0OnQZI9O4EvDgEBAQEJCwkJEiqCJQEBAQQnCwEFNgoRCxgJBBIPCQMCAQIBDyQSBgEMBgIBAQ6HXQEDFQnBZBA6AwqFXxeNChmBIiU6hDYEliuDHIUVhhWIaIFn X-IPAS-Result: Aq8DANR0wVLB/UPmlWdsb2JhbABYg0OnQZI9O4EvDgEBAQEJCwkJEiqCJQEBAQQnCwEFNgoRCxgJBBIPCQMCAQIBDyQSBgEMBgIBAQ6HXQEDFQnBZBA6AwqFXxeNChmBIiU6hDYEliuDHIUVhhWIaIFn X-IronPort-AV: E=Sophos;i="4.95,573,1384297200"; d="scan'208";a="42888313" Received: from smtpout5.laposte.net (HELO smtpout.laposte.net) ([193.253.67.230]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Dec 2013 14:29:01 +0100 Received: from [192.168.0.12] ([82.225.106.147]) by mwinf8510-out with ME id 7pUz1n00A3AqFLq03pUzqK; Mon, 30 Dec 2013 14:29:00 +0100 Message-ID: <52C1751B.9040404@laposte.net> Date: Mon, 30 Dec 2013 14:28:59 +0100 From: Vu Ngoc San User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kakadu , caml-list@yquem.inria.fr References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome 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 > 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