Here is the latest Caml Weekly News, for the week of November 21 to 28, 2006.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/65b9e6b67afbb553/82de5c2e53096a47#82de5c2e53096a47Vincent Hanquez announced:
I've made a small bindings for inotify, aka linux file system notification new subsystem. It's available here: http://tab.snarc.org/projects/ocaml_inotify/ or the archive is directly here: http://tab.snarc.org/download/ocaml/ocaml_inotify-0.2.tar.bz2 You need a really recent glibc to have inotify syscall available through /usr/include/sys/inotify.h. I didn't bother putting some code to handle old glibc, but I accept patch :) The archive contains an example program on how to use the interface.Richard Jones then said:
I think OMake includes bindings for gamin. Or FAM which is the older SGI-based daemon, but gamin is C API compatible with FAM. http://svn.metaprl.org/viewvc/mojave/omake/src/clib/omake_notify.c?revision=1326&view=markup&pathrev=1326 http://www.gnome.org/~veillard/gamin/Vincent Hanquez answered:
> I think OMake includes bindings for gamin. it seems to be talking FAM. > Or FAM which is the older > SGI-based daemon, but gamin is C API compatible with FAM. Sounds more like a bad thing than a good thing to me. Direct inotify binding are much smaller/simpler anyway.
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/c2d9e5818b899795/20b9f4155661a0a1#20b9f4155661a0a1Richard Jones announced:
Thanks to the brilliant efforts over many months by Martin Jambon, Camarade_Tux, Luca Brivio, simo.magic, ukai, teruakigemma, and Yamagata Yoriyuki   the OCaml tutorial has now been translated into 3 other languages: French: http://www.ocaml-tutorial.org/fr Italian: http://www.ocaml-tutorial.org/it Japanese: http://www.ocaml-tutorial.org/ja (And English at http://www.ocaml-tutorial.org/ ) The Merjis contributions are now all public domain, and those of the other contributors are copyrighted by them respectively. Rich.  I sincerely apologise if I have missed out any of the translators from this list.  And don't forget all the people who helped write the English version http://www.ocaml-tutorial.org/#Acknowledgements .
Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/8cced5418a89870a/Deep in this thread, David Monniaux said:
In C, if you are really concerned about getting your exact constants up to the last bit, you should use the hexadecimal float notation introduced in C99. You should also use "%a" or "%A" to print out your floating-point values in hexadecimal if you intend to reload them on another IEEE-754 system in a portable way. (Unfortunately on OCaml, %a is already used for another use... Xavier, what do you think of adding the hexadecimal float conversion to the family of printf functions?) Anyway, "IEEE-754 compliant", as used by common vendors, is a fairly vague claim. For instance, contrary to a commonly held belief, the same C or Caml program ran on two different major platforms (say, IA32 vs AMD64 or IA32 vs PowerPC) can give different results, possibly even depending on compiler options, and this has nothing to do with how they parse constants... You might wish to read my preprint: http://www.di.ens.fr/~monniaux/biblio/pitfalls_of_floating_point.pdf The only widespread language that I know about that has fixed semantics for floating-point is Java if the 'strictfp' modifier is used. (Originally, Java was supposed to have a fully fixed semantics, but they realized that implementing it over the 80387 compatible floating-point stack was difficult and that it also precluded some optimizations, so they relaxed it by default and introduced 'strictfp'. Goodbye predictability.)Probably replying to an off-list message, David Monniaux then said:
In the Astrée project, we use some small C functions and OCaml wrappers to change rounding modes. It's not easy (some systems have fpgetround/fpsetround, others fegetround/fesetround, some have none and you have to use assembly, and old versions of GNU libc on IA32 have fegetround/fesetround that change rounding for the 387 FPU but not for SSE, which may break some external C libraries). [ Hey, we should publish our libraries. ] In addition, some C libraries don't work properly when rounding is not "round to nearest". I filed bugs against FreeBSD libc (printf doesn't work properly with some arguments) and GNU libc (pow() does not work properly). Rounding modes other than the default "round to nearest" tend to be largely untested on many systems and libraries, because few people use them. #pragma FENV_ACCESS is not even implemented on gcc; -frounding-math is supposed to signal rounding modes other than round to nearest, but the documentation states that it's not even sure it works... Not that I want to advertise myself too much, but I think you should read http://www.di.ens.fr/~monniaux/biblio/pitfalls_of_floating_point.pdf if you are concerned about interactions between compilers and floating-point.
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.