Hello,

Here is the latest Caml Weekly News, for the week of 29 July to 05 August, 
2003.

1) lablgtk status on Mac OS X
2) GODI available for download
3) ocaml courses
4) GD4O

==============================================================================
1) lablgtk status on Mac OS X
------------------------------------------------------------------------------
** Stephane Legrand asked and Jed Davis answered:

> Does anyone know the current status of lablgtk/lablgtk2 on Mac OS X ?
>
> According to Google, it seems that :
>
> - lablgtk (for gtk+-1.2.x) works because, for instance, mlDonkey seems
>   to work including the GTK GUI.

I got the file synchronizer Unison to work with lablgtk on OS X, but
only with X11 gtk.  There's a port of gtk to the native graphics
system (http://gtk-osx.sf.net/), but it had some problems: lablgtk has
a method for extracting the X11 window id from the gtk window struct,
which I had to stub out so lablgtk would build, but even then I just
got a lot of gtk error messages and a crashed program for trying to
use Unison with it.  (At that point I gave up and used the X11 gtk
rather than investigating further.)

> - lablgtk2 (for gtk+-2.x.x) : ??
>   I didn't find anything about this. GTK+-2 and OCaml are available on
>   Mac OS X but does anyone has ever tried to compile/use lablgtk2 ?

Well, it compiles, but I haven't tried using it yet...

==============================================================================
2) GODI available for download
------------------------------------------------------------------------------
** Gerd Stolpmann announced:

In the past days I have worked on GODI, an experimental source-based
O'Caml distribution, and I think it is now worth a try.

You can get the current bootstrap tarball here:

http://www.ocaml-programming.de/packages/godi-bootstrap-20030730.tar.gz

Currently, GODI is based on 3.06, but I will switch to 3.07beta the next
days (and drop a message, if so).

It has been tested on Linux and Solaris.

Read the README file, it contains further instructions (and is currently
the only source of documentation).

Gerd

------------------------------------------------------------
README
------------------------------------------------------------

GODI is an experimental distribution of the Objective Caml language
as packages that can be automatically built from their sources. GODI
does not include pre-compiled binaries, but it is possible to create
them, even in packaged form.

GODI is derived from the NetBSD pkgsrc system (which is derived from
the FreeBSD port system), and has a similar way of dealing with
sources, although not everything is identical.

Basically, GODI is a framework to download, compile, install, and
package O'Caml software. This software is not included in GODI, but
GODI knows from which Internet sites it can be downloaded. To do so,
GODI provides small archives with build instructions, the build.tgz
archives. These instructions (basically Makefiles) are dynamically
added to the GODI framework, and extend it with the information needed
to deal with a certain piece of software.

After the software has been installed, it is always archived as
so-called binary packages. The binary packages can be easily
transferred to other computers with the same operating system, where
they can be added to the local GODI installations without having to
rebuild them again.

GODI knows about software dependencies, and automatically builds
prerequisites first. Furthermore, GODI can upgrade hierarchies of
dependent libraries by rebuilding the libraries in the right order.

...

** Fred Yankowski said and Gerd Stolpmann answered:

> I gave it a try on a Linux 2.4.20 / Debian 3.0 machine, where (as far
> as I can recall) I have never installed ocaml.  Although I have lots
> of experience with Debian package management, I've never BSD-style
> package management tooks before.  So here's what ensued:

Thank you very much. I need more such user reports to make GODI as easy
and as reliable as possible.

> The godi-ocaml package built and installed easily.
>
> To build godi-ocaml-graphics I had to first install the Debian
> xdev-libs package to get the needed Xlib.h and Xutil.h files.  No big
> deal.

Ok, I will add a hint to the README.

> Building godi-ocaml-labltk was a minor pain.  I had to install the
> Debian tcl8.3-dev and tk8.3-dev packages to get the tcl.h and tk.h
> files.  But building godi-ocaml-labtl would still fail to find those
> headers.  I saw the note in the main README about "So if your tcl/tk
> libraries are not found, you have to fix the problem in
> godi-ocaml-src" and I eventually saw the note in the DESCR file for
> godi-ocaml-src saying that tcl/tk should be installed first.

The reason for this strange dependency is that the O'Caml sources
contain both the base system and the labltk code, but that I wanted to
split it up for GODI. Not for everybody labltk is important, so it 
should be possible to install only the base system without labltk.    
However, because the base system and labltk are configured by the same  
script, the question arose where to put this common configuration step.
This is the idea of godi-ocaml-src, it configures all of the O'Caml
system and saves the configuration such that the other packages
(godi-ocaml, godi-ocaml-graphics, and godi-ocaml-labltk) can find it and
use it.

Maybe I should rename it to godi-ocaml-config to make this role clearer.

> So then it was a bit of a mystery, how to rebuild godi-ocaml-src and
> whatever depends on it.  Nothing much happened when I ran 'godi_build
> godi-ocaml-src' again,

Because it thinks it is up to date. godi_build -force godi-ocaml-src 
would do it.

Again a useful addition to the README file.

> so I ran 'godi_delete godi-ocaml-src' and tried
> again, whereupon it rebuilt from source and finished OK.

So you were able to help yourself.

> Now, presumably, godi-caml and godi-caml-graphics need to be rebuilt
> as well.  Doing "godi_build godi-ocaml" reports that the package is
> already up-to-date.  Doing "godi_delete godi-ocaml" fails because the
> godi-ocaml-graphics package depends on it, so I did "godi_delete -f
> godi-ocaml" to force the delete.

The -f option allows you to break the system, and it is normally not a
good idea. The -r option would have been right, because it deletes the
dependent packages, too.

> That worked, mostly, but gave some
> warnings about directories that could not be removed because they aren't
> empty, because of files still there for godi-ocaml-graphics.  (OK,
> that wasn't my brightest move, but I thought using -f would
> recursively remove any packages that depend on godi-ocaml -- and that
> did not happen).

Yes, -r would do that.

> Run "godi_delete godi-ocaml-graphics".  Now doing
> "godi_build godi-ocaml" rebuilds from source ... but it fails near the
> end because a lib/ocaml/std-lib/ directory already exists.  Remove
> that and try again; now the build finishes OK.

This is one of the problems with GODI: you normally cannot install over
old files, because the installation routines are not intelligent enough.

> Build godi-ocaml-graphics again; OK.  And now building
> godi-ocaml-labltk works just fine.  Minimal testing suggests that the
> executables are working well.  ocamlbrowser runs OK.
>
> So, that's how it went for someone who knows Linux system admin well,
> but has no experience with BSD packaging tools and almost no
> experience with ocaml distribution/packaging.  The "GODI" tools work
> well, but I need a bit more information about their theory of
> operation to understand how to recover when things go wrong.

Well, the documentation is not complete enough. In principle, it works
the same way as the NetBSD tools; maybe I should add an example how to
do the installation steps manually, and add a pointer to the NetBSD
docs.

>  I'd also
> like to understand the role of the godi-ocaml-src package better, and
> what sort of implicit dependencies other GODI ocaml packages have on
> it.

godi-ocaml-src unpacks the O'Caml sources, configures them, and creates
a tar.gz archive of them, so other packages can extract the already
configured source tree from it.

> Overall, it's an impressive first cut at an easy to use package
> management system for Ocaml.

I hope the remaining difficulties can be resolved, so it would be easy
for everybody.

** Jacques Garrigue said and Gerd Stolpmann answered:

> I have two questions concerning godi itself:
>  - is it a good idea to use a small tgz by package?
>    we might en up with lots of them!
>    personnally I would rather go for updating directly from a CVS
>    repository, and eventually distribute a big tgz containing all 
>    instruction corresponding to a specific version of ocaml.   
>    but you may have your reasons.

CVS is a good tool to get the current development version, i.e. for the
unstable branch (when it exists). For the casual user, it is too random
which version is the current one. There are further disadvantages, e.g.
you cannot use CVS behind firewalls (at least like firewalls that are
typically used in company LANs).

On the other hand, a big tgz has the disadvantage that you cannot "pin"
certain versions of libraries, so that they are excluded from updates. 

The current solution wants to be a compromise that works for everybody.
That the checks are so slow is caused by bmake calls that find out the
version on the disk; this can be improved, e.g. by comparing the $Id$
tags once they are in place.

By the way, I am not using CVS to manage the sources but subversion.
There are several reasons: (1) I want to check it out, (2) it has
features that can be very helpful to track foreign sources, and (3) it  
works even over HTTP.

>  - what about windows? Do you think it is reasonable to have a binary
>    distribution of godi with all the necessary commands (not depending
>    on cygwin)? Or a distribution on top of cygwin.
>    Not depending on cygwin would be a big plus for occasional users.

For a binary distribution we basically need the package tools, and some
scripts around them. I do not know whether there are Windows ports. Of
course, these tools are typical Unix programs, i.e. lots of pipes,
forks, etc., so that a MinGW port would be some work (but certainly
doable).

The scripts around these tools could be written in O'Caml itself, as we
do not have the bootstrap problem for a binary distribution. (As a last
resort, we could also rewrite the package tools in O'Caml, which is not
too hard.)

> > Next, building godi-ocaml and godi-ocaml-labltk. godi-ocaml went fine,
> > but godi-ocaml-labltk failed, because it needs some configuration
> > options (I see no way to pass them). Since I'm used to BSD packages, I
> > go to the godi-ocaml-labltk/work directory, and reconfigure by hand.
>
> I realize now that this configuration problem is going to be very
> complicated. BSD packages are OS-oriented: they assume a closed world,
> where everything is controlled by the packaging system. So you don't
> need to tell them where something is on the system, they already know
> it.
>
> With godi, the situation is different. For instance, tcl/tk headers   
> may be in many places, maybe even several versions of them, and the
> user should be able to indicate where to find them. Same thing for
> camlimages, lablgl, lablgtk, etc...
> My feeling is that there has to be a way to give this information
> by hand the first time you install a package, and these parameters
> would be reused in following installations. When the package is
> installed as a dependency, this may require some interaction from the
> user.

In the current version of GODI, the godi.conf file contains these
configuration options. Of course, this is a non-interactive solution,
but I have added now hints that are printed on the screen just before
the build starts (and the user must confirm). So the user is now
reminded that there are such options, and where they can be found.

In the future, I can imagine that we have a labltk program that assists 
the user in configuring the system. This GUI would be the better   
solution for "camlimages, lablgl, lablgtk, etc...", but of course not 
for labltk itself.

I see only one way for labltk: implanting more knowledge about the
various operating systems, and more intelligence to find even unusual 
locations for tcl/tk.

There is not only the question of configuration options to find external
installations, but also the question which libraries one should better
include in GODI. Currently, I have only included GDBM (because an ndbm
implementation is necessary for a full O'Caml installation, and I wanted
to have something predictable), and PCRE (because PCRE4 is not yet
widely available, but the O'Caml bindings require it). Of course, the
question is where to draw the line. If we had a GUI for GODI, it could
even be justified to include tcl/tk if the user wishes so.

> Also, the possibility of finishing the work by hand must be left,
> otherwise recovering from simple configurations bugs can become  
> unwieldly.

This is also necessary for the developers. Currently, the whole make
infrastructure works like NetBSD's, and I am not going to change this.

> I'm afraid this is just one example of mismatch between an
> OS-oriented packager and a language-oriented multi-platform packager.

I hope there will not be more. I have already resolved several other
mismatches:

- The original scripts require root privileges for installation. Of course,
  we do not want that.

- The original package tools store the version conditions like
  "libraryXY>=3.5" in the binary packages. I have changed that to
  "libraryXY=3.5" because of OCaml's strict interface checksums.

- Some of the PLIST issues are resolved. There is a special
  PLIST.godi format that recognizes additional directives, so you
  can package whole directories, with filename globbing, and under
  a number of O'Caml-specific conditions.

- There can be several GODI installations on the same system (no
  conflict because there is only one /etc/mk.conf as in NetBSD)

Up to now, it was quite easy to change the build and packaging scripts
as needed (I guess there would be more trouble if I had used a closed
system like rpm).

> Another one is the use of makefiles internally and in packages. While
> makefiles are not intrinsically bad, they have one big default: they
> depend heavily on the behaviour of external commands on the system. If
> you have only platform this is not a problem: you just have to check
> once that this works, but if you must handle multiple platforms, it is
> very hard to be sure that the Makefile is portable.
> I don't know how CPAN handles that, but this is going to be painful.
> Using an ocaml only tool like ocamake may be an interesting option, at
> least for simple packages.

It is painful. I have already run into problems, e.g. /bin/sh on Solaris
is not even POSIX-compliant, and it starts subshells under much more
conditions than a standard shell. Fortunately, most of the tools are not
that problematic; an mkdir is an mkdir. And most of the O'Caml sources
come with Makefiles that have the same portability problems; in the long
run, I guess most of the bugs will occur in the upstream Makefiles.

(There is already such a problem in godi-wlex. The "patch" utility of
Solaris does not grok the wlex patch.)

In my opinion, the portability problem can only be _finally_ solved if
the upstream Makefiles are replaced by something better. Perl has its
Makefile.PL, which is a Perl script that writes the system-dependent
Makefile. However, Perl is not compiled, and the possible cases are
simpler to manage.

> Just some thoughts.
> I certainly believe that godi is a big step in the right direction.
>
> Jacques Garrigue
>
> P.S. A small detail, but would it be hard to replace godi_ftp by
> fetch? On my system godi_ftp is 351K whereas fetch is only 18K. I
> suppose this is also reflected by the size of the sources.

You can set FETCH_CMD in godi.conf; I don't know if the options are
compatible enough.

> I wonder also if there is a packaging system based on gmake rather
> than bmake. It feels a bit strange to install bmake only for internal
> purposes.

I consider bmake as just another scripting language. Of course, we could
port the whole bsd.pkg.mk to gmake, but does this make sense? It has
more than 4600 lines, and it makes heavy use of the BSD extensions.

If we are going to switch to another tool, it will be more attractive to
write a small make utility in O'Caml that can be scripted in O'Caml.
There is very ugly code in bsd.pkg.mk that would have a trivial and
elegant expression in O'Caml.

==============================================================================
3) ocaml courses
------------------------------------------------------------------------------
** Chuck Anderson asked and Maxence Guesdon answered:

> I'm looking for examples of courses covering functional programming or
> application development using Ocaml.  Thanks for any pointers.

Have a look at the caml humps:
http://caml.inria.fr/humps/

of directly:
http://caml.inria.fr/humps/caml_Documentation__teaching__lecture_notes.html

==============================================================================
4) GD4O
------------------------------------------------------------------------------
** Matt Gushee announced:

I am pleased to announce the first alpha release of GD4O (that's an 'O',
as in OCaml), an OCaml interface to the GD graphics library. It's
available at:

    http://havenrock.com/software/gd4o/

GD4O is based on OCamlGD 0.7, so most of the credit for this package
belongs to Shawn Wagner; so far I have added only a few functions,
created a more thorough test program, and created a new Makefile that
instals GD4O as a Findlib package. My goal is to provide a complete
and up-to-date interface to GD.

I should explain briefly how this project came about. I have spent a
good deal of time searching in vain for a comprehensive raster graphics
library for OCaml, and I have gotten the sense from a recent discussion
on this list (see the thread entitled "Graphics Frustration") that
others are interested in the same thing. I had noted with interest the
existence of OCamlGD, but also noted that it is quite incomplete and has
not been updated in the last year. A couple of weeks ago I emailed Shawn
Wagner to ask what his plans were for the package; he responded that he
didn't expect to continue developing it, at least not in the near
future. Since then I have emailed him again to ask if he would object to
my taking over the project, but I have not heard from him again. So,
technically speaking, this project is a fork--hence the new name. But
I don't see any reason to expect a competition here.

I'd also like to say that I am not really the best person to be doing
this sort of work, since I really don't know C very well. But since
noone else seems to be motivated enough to do it ...  Anyway, I expect I
will be needing some help in order to make this a quality package. So I
welcome constructive criticism, patches, and so on from all of you.

==============================================================================
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
zM

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
(alan.schmitt@inria.fr) and I'll mail it to you, or go take a look at
the archive (http://pauillac.inria.fr/~aschmitt/cwn/). If you also wish
to receive it every week by mail, just tell me so.

==============================================================================

Alan Schmitt