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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 0FA327EC6E for ; Wed, 18 Dec 2013 07:54:24 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of flux@modeemi.cs.tut.fi) identity=pra; client-ip=130.230.4.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="flux@modeemi.cs.tut.fi"; x-sender="flux@modeemi.cs.tut.fi"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of flux@modeemi.cs.tut.fi) identity=mailfrom; client-ip=130.230.4.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="flux@modeemi.cs.tut.fi"; x-sender="flux@modeemi.cs.tut.fi"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.cs.tut.fi) identity=helo; client-ip=130.230.4.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="flux@modeemi.cs.tut.fi"; x-sender="postmaster@mail.cs.tut.fi"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAMxFsVKC5gQqmWdsb2JhbABZFoMsuUiBNA4BAQEBAQgLCwcUKIIlAQEBAwE6RAsLISUPAQQNC0SHcAMJCA3CPA2GfBeMdAuCGhaEIASWK4FrgTCLKohn X-IPAS-Result: AgwBAMxFsVKC5gQqmWdsb2JhbABZFoMsuUiBNA4BAQEBAQgLCwcUKIIlAQEBAwE6RAsLISUPAQQNC0SHcAMJCA3CPA2GfBeMdAuCGhaEIASWK4FrgTCLKohn X-IronPort-AV: E=Sophos;i="4.95,505,1384297200"; d="scan'208";a="49478513" Received: from mail.cs.tut.fi ([130.230.4.42]) by mail2-smtp-roc.national.inria.fr with SMTP; 18 Dec 2013 07:54:23 +0100 Received: from amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) by mail.cs.tut.fi (Postfix) with ESMTP id 5ED9FD57 for ; Wed, 18 Dec 2013 08:54:23 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis1.cs.tut.fi (amavis1.cs.tut.fi [130.230.4.69]) (amavisd-maia, port 10024) with ESMTP id 02469-25 for ; Wed, 18 Dec 2013 08:54:22 +0200 (EET) Received: from modeemi.modeemi.fi (modeemi.modeemi.fi [130.230.72.134]) by mail.cs.tut.fi (Postfix) with SMTP id 9FA38D56 for ; Wed, 18 Dec 2013 08:54:22 +0200 (EET) Received: from coffee.modeemi.fi (coffee.modeemi.fi [130.230.72.140]) by modeemi.modeemi.fi (Postfix) with ESMTP id 9442A39465 for ; Wed, 18 Dec 2013 08:54:22 +0200 (EET) Received: by coffee.modeemi.fi (Postfix, from userid 17990) id 8810C2D6166; Wed, 18 Dec 2013 08:54:22 +0200 (EET) From: Erkki Seppala To: caml-list@yquem.inria.fr References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> Date: Wed, 18 Dec 2013 08:54:22 +0200 In-Reply-To: (Florent Monnier's message of "Tue, 17 Dec 2013 15:17:16 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2 X-Validation-by: flux@modeemi.fi Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome Florent Monnier writes: > 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).) > Ya we should fork SDL into an SDLERR project that would return proper > error codes for every possible type of errors. Maybe there would be > some sponsors for such a project. 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.) 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. -- _____________________________________________________________________ / __// /__ ____ __ http://www.modeemi.fi/~flux/\ \ / /_ / // // /\ \/ / \ / /_/ /_/ \___/ /_/\_\@modeemi.fi \/