Previous week Up Next week


Here is the latest Caml Weekly News, for the week of 18 October to 01 November, 2005.

Sorry for not sending a CWN last week: I was in vacations with a very slow internet connection.

  1. GUI Builder for windows OS.
  2. FastCGI
  3. Relating parts of ML and Haskell
  4. creal 0.7
  5. OCaml-intensive summer internship at trading firm
  6. Windows, Godi, Findlib and all that
  7. LablGtk 2.6.0 and LablGL 1.02
  8. Objective Caml 3.09 released
  9. Updates for O'Caml 3.09
  10. O'Caml 3.09 and GODI
  11. Makefile for wxcaml on Windows using Microsoft tools
  12. Question about polymorphic variants
  13. Ocaml for Experienced Programmers
  14. Findlib 1.1 released

GUI Builder for windows OS.


Mark Samir asked:
I want to  implement  a  GUI for  my program.  Provided for rapid development, 
I need to a GUI builder. MLGlade and Zoggy are two popular GUI builders. Both
of them are intended for  Linux  OS but I develop my program in Windows OS. I
tried to compile source code of those tools but I could not do that. Because 
There is  need to  utilities such as  ./configure and  autoconfig that are not
in Windows OS.  
Does any friend know a GUI builder for Windows OS.?
Matthew Hannigan answered:
You might try gazpacho; it's like glade but better.

There is a windows installer for it.
Jacques Garrigue also answered:
A possible option (as suggested by someone else) would be to use glade
or gazpacho. But you would then need to use the lablgtk binding to
libglade (the runtime part to use a GUI description). It can be
compiled on windows, and it is included in the source distribution,
but not in the binary distribution. You might try to compile it



David Baelde asked:
There seems to be many (Fast)CGI implementations in OCaml around:
XCaml, CamlGI, caml-fastcgi, OCamlNet... But many seem dead, or won't
even build. I'm wondering which one should I choose, and I'd be glad
to find some examples or a good doc to start with. Any experiences ? I
hope the OCaml FastCGI community hasn't give up.
Jonathan Bryant answered:
I'm currently working on one for an in-house project I'm doing.  I can
post the source if you would like.  Currently, request and response
handling are done, cookies are done, and sessions just need a little
tweak to get them working.  The persistance of sessions works (rather
nicely I might add, I just need to rewrite them to use cookies, that is
unless someone knows off hand if there is an attribute in the HTTP
headers to start a HTTP session within the web server.  There are also
URL en/de-code functions...

The library is in pure OCaml and is (almost) purely functional.  No
libraries external to the main OCaml distribution are required.
Maxence Guesdon also answered:
You may have a look at Ocgi:

The library includes functions to retrieve arguments and environment
values. Functors can be used to create "models" of cgi handling sessions
with cookie or in parameters. A lot of useful functions are included to
send mails, escaping strings, building HTML structures (list in tables, ...).
At last, a template tool is included to make the use of forms easier 
(using generated record types). This tool can also be used to create
templates for html code or even mail bodies (or any text, in fact).
Alessandro Baretta also answered:
We have more or less given up. The AS/Xcaml connects to the HTTP 
client over any Netcgi compatible connector. Baretta SRL has 
recently commissioned the development of a full HTTP/1.1 
implementation to Gerd Stolpmann within the framework of the 
Ocamlnet/Netcgi, thus eliminating the need for fastcgi.
Eric Stokes also answered:
The fastcgi support in Ocamlnet is mature and quite stable, and it is
supported in wdialog applications.

Relating parts of ML and Haskell


Jacques Carette said:
[I am posting this message to caml-list on behalf of Oleg, who is 
not a subscriber.  I asked him to compose this, as the messages he 
points to are just as relevant to Caml programmers as to Haskell 
programmers to understand 'the other side' -- Jacques]

Correspondence between ML structures and functors and Haskell type
classes is described in a message:

Applicative translucent functors in Haskell

The message is based on a draft paper by Chung-chieh Shan, who showed
the complete translation of Dreyer-Crary-Harper module language into
System Fw. The message attempted to interpret some of Shan's results
in idiomatic Haskell with the full use of type classes. That message
is both Haskell and OCaml literate code. It can be loaded in GHCi or
Hugs -98, and (after some sed filtering) into OCaml.

The upshot of the correspondence between type classes and ML modules
is as follows:

  ML signatures correspond to Haskell type classes, and their
  implementations to the instances

  Abstract types in ML correspond to either uninstantiated or
  explicitly quantified type variables in Haskell

  Type sharing is expressed via type variable name sharing

  Functor (signatures or structures) correspond to Haskell (class
  declarations or instances) with type class constraints

  The argument of functors is expressed via types, with additional labels
  when needed for finer differentiation

  Functor applications are done by instance selection based on types
  at hand plus the additional labels

  OCaml signature attribution operation -- casting the module or
  the result of the functor into a desired signature and hiding
  the extras -- sometimes involves additional tagging/untagging tricks
  (cf. SetESet). This tagging, done via newtype, is syntactic only and
  has no run-time  effect.

  Hiding of information (`sealing', in ML-speak) is done by
  existential quantification. To gain applicativity, we quantify over
  a higher-ranked type variable (Skolem function proper).

A follow-up message (written together with Chung-chieh Shan)

Applicative translucent functors in Haskell

is devoted to the problem of sharing constraints and exponential
explosion and brittleness of ``sharing by construction'' (or
positional sharing). The message translates Harper and Pierce's
example into Haskell, using only the most common Haskell extensions to
give type-equality constraints by name and avoid an exponential
blowup.  This exercise suggests that, while type-level records may be
convenient to have in Haskell, they may not be strictly necessary to
express sharing by specification.  As shown below, we can indeed refer
to type parameters "by name", taking advantage of the ability of a
Haskell compiler to unify type expressions and bind type variables.
Our technique may be generalizable to encode all sharing by
specification.  We hope this message helps clarify the difference
between the two sharing styles, and relate the ML and Haskell

creal 0.7


Jean-Christophe Filliatre announced:
I've recently translated Hans Boehm's exact real arithmetic library from
Java to ocaml (see

It is bundled with another exact real arithmetic implementation, and
the two have almost the same interface, so that it is easy to switch
from one to the other.

The library includes a small (exact!) calculator.

You can download the library from

OCaml-intensive summer internship at trading firm


Yaron Minsky announced:
Jane Street Capital ( is a proprietary
trading company located in Manhattan.  We're looking for students
interested in internships for the summer of 2006.

Jane Street is an open and informal environment (you can wear shorts
and a t-shirt to the office), and the work is technically challenging,
including systems programming, machine learning, statistical analysis,
parallel processing, and anything that crosses our path that looks
useful.  One unusual attraction of the job is that the large majority of
our programming is done in OCaml.  Here's what we're looking for from

 - A commitment to the practical. Both development and research are
   tightly integrated with our trading operation, and we work very
   hard to keep our work relevant. One of the big attractions of the
   job is the opportunity to apply serious ideas to real-world

 - Great communication skills. We need people who can explain
   things clearly and cogently, who can read dense academic papers
   and write clear documentation.

 - Strong programming skills.  Most of our programming is
   in OCaml, so being a solid Caml hacker is a big plus.  Extra points
   for deep knowledge of OCaml internals and experience wrapping
   thorny libraries.  But we're also interested in great programmers
   who we are convinced will be able to pick up OCaml quickly, so
   anyone with high-level of proficiency with functional languages
   would be a good match.

 - Top-notch mathematical and analytic skills.  We want people who
   can solve difficult technical problems, and think clearly and
   mathematically about all sorts of problems.

 - Strong Unix/Linux skills --- We're looking for someone who knows
   their way around the standard Unix tools, can write makefiles,
   shell scripts, etc.  We're also very interested in people with
   serious systems administration and architecture experience.

Summer interns are paid quite well, and we can help out with housing
costs if you don't live nearby. If you're interested, please send a
cover-letter and resume to:

Windows, Godi, Findlib and all that


Yaron Minsky asked and Gerd Stolpmann answered:
> I've been trying to figure out what the state of OCaml on Windows is,
> and I'm wondering if anyone on the list can help me out.  I've been
> trying to get godi, findlib and integration with MS excel going at the
> same time.  The problem is that these approaches appear at first
> glance to be incompatible.  Here are the dependencies that I know
> about.
> 1. Godi works only on cygwin, and isn't supported even with mingw.

Porting Godi to mingw has become quite important. It is now
top-priority, but apparently not simple. A lot of preliminary work has
already been done, especially getting rid of all the C helper programs
(this is not yet released, though), so the port has only to deal with
O'Caml programs and shell scripts.

However, there is no solution in the short term. I expect the release of
the mingw port in summer 2006.

> 2. Findlib works with cygwin -or- mingw, but doesn't work with the native build

This should be doable. Findlib is a pure O'Caml program, and the system
side is very simple. Although I don't know what is going wrong, I
suspect the calling conventions of external programs are different.
Findlib executes ocamlc as subprocess.

> 3. The real windows support (win32 libraries and ocamole, the latter
> of which provides Excel integration), only work with the native build.

I have actually no idea whether this can be ported to mingw, or whether
one can at least link mingw- and msvc-generated libraries together. The
mingw web site says this is possible.


> Does anyone have a sense of whether any of these issues can be
> overcome?  How much work, for instance, would it take to get findlib
> working on the native win32 build?  How about Godi?  How about getting
> theings like ocamole working with the mingw build?

LablGtk 2.6.0 and LablGL 1.02

Jacques Garrigue announced:
After more than one year, there are two new releases for LablGtk2 and
LablGL, respectively interfaces for the Gtk2 GUI library, and the
OpenGL 3D library.

You can find them at:

There are also (semi-)binary releases for windows, that can be
used directly with the OCaml MSVC or mingw ports. ocamlopt is now
supported in binary releases.

For lablgtk, changes are two numerous to write, and include support
for some new 2.6 widgets, and better thread support.

For lablGL, here is the complete list since 1.01:
* fix GlMat.mult_transpose
* correct GlTex.image2d border bug
* add glGetError
* add index_logic_op and color_logic_op

Many people have contributed with bug reports and fixes, and most of
the improvements in lablgtk are by Olivier Andrieu.

(Note that if you got these releases before this annoucement, you may
have jumped the gun: the files were modified several times in the last
24 hours.)

Objective Caml 3.09 released


Xavier Leroy announced:
It is my pleasure to announce the release of Objective Caml version 3.09.0,
the "Halloween" release.  Be very afraid :)

Novelties in this release include:

- Introduction of private row types, for abstracting the row in object
  and variant types.  (See Jacques Garrigue's paper, " Private rows:
  abstracting the unnamed", available from

- New warnings for variables locally bound and never used.

- A revised implementation of "ocamlopt -pack" that does not depend
  on GNU binutils and should work on all platforms supported by ocamlopt.
  The downside is that object files intended for later packing should
  be compiled with an appropriate "-for-pack" option.

Plus the usual assortment of corrections and small improvements listed

The release can be found at
and is currently available as source code and Windows binaries.
More binaries will be added in the coming weeks.


- Xavier Leroy, for the OCaml development team


Objective Caml 3.09.0:

(Changes that can break existing programs are marked with a "*"  )

Language features:
- Introduction of private row types, for abstracting the row in object
  and variant types.

Type checking:
- Polymorphic variants with at most one constructor [< `A of t] are no
  longer systematically promoted to the exact type [`A of t]. This was
  more confusing than useful, and created problems with private row

Both compilers:
- Added warnings 'Y' and 'Z' for local variables that are bound but
  never used.
- Added warning for some uses non-returning functions (e.g. raise), when
they are
  passed extra arguments, or followed by extra statements.
- Pattern matching: more prudent compilation in case of guards; fixed PR#3780.
- Compilation of classes: reduction in size of generated code.
- Compilation of "module rec" definitions: fixed a bad interaction with
  structure coercion (to a more restrictive signature).

Native-code compiler (ocamlopt):
* Revised implementation of the -pack option (packing of several compilation
  units into one).  The .cmx files that are to be packed with
  "ocamlopt -pack -o P.cmx" must be compiled with "ocamlopt -for-pack P".
  In exchange for this additional constraint, ocamlopt -pack is now
  available on all platforms (no need for binutils).
* Fixed wrong evaluation order for arguments to certain inlined functions.
- Modified code generation for "let rec ... and ..." to reduce compilation
  time (which was quadratic in the number of mutually-recursive functions).
- x86 port: support tail-calls for functions with up to 21 arguments.
- AMD64 port, Linux: recover from system stack overflow.
- Sparc port: more portable handling of out-of-bound conditions
  on systems other than Solaris.

Standard library:
- Pervasives: faster implementation of close_in, close_out.
  set_binary_mode_{out,in} now working correctly under Cygwin.
- Printf: better handling of partial applications of the printf functions.
- Scanf: new function sscanf_format to read a format from a
  string. The type of the resulting format is dynamically checked and
  should be the type of the template format which is the second argument.
- Scanf: no more spurious lookahead attempt when the end of file condition
  is set and a correct token has already been read and could be returned.

Other libraries:
- System threads library: added Thread.sigmask; fixed race condition
  in signal handling.
- Bigarray library: fixed bug in Array3.of_array.
- Unix library: use canonical signal numbers in results of Unix.wait*;
  hardened Unix.establish_server against EINTR errors.

Run-time system:
- Support platforms where sizeof(void *) = 8 and sizeof(long) = 4.
- Improved and cleaned up implementation of signal handling.

Replay debugger:
- Improved handling of locations in source code.

- extensible {foo } syntax
- user can give .txt files on the command line, containing ocamldoc formatted
  text, to be able to include bigger texts out of source files
- -o option is now used by the html generator to indicate the prefix
  of generated index files (to avoid conflict when a Index module exists
  on case-insensitive file systems).

- Configuration information is installed in `ocamlc -where`/Makefile.config
  and can be used by client Makefiles or shell scripts.
Damien Doligez added:
> Replay debugger:
> - Improved handling of locations in source code.

Please note that this entails an incompatible change to the ocamldebug-emacs
interface, so you will have to reinstall the emacs mode files when you switch
to 3.09.0.
Aleksey Nogin said:
I have built binary and source RPMs for Fedora Core 2, 3 and 4, Red Hat 
Enterprise Linux 3 and 4, and Mandrake 10.1. Get them from
Aleksey Nogin said and Damien Doligez answered:
> AFAIU, there are two warnings - "Y" for variables bound with let  
> and "Z" for variables bound by pattern matching. By default, Y is  
> enabled and Z is not.

The rules for Y are a bit complex.  They are designed to match our style
of programming, where we sometimes document patterns by giving names to
all the arguments, even if they are unused.

Y will warn you on all variables bound with an "as" (in a let-in or a
match).  For the other variables of a let-in pattern, it will warn you
only if all of them are unused.  Examples:

   let (x, y) = (0, 0) in 0;;            (* warning on x and y *)
   let (x, y) = (0, 0) in x;;            (* no warning *)

   let (x, y) as z = (0, 0) in (x, y);;  (* warning on z *)
   match 1 with _ as z -> 1;;            (* warning on z *)

Variables whose names start with _ are always ignored for the  
purposes of
these warnings (both Y and Z):

   let (_x, y) = (0, 0) in 0;;           (* warning on y *)
   let (_x, y) = (0, 0) in _x;;          (* warning on y *)

Z will warn you on all unused variables bound by "let-in" or "match",
except the ones that are (or would be) reported by Y.  Note that it  
make much sense to have Y disabled and Z enabled.

Pattern-matchings introduced by the "fun" and "function" keywords behave
like the ones that start with "match".

> Use "ocamlc -wA" to enable all the warnings.

That should be "ocamlc -w A" with a space.

Updates for O'Caml 3.09


Gerd Stolpmann announced:
I just released new versions of some libraries that work for O'Caml

- xstrp4 1.6
- PXP 1.1.96 (there also some minor bugfixes in it)
- WDialog 2.1.2

These all failed because of the loc to _loc change in camlp4. Tip: Use
the -loc argument of camlp4 to revert to the old name of this variable,
and you need not to change code. This also works for O'Caml 3.08.

See for download links etc.

O'Caml 3.09 and GODI


Gerd Stolpmann said:
GODI had good success in the transition to 3.09. Although not yet
released, there is already an almost working GODI for 3.09. Especially
useful for developers who want to check their software for 3.09.

To get this release, download the bootstrap archive:

Call the bootstrap script with the additional argument --section 3.09,

./bootstrap --section 3.09 --prefix /opt/godi-3.09

then continue as explained in README.

Not all libraries are already available, but most are.

Makefile for wxcaml on Windows using Microsoft tools


Jeremy O'Donoghue announced:
I've been working to get wxCaml to compile and run using the Microsoft tools.

This seems only to require some small changes to the Makefile, and I
attach a (rather messy) modified version.

The user will need to change

PWD (wxCaml build directory)
OCAMLDIR (Ocaml installation directory)
WXWINDOWS (wxWidgets installation directory)
WXHASKELL (wxHaskell build directory)
VCLIBDIR (Visual Studio library directory)

to reflect the appropriate values for their build environment.

I have added support for both bytecode and native code versions of the
wxcaml library. Both version compile and run the test application, but
both generate a memory leak indication on exit. I will look into this
when time allows.

I can confirm that the wxcaml tarball worked successfully with up to
date versions of wxWidgets and wxHaskell - wxWidgets 2.6.2 and
wxHaskell 0.9.4 in this case.

There appears to be no license file with the wxCaml tarball. I have
licensed the Makefile attached under the wxWindows library license, as
it seems most appropriate (wxWindows and wxHaskell, the main
components use this license).

However, I will be happy to change to any recognised Open Source
license if SooHyoung Oh, the wxCaml author, requests - this
contributon is trivial.

I would prefer that there is some clarity in the licensing of wxCaml
in any case - it is really impossible to do anything more than play
with it until this is done.

(Editor's note: see the archive link for the attachment.)

Question about polymorphic variants


Xavier Clerc asked and Jacques Garrigue answered:
> I have a question concerning polymorphic variants and type inference.
> Formulating my question from the example of section 4.2 in the ocaml  
> manual (version 3.08), I define a function f:
> let f = function
> | `On -> 1
> | `Off -> 0
> which is inferred as: val f : [< `Off | `On ] -> int
> Then, I use this function in the following expression :
> f
> which is in turn inferred as: _[< `Off | `On ] list -> int list
> My question is about the meaning of the leading underscore in the  
> inferred type (given that I understand the meaning of the underscore  
> in an expression such as "Stack.create ()" that is inferred as: '_a  
> Stack.t).

This is exactly the same meaning: [< `Off | `On] has some form of
flexibility left, which you might see as a type variable, and as such
it obeys the same rules as type variables.

An example close to the above one would be:

# (fun (x,y) -> x+1);;
- : (int * '_a) list -> int list = <fun>

Now you might wonder why '_a cannot be polymorphic in the above
example. That is, could there really be a definition of such
that the polymorphic type would be dangerous (causing a segmentation
fault for instance.) The answer is yes, with a counter-example using
the difference in representation between normal arrays and float
Actually, since this counter-example wouldn't apply to the above case
of polymorphic variants, this would probably be safe to leave the
polymorphic variant type as polymorphic...
Xavier Clerc then asked and Jacques Garrigue answered:
> > The answer is yes, with a counter-example using
> > the difference in representation between normal arrays and float
> > arrays.
> In this counter-example, it is not clear to me whether the possible  
> problem is type-related or runtime-related. I mean, would this  
> counter-example still hold if arrays were both boxed or both unboxed ?

No, the difference in representation is essential here.

But at the type level, this problem can be expressed a bit
differently: whether it is safe to add a "top" to the type system,
allowing any type to be coerced to it. While some languages might
allow that, there is no fundamental reason it should be so (an this is
indeed not the case in ocaml.)
If we cannot assume the existence of such a type, then we cannot prove
that polymorphism in this case would be safe.

Note that the property used by the relaxed value restriction, that
one can always add safely a "bottom" to the type system, is much more
reasonable, as it's only assumption is that the representation of
values depend only on (typed) values, not on types alone. This is
valid in ocaml, but some other language might still break it.
> > Actually, since this counter-example wouldn't apply to the above case
> > of polymorphic variants, this would probably be safe to leave the
> > polymorphic variant type as polymorphic...
> Does this mean that inferring "[< `Off | `On] list -> int list" would  
> be perfectly safe in the example above ?
> (by saying so, I am not pleading for any compiler change, I am just  
> trying to organize my thoughts)

I believe so, but I don't have a proof ready for that.
One way to do it would be to prove that any instance of [< `Off | `On]
is a subtype of [ `Off | `On ], which sounds trivial in this case.
So I would say this should apply to both [< ... ] types (closed
polymorphic variants, including the [< ... > ...] case) and <...; ..>
types (extensible object types.) But not to [> ...] types (open
polymorphic variants.)
Xavier Clerc then asked and Jacques Garrigue answered:
> I must admit that I don't grasp the link between the existence of a  
> "top" type and the inference of a polymorphic type in the given  
> examples. I would expect inference of 'a array in arrays example and  
> 'a in " (fun (x, y) -> x + 1)" and don't see in what  
> circumstances such types would not be safe (modulo the array  
> representation issue discussed above).
> Could you exhibit an example where such inference would be false/ 
> unsafe ?

Here is the concrete counter-example for top. It uses the (unsafe) Obj
module to produce a segmentation fault, but through an operation that
most people would suppose to be safe.

# let l = [| Obj.repr 1.0 |];;
val l : Obj.t array = [|<abstr>|]
# l.(0) <- Obj.repr 1;;
Segmentation fault

How does it relate to top? Essentially, every ocaml value is
represented by a fixed-size word, either an integer or a
pointer to a boxed representation. All Obj.repr does is return its
argument with type Obj.t, the type of all ocaml values, which we can
see as another name for top. So one could assume that Obj.repr is a 
coercion to top. The trouble, as you can see here, is that Obj.t
itself appears to be unsafe. Here l is created as an array, initialized
with a float. This means that internally it will get a float array
representation. Now when we try to put an integer into it, it will try
to use the float array assignment operation, which attempts to
dereference the argument to get its float representation. This
naturally results in a segmentation fault.
As a result we can see here that one assumption in the above must be
false. Since the definition of Obj.repr is exactly that of a coercion
to top, this must mean that adding top to the type system is unsound.

Now, how can I use it to find a problem in the following typing?

  # let g = map (fun x -> 1) ;;
  val g : 'a list -> int list

I first need a "bad" implementation of map, which uses arrays behind the
  let map f =
    let arr = ref [||] in
    fun l ->
        (fun x -> if !arr = [||] then arr := [|x|] else !arr.(0) <- x) l; f l
  val map : ('a -> 'b) -> 'a list -> 'b list

This function just keeps the last list element in a one-element array,
but does nothing with it, so it is exactly equivalent to
Actually, it cannot do anything bad, as the type system protects me:

  # let g = map (fun x -> 1) ;;
  val g : '_a list -> int list

But now let's assume that Obj.t is really top, and Obj.repr a safe

  # let g' l = g ( Obj.repr l) ;;
  val g' : 'a list -> int list

This time we've got the right type.
Let's use it:

  # g' [1.0];;
  - : int list = [1]
  # g' [1];;
  Segmentation fault

> Well, the only way to get rid of the leading underscore in inferred  
> type is to "use" all the tags of the type (that is "converge" toward  
> the upper bound of the variant), as in the following toplevel session :
> # let f = function
>    | `Off -> 0
>    | `On -> 1;;
> val f : [< `Off | `On ] -> int = <fun>
> # let mf = f;;
> val mf : _[< `Off | `On ] list -> int list = <fun>
> # mf [`On];;
> - : int list = [1]
> # mf;;
> - : _[< `Off | `On > `On ] list -> int list = <fun>
> # mf [`Off];;
> - : int list = [0]
> # mf;;
> - : [ `Off | `On ] list -> int list = <fun>
> Does this mean that [`Off | `On] list -> int list could be inferred  
> for mf as one can pass [`Off | `On] where [< `Off | `On] is waited  
> (as [`tag1 | `tag2 ... | `tagn] is shorthand for [< tag1 | `tag2 ...  
> | `tagn > tag1 | `tag2 ... | `tagn]).

Certainly, as [`Off|`On] is an instance of [< `Off|`On].
But [`Off] or [`On] are other possible instances of [< `Off|`On], so
the latter is more general.
By the way, you can get your intended type directly with a type
  # let mf = (f : [`Off|`On] -> _);;
  val mf : [ `Off | `On ] list -> int list = <fun>

Ocaml for Experienced Programmers


Tato Thetza said and Brian Hurt answered:
> sorry I meant
> Ocaml for Experienced Programmers:

This link wasn't really intended for public consumption, so it's been 
removed.  I forgot to put it in the robots.txt file, so it got out.  My 
apologies for the inconvience.

The good news is that the Pragmatic Programmers have expressed interest in 
publishing the book.  They have a "beta book" deal:

I'll see how quickly I can get the book into the program.  I probably need 
to finish writting it first, however.  This is, however, my new job.

Thanks for the good feedback, however.
Yaron Minsky added:
For what it's worth, I've looked at the book too, and found it to be
the best thing of its kind out there.  When it's released, we will
definitely buy a few copies.

Findlib 1.1 released


Gerd Stolpmann announced:
I just managed to get a new version of findlib released. It works now
perfectly (hopefully) with O'Caml 3.09, and you can use all 3.09
command-line arguments.

There are also a number of improvements triggered by discussions:

- The check whether a package is already installed has been
  relaxed. In particular, the destination directory may already
  exist. It is, however, still not allowed to overwrite files
  when packages are installed.

- One can declare files as optional when installing a package.

- One can patch the META file when installing a package.
  Currently, there are three types of patches: The version
  string can be overwritten. Subpackages can be removed.
  Archive references can be removed when the corresponding
  files do not exist.

  Especially the latter is still experimental because it is
  unclear whether it improves anything. The resulting META
  file may be broken.

- There is an exists_if variable in META. The idea is to
  disable subpackages when a certain file does not exist,

  package "foo" (
    exists_if = "foo.cma"
    archive(byte) = "foo.cma"

  If this package is only optionally built, the exists_if 
  variable may hide the package.

- The may be a directory with findlib configuration snippets.
  If you have findlib.conf.d and put *.conf files into it,
  these files will be read.

  This is to be used in conjunction with the following...

- It is now possible to drive patched compilers. Assume you 
  have ocamlc-mypatch which is binary compatible with ocamlc.
  It is now possible to use the patched compiler instead of
  the regular one with ocamlfind.

  First, you need to define the patched toolchain. Use this
  in findlib.conf:

  ocamlc(mypatch) = "ocamlc-mypatch"

  (This works with all findlib.conf parameters.)
  Second, you can select this toolchain by:

  ocamlfind -toolchain mypatch ocamlc ...

  Note that the -toolchain argument is before the command

  One should put the toolchain definition into its own 
  mypatch.conf file for easier installation.

There are also a number of bugfixes.

for documentation and links. See
for downloads.

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}$'?'&lt;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