Hello
Here is the latest Caml Weekly News, for the week of April 26 to May 03, 2011.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-04/msg00264.html
orbitz said:
Hey everyone, I wrote up a short review of the paper "Efficient
Parallel Programming in Poly/ML and Isabelle/ML" which discusses how
multicore support was added to Poly/ML. I am not an expert so if I got
details wrong please correct me but the hope is Poly/ML's story might
be helpful for Ocaml.
http://functional-orbitz.blogspot.com/2011/04/jc-efficient-parallel-programming-in.html
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-04/msg00281.html
Dana announced:
I have implemented a prototype that does dynamic contract checking for
OCaml code. The prototype is built upon the source code of
ocamlc-3.11.2. Please see a tutorial for the details:
http://gallium.inria.fr/~naxu/research/camlcontract.pdf
This document also describes where to access the source code.
If you are interested in co-improving it or have any comments, please
feel free to drop me an email.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-04/msg00282.html
Christophe Raffalli announced:
I just wrote in two days a small openGL game (~500 lines in one file),
with fun options:
- anaglyph 3D (yet to tune, I have not received my cyan/red glasses yet)
- game replay
- register game and high-score on a web site.
Please visit http://lama.univ-savoie.fr/~raffalli/spheres.php
Many possibilities for this code:
- have fun and have the best high-score on the web site ;-)
- use the fun factor for teaching ... please inform me if you have any
succes failure ... There are FIXME in the code
which could be good idea ... This is how this game started after all ...
- write program that play the game.
- find a way to check that game on the website are real game played by
human at normal speed (hard research ?)
- port to other openGL bindings for OCaml (send me your file, I will put
it on the website)
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-04/msg00242.html
Thomas Braibant asked and Ethan Burns replied:
> There exists at least 3 different bindings for openGL in OCaml (and maybe
> more).
>
> For the untrained eye, it is difficult to pick one. Could someone sum
> up the pros and cons of each of these libs ?
I have only really tried glMLite (and even then I only used it to draw simple
rectangles using vertex buffers) but I did also look into the others a tiny
bit. Here is what I found:
> - LablGL http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgl.html
This appears to be the 'default' OpenGL for OCaml. It is suppose to work
with lablgtk (I don't know if the others do) but it does not seem to have
support for shaders and some later OpenGL funtionality.
> - glMLite http://www.linux-nantes.org/~fmonnier/ocaml/GL/
Supports the newer OpenGL functionality (GLSL shaders and vertex buffers).
My friend had a difficult time getting it to compile/work on OSX but with
some minor changes I believe that he eventually got it working.
> - glcaml http://glcaml.sourceforge.net/
glcaml seems to be a set of automatically generated stubs. It seems to
support some of the latest OpenGL but the interface is automatically
generated so it doesn't have a very OCaml-ish feel to it.
Anthony Tavener then added:
Ethan's summary is good. I'll elaborate a bit on glcaml...
I use glcaml, but don't recommend it in general. There are two reasons
I chose it: 1. It looks like OpenGL, so my familiarity with it
directly translates... the only differences are lowecase GL constants
and no parentheses around arguments. 2. It (kind-of) supports features
like shaders.
What I mean by "kind-of" is that the bindings are broken for a lot of
lesser-used features. I've been maintaining my own modifications to
support features I need (same with sdlcaml)... though I recently
decided I should follow OpenGL 4 (basically the same as OpenGL ES 2),
which strips the interface down to a minimal set heavily reliant on
shaders. This is turning into "yet another set of bindings".
I know I tried glMLite... but can't remember what problems I
encountered, and I did encounter problems which led me to settle on
glcaml.
Also, there is one other binding I know, by Jeffrey Scofield, for
OpenGL ES 1, and he uses this for iPhone development:
http://psellos.com/ocaml/lablgles-build.html
Summary:
If you don't need shaders: LablGL
If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES
If you need shaders: glcaml or glMLite
Oh, if anyone knows of someone making OpenGL 4 / OpenGL ES 2
bindings... please speak up! :)
David Sheets suggested:
You could also compile your OCaml to Javascript and use WebGL. We've
not yet written the ocamljs bindings to mimic lablgles but the
javascript shim is fairly small, "native" (not autogen'ed bindings)
and simple. The business logic stays in OCaml. We will soon be
tightening the ocamljs/closure-compiler toolchain to get even smaller
and faster js files.
You can see some early results from this design at http://ashimagames.com/
We are actively investigating compiling a strict OCaml subset
(directly semantically translatable to recursion-less GLSL) to
GLSL/Javascript for numeric library portability and algebraic
simplification of shaders.
If you are interested in this architecture, let me know and I can
clean up and send you the closure-compiler externs files we use to
escape the minification of the WebGL interface. If you require ocamljs
assistance, I would also be happy to help with that.
rixed then asked and David Sheets replied:
> I really like the idea of compiling an ocaml subset into GLSL but I
> don't see why the very same compiler should be limited to webgl. Isn't
> webgl using the same shading language than stock opengl ?
Sorry if I was unclear in my earlier message. The compiler will not be
limited to webgl; one could use the same shaders (perhaps after
stripping comments) in any OpenGL ES 2 or later implementation. Our
current interests are for typed tagless interpreters/emitters
targeting ESSL and Javascript. An emitter for desktop GL shaders (or
DirectX shaders) should not be difficult after this is done.
Jacques Garrigue also said and Florent Monnier added:
> Actually, LablGL has some shader support, provided by Florent Monnier.
> It has been in CVS for more than a year (file src/glShader.ml), but somehow
> I never came around to make a new release.
> I'm really sorry for the inconvenience.
>
> If some people could test this code, this would be most helpful, and I
> could make a release in a few weeks.
>
> Jacques Garrigue
I take the opportunity of this thread to ask to the users what
they would prefer about this module (GlShader).
This is about all the functions which has a "count" parameter in the OCaml
interface (and which wrap a C function which ends with the letter "v" for
vertex probably)
http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-ocaml/lablGL/src/glShader.ml?rev=1.1;content-type=text%2Fx-cvsweb-markup
http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-ocaml/lablGL/src/ml_shader.c?rev=1.1;content-type=text%2Fx-cvsweb-markup
The array data are currently provided to these functions in a *flatten* way,
and the question is maybe the users would prefer a more high-level interface?
A more high-level way would be an array of array or an array of tuples.
An array of tuples would be the safer but would probably not be the more easy
to manipulate, while a tuple is immutable.
An array of array would need to check the size of every sub-array.
With these two alternatives, the "count" parameter would not be needed
anymore.
Please tell us what you would prefer.
___
doc for glUniform* and glUniformMatrix* :
http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml
___
external uniform4fv: location:int -> count:int -> value:float array -> unit =
"ml_gluniform4fv"
CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars )
{
int count = Int_val(ml_count);
int i, len = Wosize_val(vars) / Double_wosize;
GLfloat val[len];
if (len != (4 * count)) caml_failwith("GlShader.uniform4fv: the array
size
should be a multiple of 4");
for (i=0; i<len; i++) {
val[i] = Double_field(vars, i);
}
LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC)
glUniform4fv( Int_val(location), count, val );
return Val_unit;
}
==============================
external uniform_matrix4x3fv: location:int -> count:int -> transpose:bool ->
value:float array -> unit = "ml_gluniformmatrix4x3fv"
CAMLprim value ml_gluniformmatrix4x3f(
value location,
value transpose,
value mat )
{
GLfloat val[12];
int i, len;
len = Wosize_val(mat) / Double_wosize;
if (len != 12) caml_failwith("GlShader.uniform_matrix4x3f: array should
contain 12 floats");
for (i=0; i<12; i++) {
val[i] = Double_field(mat, i);
}
LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC)
glUniformMatrix4x3fv(
Int_val(location),
1,
Bool_val(transpose),
val );
return Val_unit;
}
Anthony Tavener then added:
This is fantastic work and I'm glad to see LablGL getting shader
support! But I've been targeting the reduced set of OpenGL4/GLES2, so
my input is more as an observer than potential client.
The premise behind the "vector" functions (ending with v), is that if
the application already has what amounts to a contiguous array of
floats in memory, it's far more efficient to pass the pointer to where
it is. This can easily be and often is the case from C code. No so
from OCaml (not that this is bad!).
First problem in my mind, is that there's going to be a remapping
anyway: from OCaml float to "float32". Since we're unable to use the
data in-place, it might as well be in any arbitrary form the
application wants, but then to avoid two remappings the interface from
LablGL must be fairly "raw" (float32 array). Alternatively, the data
is structured with types useful in application code and known by the
functions.
Any way I think of a higher-level construct, it just comes back as
being more straight-forward to let the OCaml-side iterate multiple
uniform_matrix calls or map to the desired array (float32). Having a
somewhat structured input (like array of arrays, or array of tuples)
is more cumbersome unless the application-data is already in that
form, which I think is unlikely. I wouldn't work with such structures,
especially not if they were being remapped anyway. I'd prefer to have,
say, a tree of my own matrix type which I then remap once (per frame!)
for OpenGL. In C, I would certainly strive for contiguous arrays of
floats so the CPU has no additional burden.
So, it seems unfortunate, but the interface being as raw as possible
makes the most sense to me. If you have LablGL matrices or something,
then taking a function which extracts those from a data structure so
you can pack them into a float array... that would be nice and high
level for the uniform_matrix*v calls.
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at http://planet.ocamlcore.org/.
Simple Pcre based url parsing:
https://mancoosi.org/~abate/simple-pcre-based-url-parsing
Logic programming in Scala, part 2: backtracking:
http://ambassadortothecomputers.blogspot.com/2011/04/logic-programming-in-scala-part-2.html
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.