Previous week Up Next week

Hello

Here is the latest Caml Weekly News, for the week of 11 to 18 May, 2004.

  1. CamlTemplate 0.9.1
  2. ocamlconf-0.5 release
  3. Windows (MSVC) applications without the console window...
  4. GODI news
  5. Announcing ocalibs
  6. A short history of Ocaml
  7. XML library, SOAP library and WSDL library?
  8. Counting bits in a big_int
  9. LocalCaml 0.1.0
  10. Ocaml shared libraries

CamlTemplate 0.9.1

Benjamin Geer announced:
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-0.5 release

Kenneth Knowles announced:
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!)
    

Windows (MSVC) applications without the console window...

Felix Winkelmann asked and Nicolas Cannasse answered:
> 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.
    

GODI news

Gerd Stolpmann said:
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.)
    

Announcing ocalibs

Jere Sanisalo announced:
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)
    

A short history of Ocaml

Brian Hurt said:
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
    

XML library, SOAP library and WSDL library?

Vasili Galchin asked and Nicolas Cannasse suggested:
>    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
    

Counting bits in a big_int

In a thread about fast bitcounters, Markus Mottl proposed:
> 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.
    

LocalCaml 0.1.0

Benjamin Geer announced:
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[1].  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[2] 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:anonymous@cvs.saucecode.org:/cvsroot login
cvs -z3 -d :pserver:anonymous@cvs.saucecode.org:/cvsroot co localcaml

Apologies for cross-posting.  Please post followups to the ocaml-i18n
mailing list[3].

Ben

[1]
http://search.cpan.org/~sburke/Locale-Maketext-1.09/lib/Locale/Maketext/TPJ13.pod

[2] http://saucecode.org/camltemplate/

[3] http://www.orcaware.com/mailman/listinfo/ocaml-i18n
    

Ocaml shared libraries

Eric Stokes asked:
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
    

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