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 816A17EC6E for ; Tue, 17 Dec 2013 20:29:38 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of flux-caml@inside.org) identity=pra; client-ip=130.230.4.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="flux@modeemi.cs.tut.fi"; x-sender="flux-caml@inside.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.national.inria.fr; envelope-from="flux@modeemi.cs.tut.fi"; x-sender="flux@modeemi.cs.tut.fi"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.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=mail3-smtp-sop.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: As0AAMelsFKC5gQqmWdsb2JhbABZFoMsg1i1ZoE1DgEBAQEBCAsLBxQogiUBAQEDASNbCwsaAgUhAgIPAQQYRBuHYQixD5hWF4Epi0uBa1CCWIFIBJgWgTCUEQ X-IPAS-Result: As0AAMelsFKC5gQqmWdsb2JhbABZFoMsg1i1ZoE1DgEBAQEBCAsLBxQogiUBAQEDASNbCwsaAgUhAgIPAQQYRBuHYQixD5hWF4Epi0uBa1CCWIFIBJgWgTCUEQ X-IronPort-AV: E=Sophos;i="4.95,502,1384297200"; d="scan'208";a="41477571" Received: from mail.cs.tut.fi ([130.230.4.42]) by mail3-smtp-sop.national.inria.fr with SMTP; 17 Dec 2013 20:29:37 +0100 Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id 8585F40B for ; Tue, 17 Dec 2013 21:29:36 +0200 (EET) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 09878-41 for ; Tue, 17 Dec 2013 21:29:35 +0200 (EET) Received: from modeemi.modeemi.fi (modeemi.modeemi.fi [130.230.72.134]) by mail.cs.tut.fi (Postfix) with SMTP id CACB640A for ; Tue, 17 Dec 2013 21:29:35 +0200 (EET) Received: from coffee.modeemi.fi (coffee.modeemi.fi [130.230.72.140]) by modeemi.modeemi.fi (Postfix) with ESMTP id B38D1396FA for ; Tue, 17 Dec 2013 21:29:35 +0200 (EET) Received: by coffee.modeemi.fi (Postfix, from userid 17990) id A26302D6045; Tue, 17 Dec 2013 21:29:35 +0200 (EET) From: Erkki Seppala To: caml-list@yquem.inria.fr References: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch> <1C9496037B6149EC970D65C3BFA490F7@erratique.ch> Date: Tue, 17 Dec 2013 21:29:35 +0200 In-Reply-To: <1C9496037B6149EC970D65C3BFA490F7@erratique.ch> ("Daniel =?utf-8?Q?B=C3=BCnzli=22's?= message of "Tue, 17 Dec 2013 18:47:42 +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=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2 Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome Daniel B=C3=BCnzli writes: > However I think this discussion is mostly irrelevant here > since we are constrained by the loose design of the underlying library > which, as I said, doesn't differentiate/document enough its errors and > provides them only as strings. So what I did is to return `Error > whenever the function may return an error and the documentation > indicates that Sdl.get_error () can be used to get more information > (they don't expose error codes). Amazing! I checked SDL2 out and indeed, the only way to do reporting is with SDL_SetError(const char *fmt, ...);. I imagine it must be a great easy way to make simple error reporting, but it sure doesn't make it easy to handle them. Here is an overly-complicated and slightly unrealistic solution: - Find each error from the code automatically Examples: SDL_SetError("SDL not built with video support"); SDL_SetError("Couldn't open %s", filename); - Transform them into: type error =3D [ `SDL_not_build_with_video_support | `Couldnt_open of string ] - And maybe: exception SDL_Error of error With some code analysis one could even discover what errors are thrown by which functions :-o. (Actually without that the previous mapping without exceptions wouldn't be very useful.) This scheme of course fails with SDL_SetError("%s%s%s", prefix ? prefix : "", prefix ? ": " : "", message); which would need manual handling. So perhaps it's not realistic, not worth the trouble and not aligned with your goals of making a very thin wrapping layer. Maybe this kind of 'safer' layer could be built as an additional layer over Tsdl. But I think a small enhancement would be making the error an `Error of string. It would make the stringly typed error handling of SDL more apparent to the user and give more direct suggestion on how to deal with them. > Thin (bindings to) SDL. I could have used Sdl but I don't like to take ow= nership of toplevel names that are used in other settings. I think the name might make one think the bindings are for libsdl1. Would Tsdl2 be too verbose? Thanks for great work! I'm sure to check the bindings out in practice the next time I find myself needing to deal with the task SDL is suitable for :). --=20 _____________________________________________________________________ / __// /__ ____ __ http://www.modeemi.fi/~flux/\ \ / /_ / // // /\ \/ / \ / /_/ /_/ \___/ /_/\_\@modeemi.fi \/