Previous week Up Next week


Here is the latest Caml Weekly News, for the week of 23 to 30 August, 2005.

  1. Berkeley DB
  2. OPath 0.2 released
  3. OCamlDuce 3.08.4
  4. GODI news
  5. Does LablTk have a future?

Berkeley DB


Continuing the thread from last week, Christopher Alexander Stein said:
I actively maintain a BDB OCaml interface 
( It 
currently works with BDB 4.3.21. Please send me any bug reports 
and bug fixes.

OPath 0.2 released


Jamie Clarkson announced:
I'm pleased to announce the availability of OPath 0.2.

OPath is a physically based 3D renderer written in OCaml. It takes a scene
description written in a simple declarative language and runs various 
ray or
path tracing algorithms to generate high dynamic range images.

This release is mostly for architecture stabilization and improving
robustness.  One or two new features have been added however:

  * Thin lens camera (for depth of field rendering)
  * 2D texturing
  * Dielectric materials (e.g. glass)

Homepage with some nice renders:

Source under MIT license and a Win32 binary are available: 

All comments appreciated, enjoy!

OCamlDuce 3.08.4


Alain Frisch announced:
OCamlDuce 3.08.4 is now available (
As the version number says, it has been synchronized with OCaml 3.08.4.

More importantly and due to overwhelming popular demand, OCamlDuce now 
comes with some amount of binary-compatibility with OCaml. This should 
make it easier to try OCamlDuce.

OCaml-generated  files (.cmi/.cmx/.cmo) can be used by OCamlDuce without 
recompilation. You can thus install OCamlDuce and re-use already 
installed libraries from an existing OCaml installation. Provided that 
the OCaml and OCamlDuce versions match, of course.

It is even possible to have a mixed OCaml/OCamlDuce project, where 
OCamlDuce is only used to compile some modules whose interface are pure 
OCaml (OCaml and OCamlDuce produce identical .cmi files for the same 
pure OCaml .mli file).
John Skaller wondered and Alain Frisch answered:
For what concerns John's question about the integration of OCamlDuce in 
OCaml, there are many answers. 1) I'm not directly involved in the 
development of OCaml. 2) The -Duce part, taken from CDuce, is a big 
piece of code which still evolves in some experimental ways and which 
couldn't be easily maintained by someone else in its current state. 3) 
OCaml is a general purpose language, and the extension adds support for 
a specific domain (and OCaml is already big enough). 4) One of the 
design guidelines for OCamlDuce was to obtain an easy merger between two 
existing implementations; due to this constraint the result is not as 
elegant or integrated with the rest of the language as one might expect 
from an ML+CDuce merger written from scratch (but it works). The 
constraint of being able to compile any existing OCaml program with 
OCamlDuce, for instance, resulted in the introduction of explicit 
delimiters {{..}} for all the new constructions, which is syntactically 
heavy and theoretically useless.  5) It's too early to say whether 
OCamlDuce is useful or not compared to a simpler solution with two 
compilers (OCaml, CDuce).

GODI news


Gerd Stolpmann announced:
Welcome to GODI news, the newsletter that informs you about updates of
GODI, the source-based O'Caml distribution.


1. GODI upgrades to O'Caml 3.08.4
2. Various problems solved
3. Current GODI development
4. Where to find more information about GODI


The GODI project recently upgraded to O'Caml 3.08.4. This means that the
"3.08" branch of the distribution now bases on this O'Caml version
instead of the formerly used version 3.08.3. The old version is
discontinued at the same moment.

Existing installations of GODI can be easily upgraded using the standard
mechanism. This works in an almost fully automatic way, GODI takes care
not to only build the new O'Caml base but also rebuilds all dependent
libraries. Although well tested, it is recommended to save a copy of the
old installation before trying the update.

To start the update, invoke godi_console in interactive mode, and do:

- Update the list of packages
- Go into the menu where one can select the packages. Press 'u'
  to upgrade the packages, and confirm with 'o'. Start the installation
  as usual. There is one special point that requires manual 
  intervention: Because godi_console updates itself, the user is
  warned about potential problems, and another confirmation ('o')
  is required. You will see a describing message at that point.
- Enjoy the updated installation

It is also possible to do the same from the command-line:

$ godi_console update
$ godi_console wish -rebuild
$ godi_console perform -wishes -newer
$ godi_console wish -reset


As more and more operating systems are shipping with GCC 4 as default
compiler, it became urgent to fix the incompatibilities with this GCC
version. Partly, the problem could be solved by the upgrade to O'Caml
3.08.4. However, GODI still uses some C programs that could not be
compiled. These had to be additionally fixed.

It is recommended that users of GCC 4 bootstrap GODI from the beginning.
(You can find out the GCC version by entering the command 
"gcc --version".)

Another problem in the past months affected only Mac OS X 10.4 users.
Because of a change of a system call some programs had to adapted to the
new style.


Current versions of godi_console include an integrated rewrite of the
"BSD make" utility GODI uses to drive all sorts of shell scripts. One
can call this version of the "make" utility by calling "godi_console
make ..." instead of "godi_make ...". It is still experimental, although
it seems to be good enough to replace the old C program that is
currently being used.

For a discussion of the consequences, see this thread:


GODI is a source-based O'Caml distribution. It consists of a framework
that automatically builds the O'Caml core system, and additionally
installs a growing number of pre-packaged libraries. GODI is available
for O'Caml-3.07 and 3.08. It runs on Linux, Solaris, FreeBSD, NetBSD,
Cygwin, HP-UX, MacOS X.

Advantages of using GODI:

      * Automatic installation of new libraries: GODI knows where a
        library can be downloaded, which prerequisites are needed to
        build it, and which commands must be invoked to compile and
        install it
      * Complete package management of the installation: A library is
        installed as a package (a managed set of files), so it is
        possible to remove it later without any hassle.
      * GODI implements the necessary logic to upgrade installations:
        Because of the way O'Caml works, all dependent libraries must be
        recompiled if a library is upgraded to a newer version. GODI
        automates this process.
      * Integration with the operating system: If additional C libraries
        are needed to build an O'Caml library, and the operating system
        includes them, they will usually be automatically found and
        used. Non-standard locations can be configured (there is only
        one configuration file for the whole installation).
      * GODI has a menu-based user interface that makes it simple to use
        even for beginners.
      * GODI tries to standardize the directory layout of library
        installations, so it becomes simpler to find files of interest.

GODI currently supports 73 add-on libraries and 12 applications written
in O'Caml.

Read more on the GODI homepage:

Does LablTk have a future?


Matt Gushee said:
I've been thinking about GUI toolkits lately, and particularly Tk. I 
know there are a lot of people who believe Tk is dead, or should die. 
Personally, I'm not so sure. If you look at the features of Tk 8.5, and 
the development roadmap for future versions--perhaps it's too little, 
too late--but it is clear that the core Tcl/Tk developers are far from 
giving up. Indeed, they seem lately to have gotten a clue about what is 
needed to keep Tk a viable GUI toolkit.

Regardless of the status of Tk itself, LablTk seems to be going nowhere 
(note that I am not implying any criticism of the OCaml team--they have 
other, quite legitimate, priorities). It is poorly documented and is not 
keeping up with the recent improvements in Tk. Those who try to use it 
often run into trouble, and have difficulty getting their questions 
answered. Yet, for whatever reason, it remains the default GUI toolkit 
for OCaml.

I believe that Tk, while certainly not an ideal GUI, is still adequate 
for many applications, and if the above deficiencies are remedied, could 
still serve as OCaml's default GUI library for some time to come. And it 
occurs to me that, having several years' experience with Tk in various 
forms, and having studied much of the LablTk source code, I am in a 
position to do several things that might help revive LablTk. My purpose 
today is to inquire whether there is enough interest in the community to 
justify any or all of these projects. If there is, I am prepared to work 
on one or more of them--preferably with collaborators, but alone if 
necessary. If there is little or no interest, maybe it is time to 
consider (again) dropping LablTk entirely. Who wants to maintain code 
that isn't used or usable?

1) A Quick Reference

    This document would outline (with little or no explanation) the
    complete LablTk API, including all widget commands and the possible
    values of all LablTk-specific types. Currently the latter information
    can only be obtained by digging through the source code.

    Actually, I wrote a LablTk quick reference some time ago. It may need
    a bit of work, but no more than a couple of hours, I'm sure. So I
    *will* do this if there is any interest at all in it.

2) A Book

    This would be an in-depth tutorial on how to develop useful
    applications with LablTk. It would assume some programming
    experience, but it would not require advanced knowledge of OCaml, nor
    any knowledge of Tcl.

    I'm thinking to publish both a print edition and an inexpensive
    electronic edition. Though I need to research the costs a bit more, I
    believe I can offer the print edition--self-published using Print On
    Demand--at a reasonable price, comparable to what you pay for
    programming books at a bookstore (no, I don't hope to get rich off
    this--just to be modestly compensated for my efforts :).

3) A Community-based Modernization Project

    The idea here is to provide a Tk-based GUI library that is complete
    and in sync with the latest stable version of Tk. Other features that
    would be nice to have include (a) support for a few Tcl commands that
    are not strictly part of Tk, but are useful and commonly used in Tk
    programs--in particular I'm thinking of the 'after' command; and (b)
    a framework that allows downstream developers to create custom
    widgets with interfaces analogous to the builtin widgets. I'm not
    sure if (b) is feasible or not within the constraints of the OCaml
    type system--I've tried and failed in the  past--but I imagine
    there's some way to do it.

    Two other interrelated questions are whether this project should be
    done in parallel with LablTk or as a replacement, and whether the
    LablTk API should be preserved or something new designed. But it's
    probably not necessary to decide these questions immediately.

I eagerly await your comments.
Francois Rouaix said and Matt Gushee answered:
> I'm not active in the LablTk or CamlTk community anymore, but as the 
> writer of the (probably) largest piece of CamlTk code lying around (the 
> MMM browser), I want to let you know to feel free to pilfer code from 
> MMM, if useful or relevant.


> Also, you mention "extra Tcl" commands such as "after". I remember after 
> and timers to be present in CamlTk. Maybe they weren't ported to LablTk.

Yes, I think that's right. I wrote an app about a year ago that needed 
'after'. Though for some reason I can't recall, I didn't want to use the 
CamlTk version verbatim, I did model my implementation after it.
Jon Harrop said and Matt Gushee answered:
>>Regardless of the status of Tk itself, LablTk seems to be going nowhere 
> It is odd that you should bring this up now. I've spent the past week writing 
> a simple database for a new veterinary surgery in OCaml using labltk. I had 
> tried lablgtk before but failed to get to grips with it. By comparison, the 
> labktk examples explained everything that I needed and I had a decent GUI up 
> and running within a few hours.

Yes, it does have that simplicity about it.

>>1) A Quick Reference

> I haven't used anything exotic (or even non-trivial) but it seems to me that 
> the API is already so simple that there isn't really a need for a quick 
> reference.

Well, you need some source of information other than the OCaml manual. 
To give just one example, if you want to do anything serious with 
Listbox widgets, you need to know the Listbox.index type, which isn't 
described in the manual.

Now, I have lately realized that you can explore LablTk with 
ocamlbrowser, so a reference doc isn't strictly necessary. But you could 
say the same about any OCaml module ... anyway, the document mostly 
exists, and some people may find it more convenient/pleasant to use a 
Web page or a printed document.

>>2) A Book

> I think labltk is too specific to be commercially viable.

Specific in what sense? And do you mean LablTk as a tool, or as a book 

> Also, unless I've 
> missed some hidden complexities in Tk programming, I think you'd have a job 
> filling enough pages to call the result a book.

Ever used the Canvas or Text widgets? There's a lot going on there. 
Besides, there are several mainstream (i.e. published by major tech 
publishers and available in any well-stocked bookstore) books about Tk 
programming (including at least Tcl/Tk, Perl/Tk and Tkinter). They've 
mostly been available for several years, so there must be some market 
for them.

Of course--and as an author/publisher, I'm sure you know this--the 
questions of what to write about, and how and how much, depend a great 
deal on the audience.

I can tell you that when I read _Effective Tcl/Tk Programming_ in about 
'98, when my GUI-coding experience was limited to a few toy apps in 
Visual Basic, I found it tremendously useful, with its in-depth 
explanation and extended examples of the more complex widgets, geometry 
managers, and the event handling mechanism. Properly described, it was a 
book about GUI programming *with* Tk, rather than strictly about Tk itself.

Maybe today's OCamlers are by and large beyond needing that sort of 
book. But it's kind of self-defeating to take for granted that the 
status quo will continue. I'm inclined to think that as OCaml gains in 
popularity--as it is certainly doing--there will be more people who need 
more hand-holding. Which doesn't necessarily mean there's much of market 
for a book such as I've proposed, just that I see some reason to hope.

> However, I would be very interested in a book that described how to write GUIs 
> using OCaml.

That might indeed be a good thing. I don't think, in my current state of 
knowledge, I'm the one to write it.

> As I'm the author of the only existing self-published book on OCaml, you may 
> be interested to know that it is doing well (~500UKP per month for 6 months 
> so far).

Well, at 85 quid a pop, I should think so (what is that in US money, 
about $120?)! But you're targeting an audience that has significant 
institutional support. I doubt very much that any and all OCaml books 
can be sold for that kind of money.

>>3) A Community-based Modernization Project

> I think it would be more constructive to create a decent cross-platform GUI 
> library from the ground up for FPLs/OCaml.

Great idea! But it sounds to me like the kind of thing that will never 
get finished.

> This wouldn't need to be anything 
> fancy, just easy access to the simplest GUI elements to start with.

What kind of apps do you envision writing with only the simplest elements?

> I'd like to see GUIs described by purely functional data structures. I'm
> still factoring my current code so I'll let you know what I come up with.
> Also, despite GUI code being a pedagogical example for OO, I'm not yet
> convinced that OO adds anything useful.

Agreed. Once I too was among the benighted souls, those who worship the 
false god of OO. But then I saw the functional light, and I was saved! 
Amen, brother!

Thanks for the comments. Lots of good food for thought there.

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1

If you know of a better way, please let me know.

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