Here is the latest Caml Weekly News, for the week of 11 to 18 May, 2004.
I've released version 0.9.1 of CamlTemplate, a general-purpose template processor. Its functionality and API have been stabilising in recent releases, and I'm not currently planning any major changes before version 1.0, which I'd like to release soon. So if you use CamlTemplate, or think you might do so, now would be a good time to send me any suggestions you might have. CamlTemplate is available via GODI, and from here: http://saucecode.org/camltemplate/ Changes since the previous version: * Changed the line-continuation character from '#' to the more standard '\'. * Now requires OCaml 3.07. * Use GODI's OCamlMakefile when available. * Some clarifications in the manual.
OCamlConf : A simple OCaml build tool ------------------------------------- OCamlConf is an O'Caml build tool that resembles GNU autoconf to the user. It provides many useful functions for building your O'Caml project from a minimal amount of specification. See the homepage at http://kenn.frap.net/ocamlconf/ for more details -------------------- New in this version: * No longer generates two files, "configure_out.ml" and "configure." The configure script is a hybrid shell script / ml program that contains everything it needs to run, provided they have a bourne shell, sed, and ocaml installed * Renamed "MakeMake" to "AutoMake" to indicate that it is a super-high-level wrapper. * Factored out MakeMake into several modules, allowed finer control of the build * Bugfixes in mixed C/O'Caml libraries, which are certainly the toughest to build right. * Dramatically improved documentation (if I do say so myself!)
> I'm using OCaml 3.07 on Windows (MSVC build) and I wonder > whether it's possible to create standalone applications > that run without opening a console window. Some googling > directed me to mkwinapp (from the OCaml-Win32 distribution) > but apparently it doesn't work. I'm using Windows XP home. > > Any ideas? You need to get OCaml Win32 API from here : http://www.speakeasy.org/~hchomsky/ocaml-win32.html And then a simple call to free_console() will remove the console. One other way is to hack the exe in order to change its mode from "console application" to "win32 application". Maybe an ocaml linker option would be nice to do that.Felix Winkelmann said and Xavier Leroy answered:
> mkwinapp just appears to be ineffective on a bytecode-compiled > file. But (as I said in my followup), it works nicely with native > code compiled with ocamlopt. So it really seems to be related > to the invocation of ocamlrun (I guess), For another example of how to build a non-console application in bytecode, you could look at otherlibs/labltk/browser/Makefile.nt in the OCaml source distribution. Basically, the trick is to link as follows: ocamlc -custom ... winmain.obj -cclib "/link /subsystem:windows" when winmain.obj is obtained by compiling otherlibs/labltk/browser/winmain.c.
Today the GODI distribution releases a new stable version of the bootstrap tarball. This version includes support for: - Linux - Solaris - FreeBSD - NetBSD - HP-UX - MacOS X - Cygwin The latter four OS are supported for the first time. Read below how to install or upgrade GODI. There are also new packages, in particular: - apps-unison: File synchronizer - godi-camltemplate: Templates to generate web pages, SQL queries etc. - godi-camomile: A comprehensive Unicode library - godi-ocaml-mysql: MySQL client bindings - godi-xml-light: minimal XML parser & pretty printer Many thanks to Alain Frisch, Benjamin Geer, Owen Gunden, and Yamagata Yoriyuki, who created the packages. How to install GODI for the first time: Download the new bootstrap tarball: http://www.ocaml-programming.de/packages/godi-bootstrap-20040514.tar.gz Please read these web pages and follow the instructions: - http://www.ocaml-programming.de/godi - http://www.ocaml-programming.de/packages/documentation/godi/README.html The latter is also included in the tarball. How to upgrade: Just start godi_console, update the build instructions, and then select the packages to upgrade from the list. Include at least godi-core-mk, godi-core-pkgtools, and godi-tools, or press 'u' to select all for which an upgrade is available. Then continue as usual. The rest is done automatically. (This is why you need GODI.)
I've been working for a few months on largish project for ocaml, named ocalibs. It's still mainly work in progress, but I thought it (or parts of it) may be of some intrest to the folks here. Ocalibs is a collection of libraries and tools to ease game development. The main purpose for ocalibs is to serve as a test bed for me to see if realtime "big" games can be built easily with ocaml. As it is, ocalibs currently works only with the MSVC branch of ocaml (windows only). Later, if it turns out that ocalibs is not suitable for full game development (for any reason), I intend to turn it into a toolkit with which it's easy to develop intermediate convertors from editor data (ie. maya, raw textures from photoshop and such) into game related platform specific data (say, native PS2 data). It has many unfinished parts (which will probably be removed in a month or two), but some snippets of intrest: - DirectX 9 bindings. Can already init the screen, read the mouse to some degree and render meshes (no textures yet). - XML based exporter for Maya. The exporter is written in C++, but may be of use for anyone who wishes to use Maya as their tool of choice for any project. - XML scene importer (using xml-light). Handles scene hierarchies as well. - Custom make system. Inspired by ocamake and the MSVC IDE. The make system consists of project "makefiles". Each makefile tells it's own sources and dependencies of other projects, native libraries and ocaml projects. When running the tool, the tool automatically checks each dependant project for changes and recompiles as necessary. For the link phase, the libraries are collected from the dependant projects. Ocalibs can be found at: http://sourceforge.net/projects/ocalibs/ (cvs only; no files released)
For a long, involved, reason, I've written a short (about 1 page) history of Ocaml, as best as I understand it from various on-line resources. I'd like to get everyone's opinions on it, especially the people who were there (please oh please check to make sure I spelled everyone's name correct- I'm a stupid 'merkin and not used to charaters with accents, unless they come from the south :-). Comments on all levels- from flawed chronology and incorrect causality to bad grammar and misspellings are welcomed. Don't worry about hurting my feelings. The HTML version is here: http://www.bogonomicon.org/bblog/ocaml-history.html A PDF version is here: http://www.bogonomicon.org/bblog/ocaml-history.pdf For some reason, DocBook wants to make a 1-page article take 4 pages in the pdf version, I'm not 100% sure why. Thank you.Vincent Balat said:
For other information, you can have a look to this: http://www.pps.jussieu.fr/~cousinea/Caml/caml_history.html
> I am looking to see if there already exist: > > 1) a XML processing library, i.e. DOM parser Xml-Light : http://tech.motion-twin.com/xml-light for parsing + DTD handling. You can also checks other available librairies at http://caml.inria.fr/humps > 2) I know that somebody is doing SOAP work, but > unfortunately I miplaced this mail ... oops. > > 3) WSDL (Web Services Description Language) > library
> How about this: > > --------------------------------------------------------------------------- > open Big_int > open Nat > > let nbits x = > let nat = nat_of_big_int (abs_big_int x) in > let nwords = num_digits_nat nat 0 (length_nat nat) in > Sys.word_size * nwords - num_leading_zero_bits_in_digit nat (nwords - 1) > --------------------------------------------------------------------------- > > This runs another order of magnitude faster, and it's shorter, too :-)Yaron Minsky then asked and Xavier Leroy answered:
> Nice. The weird thing about the Nat module is that it's completely > undocumented. Is there any reason to think it wil be stable between > revisions? For instance, does Xavier's reimplementation have the same > Num module with the same interface as the previous one? The Nat interface hasn't changed since the beginning of OCaml, and my recent reimplementation of the low-level primitives preserved its interface. > I guess my real question is: why is Nat undocumented? Nat is a very low-level API, based on in-place modification of sub-numbers of big integers. Consequently, it's hard to use directly, and it's also hard to document. The lack of documentation is both an encouragement not to use it, and an evidence that we are lazy :-) If you really want to know what Nat does, the following tech rep is useful: "The CAML Numbers Reference Manual" by Valerie Menissier-Morain, technical report 141, INRIA, july 1992, available at ftp://ftp.inria.fr/INRIA/publication/RT/RT-0141.ps.gz . It documents the Caml V3.1 API for exact-precision arithmetic, but the part of it that deals with the "nat" abstraction still applies to the Nat module of OCaml.
This is to announce a very preliminary implementation of a message catalog system for localising text in OCaml programs; it's called LocalCaml. The approach I've taken is partly inspired by Perl's Locale::Maketext module. In an attempt to provide the flexibility needed to adapt sentence structure and morphology to numeric parameters in messages, the library uses a general-purpose template engine, CamlTemplate as a language for writing message templates. This isn't a proper release yet; I'm posting this message in order to ask for feedback from the OCaml community. If you're interested in i18n in OCaml, please have a look and let me know what you think. You can get the tarball from here: http://saucecode.org/localcaml/releases/localcaml-0.1.0.tar.gz Anonymous CVS access is also available: touch ~/.cvspass cvs -d :pserver:firstname.lastname@example.org:/cvsroot login cvs -z3 -d :pserver:email@example.com:/cvsroot co localcaml Apologies for cross-posting. Please post followups to the ocaml-i18n mailing list. Ben  http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext/TPJ13.pod  http://saucecode.org/camltemplate/  http://www.orcaware.com/mailman/listinfo/ocaml-i18n
As the director of a shop who is using Ocaml to do real work (yes I know, research is more important :P), I would really like to be able to build a shared library out of code that I have written in Ocaml, and link other Ocaml programs to it. There are practical reasons for wanting to do this, I write and maintain some rather large systems written in Ocaml. Currently, whenever I update a library (not changing its interface), I need to recompile and reinstall the entire system. These problems I can live with for now. But... I also have "delusions" (or so I'm told). IMHO, Ocaml is fast enough, and has enough good libraries in existence to create a climate where Ocaml software will slowly start replacing software written in C. I've been watching the building blocks go into place for six months now, and things look like they are accelerating. As the number of libraries, and applications using them increases, static linking starts to become a nightmare very quickly. If you were, for example, to build a desktop environment in Ocaml, you'd have to rebuild the entire system every time you changed a core library. And, all the little executables in the desktop would be HUGE. I think that Ocaml is a very good language (understatement) for building large reliable systems, and I would hate to see its growth be hampered artificially by its lack of shared libraries.Xavier Leroy answered:
I'm not sure which aspect of shared libraries you're interested in. Unix shared libraries or Windows DLL offer the following features: 1- Smaller executables through code sharing. 2- Upgradeability: upgrade the shared library and (with luck) all executables that refer to it are automatically upgraded. 3- Dynamic loading of code in a running program. There is however one big difference between C and OCaml, which is that OCaml has type-safe linking. The linker checks that clients of a library were typed and compiled against the interface and cross-module optimization information of the library. As it is done today, this check is rather brittle: any change in the library interface or optimization information cause it to fail and require a recompile of the client modules. For static linking, this is not too bad: a package management framework such as GODI can automate the recompilation of clients when the library changes. More importantly, you need to bring things in sync only when you're rebuilding your client: already compiled programs continue to work, since they embark their own version of the library. With shared libraries, any update on the shared lib would immediately invalidate all executables that use it. This is the well-known "DLL hell" problem, just exacerbated by the very strict consistency checkings done by the OCaml linker. So, feature 2- above is really not applicable to OCaml as it is today, and static linking is much more usable than dynamic linking of shared libs. As for feature 1- (smaller executables), I'm not convinced this is a major issue. I'm old enough to remember the introduction of shared libraries in the Unix world (in SunOS 4). At that time, the saving in disk space was significant: disks were small (a complete SunOS 4 install could fit in as little as 100 Mb) and the size of executables wasn't negligible compared to the size of data files. Times have changed, however: disk space has increased much faster than executable sizes, and the disks on a modern machine are mostly filled with data (think MP3 and movies :-), making executable sizes a non-issue. Feature 3- (dynamic code loading) is already available in bytecode through the Dynlink API. I understand there's a demand for having it in native-code as well, and that might be possible without too much fuss, at least on selected operating systems. So, in summary: shared libraries are simply too fragile, especially when combined with OCaml's type-safe linking. This is such a big problem that the drawbacks of static linking (bigger executables) appear very minor in comparison.Olivier Andrieu suggested:
These questions have already been raised on the list (it does not mean they're not worthy of being mentionned again :), so you may be interested by this in-depth reply from Xavier: http://tinyurl.com/2ywsu
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.