caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Florent Monnier <monnier.florent@gmail.com>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: caml list <caml-list@inria.fr>
Subject: Re: [Caml-list] SDL2 bindings, testers and feedback welcome
Date: Tue, 17 Dec 2013 15:17:16 +0100	[thread overview]
Message-ID: <CAE1DttAHRjXJXD2MYpW6-s17phSEUnDsu5ghQiJSFx_=o7NJpg@mail.gmail.com> (raw)
In-Reply-To: <4DDEBB7487B641C0834F09D522EA9918@erratique.ch>

2013/12/17, Daniel Bünzli wrote:
> Hello,
Hi Daniel!

Thanks for your previous help for compilations on Raspberry Pi, since
then I enjoy so much programming on this small machine, and I've been
able to make mini-demos for kids with it, which was such a happy
moment for me (and I hope for them too).

> I have written thin bindings to SDL 2 using ocaml-ctypes. The binding

I don't know anything about "ocaml-ctypes", I will have to add on my
TODO list to search for sme blog posts and/or tutorials about it.

> is finished but should be considered unstable: it was not thoroughly
> tested and may still change as it has not been *used* yet. The purpose
> of this unstable release is to:
>
> 1) Iron out the install procedure and test on a variety of platforms.

I can test it on Mageia Linux and on MS/Windows with Cygwin Terminal
with MingW's compilator.

Should we test SDL 2.0.0 or 2.0.1 (or both?)

Can I request you later to test a compilation on OSX?

> 2) Get feedback about the design of the binding (see below).

The most interesting it there :)

> More precisely, apart from the eventual bugs, I'm interested in
> getting feedback in the following areas:
>
> * I used an 'a result = [ `Error | `Ok of 'a ] rather than an exception
> for functions that return error codes/null is error. I tend to lean
> on exceptionless designs but I'm still unsure whether it is a good
> idea that case.

I also prefer exceptionless designs, but in practice I found that it's
more painfull for writting quick and dirty small/mini demos and quick
experimentations.
And experimentation is important for writting screensavers,
mini-games, and various multi-media/infographic things.

But I would say (IMHO) that it would be good to have both, an
exceptionfull module for beginning, and an exceptionless module for
the rewritting of the initial drafts.

Being myself a perfectionist, I found interesting to migrate what I
felt is perfection, from very well written code, into very quickly
written code, I mean as in a race or a challenge :-)

>                 One of the problems is that SDL doesn't make a clear
> distinction (at the signature level *and* in the documentation)

SDL 1/2 are C libs.
We should not expect something tailored for our language.

If something is missing there, this our job to provide it, and then to share it.

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 think this could be an interesting project to make an equivalent for SDL 2.
And from there trying to make something that would tend to be a
standard for any kind of C libs.
These API descriptions could then be used for different purposes by
different projects.

I would like to elaborate and discuss more on the topic, and to share
my experimentations but I have now to go to the state ajency for
unemployed people. If someone is interested to sponsor my
experimentations, I could allocate more energy on it than when I'm
doing it as a volunteer. to be continued...

> between programming errors (invalid_arg), exceptional errors
> (e.g. out of memory) and non-exceptional errors (e.g. could not
> access/setup a resource).

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.

> * The signature/approach of certain binding functions may be disputable
> or may need change to achieve reasonable performance.

could you elaborate?

> * Testing the binding to the joystick/game controller/force feedback api,
> I have none of these things in my hands.

I bought a 5 euro joypad last year for testing SFML2 and SDL2.
I can test the joypad events.

> I welcome discussions/ideas about these points and the general design
> of the binding on github's issue tracker (http://github.com/dbuenzli/tsdl)

Thanks for accepting feedbacks.

> Note that the philosophy of the binding is to be "thin", that is a
> mostly type-safe(r), minimal, hopefully efficient, one-to-one
> binding. This means that I'm not interested in prettyfing the C API
> like OCamlSDL does.

I share your views and tastes.
(Even if I like both ways.)

But thin could be understood in different ways, and addapted to the
idioms of the language.
for example a piece of ocaml--sdl code like:

   let stuff = Sdlmodule.func params in

will then be rewritten in C by copy-pasting the func-stub :

   SDL_t stuff = SDL_ModFunc(params);
   if (stuff != 0) {
      myprint("Err: %s", SDL_GetError());
      myexit() // or myNextLoop();
   }

On the OCaml formulation my equivalent will be a try on the main entry
display function, with the exceptional case to be either nothing or a
failsafe handling, that has its own close equivalent in pure C.

>                     I expect tsdl code to look like C SDL code
> (including the inconsistent naming schemes) and the binding to be used
> by programmers to build higher-level, more OCaml friendly, abstractions.
>
> To install (only tested on osx and linux so far) you'll need at least SDL
> 2.0.1
> installed on your system. Then:
>
> opam repo add erratique-u http://erratique.ch/software/opam/unreleased
> opam update && opam install tsdl
>
> On osx 10.8.5 with OCaml 4.01.0 there's a heisenbug I couldn't track so far
> (see [1] for more info). Use 4.00.1 instead for now but note that the
> binding
> takes a long time to compile (~8 min on my machine) with that.
>
> If you want to hack the sources:
>
>   git clone http://github.com/dbuenzli/tsdl
>   cd tsdl && ./build test.native && ./test.native
>
> The documentation of the binding is here:
>
>   http://erratique.ch/software/tsdl/doc/Tsdl
>
> Best,
>
> Daniel
>
> [1] http://lists.ocaml.org/pipermail/ctypes/2013-December/000027.html
>
> P.S. If anyone wonders, the existing OCamlSDL is a very good binding
> to SDL 1.X, but SDL 2.0 is an entirely new, incompatible, API.

The API is not entirely new. A lot is compatible, and a compatibility
layer has been carefully designed to help progressive and painless
migrations.

Without the Licensing issues on OCamlSDL, we could have migrated it to SDL 2.X

I would still want to try it if only the authors could be reached to
ask them permission to switch from the highly restrictive and
incompatible current license of OCamlSDL into the more convenient
zlib/png license of SDL 2.

>                                                                Besides
> SDL 2.0 changed to a zlib license, tsdl is under BSD3, OCamlSDL is
> LGPL.

Indeed, and LGPL without exception on static linking needed by ocamlers.

Would it be indiscreet to ask you if you wrote this code as a
volunteer or if you got paid for it, and how much? If that's
indiscreet, please just ignore this question.

-- 
Cheers
Florent

  parent reply	other threads:[~2013-12-17 14:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  6:11 Daniel Bünzli
2013-12-17  7:02 ` Anthony Tavener
2013-12-17 14:17 ` Florent Monnier [this message]
2013-12-17 15:14   ` Daniel Bünzli
2013-12-18  6:54   ` Erkki Seppala
2013-12-18  8:05     ` Anthony Tavener
2013-12-18  9:24       ` Daniel Bünzli
2013-12-18  8:18     ` Florent Monnier
2013-12-22 10:01       ` Kakadu
2013-12-30 13:28         ` Vu Ngoc San
2013-12-17 17:05 ` Ashish Agarwal
2013-12-17 17:47   ` Daniel Bünzli
2013-12-17 18:57     ` Ashish Agarwal
2013-12-17 19:45       ` Anthony Tavener
2013-12-18 15:40         ` Ashish Agarwal
2013-12-18 18:02           ` Yotam Barnoy
2013-12-18 19:53             ` Daniel Bünzli
2013-12-18 22:29               ` Ashish Agarwal
2013-12-18 22:45                 ` Daniel Bünzli
2013-12-17 20:26       ` Daniel Bünzli
2013-12-18  1:13         ` Francois Berenger
2013-12-18  6:44           ` Erkki Seppala
2013-12-18  9:21           ` Daniel Bünzli
2013-12-19  1:11             ` Florent Monnier
2013-12-19  6:39       ` Florent Monnier
2013-12-17 19:29     ` Erkki Seppala
2013-12-19  5:20 ` Florent Monnier
2013-12-19  5:27   ` Florent Monnier
2013-12-19  7:13   ` Daniel Bünzli
2013-12-19 12:38     ` Florent Monnier
2014-02-12 10:43 ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE1DttAHRjXJXD2MYpW6-s17phSEUnDsu5ghQiJSFx_=o7NJpg@mail.gmail.com' \
    --to=monnier.florent@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).