Previous week Up Next week


Here is the latest OCaml Weekly News, for the week of March 11 to 18, 2014.

  1. I never succeeded in using Format
  2. OpenGL and LWT
  3. Other OCaml News

I never succeeded in using Format


Continuing the thread from last week, François Pottier announced:
Interesting discussion, which prompted me to come out of my retreat and
publish a new implementation of PPrint, available now :-)

Oleg is right: the now-old PPrint implementation uses backtracking and its
time complexity is dependent on the window width.

Oleg's message caused me to think, and I realized that I had missed a major
opportunity for simplification and optimization, which in fact was shortly
thereafter mentioned by Bob in his reply to Oleg's message. The idea is
simple. The PPrint API requires the document to be constructed in an eager,
bottom-up manner. (One reason for this decision was syntax: I did not want the
user to have to write "lazy" everywhere, and I did not want to impose the use
of a syntax extension.) So, we are paying a high cost in space (linear space
overhead), but in return, it is easy to compute the required width of every
(sub-)document as it is constructed. This in turn means that the rendering
process can be performed in linear time, without dependency on the window
width, without any backtracking or buffering.

I have implemented this idea in the new version of PPrint and compared it with
the old version. In short, the results are as follows, for a set of
randomly-generated documents:

  - the construction of the document is roughly just as fast as it was
    (but documents occupy slightly more space in memory)

  - rendering is faster than before, between 2x and 3x faster

  - the code is much simpler than before (this is the key benefit)

  - two features are lost (namely, the primitive operators [nesting] and
    [column], which were used to get access to the engine's state during
    rendering; they are no longer supported because they prevent the width

I should point out that rendering is now between 10x and 20x faster than the
construction of the document, which (I believe) means that the current
implementation is essentially unbeatable in terms of throughput. So, in my
view, the bottom line is, if one is willing to live with linear space
overhead, then this approach is preferable for its simplicity and efficiency;
if one must work in constant space, then Oleg's approach is preferable.

The new release of PPrint is available here:

and should reach opam pretty soon ("opam install pprint").

OpenGL and LWT


Deep into this thread, Richard Neswold said and Daniel Bünzli replied:
> Most OpenGL bindings (including LabGL) include 'libglut', which is a
> library that is bundled with OpenGL that opens a UI window with an
> OpenGL context in it. It would be nice to use this library because it
> hides these details (i.e. the same code runs on Unix and MacOSX and
> Windows.) Unfortunately, the way libglut works is you call main_loop()
> which never returns. Before calling main_loop(), you register
> callbacks for mouse and keyboard events. You can also register a
> callback for periodic timeouts. Lastly, there's a callback which gets
> called whenever the libglut main loop is "idle" (with unspecified
> latencies, frequency, or guarantees.)

I wouldn't use glut which is no longer bundled on osx, is quite limited
in functionality and reclaims your main loop. Use SDL, it provides
similar functionality to setup an OpenGL context in a platform
independent way but it doesn't reclaim control on your main() which will
make integration with lwt trivial. There is:

I also wrote newer and lower level bindings that target SDL2, they are
not released yet but are becoming stable see:

(the heisenbug on osx mentioned in that message can be solved see [1]).  



Daniel Bünzli later corrected:
> I wouldn't use glut which is no longer bundled on osx,

Well that's wrong. But it's no longer recommended, see
Richard Neswold then said and Daniel Bünzli replied:
> I could have an Lwt thread call Sdl.poll_event and then go to sleep if
> no events were available, but I'm trying to make this driven by events
> and not resort to polling, if possible.

There is certainly more than one way to do that, but that's what I do at
the moment (with another cooperative threading library). Favor the
treatement of the UI events, if there's no UI event run the scheduler
for 10ms.

let rec loop deadline =  
  while Sdl.poll_event e do do_event e done;
  run_scheduler ~timeout:10;  
  loop ()

Regarding Tsdl.Sdl.wait_event, it's not really better than that, if you
have a look at its C implementation [1] you'll see it tries to get an
event and if none is available it will sleep for 10ms before trying
again. This means that any SDL based program using Sdl.wait_event,
constantly uses ~1.5% cpu (at least on osx), you should be able to bring
that down by writing your own loop as above and augmenting the timeout
value when your application is not in the foreground.




Other OCaml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the
recent posts from the ocamlcore planet blog at

BitMasks Library:

WODI now officially supports cygwin64:

Old cwn

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.

Alan Schmitt