Olivier Mengué – Code & rando

Note: I'm posting this on my blog because since May 2011 GitHub is gone in submarine mode: the Google group is closed, support requests are not public anymore and users can't keep track of their past support requests. And I got no response to the last feature request I submitted.

When my repo is a fork, I would like to be able to fast-forward all the branches that exist in my repo to the latest commit on that branch in the parent repo.
The user inteface would be a single button at the left of "Pull request".
Of course, the process should fail for branches where fast-forward (as defined by git merge) is not possible. For example if I committed directly in a branch of the parent repo (instead of branching before committing) of if the parent has done dirty things with his repo. This is a merge conflict.
The process should also warn me about branches that have been added/removed in the parent repo compared to mine and give me the option to do the same (a list of branches with checkboxes to select the ones to pull/keep/delete). The default action must be conservative (not remove the local branches if they have not been merged into another branch of the parent repo ; not add branch from the remote repo which are locally missing but have been merged into another branch of the parent repo).

Github should also warn me when I'm submitting a pull request but the local branch from which I branched for my patch is not fast-forwarded. This probably means either I missed recent commits of the parent (so my patch may not be relevant anymore) or that I did the fast-forward (on a working repo not on Github) but did not push it to GitHub.

I'm currently playing with XSLT to improve my XMLTV grabbing solution. Much fun playing with a functionnal language available in most web browsers.

I had the need to handle timezone with daylight savings to display date/times in my timezone, Europe/Paris (same as most of western Europe), which has currently the following definition (I'm not interested in history for this project):

• Winter is UTC + 01:00
• Summer is UTC + 02:00
• Transition from winter to summer occurs on the last sunday of March at 01:00 UTC
• Transition from summer to winter occurs on the last sunday of October at 01:00 UTC

So I wrote the following template date-time-Paris which is very specialized as it handles only one specific timezone, but it is very fast. I'm using only two extensions from EXSLT: date:day-in-week() and date:add().

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:tap="test:tap"
  xmlns:date="http://exslt.org/dates-and-times"
  extension-element-prefixes="date"
  >

  <!-- Transformation de l'heure UTC en heure de Paris -->
  <!-- Copyright (c) 2008 Olivier Mengué -->
  <xsl:template name="date-time-Paris">
    <!--
      Daylight savings transitions:
      - last sunday of March at 1:00 UTC
      - last sunday of October at 1:00 UTC
      Time offsets:
      - winter: +01:00
      - summer: +02:00
    -->
    <xsl:param name="date-time-Z"/><!-- UTC -->
    <xsl:variable name="len" select="string-length($date-time-Z)"/>
    <xsl:variable name="seps" select="translate($date-time-Z, '0123456789', '')"/>
    <xsl:if test="$len &lt; 11 or substring($date-time-Z, $len, 1) != 'Z' or ($seps != '--T::Z' and $seps != '--T::.Z' and $seps != '--Z' and $seps != '--TZ' and $seps != '--T:Z')">
      <xsl:message terminate="yes">date-time-Paris: date '<xsl:value-of select="$date-time-Z"/>' invalide.</xsl:message>
    </xsl:if>
    <xsl:variable name="month" select="number(substring($date-time-Z, 6, 2))"/>
    <xsl:variable name="offset">
      <xsl:choose>
        <xsl:when test="$month &lt; 3 or $month &gt; 10">1</xsl:when>
        <xsl:when test="$month &gt; 3 and $month &lt; 10">2</xsl:when>
        <xsl:otherwise>
          <xsl:variable name="transition-day" select="32 - date:day-in-week(concat(substring($date-time-Z, 1, 7), '-31Z'))"/>
          <xsl:variable name="less" select="translate(substring($date-time-Z, 8), '-T:Z', '') &lt; $transition-day*1000000+10000"/>
          <xsl:value-of select="1+number(($less and $month = 10) or (not($less) and $month = 3))"/>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:variable>
    <xsl:value-of select="concat(translate(date:add($date-time-Z, concat('PT', $offset, 'H')), 'Z', ''), '+0', $offset, ':00')"/>
  </xsl:template>

The implementation is really short, however it is quite complex as XSLT 1.0 requires to uses many tricks to workaround languages limitations (no native date type, no string order, no xor operator). Here are some tips to follow the code:

• (a xor b) is equivalent to ((a and not(b) ) and (not(a) and b)).
• number(true()) is 1, number(false()) is 0.
• March and October have the same number of days: 31.
• $transition-day*10000000+10000 for october 2008 (26010000) is an number representation of 2008-10-26T01:00:00Z.
• the second argument to date:add() is a ISO 8601 duration. Ex: PT2H (2 hours).

In fact I present here the fourth version of the code, the first one was much longer (5x) as I was using intermediate templates for computations (last-sunday-of-month, previous-sunday). Of course the key to debug, and then optimise and refactor the implementation was to start with a good test suite. The test suite is of course written in XML and embedded in the stylesheet so it can evolve with the code.

  <tap:suite name="date-time-Paris" xmlns:t="test:date-time-Paris">
    <t:t dt="2008-09-24T21:37:52Z"     r="2008-09-24T23:37:52+02:00"/>
    <t:t dt="2008-09-24T23:37:52Z"     r="2008-09-25T01:37:52+02:00"/>
    <t:t dt="2008-09-24T23:37:52.325Z" r="2008-09-25T01:37:52.325+02:00"/>
    <t:t dt="2008-10-01T00:00:00Z"     r="2008-10-01T02:00:00+02:00"/>
    <t:t dt="2008-10-26T00:59:59Z"     r="2008-10-26T02:59:59+02:00"/>
    <t:t dt="2008-10-26T01:00:00Z"     r="2008-10-26T02:00:00+01:00"/>
    <t:t dt="2008-10-31T12:00:00Z"     r="2008-10-31T13:00:00+01:00"/>
    <t:t dt="2008-11-24T21:37:52Z"     r="2008-11-24T22:37:52+01:00"/>
    <t:t dt="2008-12-31T23:30:00Z"     r="2009-01-01T00:30:00+01:00"/>
    <t:t dt="2009-01-01T00:00:00Z"     r="2009-01-01T01:00:00+01:00"/>
    <t:t dt="2009-03-01T12:00:00Z"     r="2009-03-01T13:00:00+01:00"/>
    <t:t dt="2009-03-29T00:59:59Z"     r="2009-03-29T01:59:59+01:00"/>
    <t:t dt="2009-03-29T01:00:00Z"     r="2009-03-29T03:00:00+02:00"/>
    <t:t dt="2009-03-30T12:00:00Z"     r="2009-03-30T14:00:00+02:00"/>
    <t:t dt="2009-07-01T00:00:00Z"     r="2009-07-01T02:00:00+02:00"/>
  </tap:suite>

A more complete testsuite can be generated from a local dump of the zoneinfo database (directly works on Ubuntu Hardy, however the zdump tool is missing on RHEL/CentOS):

zdump -v Europe/Paris | perl -ne 'm/ (Mar|Oct) (\d{2}) (\d{2}:\d{2}:\d{2}) (20[0-5]\d) UTC = ... (?:Oct|Mar) (\d{2}) (\d{2}:\d{2}:\d{2}) / && do { my $mm = sprintf "%02d", 3+7*($1 eq 'Oct'); print "    <t:t dt=\"$4-$mm-$2T$3\" r=\"$4-$mm-$5T$6\"/>\n"; }'

Now, we need is a way to run the test suite. In XSLT terms, we say: "to apply a template to the test data". This template will just apply a date-time-Paris call to each of the tests.

  <xsl:template match="t:t" xmlns:t="test:date-time-Paris">
    <xsl:call-template name="tap:is">
      <xsl:with-param name="got">
        <xsl:call-template name="date-time-Paris">
          <xsl:with-param name="date-time-Z" select="@dt"/>
        </xsl:call-template>
      </xsl:with-param>
      <xsl:with-param name="expected" select="@r"/>
      <xsl:with-param name="name" select="@dt"/>
    </xsl:call-template>
  </xsl:template>

</xsl:stylesheet>

We now have a complete stylesheet that can be used as a library in other stylesheet. But we have not yet run the tests. Also you probably wonder what are this XML namespace test:tap and the template called tap:is.

test:tap is just a small XSLT test framework that I wrote and the report test results following the Test Anything Protocol that is well known by Perl programmers. tap:is is part of the test:tap API and just check for equality and reports in the TAP format.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:tap="test:tap"
  >

  <!-- Run all the tests in the test suite -->
  <xsl:template match="tap:suite">
    <xsl:message>1..<xsl:value-of select="count(node()[name()!=''])"/></xsl:message>
    <xsl:message># Suite: <xsl:value-of select="@name"/></xsl:message>
    <!-- TODO fix this expression -->
    <xsl:apply-templates select="node()[name()!='']"/>
  </xsl:template>

  <!-- Test Anything Protocol style reporting of tests -->
  <xsl:template name="tap:is">
    <xsl:param name="got"/>
    <xsl:param name="expected"/>
    <xsl:param name="name"/>
    <xsl:choose>
      <xsl:when test="$got = $expected">
        <xsl:message>ok <xsl:value-of select="position()"/> - <xsl:value-of select="concat($name, ' -&gt; ', $got)"/></xsl:message>
      </xsl:when>
      <xsl:otherwise>
        <xsl:message>not ok <xsl:value-of select="position()"/> - <xsl:value-of select="$name"/></xsl:message>
        <xsl:message>#          got: <xsl:value-of select="$got"/></xsl:message>
        <xsl:message>#     expected: <xsl:value-of select="$expected"/></xsl:message>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

</xsl:stylesheet>

We now have two libraries. Let's add a bit more XSLT to glue them together. The main stylesheet applies tap:suite templates to all tap:suite from all imported stylesheets.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  >

  <!-- Test framework -->
  <xsl:import href="tap.xslt"/>

  <!-- All stylesheets to test -->
  <xsl:import href="date-time-Paris.xslt"/>

  <!-- Launch the tests embedded in libraires, whatever the input is -->
  <xsl:template match="/">
    <xsl:for-each select="document('')/xsl:transform/xsl:import/@href">
      <xsl:apply-templates select="document(.)//tap:suite" xmlns:tap="test:tap"/>
    </xsl:for-each>
  </xsl:template>

</xsl:transform>

We now have everything to run the test suite:

$ echo '<x/>' | xsltproc tap-run.xslt -
1..15
# Suite: date-time-Paris
ok 1 - 2008-09-24T21:37:52Z -> 2008-09-24T23:37:52+02:00
ok 2 - 2008-09-24T23:37:52Z -> 2008-09-25T01:37:52+02:00
not ok 3 - 2008-09-24T23:37:52.325Z
#          got: 2008-09-25T01:37:52.3249999999998+02:00
#     expected: 2008-09-25T01:37:52.325+02:00
ok 4 - 2008-10-01T00:00:00Z -> 2008-10-01T02:00:00+02:00
ok 5 - 2008-10-26T00:59:59Z -> 2008-10-26T02:59:59+02:00
ok 6 - 2008-10-26T01:00:00Z -> 2008-10-26T02:00:00+01:00
ok 7 - 2008-10-31T12:00:00Z -> 2008-10-31T13:00:00+01:00
ok 8 - 2008-11-24T21:37:52Z -> 2008-11-24T22:37:52+01:00
ok 9 - 2008-12-31T23:30:00Z -> 2009-01-01T00:30:00+01:00
ok 10 - 2009-01-01T00:00:00Z -> 2009-01-01T01:00:00+01:00
ok 11 - 2009-03-01T12:00:00Z -> 2009-03-01T13:00:00+01:00
ok 12 - 2009-03-29T00:59:59Z -> 2009-03-29T01:59:59+01:00
ok 13 - 2009-03-29T01:00:00Z -> 2009-03-29T03:00:00+02:00
ok 14 - 2009-03-30T12:00:00Z -> 2009-03-30T14:00:00+02:00
ok 15 - 2009-07-01T00:00:00Z -> 2009-07-01T02:00:00+02:00

So now I know that I have a failing test due to rounding occuring. For my XMLTV project it is not important as I will not have to handle decimal seconds.

Il est possible d'utiliser et de modifier sous Windows les données d'une base de données Microsoft Access sans le logiciel Microsoft Access.

Le pilote d'accès aux bases de données Access, Microsoft Jet Engine, est depuis longtemps un composant intégré à Windows. Voici comment paramétrer OpenOffice.org 2.4 sous Windows pour utiliser une base et ainsi profiter du requêteur graphique (semblable à celui d'Access), réaliser des mailings, etc.

Les journées Perl 2008 auront lieu à la fin du mois à Albi. Une fois de plus je ne présenterai pas de Perl. Il y a un an et demi j'avais présenté l'ORM de Django aux Journées Perl 2006. Cette fois-ci, ce ne sera pas du Python, mais du shell Unix (ksh, bash...) : ma présentation est intitulée Mieux programmer en shell. Le contenu sera fortement inspiré du guide de style non officiel d'OpenSolaris.

Mise à jour : voici les dispositives de ma présentation « Mieux programmer en shell ».

Nothing is as good as a old Unix shell for running and monitoring batchs. Here is a proposition for a simple framework that will improve readabilty of the code while increasing error reporting in the output.

Suite à mon précédent post, j'ai profité qu'exiftool est un module Perl pour re-développer en Perl mon outil de rotation des images JPEG vraiment sans perte. Voici ci-dessous le code et les astuces pour l'intégration dans Nautilus.

TiddlyWiki is a standalone wiki that is fully interactive and fully contained in a single HTML file. Here is a tip to add a favicon to your wiki.

To enable saving you have to give to the browser some special permissions allowing the JavaScript code to write to your disk. When using it with Microsoft Internet Explorer, the easy way to enable saving is to just rename your wiki as .hta to transform it into an "HTML Application", as Microsoft calls it.

But you can do better with HTML Applications than just decreasing the security level. I was particularly interested in a better integration with Windows. I wanted in particular to change the icon of the window that appears in the taskbar (I commonly have about 30-40 windows opened on my desktop). This is quite easy: you just have to add an <HTA:APPLICATION ICON="myfile.ico"> tag the <head> section of the HTML file.

Here is how to do it the TiddlyWiki way:

1. Get an icon and save it as tiddlywiki.ico in the same directory as your wiki.hta file. For example: http://www.tiddlywiki.org/favicon.ico. You can also create you own icon here or here.
2. Edit the built-in tiddler MarkupPreHead
3. Insert the following text just after <!--{{{-->:

   <!--[if IE]>
   <HTA:APPLICATION ID="oHTA" APPLICATIONNAME="My wiki" ICON='tiddlywiki.ico'/>
   <![endif]-->
   <link rel='shortcut icon' href='tiddlywiki.ico' type='image/vnd.microsoft.icon '/>
   

4. Reload your wiki.hta. That's it!

I now have to explore how to convert this to a plugin...

Le site Vélib’ utilise des services web pour afficher les informations sur les stations :

• la liste statique des stations : numéro, nom, adresse, latitude, longitude ;
• les informations dynamiques sur une station : vélos disponibles, emplacements libres, impression de tickets.

Voilà donc une occasion d'expérimenter Yahoo! Pipes, l'application web de développement et d'hébergement de scripts de traitement de données du web.

J'ai réalisé ces quelques « pipes » utilisant les services web Vélib’ :

• des tuyaux orientés utilisateur final (tags : Vélib’, Paris) :
  • Vélib’ : disponibilité de plusieurs stations : afficher d'un coup le nombre de vélos et de places disponibles sur 1 à 4 stations. Mieux que sur le site officiel !
  • Vélib’ : localiser une station par son numéro
  • Vélib’ : toutes les stations : la liste des stations avec leurs coordonnées dans le format attendu par Yahoo! Pipes pour l'affichage sur une carte.
• des tuyaux orientés développeur, c.à.d. des interfaces Yahoo! Pipes à réutiliser (tags : Vélib’, Paris, api) :
  • API Vélib’ : infos statiques station brutes
  • API Vélib’ : infos dynamiques station brutes

J'ai voulu créer un pipe recherchant toutes les stations autour d'une adresse donnée. Récupérer une adresse est facile avec le tuyau Location Builder. Mais j'ai rencontré un obstacle insurmontable lorsque j'ai voulu comparer les coordonnées latitude/longitude obtenues avec celles des stations : il impossible de manipuler des nombres flottants et même de convertir du texte en nombre.

Bilan de cette utilisation de Yahoo! Pipes dans Firefox globalement positif :

• Le concept est génial : c'est la programmation fonctionnelle appliquée aux données structurées du web !
• L'interface d'enchaînement des tuyaux est très intuitive. Le drag'n drop est parfait : on oublie que l'on est dans une appli web et on est vraiment dans un outil de développement.
• Le debogueur est génial ! On visualise facilement le résultat de chaque étape de la plomberie.
• C'est bien plus facile à développer et déboguer que XSLT !

Néanmoins l'étiquette « beta » reste de rigueur :

• l'API, c.à.d. la liste des tuyaux disponibles, n'est pas très intuitive : je n'ai pas compris la logique du classement
• la documentation des tuyaux est inexistante : Yahoo! ne propose qu'un exemple comme forme de documentation.
• la documentation de l'affichage de la sortie des tuyaux est aussi inexistante : les éléments title ou y:location.lat/y:location/lon sont particuliers dans l'affichage final, mais il n'existe nulle part de liste complète de ces éléments.
• l'API est plutôt incomplète : j'aimerais pouvoir traiter des nombres flottants tels que des coordonnées (latitude, longitude)
• les regex soit-disant « Perl-like » ne le sont pas. Par exemple \L fonctionne pour mettre en minuscules, mais pas \E. Et comme rien n'est documenté...
• les transformations de types sont laborieuses : le concept d'« item » est nouveau par rapport à d'autres langages de programmation, mais n'est expliqué nulle part. C'est un Item builder qu'il faut utiliser pour convertir du texte en item, mais il est rangé dans la catégorie des Sources. La réorganisation de l'arbre d'un item se fait en utilisant un tuyau Rename. Et il est impossible de convertir du texte en nombre...

Suite à un message sur la liste des Mongueurs de Perl à propos d'encodage de caractères, j'ai fait un petit historique des jeux de caractères que j'ai utilisés depuis 1989 :

J'étais en full cp437 sous MS-DOS.

Je suis passé au cp437/cp1252 avec Windows. J'ai résisté au passage à cp850 pour garder le jeu complet de caractères semi-graphiques de cp437.

Avec Unix/Linux j'ai ajouté iso-8859-1 vers 1993.

Avec Windows NT, j'ai abandonné finalement cp437 au profit de cp850, toujours utilisé dans les fenêtres DOS.

L'euro est apparu et je suis passé à iso-8859-15 sous Linux.

Depuis Windows 2000, RegEdit 5 enregistre ses fichiers en « Unicode » (comme dit Microsoft), c'est à dire ucs-2le. C'est donc un encodage de plus que j'utilise régulièrement.

Coté Linux, j'ai abandonné iso-8859-{1,15} pour utf-8 (merci à RedHat d'avoir initié ce changement sur l'ensemble d'une distrib). Mon Nokia N800 est aussi en UTF-8. Malheureusement je bosse encore aussi sous Solaris et AIX qui ne connaissent pas UTF-8 pour les locales de base.

Les encodages de caractères que j'utilise actuellement régulièrement sont donc ASCII, utf-8, cp1252, cp850, ucs-2le et iso-8859-1.

Bref, le « full utf-8 », c'est à dire un environnement où toutes les données texte sont uniquement encodées en UTF-8, est pour moi un mythe. La compatibilité avec les anciennes applications, les anciens formats de fichiers ou les systèmes d'exploitation où UTF-8 n'est pas l'encodage primaire nécessite la manipulation de multiples encodages.

Ma solution : avoir la boîte à outils qui me permette d'éditer les fichiers de la façon la plus transparente possible (détection au chargement d'un fichier texte) et de faire facilement les transformations nécessaires. Et si on travaille sur plusieurs plate-formes, il faut que la boîte à outils soit également portable.

Ma boîte à outil, c'est Vim, avec ces paramètres :

" List of encodings for autodetect
if has('win32') || has('win64')
  set fileencodings=ucs-bom,utf-8,cp1252
else
  set fileencodings=ucs-bom,utf-8,iso88591
endif