Tag - ocaml

Entries feed - Comments feed

Last entries

Thu 23 Jul 2009

Transition to OCaml 3.11.1 has started in Karmic

OCaml I previously mentioned that Ubuntu Karmic currently ships with OCaml 3.11.0 and all associated libraries and programs. While it is nice to have a coherent set of OCaml packages, it would be much better to the latest coherent set of OCaml packages in Karmic! :-) Debian initiated its own transition to 3.11.1 about 4 weeks ago and this transition is nearly finished (and took in fact only 3 weeks).

I therefore raised the issue of such a transition for Karmic. After a few questions, it has been agreed upon to start a similar transition in Karmic. Moreover Andrea Gasparini, an Ubuntu's Master Of The Universe (aka MOTU), volunteered to help me. Se we opened the first bug initiating the transition. Overall, there are 124 source packages to synchronize or recompile in 6 successive rounds.

One can monitor the status of the transition of the Ubuntu OCaml transition monitor. A comparative list of source package versions between Debian unstable and Ubuntu karmic is also available.

Thu 25 Jun 2009

Transition to OCaml 3.11.1 has started in Debian

Debian The 24th of June, the Debian package for new upstream OCaml 3.11.1 has been uploaded. Thus upload marks the start of the transition to OCaml 3.11.1 in Debian Sid (aka unstable). Right now, the new package has been successfully built on most of Debian supported architectures.

Following this first round, other packages are being uploaded in successive rounds. You can follow this transition on Stéphane Glondu's dedicated OCaml transition monitor.[1]

The count-down has started. We will see how much time it will take to do this transition for the 138 source packages.

Thu 18 Jun 2009

Ubuntu 9.10 will ship with OCaml 3.11.0... for now

As I recently announced on caml-list@, all OCaml packages coming from Debian were correctly compiled against OCaml 3.11.0 in Ubuntu Karmic Koala 9.10 to be released in next October. That means that current Karmic has a coherent set of OCaml packages, which I consider a worthwhile property.

Unfortunately, OCaml 3.11.1 has just been released and Debian developers are starting a transition to OCaml 3.11.1 in Debian unstable. As until the 25th of June all packages are directly imported from Debian unstable to Ubuntu Karmic, that would break various OCaml packages in Karmic, certain packages being compiled with 3.11.0 while others with 3.11.1.

Consequently, after discussion with Debian and Ubuntu developers[1], I have decided:

  1. To block the automatic import of OCaml packages from Debian to Ubuntu[2]. This blocking is currently effective. So, from now, Karmic will ship with OCaml 3.11.0 and the current package versions;
  2. To monitor transition from 3.11.0 to 3.11.1 in Debian and, if done quickly enough, to trigger a similar transition in Karmic. The Feature Freeze is set to the 27th of August so this is the absolute limit date for such a transition to end.

I am also considering providing 3.11.1 packages through Ubuntu PPA (Personal Package Archive) system. But I first need to learn how to use it. :-) But even if Karmic does not ship with 3.11.1, Karmic+1 which is LTS (Long Term Support) will have it.

If you read this blog entry and have an issue with this decision, let me know either through the comments or by sending an email at: dmentre AT linux-france.org.

Notes

[1] Several Ubuntu people were in favor of also doing such a transition in Karmic, but I cannot commit to monitor and handle it during that time period.

[2] I have been pretty conservative and blocked all OCaml based packages (because an updated package might need in up-to-date version of OCaml). We might lift this constraint a bit and allows synchronization of certain packages. Right now, I have not seen any such need. You can monitor the status of out-of-sync package in Karmic on this page.

Thu 11 Jun 2009

OCaml 3.11.0 on Ubuntu Karmic Koala nearly complete

OCaml As I have previously stated, there is no OCaml developers on Ubuntu and all OCaml packages in Ubuntu are coming from Debian. So there is apparently no much work to do in order to have a large set of OCaml packages on Ubuntu. Except that there are synchronisation issues. :-)

Debian's OCaml packages are imported automatically from unstable repository a the beginning of each new development cycle of Ubuntu[1] until a Debian Import Freeze takes effect (the 25th of June according to Karmic release schedule). Once imported, packages are automatically build. But OCaml packages have a stringent need to be compiled in the right order and against the correct version of the OCaml tool chain. In case of change (e.g. going from 3.10.2 to 3.11.0) all packages should be recompiled.

Therefore, I have adapted original Debian's monitoring scripts to Ubuntu:

Ocaml transition monitor for Ubuntu

On the 124 of such OCaml packages in Ubuntu, only 3 have remaining issues:

Once done, all OCaml packages should be correctly rebuild for OCaml 3.11.0. \o/

Of course, OCaml 3.11.1 should be released Really Soon Now™ and all that work should be redone once again. "There is no such thing as a simple job".[2] ;-)

Notes

[1] One can monitor the import of new packages on page http://packages.ubuntu.com/karmic/n....

[2] Tim Daily, of Axiom's fame.

Thu 28 May 2009

Une nouvelle application demexp en web avec web2py

Le projet d'expérience démocratique est un projet de démocratie directe à grande échelle. Il a démarré il y a quelques années déjà mais il a du mal à décoller, en particulier par manque d'un logiciel adapté. En effet le projet nécessite un logiciel de vote électronique en ligne ayant des caractéristiques bien particulière comme le vote Condorcet, une délégation possible du vote, à tout moment possibilité de changer un vote, etc. J'avais écris un serveur et un client lourd (en OCaml) pour remplir ce rôle mais les développements ont stagné pour diverses raisons : manque de motivation de ma part, trop de choses encore à faire, client lourd trop compliqué à déployer et à maintenir, langage OCaml peu connu donc je suis le seul développeur sur le projet, etc.

Hors, très récemment, une nouvelle application est apparue, programmé par Jean-Marc Fauché : une implémentation des idées de demexp en technologie web. Plutôt que de partir de mon code, Jean-Marc redémarre de zéro en langage Python, en utilisant le framework web2py.

Les caractéristiques de web2py sont intéressantes :

  • un déploiement aisé des applications : on peut télécharger une application dans un serveur existant ou récupérer une application existante à partir d'un serveur ;
  • on peut développer l'application en ligne : base de données, modèles et vues (même si à mon avis ce n'est pas forcément très utile pour de grosses applications) ;
  • les rapports d'erreurs (exceptions) sont accessibles en ligne, par l'interface d'administration ;
  • le déploiement est hyper-simple : unzip web2py_src.zip && python web2py/web2py.py ;
  • web2py est organisé autour de l'architecture modèle-vue-contrôleur et incite à utiliser ce modèle ;
  • le système de template utilise le langage Python plutôt qu'un autre langage ad hoc ;
  • un système de traductions en ligne, là aussi par l'interface d'administration ;
  • la base de donnée est vue au travers d'objets Python et toute modification des descriptions de la base est répercuté sous forme de commandes SQL de mise à jour de la base ;
  • et bien sûr un soin tout particulier apporté au framework pour faire des applications web sûres par défaut.

En bref, web2py semble la plate-forme idéale de prototypage rapide d'applications web, améliorant les idées trouvées dans d'autres frameworks comme Django ou Ruby on Rail. Pour des développements longs et importants, je ne suis pas sûr qu'il soit totalement satisfaisant, les aspects dynamiques de Python ont leurs limites (qui ne connait pas le typage fort d'OCaml ne peut pas comprendre le sens de la vie ;-). Mais il faut reconnaître a développé en quelques semaines une application qu'on peut tester et facilement déployer.

J'ai installé un dépôt Mercurial pour consulter le code de Jean-Marc. Si vous voulez tester son code, sa dernière version publiée est utilisable sur ce site temporaire : http://bentobako.org:8000/Demexp/.

En guise de conclusion, l'expérience démocratique semble redémarrer et on ne peut que s'en réjouir.

Mon 09 Mar 2009

OCaml revisions for each Ubuntu release

OCaml revision in Ubuntu for a given release depends more or less of the OCaml revision in Debian unstable at the time the Ubuntu release is started. Here is a short reminder of OCaml revisions for recent Ubuntu releases:

  • Hardy Heron (8.04): OCaml 3.10.0
  • Intrepid Ibex (8.10): OCaml 3.10.2
  • Jaunty Jackalope (9.04): OCaml 3.10.2
  • Karmic Koala (9.10): (probably) OCaml 3.11.0

As a reminder, the current official OCaml release is 3.11.0 and Debian unstable is currently also migrating to 3.11.0 (you can see its progress on Debian OCaml transition monitor). The probability is high that this transition will be finished or at least in good shape before the Debian Import Freeze of Karmic on June the 25th.

Thu 05 Mar 2009

Some comments on extprot

I recently discovered extprot. extprot is a "long-term binary encoding for cross-language communication and long-term serialization". In short, this is a protocol that can be used to encode messages between two different computers, similarly as ONC-RPC, XMP-RPC, ANS.1, Corba, Java RMI, SOAP or Google's Protocol Buffers, amongst others. And of course, extprot is Free software under MIT license.

extprot has interesting properties:

  • it is extensible: one can add new data types without breaking compatibilities with previous version of the encoding;
  • it is descriptive: one describes the message format and a compiler produces encoding and decoding code for a specific programming language;
  • it is self-delimiting: each message or part of a message has its own length, allowing to skip it if not needed or unknown to the decoder;
  • it is self-describing: each part of a message contains a basic type, allowing to decode the message even if the overall message description is unknown.

Overall, I found the description and rationale behind extprot quite interesting. I share the same views as Mauricio Fernández, extprot's author, regarding the compactness and efficiency of binary protocols compared to textual ones, like XML-RPC or SOAP. Having used ONC-RPC in a project of my own, the descriptive aspect is quite useful and I have experimentally verified that a binary encoding is much more network efficient than a textual one. Compared to ONC-RPC, extprot adds the self-describing aspect and support certain data types specific to OCaml, like Sum types or Polymorphic types.

However, extprot is a non-standard, proprietary protocol.

After looking at the binary encoding of the protocol, I made a few observations:

  1. The wire_type within the prefix of each piece of data is encoded over 4 bits, 16 values. 10 values are already used, leaving only 6 left, not accounting the use of the least significant bit. I would suggest to use a bit larger encoding, over 5 or 6 bits;
  2. In the encoding of signed integer with vints, the 63rd bit is put in zero position, in fact limiting values to 64 bits. It might be better to allow encoding of 128 bits or more integers in the future;
  3. The endianess of Bits32 and Bits64_long integers is not specified;
  4. There are no unsigned integer for 32 and 64 bits integer. They are necessary so as not to loose the semantics of those integers, even if one could encode them as vints;
  5. There are no 32 bits floats.

I'm not sure of the rationale behind the current scheme, except it is very OCaml oriented (which is not a bad point for me ;-). In light of those remarks, I would suggest following modifications:

  • Drop Bits32 and Bits64_long types and encode all integers (except 8 bits and booleans) as vints, so as to simplify the encoding. As a side effect, there is no need to specify the endianess of integers;
  • Increase the wire_type size to 6 bits (64 values);
  • Introduce vints tags for signed_int32, unsigned_int32, signed_int64, unsigned_int64. It might impact performance a little but I'm pretty sure the overhead is negligible on modern processor with carefully craft code;
  • The encoding/decoding of signed vints depends on the tag value, so that we have (n >> 63) for signed_64bits, (n >> 31) for signed_32bits, etc.;
  • Eventually, introduce float_32bits, even if I don't see how they could be mapped on OCaml's 64 bits floats.

extprot is an interesting proposal, with the (relative) simplicity and efficiency of binary encoding of ONC-RPC, with the added bonus of being self-describing as XML based protocols like XML-RPC or SOAP. However, extprot is not a standard, limiting its attractiveness compared to other protocols like ASN.1 or Corba.

A real comparison of those different protocols would be quite interesting, but this is too much work for this simple blog entry.

Thu 26 Feb 2009

List of Ubuntu patches applied to Debian OCaml packages

I have updated my set of pages around OCaml packages in Debian and Ubuntu with a page that lists the Ubuntu patches applied to Debian OCaml packages. The page is updated daily.

I also published the source code of those hacks^Wscripts. The compute script is called in a cron job.

Mon 23 Feb 2009

  • David Mentré
  • Web
  • 5

Serveurs web haute performance

Une remarque de Jean-Marie m'a rappelé que la plupart des sites web actuels sont vraiment lents (un exemple au hasard ? Voyages-sncf.com bien sûr !) alors que nos machines, disques durs et réseaux sont de plus en plus rapides ! La principale cause, comme d'habitude, c'est que l'on utilise de plus en plus de logiciel dynamique et plus ou moins interprété comme du PHP ou du Python. Mais un composant essentiel de la pile web, c'est quand même le serveur web. Et celui que la plupart des gens utilise, Apache (52% de part de marché en janvier 2009), est il faut le dire une vraie bouse. Heureusement, le monde du Libre est formidable : il y a des alternatives ! \o/

La première alternative, c'est lighttpd (prononcer lighty) et c'est celui que j'utilise sur mon serveur web. Subjectivement, c'est vrai qu'il est rapide. Il se lance ou se relance en un clin d'œil et le fichier de configuration a une syntaxe plutôt agréable. Et objectivement, il est rapide d'après des tests faits par Fred sur deux machines identiques. ;-) Malheureusement, sa documentation est plutôt légère : quand je me pose des questions sérieuses sur un module, par exemple l'ordre d'interprétation des règles de ré-écriture d'URL, je ne trouve pas d'information détaillée. Par contre, comme il est utilisé par beaucoup de gros sites pour leurs parties statiques (YouTube, Wikipédia, ...), on peut supposer qu'il est correctement programmé du point de vue sécurité.

L'autre prétendant, c'est nginx. Pour lui, je n'ai pas trop d'expérience. Il fait un peu fouilli puisqu'il fait, en plus de serveur web, mail proxy server. Et j'ai entendu dire qu'il y avait des bugs et que les développeurs étaient plus intéressés à rajouter de nouvelles fonctionnalités qu'à les corriger : un peu embêtant pour un serveur web accessible à la sauvagerie du Wild Wide Web. Mais bon, ce ne sont que des ouïes dire, à vérifier donc.

Le troisième prétendant, petit nouveau dans l'arène, c'est Cherokee, que j'ai découvert grâce aux notes de version de la toute nouvelle Debian Lenny. :-) Cherokee a l'air très sympa (outre son logo ;-) : configuration par une interface web (sécurisée par mot de passe unique et ssh) mais sauvegardée dans un fichier texte, documentation qui a l'air complète, et toutes les fonctionnalités qu'on peut attendre d'un serveur web moderne : équilibrage de charge, ré-écriture d'URL, support de FastCGI et consorts, serveurs virtuels, etc. Et surtout, il est rapide... enfin d'après leurs propres benchmarks. :-) Mais bon, j'envisage à moyen terme de le tester à la place de lighttpd.

Enfin, mon outsider, c'est Ocsigen. Plus qu'un serveur web, c'est un environnement de développement complet, en OCaml, qui est intégré au serveur web. Et depuis la dernière version 3.11 du compilateur OCaml qui permet de charger des modules de code natif dans un programme OCaml, Ocsigen fonctionne en code natif ! Cela veut dire que l'on a un environnement de développement web avec toutes les bonnes propriétés d'OCaml (typage fort à la compilation, y compris sur des requêtes SQL de PostgreSQL, garbage collector performant, beaucoup de bibliothèques, ...) et qui en plus produit du code natif, donc réellement efficace (comme le montre ces tests de Dario Teixeira). Cela me semble la meilleur combinaison pour faire des sites web qui poussent ! Évidemment, il faut programmer en OCaml et surtout se faire à l'environnement d'Ocsigen, ce qui n'est pas aussi simple qu'en PHP par exemple. Mais même en tant que simple serveur web de pages statiques, Ocsigen se compare correctement à lighttpd et Apache, sans toutefois être aussi performant. Et bien sûr, pour les sites dynamiques, il est nettement plus rapide que Ruby (qui certes n'est pas le langage le plus rapide) !

Face à Apache, tous ces serveurs web ont beaucoup d'avantages mais un gros inconvénient : les logiciels web sont tous conçus pour Apache. Donc il faut souvent adapter la configuration du serveur web, notamment dans la gestion des droits d'accès (configuration équivalente aux .htaccess). Rien de bien mortel, mais c'est toujours du travail en plus et on a toujours le risque de faire une erreur.

En tout cas, une chose est sûre, la liberté et la dynamique du Libre nous permet d'avoir des solutions réellement innovantes. Il ne vous reste plus qu'à les utiliser. ;-)

Thu 19 Feb 2009

Up-to-date status of OCaml packages on Ubuntu

I have set-up a set of scripts that give the status of OCaml packages on Ubuntu. As there is no OCaml packagers on Ubuntu, nearly all OCaml packages of Ubuntu are directly imported from Debian during the synchronization periods between Debian sid and Ubuntu. Those pages are made to help the job of Debian developers. They are doing a wonderful jobs regarding packaging of OCaml software on Debian and they are interested in helping the OCaml support on Ubuntu.

So, on those very basic pages, you'll find:

In all the above files, the format is:

 debian-source-package  distro-release  ocaml-compiler  package-version

Those lists of packages are made with quickly hacked scripts from Debian's OCaml developers:

page 2 / 2