Hello
Here is the latest Caml Weekly News, for the week of 27 April to 04 May, 2004.
The Seventh Annual
ICFP PROGRAMMING CONTEST
4 June - 7 June 2004
http://icfpcontest.org/
Convinced your favorite programming language provides unbeatable
productivity? Convinced you and your friends are world-class
programmers?
If so, we're providing you the opportunity to prove it! We are
pleased to announce the Seventh ICFP Programming Contest to be held in
conjunction with the 2004 International Conference on Functional
Programming (ICFP 2004). All programmers are invited to enter the
contest, either individually or in teams; we especially encourage
students to enter. You may use any programming language (or
combination of languages) to show your skill.
On Friday, 4 June 2004 at 12:00 Noon (EDT), we will publish a
challenge task on the Web site and by e-mail to the contest mailing
list. Teams will have 72 hours until Monday, 7 June 2004, 12:00 Noon
(EDT) to implement a program to perform this task and submit it to the
contest judges. We have designed the contest for direct, head-to-head
comparison of language technology and programming skill. We have a
range of prizes including cash awards and, of course, unlimited
bragging rights for the winners.
For more information about the contest, prizes, and registration,
point your browser to the contest website.
- 2004 ICFP Contest Team
http://icfpcontest.org/
Hi list,
here is my report about the progress of the GODI system. A lot of things
have happened since the last "GODI news", so this is quite long.
We have two release lines, one is the "stable" release, in the sense
that the GODI core does not change during its lifetime, the other is the
"development" release, where exactly this happens. Of course, there is
also development in the stable release, as lots of new packages have
been added.
*** The stable release ***
You get the stable release when you download and install GODI using the
instructions as explained at http://www.ocaml-programming.de/godi, and
as detailed in the README file in the bootstrap tarball. It is known to
run on Linux, Solaris, and FreeBSD.
The stable release includes 24 libraries beyond those coming with the
core O'Caml distribution. It has 50 packages in total.
Recent additions include:
- expat: bindings for the popular XML parser
- getopt: parsing of command-line arguments
- zip: Compression
- cduce: XML transformation language
- ocamlsdl: bindings for SDL
- ocamlodbc: bindings for ODBC
- headache: manage headers of source code files
- godiva: the GODI Verpacken Assistant (read more below)
Most packaging was done by Alain Frisch, thank you very much.
The stable release already includes godi_console, the frontend
application to update, install, and delete packages. It is menu-based
and quite simple to use. One of the key features is that it can download
updates from the GODI server, so when new packages or upgrades are
available, it is very easy to get them installed. Btw, this is not done
using cvs or other configuration management, but by plain http. I
explain the reasons below.
*** The development release ***
This is also some kind of release, although only announced in godi-list.
See below how to install it. The current version should work on Linux,
Solaris, FreeBSD, NetBSD, MacOSX, and Cygwin. Development focuses on
getting it running on further platforms.
The changes illustrate this:
- One of the things where the platforms differ is the handling
of shared libraries. I do not mean creating them, but rather
using them. The GODI framework was extended to allow the integration
of non-ELF based systems.
- The bootstrap script is more intelligent regarding finding
executables in PATH. This is a bit tricky, as for some OS one
should _not_ look certain utilities up by PATH to get the right
versions, but on the other hand, extending PATH is the usual
way of pointing to non-standard locations. Finding the right way
was explored by lots of experiments.
- Especially for Cygwin, new ways of installing packages had to
be explored. The problem is that Windows locks running executables,
such that you cannot replace them. A workaround was found.
- Of course, there are also many smaller fixes.
I want to thank Eugene Kotlyarov for help on the Cygwin port, and
Matthew Backes for giving me access to his Macintosh.
Of course, one can only port GODI to a certain platform when there is a
development machine for it. If you would like to get GODI running on
your platform, and you have such a machine, you are more than welcome.
How to get the dev release:
- Download this bootstrap archive:
http://ocaml-programming.de/packages/godi-bootstrap-20040426.tar.gz
- After unpacking, run ./bootstrap --prefix XXX as usual.
- IMPORTANT: Now change in <prefix>/etc/godi.conf:
GODI_SECTION=dev
Otherwise you get the stable GODI version.
- Finally, run ./boostrap_stage2
When everything works well, the dev release becomes the new stable
release. I expect that this happens in one or two weeks.
*** GODIVA ***
GODI, and implicitly the BSD port system on which it bases, was
criticized as being too complicated for packagers. (Well, I would say it
is quite simple, but this is the impression some people have.) Owen
Gunden and William Lovas developed a tool for GODI that simplifies
packaging, namely GODIVA:
http://projects.phauna.org/GODIVA/
You only need to write a small specfile like
Package: godi-foolib
Version: 2.0
Revision: 0
Depends: godi-ocaml (>= 3.06)
Build-Depends: conf-foo, godi-findlib (>= 0.8.1)
Sources: http://www.phauna.org/foolib/foolib-2.0.tar.gz
Homepage: http://www.phauna.org/foolib/
Maintainer: Owen Gunden <ogunden@phauna.org>
Options: configure, opt
Docfiles: README, VERSION, LICENSE
Description: O'Caml bindings for the foo library.
Foolib provides bindings for the foo library using the leetness
of labls! It's a lot of fun.
(taken from the web site). However, GODIVA requires that the source code
follows a policy (e.g. that "make all" creates the bytecode version of
the software, and "make opt" creates the native code version), so the
downside is less flexibility. I think it is a good starting point to get
familiar with the GODI packaging system.
*** The GODI server ***
GODI also has a server infrastructure:
- http://www.ocaml-programming.de is web space I bought from a
commercial provider. Nowadays, web space is cheap, fortunately. It is
http only, no scripts, no databases. Includes several gigabytes of
transfer volume per month.
- https://gps.dynxs.de is the small box left to my desk. It is
connected with a DSL line, so bandwidth is very limited, but
I can install what I want. It is currently running Debian-3.0.
For obvious reasons, the "main" thing must happen on
www.ocaml-programming.de, as this server can cope with high download
volume. For development, gps.dynxs.de is the better choice.
There are currently the following services:
- http://www.ocaml-programming.de/godi is the homepage
- http://www.ocaml-programming.de/godi-build is the directory with
the "build instructions", i.e. the small tarballs that explain
GODI how to install software
- http://www.ocaml-programming.de/godi-backup contains copies
of the source tarballs. There is a mirror of this directory
at http://lcavwww.epfl.ch/~henridf/godi-backup, thanks
Henri Dubois-Ferriere.
- https://gps.dynxs.de/mailman/listinfo is the home of the
mailing lists godi-list and godi-commits
- https://gps.dynxs.de/svn is the home of the Subversion
repository
- https://gps.dynxs.de/tracker is the home of the bug tracker
- https://gps.dynxs.de/godi_admin is the GODI administration
tool for developers. This is a web application allowing the
developers to release their packages without my help. The
packages must already be checked in to the repository. The
source tarballs are checked for availability. Finally, the
tool manages that the right tarballs are uploaded to
the godi-build and godi-backup directories.
Recently, the tracker and godi_admin were set up.
When a GODI user tries to update the installation, GODI looks into
http://www.ocaml-programming.de/godi-build and checks whether there are
new versions of the packages. If so, these are downloaded. These are the
so-called build instructions, mainly containing a Makefile explaining
how to do the rest. The software as such is downloaded from the original
web server, if possible, and from
http://www.ocaml-programming.de/godi-backup, or the mirror as fallback
solution.
Only HTTP is involved. For the users, it has the advantage that
firewalls do not block the downloads. For GODI, the advantage is that
cheap web space can be used to serve the requests.
*** LINKS ***
The most important links again:
- http://www.ocaml-programming.de/godi explains how to install the
stable version of GODI
- https://gps.dynxs.de/mailman/listinfo/godi-list is the GODI mailing
list. Archives can be found at
https://gps.dynxs.de/pipermail/godi-list .
This is a bit of a repeat of a question that I posted to comp.lang.python
(sorry to anyone who was there too!). I'm looking for some advice on
integrating a python GUI with an OCaml library. (Note: I'm fairly new to
both ocaml and python; more of a perl and c++ programmer!)
Basically the story is this, I'm building a GUI on the front of an existing
OCaml tool. I'm writing the GUI in wxPython (there are a number of reasons
why, I investigated various caml gui toolkits and unfortunately they didn't
quite satisfy the requirements I had). Currently the GUI is envisaged as a
glorified configuration file editor; it should help users to generate
configuration files that are then handed to the ocaml tool to execute.
The problem is this, both the python GUI and the ocaml tool need to know how
to parse/understand the configuration file format, and I'd like to write the
parser once (in ocaml, using ocamllex/yacc probably) and use it twice (in
the GUI and the base tool). My challenge now is to figure out how to call
the ocaml parser library from python.
I currently have two possibilities in mind. Surfing the web uncovered
Pycaml, which suggests integration both ways, however from the examples I
only understand how python can be called from ocaml (not the other way).
The second possibility is to wrap the ocaml module in a c library that can
then be imported into the python code.
What I'm hoping is that someone on the list has tried this sort of thing
before and can give a little advice on the best way forwards (and hopefully
reduce the number of blind alleys I explore!).
Basile Starynkevitch proposed:
You might consider having the GUI in Python and the main OCaml program
be two different processes communicating thru pipes. You might even
consider using my GUIS program, which is a GUI GTK "server" listening
on an input pipe (which could be written by your Ocaml program) for
Python commands and writing on an output pipe arbitrary textual stuff
(which have to be parsed by your Ocaml).
GUIS is available from http://starynkevitch.net/Basile/guisdoc.html
(I intend to make a new release of GUIS in a few weeks - if you are
interested and/or want more features, it is the time to tell me).
This is a report on my attempt to make ocamlopt work with the C compiler
from the (free of charge) Visual C++ toolkit.
The toolkit can be downloaded from:
[1] http://msdn.microsoft.com/visualc/vctoolkit2003/
It contains the C compiler and the MS linker.
Then you need to find the Microsoft Assembler:
despite all the information found on the page
[2] http://users.easystreet.com/jkirwan/pctools.html
I couldn't find a way to fetch the ML.EXE and ML.ERR files.
First, the URl for the Visual C++ processor pack (which
contains MASM) download page is now:
[3] http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspx
According to [2], it would be enough to run the install program,
and find the ML.EXE/ML.ERR files somewhere on the disk while the
program complains that VC++ is not installed (when you click Ok,
the program would erase the files). Unfortunately, I couln't find
the temporary files on my disk. Maybe the latest versions are less
stupid.
At that point, the ML.EXE/ML.ERR files arrived magically on the hard
drive, probably because of a worm, or some security hole in OE.
Two .LIB were still missing: advapi32.lib and uuid.lib. I could
find them in the Microsoft Core SDK. To download this SDK, you can follow
the link "Microsoft Windows Platform SDK" from [1]. The download is
around 200 Mb and the SDK takes 500 Mb after installation. You need
only the two tiny files advapi32.lib and uuid.lib.
So, finally, except the Visual C++ toolkit itself, you only need 4 files:
ml.exe, ml.err, advapi32.lib and uuid.lib. And you can compile your
favorite hello.ml with ocamlopt. I still haven't found an official way to
get ml.exe and ml.err.
I know it's been less than a month, but Jean-Christophe Filliâtre
brought to my attention that the implementation of red-black binary
trees in Cf exhibit underwhelming performance characteristics (with
specifically very bad performance for [Cf_set.subset] and
[Cf_set.intersect]). And since the red-black binary trees are used in
several other modules, I decided to tune up their performance.
I couldn't resist tuning the API a bit as well, so if you're a user of
this library and my changing the API is a bummer for you, then let me
say this: You Should Have Told Me You Were Using The Library. (Since I
don't know of anyone else using this library yet, I continue to
feel free to change the API without notice to suit my tastes
exclusively.)
As before, the new distribution is available at either of the following
URL's:
http://www.wetware.com/jhw/src/pagoda/cf-0.2.tar.bz2
http://www.wetware.com/jhw/src/pagoda/cf-0.2.tar.gz
And the online documentation (generated by ocamldoc) can be found here:
http://www.wetware.com/jhw/src/pagoda/doc/
There is still no programmer's guide. If people start using this
library, then maybe I'll write one.
===== Pagoda Core Foundation (cf) library =====
This directory contains the Pagoda Core Foundation library, which is a
collection of miscellaneous extensions to the Objective Caml standard
library.
Highlighted features include:
- Functional streams and stream processors (extended).
- Functional bootstrapped skew-binomial heap.
- Functional red-black binary tree (associative array).
- Functional sets based on red-black binary tree.
- Functional real-time catenable deque.
- Functional LL(x) parsing using state-exception monad.
- Functional lazy deterministic finite automaton (DFA).
- Functional lexical analyzer (using lazy DFA and monadic parser).
- Functional substring list manipulation (message buffer chains).
- Gregorian calendar date manipulation.
- Standard time manipulation.
- System time in Temps Atomique Internationale (TAI).
- Unicode transcoding.
- Extended socket interface (supports IPv6 and UDP w/multicast).
- Universal resource identifier (URI) manipulation.
- I/O event multiplexing (with Unix.select).
Note: see the ISSUES file for a list of open problems in this release.
===== Required Components =====
This library requires the following external components:
- Objective Caml (v3.07+2 or newer)
- Findlib (tested with v0.8.1 and v1.0.4)
Principle development was on Mac OS X 10.3. The final version of this
library also compiled successfully without warnings and self-tests on
Suse Linux 9.0 on x86-32. Other platforms with POSIX-like environments
should require only a minimal porting effort.
One major open issue: the extended socket interface is broken under
WIN32.
(The author invites help porting the library to other environments.)
===== Version 0.2 =====
Highlights of the changes:
+ Major overhaul of [Cf_rbtree] to address serious performance issues
(should improve performance of [Cf_dfa], [Cf_lexer], [Cf_poll] and
[Cf_gadget]).
+ Defined [Cf_set.T] and [Cf_map.T] module types for use in abstracting
the underlying algorithm behind sets and maps.
+ Added [Cf_seq.constrain] (and [Cf_seq.constrain2] for consistency).
+ Defined [Cf_heap.T] and [Cf_pqueue.T] module types for use in
abstracting the use of skew-binomial heaps as either a heap or a priority
queue.
+ Reimplemented the interface to [Cf_sbheap] so it is consistent with
the new [Cf_rbtree] interface.
Announcement: Camlmix 1.0 (first release)
http://martin.jambon.free.fr/camlmix
Camlmix is a command-line tool for preprocessing any kind of file using
Objective Caml as an embedded language for inline expansion.
It has 3 major properties:
- easy: no obscure syntax, no complex library
- flexible: lets you use full featured OCaml
- universal: is not specialized in handling any specific file format
Short example:
File foo.tpl:
##
# load "unix.cma"
# use "my_utils.ml"
let my_name () = print_string "Camlmix"
##
[...]
This text has been generated by ## my_name () ##.
[...]
EOF
Command:
camlmix foo.tpl -o foo.txt
Result file foo.txt:
[...]
This text has been generated by Camlmix.
[...]
EOF
I use Camlmix for my few static web pages. It is not supposed to replace
any already existing tool, but just provide an OCaml centric
general-purpose preprocessor.
It can of course be used to preprocess OCaml programs themselves, but I
would not recommend this. It allows to create easily a primitive template
system for OCaml and probably many other kinds of dirty hacks (see
the example on the web page).
Once again, it's here:
http://martin.jambon.free.fr/camlmix
I've spent the past few days trying to implement an interpreter for the
Mathematica language. This is quite an exotic language. For example, it has a
single type - the AST - and is "strongly typed" as a side-effect. For anyone
who is interested, a brief description and my resulting code are on the web
here:
http://www.chem.pwf.cam.ac.uk/~jdh30/programming/mathematica/
I'd be particularly interested to hear any constructive criticism of my coding
style, both from the point of view of interpreter/compiler writing and also
more general comments...
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.
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.