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 <email@example.com> 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:  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  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:  http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspx According to , 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 . 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).
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.