OCamlMeeting in Paris -- Debian summary
On January 26th 2008, the OCaml community has its first meeting in Europe. There was 5 different talks, including one from me. The meeting was pretty constructive and i think some great things should come out of it. In this post, i will focus on the Debian maintainer point of view.
The meeting was organized by me, with the help of Garbriel Kerneis and Vincent Balat. I wish to thank Mme Turgis from ENST/ParisTech who has made possible all this to happen.
I announce the creation of OCamlCore, a SS2L. It will provide commercial support for OCaml and related products. It will also provide community with some resources (including a GForge, a planet, some SCM repository...)
For now, i will open administration to Debian people who wish to help (for root rights) and from the whole community for other task (gforge and general administration). For now, i will choose alone who can administrate and who cannot... This is not a very open position, but this server is also for my company.
Xavier Leroy give us a nice talk that has let us see some future direction:
- OCaml 3.11 will have native dynlink
- hope to integrate GHC like type system (GADT: Generalized Algebraic Data Types)
- need to work on parallelism, following different paradigm
But above all, Xavier talked about the fact that there is a lack of manpower at INRIA and invited the community to build tools and other things (including a CPAN like distribution) to make the language more widespread. He also stated that a lot of things will stay in place in the name of backward compatibility.
Vincent Balat has given us a nice talk about OCsigen, a new framework for programming web application. This program is already in Debian and it is at the root of Debian discussion about moving .cm[ao] into libxxx-ocaml package. This new framework allows to program web application using continuation, which should ease a lot of aspect. It also features static type checking, including static verification of the generated HTML pages.
I was impressed to see G. Stolpmann coming to the meeting. Unfortunately, i cannot follow the whole talk, since i have some phone call to make, in order to book the restaurant. From what i have seen, it seems that GODI is growing, in term of manpower. They have some issues with OCaml 3.10, because of camlp4 and some packages. At the end of the conference, he was pushing for a more general use of GODIVA. In particular, it requires to have a very uniform way of building software. It should be the foundation of a build standard for OCaml software. In my humble opinion, i don't agree on this point. Basically, its proposal was based on configure/make all, which is too C style way of doing. It is not bad, but just exclude ocamlbuild enabled software.
Nicolas Pouillard has made an introduction on how to use ocamlbuild. I have discovered how it was working, since i didn't have time to work on this topic. It seems a good thing. I hope to be able to try it at some point. The conclusion was about modifying ocamlbuild to allow the use of multiple plugins. For now, the plugin is a separate file which is compiled first and then loaded, as a special case. Nicolas is looking for a full OCaml way to handle this for multiple plugins.
OCaml in Debian
I have spoken about different aspect of Debian packaging. After a short introduction and some history about OCaml in Debian, I come to some conclusions/problems:
- we have an early integration, which makes Debian handle a lot of packages, but this is due to a long history
- we still are not able to cope with libraries incompatibilities when rebuilding, we only have addressed ocaml package ABI problem
- the debian package management system is not really compliant with the OCaml way of creating libraries, which is our main problem
- native compilation is broken on 3 arches (Xavier Leroy told us that this should be solved for ARM)
- use of Alioth has made us more efficient to integrate packages
- Debian team are working by step: from time to time we begin to integrate a lot of packages, mostly because of some maintainers wishing to integrate a software with a lot of dependencies
Talking with Xavier give me some additional informations:
- ARM is fixed, it should compile with Debian stable on ARM, he explains that the problem is related to the multi ABI flavor of ARM
- he says that we should not have any problem concerning bytecode stripping of executable, if there is still some we should find the OCaml library that triggers this behavior
- I realize that this behavior can be triggered by ocamlmakefile, that still have a "-custom" option
- he promises me that he will send me a simple test to find custom bytecode application (combination of "file X" and a specific string at the end of the file)
At the end of the presentation, there were some questions. I discover that many people are ignoring the ABI problem with OCaml and its libraries. They seem to discover that it requires regular rebuild of our packages.
I also have a discussion about the fact that Debian binary distribution doesn't fit developers need. It seems that developers prefer to have the source of libraries they compile and also the most recent release. But at the same time, people avoid using GODI, which also have the problem of needing to wait for a particular library to be released... After some discussion, I point that some companies prefer to live in a frozen world, which Debian stable can provide. Living in a frozen world helps company developers to have the same environment from the beginning to the end of a project - which can last years. It also help to avoid build environment de-synchronization between company developers.
There was also a question about interaction between installed OCaml package and GODI software. I cannot answer it, expect with a "patches are welcome".
OCaml on a JVM using OCaml-Java
Xavier Clerc explained us how he has achieved running a full OCaml environment on a JVM. This work was pretty impressive, because he was able to compile OCaml top level and provide it as an applet. This is something amazing (and working). He stated also that this should allow to do some binding with java graphical user interface from OCaml. I was pretty busy with a phone call (to a restaurant for the dinner), so i don't have attend the whole conference. Anyway, the project is promising, but it needs to recompile every library using its compiler. I think this is not suited for Debian for now.
The workshop was shorter than it should have been. This is due to accumulated time shift during the day. However, it was pretty interesting, because everybody can talked almost freely.
The initial discussion was about the "Unicode situation". This was a question about Unicode in Unison, but there is no real solution about it. For reader information, unison has problem with filename containing UTF-8 char. In particular when syncing two directories which are on two file system with a different encoding on each. Even if the file can be represented on the two file systems, the comparison (between UTF-8 and ISO8859-15) fails. This is because the comparison is a byte to byte comparison.
We discuss further the idea of OSR (OCaml standard recommendation) which was briefly discussed in the morning. I think David Teller (who have also done a great part of the IRC retranscription) was very keen on this idea.
I invited Nicolas Pouillard to discuss the three following subjects.
About camlp4 documentation, Nicolas told people about the he set up. About ocamlfind and ocamlbuild, he went back to the multiple plugin problems. About ocamlbuild and GODI, Gerd, Nicolas and Xavier tried to build a list of what metadata can be shared. This includes list of files to be installed (PLIST in GODI).
Concerning the "feedback from the Gallium", Xavier explains that he has done this in the morning (which is true). I think that Xavier implicitly agreed on the fact that if this kind of event happens again, he can do another talk about future of OCaml.
Points concerning common interfaces raise the discussion about OSR.
The organization of next year events doesn't raise particular interest. I think people would be interested to have one next year, if something comes out of this meeting.