Today I will share some tips with SSH. It is very useful everytime even with crappy OS like Windows. One of the most funny feature is the TCP forwarding by Reverse SSH. For example in the case where you must connect to a SSH server and this one is behind a firewall. You have no access to the firewall because you are at work.

First one

You must connect the computer (behind the firewall) to a server available on Internet (at home).

ssh -R 8888:localhost:22 homeuser@homeip

It will create an SSH tunnel with your computer at home. You can choose an other port; 8888 is just for the example.

Second one

At home, you can connect to your computer at work by this way :

ssh workuser@localhost -p 8888

Easy, isn’t it? Note that is possible to forward every things with SSH. All local servers in your company…

But, with Windows it’s a pain

Not really, just use Cygwin. You can install openssh-server with the packages manager. Just use ssh-host-config -y from the Cygwin terminal. Start the terminal with admin rights if necessary. A service will be installed in order to start openssh. Start the service and enjoy.

You should search on the web for more examples and tips. Here you will found the essential.

Bye

Mathieu Schroeter

Some tips about a way to restore a very big gunzip’ed image disk from a network share. I’ve changed of computer and my previous disk was saved in a image with `dd` and a pipe on gunzip. The image is located on a network share. But I can not restore the whole image because it uses too much spaces. Then, I will mount this one but it was compressed. The solution is `mountavfs`. You can use this command in order to open compressed files on the fly.

The steps are something like this:

avfsd -o allow_root ~/.avfs
mountavfs

Look at avf.sourceforge.net

sudo mount -t nfs 192.168.1.1:backup ~/mybackup

Just my backup; mount yours as usual…

cd ~/.avfs/home/myuser/mybackup

Here, I will found my image disk file.

sudo mount -o ro,loop,offset=$((63 * 512)) backup.img.gz ~/dst

I mount my file from the ~/.avfs directory (then it will be uncompressed on the fly). I must specify the partition offset because the image is the whole disk with a GPT structure. Look for fdisk, gdisk in order to retrieve the offset. The first seems to be always 63th bloc.

Now you can see the whole content of your gunzip’ed image in the ~/dst directory.

Mathieu SCHROETER

J’ai publié une nouvelle version de libvalhalla qui remet à jour les grabbers Amazon et TMDB. C’était principalement des problèmes de changement d’API chez ces deux services. A noter que les grabbers qui se basent sur des scripts PHP maison sont cassés mais non-réparés. Je pense à Allocine et ImDB. Mais pour ces deux grabbers il faut être clair, sans vrai webservice c’est très pénible à maintenir. Il existe un webservice caché pour Allocine et j’ai cet API sous la main. Par contre je ne sais pas si c’est encore fonctionnel (car l’API que j’ai a plus d’une année) et peut être que depuis tout ce temps il y a quelque chose d’officiel. En ce qui concerne ImDB j’en ai aucune idée.

A part ça il y a quelques changements plus spécifiques. Je vous invite à consulter le ChangeLog.

Site : http://libvalhalla.geexbox.org

Sources : http://libvalhalla.geexbox.org/releases/libvalhalla-2.1.0.tar.bz2

Bye bye

Mathieu

Il y a beaucoup de choses que l’on apprend pas du tout dans les cours de programmation, et même en suivant une haute école pour une formation en tant qu’ingénieur. Heureusement les logiciels libres permettent de côtoyer des spécialistes qui ont une expérience pratique du logiciel, contrairement à de nombreux professeurs qui ne connaissent que la théorie mais ne semblent pas vraiment pratiquer et passent ainsi à côté de potentiels problèmes importants. Je pense tout particulièrement au C dans le contexte des exécutables ELF utilisés par les OS Unix-like. Bien que beaucoup d’écoles restent encore trop rattachées sur les technologies Microsoft, dans le monde des systèmes embarqués GNU/Linux est particulièrement présent. Néanmoins la formation sur le langage C n’est pas toujours très bonne. Une erreur trop courante concerne les espaces de nom utilisés par les bibliothèques.

Les fonctions « static »

Quand j’étudiais le C++ à l’école d’ingénieur on devait travailler avec un outil que je déteste absolument, c’est Rhapsody. Un générateur de code à partir d’UML. L’UML c’est très bien pour poser les idées et réfléchir sérieusement sur un programme. Mais le fait qu’un langage de programmation ne soit pas objet ou orienté-objet n’empêche pas de se donner des règles reposants sur les concepts objets. Bref, Rhapsody c’est pire que tout, il génère du code (C, C++ ou autre) à partir d’UML. Finalement le programmeur fait du dessin, des carrés, des ronds et les relie avec des flèches. Il presse un bouton et des centaines de lignes de code se génèrent. Wouhaw.. moi qui aime programmer.. Bientôt on devra se former en tant que graphiste avant de réaliser un logiciel :-).

OK vous l’aurez compris, je déteste ça. Mais là où je veux en venir c’est à une petite anecdote. On travaillait donc sur ce logiciel et un des objet était instancié une seule fois (donc en tant que Singleton). Alors je demande à l’assistant qui était présent avec nous pour répondre à nos questions:

Qu’est-ce que c’est concrètement un Singleton?

Il s’assied et m’explique ce que je sais déjà, c’est à dire que l’objet est instancié qu’une seule fois. Il me montrait via l’interface de Rhapsody comment on paramètre la classe pour être un Singleton. Et me ré-expliquait toujours la même chose. J’essayais de reformuler ma question en vain. C’est finalement en allant observer le code C généré que j’ai vu l’objet instancié en tant que variable globale statique.

5 secondes pour lire le code et comprendre, 15 minutes d’explication dans le monde « merveilleux » de Rhapsody et des formes géométriques.

Mais revenons à nos fonctions statiques

Une chose que tout le monde apprend aux cours c’est qu’une variable déclarée comme étant « static » dans une fonction, garde sa valeur entre chaque appel de fonction. Par contre je n’ai jamais eu un seul professeur qui nous ait expliqué à quoi sert une variable globale statique, ou alors une fonction statique (sauf les fonctions statiques en C++, mais ici je fais référence au C).

En fait, il est très rare de voir un professeur proposer de créer une bibliothèque pendant un cours. En principe on créer des exécutables avec un main. En C je n’ai jamais vu (en dehors des logiciels libres et des professionnels), des fonctions déclarées comme étant statiques. Que se sois du code créé par des professeurs ou par des étudiants. Pourtant l’écriture de bibliothèques demandent quelques considérations supplémentaires qui concernent les espaces de nom et plus particulièrement les ELF.

Mais tout d’abord une fonction « static » est une fonction qui n’est pas « extern » (qui est le qualificateur de type par défaut). En étant « static » la visibilité de la fonction est restreinte au fichier source où elle a été déclarée. Une fonction externe peut être atteignable depuis n’importe où dans les sources. Mais dans le cas des ELF c’est encore plus subtile que ça car elle peut être atteinte depuis n’importe quelles bibliothèques ou applications étant liées avec elle.

Les Shared Object (so) et les DLL

Sans partir dans des explications compliquées et inutiles il faut bien faire la différence entre une DLL (de chez Microsoft) et un Shared Object (qui vient du monde Unix). Les développeurs pour Windows connaissent bien:

__declspec(dllexport)

Qui est un qualificateur de type inventé par Microsoft. Il permet de spécifier les fonctions qui doivent être exportées par la DLL. Vous pouvez aussi utiliser un fichier .def qui donne la liste des fonctions à exporter. Ce principe existe aussi avec les gcc >=4 mais est rarement utilisé à ma connaissance. Quoi qu’il en soit dans tous les cas vous avez une liste de symboles exportés.

La différence qui m’intéresse c’est au runtime, lorsque le lanceur d’application doit charger les bibliothèques. Dans le cas d’une DLL, le programme va rechercher les pointeurs sur les fonctions désirées à l’aide de LoadLibrary. C’est lourd mais ça fonctionne. Dans le cas d’un « so » le fonctionnement est très différent. Le lanceur de programme de Linux va charger les bibliothèques les unes après les autres dans l’ordre où elles ont été liées. Lorsque le programme a besoin d’une fonction, c’est la première occurrence trouvée qui sera utilisée.

Concrètement

Imaginons un programme qui utilise libplayer et libvalhalla. Si je n’étais pas conscient du problème que je viens d’expliquer, dans ces deux bibliothèques j’aurais pu écrire une fonction qui a exactement le même nom (de part et d’autre) comme par exemple:

libplayer:

void foobar (int a, int b);

libvalhalla:

void foobar (int c);

Ces fonctions ne sont pas static car bien entendu j’aimerais les utiliser partout dans les projets. Alors que se passe-t-il lorsqu’on lie l’application sur ces deux bibliothèques? Notez que ces deux fonctions ne sont pas non plus déclarées dans les en-têtes « publiques » que vous distribuez à vos développeurs. Par exemple vous donnez ceci à un ami:

player.so (que vous avez compilé vous même)

Et un fichier d’en-tête:

player.h

/* libplayer header */
void libplayer_is_the_best (void);

De même avec la seconde bibliothèque:

valhalla.so
valhalla.h

/* libvalhalla header */
void libvalhalla_is_the_best (void);

Maintenant vous avez créé une application tel que:

#include <player.h>
#include <valhalla.h>

int
main (void)
{
  libplayer_is_the_best ();
  libvalhalla_is_the_best ();
  return 0;
}

Dans libplayer.so il y a le symbole « foobar », mais il existe également dans la bibliothèque libvalhalla.so. Lorsque vous liez votre application vous n’avez aucune erreur. Vous utilisez deux fonctions considérées comme publiques et qui n’ont pas du tout le même nom. Alors où est le problème? Et bien c’est très simple. Quand vous liez votre programme vous devez passer les noms des bibliothèques. Par exemple:

cas 1: gcc -lplayer -lvalhalla main.c -o main

Mais vous auriez aussi pu faire

cas 2: gcc -lvalhalla -lplayer main.c -o main

Les deux façons sont correctes mais le comportement de l’application main n’est pas du tout le même. Les deux bibliothèques utilisent la fonction foobar. Cette fonction n’a pas le même nombre d’arguments dans libvalhalla que dans libplayer et leurs comportements sont différents. Les fonctions libplayer_is_the_best et libvalhalla_is_the_best utilisent « en théorie » leurs propres fonction foobar. Et bien en réalité ce n’est pas le cas.

Dans le cas 1, le chargeur de programme va commencer par player.so, puis par valhalla.so. Lorsque la fonction libplayer_is_the_best va utiliser foobar, alors le foobar de player.so va être utilisé. Mais lorsque valhalla.so va utiliser foobar, c’est aussi le foobar de player.so qui sera utilisé (aïe). Dans le cas 2 c’est le même principe mais inversé. Les conséquences peuvent être très imprévisibles.

Si vous avez une application qui est liée à des dizaines de bibliothèques il faut espérer que tout le monde ait pris la peine de faire deux choses importantes:

1. Utilisez toujours un espace de nom pour vos fonctions. Par exemple libvalhalla en utilise trois  (libvalhalla_, valhalla_ et vh_). Un espace de nom en C ce n’est rien d’autre qu’un nom identique que vous concaténez au début des noms. Par exemple nos foobar auraient pût se nommer libplayer_foobar et libvalhalla_foobar, ce qui aurait évité la collision.
2. Déclarez toujours en static toutes les fonctions qui ne sont pas utilisées en dehors du fichier source. Une fonction static n’a pas besoin d’espace de nom, car elle n’est jamais exportée! Et faire ainsi permet d’aider le compilateur à effectuer de meilleurs optimisations.

Comment détecter et debugger les collisions

Une des solution c’est de compiler votre programme entièrement en static. Il doit donc être lié aux .a de toutes les bibliothèques. Dans ce cas de figure, une collision sera forcément détectée par le linker.

Pour debugger commencez par tout compiler en -O0 -g3, puis utilisez valgrind. Vous arriverez à remonter sur l’appel de fonction qui s’est fait de la libA à la libB. Vous pourriez voir le foobar de player.so appelé par valhalla.so.

En pratique…

Il y a de nombreux mois, j’ai eu des problèmes de ce type avec libVLC et libplayer, car les fonctions de getopt étaient exportées par libVLC bien que c’était uniquement pour son propre usage. Ça me provoquait des collisions avec le getopt que j’utilise dans libplayer-test. J’ai bien entendu reporté le problème qui a été corrigé.

J’ai aussi eu un cas avec GeeXboX et le projet GuPNP. Le développeur principal a aussi été prévenu mais a priori il s’en fiche (ce n’est pas moi qui l’a contacté mais un autre du team). Du coup ce n’est pas possible de lier en static si on utilise deux de ses libs car elles ont les même fonctions non-static pour traiter le XML. Et le pire c’est que le nom de ces fonctions n’a pas d’espace de nom très original. Notez qu’en dynamique il n’y a jamais de problème car heureusement dans les deux bibliothèques, les fonctions sont les mêmes.

Bref, en fouillant bien on doit trouver ce genre d’exemple un peu partout…

J’espère que ce poste vous sera utile pour vos propres développements.

Bon code et à bientôt!

Mathieu SCHROETER

Un « nouveau » (notez bien les guillemets) projet vient de faire surface officiellement de nos dépôts. Il est nommé OpenBricks et son but et de fournir un environnement assisté pour construire sa propre distribution pour l’embarqué (ou pas, c’est pas une obligation). Au premier abord il n’y a rien de bien nouveau dans le principe, car il existe déjà de gros projets qui vont en ce sens tel que OpenEmbedded ou encore Buildroot. La première question étant bien sûr « pourquoi réinventer la roue? » est complètement illusoire dans notre cas. Car bien que ce projet voit le jour uniquement depuis ce mois, en réalité il couvre 8 ans de développement et d’expérience.

Je veux en parler sur mon blog pour une raison en particulier. Je parcours un peu les commentaires sur les news relatives à OpenBricks. Les réactions sont du genre « beuh? à quoi ça sert? quel intérêt? ».

La réponse est très simple et tout simplement incroyable, OpenBricks sert à créer la distribution GeeXboX.

Et un outil de ce genre vaut mieux le rendre un peu plus générique (c’est comme si on avait transformé notre marteau planteur de clous GeeXboX en marteau universel). Avant OpenBricks le toolchain GeeXboX était très orienté sur les spécificités du multimédia et de ce que GeeXboX propose tel que les images ISO, le générateur d’ISO, etc,… Ils arrivaient à certaines personnes d’utiliser notre toolchain à d’autres fins. Je l’ai personnellement hacké pour avoir un petite distribution Linux perso sur mon Palm ainsi que pour un robot de laboratoire. Car bien que le toolchain GeeXboX était très axé sur le multimédia, c’était facile à le modifier pour le dédier à autre chose.

Alors on peut imaginer une autre réponse pour la question « à quoi ça sert? », et bien OpenBricks sert à créer une distribution pour différentes applications et sans devoir bidouiller (contrairement à l’époque).

Que du positif! non?

A+

Mathieu SCHROETER

J’avais déjà écrit un article sur Vim il y a pas mal de temps. J’indiquais simplement ma configuration de l’éditeur. Depuis ce jour j’ai fait quelques modifications pour mon confort, mais absolument rien d’extraordinaire. J’aurais pu reprendre mon ancien article, mais quitte à en écrire un nouveau.

Les différences par rapport à l’ancien se situent principalement au niveau de « l’auto-completion ». Le but est d’avoir quelque chose de mieux que des listes indigestes comme avec  <CTRL-P>, <CTRL-N>,…. Qui ont bien entendu aussi leurs utilités. J’ai donc rajouté OmniCppComplete que vous devez installer dans votre ~/.vim. Les menus de popup s’affichent automatiquement dès que l’on tape un [.] ou une « -> » pour les structures par exemple. Si par contre vous tapez le nom d’une fonction et que vous voulez la liste des arguments, alors commencez à taper un peu son nom, puis elle sera visible dans un popup avec <CTRL-X> <CTRL-O>.

Le .vimrc ci-dessous créer également les tags à l’aide de <CTRL-F12>. Alors n’oubliez pas d’installer ctags sur votre distribution.

" Global settings
set nocompatible
syntax on
set hlsearch
set shiftwidth=2
set background=dark
set cursorline
inoremap <S-Tab> <C-V><Tab>

" Show line number
set number
highlight LineNr term=bold ctermfg=darkgray guifg=darkgray

" Special configuration for devel
filetype on
filetype plugin on
set ofu=syntaxcomplete#Complete
autocmd FileType c,cpp,cxx,h,fl,php set cindent|set cino=:0|set tabstop=8|set softtabstop=2|set expandtab
autocmd FileType make setlocal noexpandtab

" Special highlighting for Doxygen
let g:load_doxygen_syntax=1

" Show when a line exceeds 80 chars
au BufWinEnter * let w:m1=matchadd('ErrorMsg', '\%>80v.\+', -1)

" Highlight Tabs and Spaces
au BufWinEnter * let w:m2=matchadd('Tab', '\t', -1)
au BufWinEnter * let w:m3=matchadd('Space', '\s\+$\| \+\ze\t', -1)
set list listchars=tab:»·,trail:·
highlight Tab ctermbg=darkgray guibg=darkgray
highlight Space ctermbg=darkblue guibg=darkblue

" OmniCppComplete
let OmniCpp_NamespaceSearch = 1
let OmniCpp_GlobalScopeSearch = 1
let OmniCpp_ShowAccess = 1
let OmniCpp_ShowPrototypeInAbbr = 1
let OmniCpp_MayCompleteDot = 1
let OmniCpp_MayCompleteArrow = 1
let OmniCpp_MayCompleteScope = 1
let OmniCpp_DefaultNamespaces = ["std", "_GLIBCXX_STD"]

" CTags
map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .<CR><CR>
set tags=~/.vim/stdtags,tags,.tags,../tags
au CursorMovedI,InsertLeave * if pumvisible() == 0|silent! pclose|endif
set completeopt=menuone,menu,longest,preview

Bien entendu ce .vimrc est de loin pas parfait, mais il remplit parfaitement mes besoins. En quelques mots, les dépassements du 80ème caractère s’affichent en rouge, les tabulations et les espaces en fin de ligne sont mis en évidence. Pour insérer une vraie tabulation alors il faut faire <SHIFT-TAB>…

Un exemple avec libvalhalla que j’ai « salopé » exprès :o)

Vim - libvalhalla

A bientôt,

Mathieu SCHROETER

Pas beaucoup de nouvelles depuis passablement de temps. Je vais faire néanmoins un petit tour en bref des quelques activités sur lesquels j’ai travaillé. Mon activité sur les projets GeeXboX à baissé nettement depuis quelques semaines pour plusieurs raisons. J’ai eu 3 mois de service civil où j’ai qu’en même pu travailler dans mon domaine (l’informatique et plus précisément la programmation). Et de ces trois mois, sont nés deux petits projets hébergés sur les serveurs GeeXboX.

DaisyDuck & libduck

Je vous invite à consulter le site internet. DaisyDuck est un lecteur de livre audio Daisy 2.02, basé sur Qt et libVLC. Il est multi-plateforme et distribué aussi bien pour Windows que pour Linux. Il pourrait également être adapté sans trop de problème à MacOSX. Mais pour des questions de temps, je me suis arrêté à la version Windows.

Il existe de « nombreux » (beaucoup de commerciaux aussi) programmes de lecteur de livre Daisy. Mais la grande différence avec DaisyDuck c’est tout d’abord libVLC. La plupart ne sont pas capables de lire une grande variété de format, et encore moins de protocole réseau. Même qu’en principe pouvoir lire n’importe quel format n’est pas un respect entier des spécifications. Par contre c’était le but de mon travail. Permettre la lecture de livre en ligne, ce que le logiciel est parfaitement capable de faire, et ça fonctionne à merveille. Merci à l’équipe de VideoLAN.

Le deuxième petit projet est donc libduck. Il est également présenté sur le site internet de DaisyDuck. Son but est de réaliser le « parsing » des fichiers Daisy 2.02.

Malheureusement je n’ai pas utilisé libplayer comme base à DaisyDuck. La raison principale est que libplayer n’est pas encore très utilisable (compilable) pour Windows pour différentes raisons techniques. Et faute de temps, je ne pouvais pas me permettre de travailler sur le port de libplayer dans mon temps destiné à mon service civil.

Valhalla

Bien que j’ai terminé le service civil depuis fin mai, il me fallait également trouver un emploi. Et depuis mi juin, j’effectue des trajets relativement longs par jour. Mon temps libre en soirée est devenu presque nul. Je me motive alors à travailler sur les projets GeeXboX, dans le train. Et faut bien l’avouer, c’est difficile d’avancer vite. Mais ça avance qu’en même, et sur libvalhalla cette fois ci.

J’ai commencé sérieusement à ajouter le support des langues pour les méta-données. Le patch devrait arriver très vite, peut être même demain. Par contre ce n’est pas encore complet. Je dois adapter les fonctions pour les sélections des méta-données afin de pouvoir filtrer sur les langues, il me faut aussi encore implémenter le support des grabbers multi-lingues. Ou tout du moins, pouvoir paramétrer les grabbers multi-lingues pour récupérer les données dans une langue spécifique. Au moment où j’écris ces lignes, j’ai uniquement ajouté le support des langues dans la base de donnée, et adapté les grabbers afin que l’information de langue soit correctement indiquée avec les meta-données. Par exemple, le grabber Allocine indique ainsi du « fr » pour ce qui est des résumés, catégories, etc,.. Les autres grabbers sont en principe en « en » et les données qui n’ont pas de langue (par exemple un codec, la taille du fichier ou alors la résolution) sont indiquées comme « undef ». Toutes les méta-données récupérées par les « parsers » sont également en « undef ».

Un autre projet dans lequel je veux me lancer sérieusement, c’est de pouvoir paralléliser le « downloader » et les « grabbers » pour un même fichier. Afin de récupérer les images un peu plus vite. Mais je ne veux pas rentrer dans ce genre d’explications avec ce poste.

libplayer

Aux alentours de mai, j’ai intégré le support de VDPAU directement dans libplayer. Alors non, il n’y a rien d’extraordinaire, ça concerne quelques lignes. L’idée c’est que pour pouvoir exécuter MPlayer correctement avec VDPAU, il faut connaître les caractéristiques du GPU. Et pour ça, il faut interroger la carte graphique. Avec GeeXboX, cela se faisait en dehors d’Enna/libplayer avec un script et un exécutable. Mais ceci n’est plus nécessaire, car maintenant libplayer fait cette tâche de manière transparente.

Enna

Nicolas à modifié en profondeur le VFS d’Enna. J’ai donc pris le temps de retravailler le browser Valhalla. Celui-ci est désormais mieux fait au niveau des chemins d’accès (je n’ai pas envie d’expliquer ça ici). Bref, en gros ce browser re-fonctionne avec le nouveau VFS mais il a qu’en même quelques petites régressions qui ne devraient pas être trop difficiles à corriger.

Le projet de « hardware »

Réaliser un set-top box GeeXboX est très nouveau et assez ambitieux. L’idée est de partir de zéro, de la schématique au PCB puis aux prototypes, pour finir avec la distribution GeeXboX/Enna optimisée au mieux pour le matériel. Le seul gros obstacle actuellement c’est la difficulté à avoir accès aux datasheets des composants intéressants (NDA nécessaires dans quasiment tous les cas). On vise bien sûr le full-HD avec si possible un petit plus par rapport aux autres boards. Tel que par exemple des ports miniPCIe. On a les ressources techniques, manque la doc :-). Ensuite il y aura forcément le problème du temps qui pourra être investi dans ce projet. Mais pour le moment je suis assez confiant.

Pour terminer (et pour arrêter de parler de moi)

Toolchain

Davide fait un gros boulot depuis plusieurs semaines. Il a pris une excellente initiative concernant le toolchain GeeXboX. Le but est d’avoir un toolchain basé sur opkg. Tout se construit via des paquetages, que se sois les dépendances pour la construction du toolchain (gcc, binutils, etc…) que les éléments du « target ».

J’ai toujours aimé le toolchain GeeXboX pour sa simplicité. On entend souvent parler d’OpenWRT par exemple. Il est sûrement très bien, mais notre toolchain c’est notre identité. J’ai toujours été réticent à le voir se faire remplacer par une solution qui viendrait d’ailleurs. Alors un grand merci à Davide pour avoir fait ce gros job!

Le site web

Benjamin en avait marre du site web. Je le comprend tout à fait car j’ai toujours eu la flemme d’y faire des modifs. Faut être clair, chez GeeXboX en principe faut un peu toucher à tout. Mais parfois les tâches comme le site, pas grand monde à envie d’y mettre les mains. Alors Benjamin à basculer sur WordPress qui simplifie grandement la vie aussi bien pour la facilité que pour le design.

J’aimerais qu’en même dire un mot sur l’ancien site. Il avait une particularité en comparaison à beaucoup d’autres sites internet. Ce bon vieux site était entièrement réalisé en XML+XSL (un très bel exemple et très professionnel). Bien sûr les sources sont toujours bien au chaud, dans les dépots Mercurial.

Enna

Nicolas a fait diverses modifications sur Enna en plus du VFS. Néanmoins je n’ai pas encore pu compiler ces dernières modifs :-P. Faute de temps principalement, car je dois mettre à jour les EFL.

A bientôt,

Mathieu SCHROETER

Tagged: C, Enna, GeeXboX, libduck, libplayer, libvalhalla, Linux, MPlayer, opensource, programmation, Valhalla, vdpau ]]> http://skywalker13.wordpress.com/2010/07/03/quoi-de-neuf/feed/ 1 [GO]Skywalker13 DaisyDuck http://skywalker13.wordpress.com/2010/04/03/enna-et-les-metadata/ http://skywalker13.wordpress.com/2010/04/03/enna-et-les-metadata/#comments Sat, 03 Apr 2010 17:41:14 +0000 Mathieu SCHROETER http://skywalker13.wordpress.com/?p=1173 ]]> Hello,

Depuis plusieurs semaines j’ai passablement baissé le rythme sur les projets. D’une part pour cause d’obligations qui ne me permettent pas de passer énormément de temps sur GeeXboX et d’autre part parce que depuis octobre à février j’ai passé beaucoup de temps sur Enna, libplayer et libvalhalla, et ça commençait un peu à me saturer.

En principe je devrais me concentrer sur le générateur d’ISO. Depuis la branche 2 de GeeXboX, ce pauvre générateur est complètement dépassé. Que se sois les fichiers de configuration qui ont changés, des variables renommées, la disparition des thèmes du bootsplash et du menu OSD. Bref plein de petites choses qui ensemble font un gros paquet. J’ai qu’en même commencé gentiment son nettoyage de printemps. Reste à trouver aussi la motivation nécessaire (comme d’habitude).

Enna et le « ondemand »

Au début de la semaine, j’ai fais quelques petites modifications sur libvalhalla. Puis en re-testant sous Enna, un ancien « problème » m’a ennuyé plus que d’habitude. C’est un comportement bien connu depuis longtemps mais qui demandait peut être un surplus de motivation pour en venir à bout. Non pas que c’est difficile à « corriger », mais plutôt que ce n’était pas spécialement intéressant à faire. Du coup j’ai laissé trainé depuis des mois. Jusqu’à cette semaine où ça m’a particulièrement contrarié. Peut être était-ce juste une mauvaise journée, j’ai donc qu’en même pris le temps de régler cet « inconvénient ».

Comme vous le savez (j’espère), Enna utilise libvalhalla pour les méta-données. Si on ne se fie que sur ce que montre Enna, il y avait un comportement qui donnait l’impression que c’était très lent à afficher les méta-données. Par exemple, vous sélectionnez un film et il n’y a pas de backdrop, de titre, etc,… Vous pouviez laisser une heure la sélection sur le même film, vous n’auriez rien vu s’afficher de plus. La première réaction c’est que c’est lent. Mais en réalité ce n’est pas le cas. Il faut savoir que libvalhalla met à disposition plus de fonctionnalités qu’Enna en utilise. Une de ces fonctionnalité est le « ondemand ». Celle-ci était (jusqu’à hier) uniquement utilisée à moitié.

Le principe (avant):

1. Vous sélectionnez un film
2. Enna envoie une requête « ondemand » à libvalhalla
3. libvalhalla va faire un certain nombre de choses pour donner plus de priorité à cette demande que pour les fichiers trouvés par le scanner.
4. Et c’est tout :-)

En fait Enna demandait à libvalhalla de lui donner en priorité les metadata d’un fichier, mais sans aller consulter libvalhalla pour savoir si les metadata étaient disponibles ou non. Du coup il était nécessaire de changer de fichier, puis de revenir sur le précédent pour que ça commence à afficher quelque chose. Bref, c’est ça qui m’a énervé en début de semaine.

En fait libvalhalla peut signaler à Enna où en est le fichier dans les étapes que sont le « parsing », « grabbing » et « downloading ». Mais Enna ignorait complètement ces événements.

Le principe (depuis hier):

1. Vous sélectionnez un film
2. Enna envoie une requête « ondemand » à libvalhalla
3. libvalhalla va faire un certain nombre de choses pour donner plus de priorité à cette demande que pour les fichiers trouvés par le scanner.
4. libvalhalla envoie l’événement « parsed »
5. Enna l’attrape et remet à jour certaines metadata (comme le titre par exemple)
6. libvalhalla envoie un événement « grabbed » après chaque grabber.
7. Enna l’attrape et remet à jour certaines metadata (comme le synopsis par exemple)
8. libvalhalla envoie un événement « ended »
9. Enna l’attrape et remet à jour une fois pour toute.

Ainsi, on voit apparaitre au fur et à mesure les informations (également dans le panneau d’informations CTRL+I). C’est bien plus sympathique.

Le fait de sélectionner un fichier, indique à Enna qu’une requête « ondemand » doit être envoyée à libvalhalla, et ce mécanisme a des effets importants. En passant d’un fichier à l’autre vous envoyez chaque fois une nouvelle requête « ondemand » (à noter que la requête n’a aucun impacte si le fichier demandé est déjà complètement disponible dans la base de donnée).

Rappel sur le « ondemand »

La fonction s’utilise très simplement.

valhalla_ondemand (valhalla_t *handle, const char *path);

On donne le chemin du fichier qui nous intéresse (qu’il soit référencé par le scanner ou non). Maintenant imaginons qu’on appel 10 fois cette fonction à petit intervalle de temps avec des fichiers différents. Le but du « ondemand » c’est de donner une haute priorité à un fichier ou quelques fichiers. Si vous appelez la fonction pour beaucoup de fichiers, finalement ils deviennent tous « haute priorité » et entre eux il n’y a plus de différence (trop de « ondemand », tue le « ondemand »). Mais pour comprendre pourquoi, il m’est nécessaire de donner plus de détails sur le fonctionnement de libvalhalla.

J’ai déjà donné passablement d’explications dans d’autres billets de ce blog, ainsi je vais aller droit au but. Le fait qu’il y ait beaucoup de threads et qu’un « paquet » (donc une structure qui identifie un fichier) peut exister dans plusieurs threads à la fois (des cas très particuliers que je ne vais pas expliquer ici); il est difficile de savoir où se trouve un fichier à un moment précis. Ainsi la requête « ondemand » va endormir tous les threads concernés pour pouvoir chercher le fichier pour qui il faut donner une plus haute priorité. Et c’est cette action qui a un impacte non négligeable sur libvalhalla. La plupart des threads sont rapidement endormis. Mais certains sont un peu plus récalcitrants. Je pense tout particulièrement aux grabbers. Il suffit qu’un webservice bloque (problème de connexion), et donc il est nécessaire d’attendre le timeout de libcurl jusqu’au moment de pouvoir endormir ce fameux thread. Ce timeout je l’ai mis à 20 sec. Mais je me tâte presque à le réduire encore un peu (à noter qu’avec libvalhalla-1 et donc Enna-0.4 les timeouts sont pires car se sont ceux de l’OS et en principe ils sont bien supérieurs à 20 secondes).

Maintenant imaginez plusieurs « ondemand » à des intervalles relativement proches et ce foutu webservice qui bloque. Il faut donc patienter sur libcurl. Ce phénomène est visible également à la fermeture d’Enna. Si les grabbers sont actifs, au moment du « force-stop »; au pire avec Enna-devel vous devez attendre 20 sec sur un grabber. Il serait peut être bien que je permette de paramétrer ce temps directement depuis l’enna.cfg. Actuellement il est en dur dans la configuration pour libcurl de libvalhalla.

Je parle de « timeout », mais en réalité c’est un petit peu différent. C’est le temps maximal autorisé pour une transmission. Par exemple si un fichier prend plus de 20 secondes à être téléchargé, libcurl va qu’en même l’interrompre à 20 secondes.
Ainsi en utilisant un temps bien trop faible, vous risquez de faire échouer bêtement la plupart des grabbers.

L’idéal serait de pouvoir forcer libcurl à interrompre une liaison indépendamment de la valeur du « timeout ». Ca serait particulièrement utile lors du « force-stop ».
[EDIT: ce problème a été fixé!]

Autre phénomène

Les threads de libvalhalla communiquent par l’intermédiaire de FIFO. La haute priorité est simplement d’utiliser le FIFO en tant que LIFO le temps du push. Dit autrement, au lieu de mettre le paquet au fond de la pile, on le met directement au-dessus. Ainsi s’il y a plusieurs requêtes « ondemand », chacune d’elle va se remettre au-dessus. Peu importe que la requête a été fait avant ou après.  Chaque fois qu’un paquet change de thread il se remet au-dessus. C’est un peu comme si tous les paquets « ondemand » se battaient pour la première place.

Au final, tous les paquets « ondemand » seront traités en priorité par rapport au scanner, tout en restant entre eux, sur le même pied d’égalité.

Il reste encore du travail

L’état actuel n’est pas encore parfait. Dans l’activité musique, les requêtes « ondemand » se font uniquement lorsqu’un fichier est sélectionné (tout comme pour la vidéo). Le passage d’un fichier à l’autre par le biais des boutons précédent/suivant et via l’événement EOS (End Of Stream) ne provoque aucun « ondemand ». La raison vient directement de l’implémentation du « mediaplayer ». Les actions ne se font pas dans l’activité, mais directement en interne dans le mediaplayer. Et les metadata ne sont pas tout à fait considérées de la même manière entre l’activité vidéo et musique. Pour avoir un « ondemand » plus homogène, il faudrait revoir en profondeur le « mediaplayer » et éliminer les particularités (ennuyeuses) de chaque activité.

A bientôt,

Mathieu SCHROETER

La sortie d’Enna au début janvier à réveiller des critiques de tous les genres. En principe (faut être honnête) elles ne m’intéressent pas spécialement. Tout d’abord je n’estime pas qu’il y ait de concurrence entre les logiciels libres. Beaucoup de projets s’inspirent d’autres projets et c’est normal. Et si quelqu’un désire une fonctionnalité spécifique il a plusieurs solutions. La première c’est d’utiliser le projet qui offre la fonctionnalité (non?). La seconde c’est de critiquer simplement le projet car une fonctionnalité évidente est absente. Se sont ces critiques là que j’ignore spécialement, car elles n’apportent rien.  Après vous avez des gens qui critiquent mais qui aident spontanément et ils sont toujours les bienvenue.

De « POSIX » à Windows

Une des critique facile est de dire qu’Enna ne fonctionne pas sous Windows et qu’XBMC par contre est multi-plateforme. Les gens qui le disent ont tendance à oublier (ou alors à ne pas du tout connaitre, même dans les grandes lignes) l’histoire d’XBMC. Et oui, à l’origine XBMC ne fonctionnait pas nativement sous Linux. Le port à pris du temps, et c’est le même problème quand il faut porter dans l’autre sens.

Pour en revenir à Enna, je n’ai aucun intérêt personnel à l’avoir sous Windows. Néanmoins il y a eu des progrès pour qu’un jour, Enna puisse fonctionner sous Windows. Pour quand? Je n’en sais rien et ça n’a aucune importance.

Concernant le titre, si j’ai mis POSIX entre guillemets c’est parce que tout n’est pas vraiment du POSIX. Certaines choses sont des extensions du GNU par exemple. Il y a des adaptations à faire aussi entre les systèmes qui se basent sur POSIX. Même entre les noyaux Linux et *BSD, voir même Hurd.

Par exemple libvalhalla fonctionne correctement sous les noyaux Linux et FreeBSD (je pense spécialement à Debian GNU/kFreeBSD), elle fonctionne aussi avec Hurd (testé avec Debian GNU/Hurd) à la différence que les priorités sur les threads ne sont pas gérées correctement. Chaque noyau à sa façon de faire des threads et ça demande de prendre en compte les cas particuliers.

J’ai volontairement omis de mentionner Mac OS X, ou plus précisément Darwin. Bien qu’Apple dit qu’il soit POSIX-compliant, il y a qu’en même au moins un cas particulier dans libvalhalla car ce n’est pas si POSIX que ça.

MinGW

Le meilleur moyen de réaliser des ports Windows est sans aucun doute MinGW. C’est une base GCC et le compilateur peut être natif Windows ou alors compilé pour une compilation croisée sous GNU/Linux (ou d’autres OS). En principe depuis GNU/Linux on peut cross-compiler aussi bien pour Windows que pour Darwin (c’est ainsi que les différentes versions du générateur d’ISO sont faites). Néanmoins, ça peut paraitre étonnant mais il est plus facile de créer un compilateur croisé pour Windows (merci au projet MinGW) que pour Darwin.

J’ai deux cross-compilateurs binaires pour Darwin8 (PPC et i686). Ils ont été créés il y a maintenant plusieurs années par un ancien membre de GeeXboX. Malheureusement il est parti avec les secrets de fabrication. Je n’ai jamais réussi à les reproduire depuis les sources (et ce n’est pas faute d’avoir essayé). Si quelqu’un à des pistes, elles m’intéressent grandement!

libgeexbox-win32

Avant d’espérer Enna sous Windows il faut bien sûr se concentrer sur les dépendances. Et ce qui nous intéresse ici c’est donc libnfo, libplayer et libvalhalla. Au moment où j’écris cet article, libnfo et libvalhalla sont « complètement » supportés sous Windows. Je vais reprendre quelques éléments intéressants qui ont posés des problèmes.

Notez les guillemets, car en ce qui concerne libvalhalla il reste un potentiel problème. Mais néanmoins la bibliothèque est utilisable.

Libvalhalla utilise des temporisations à différents endroits. Celles-ci sont réalisées à l’aide de variable-conditions/mutex. L’idée est d’avoir des temporisations interruptibles contrairement à des fonctions du type sleep(), usleep() ou nanosleep() (attention, je parle bien de temporisations interruptibles sans l’aide de signaux). La bibliothèque Pthreads de POSIX offre tout ce dont on a besoin. Ainsi libvalhalla et libplayer reposent complètement sur celle-ci. Mais ce n’est pas directement de Pthreads que je désire parler, mais du temps pour pouvoir espérer avoir des temporisations plus ou moins précises. Les fonctions pthreads utilisent la structure `struct timespec` qui en théorie offre un champ à la nanoseconde. Même si la valeur peut être juste au moment de la lecture de l’horloge, les appels de fonctions prennent de toutes façon des nanosecondes/microsecondes. Et même pour un système temps réel dur, c’est très difficile de jouer dans ces ordres de grandeurs. Les seuls applications pratiques où je me suis vraiment amusé à compter les nanosecondes c’est lorsque que je faisais du VHDL sur un bon vieux Xilinx.

Bref.. passons.. Mon but est de pouvoir traiter des temporisations de plusieurs centaines de millisecondes. Ce qui est très facile avec un noyau Linux. La structure timespec évoquée précédemment se présente ainsi.

struct timespec {
  time_t sec;
  long int nsec;
}

Sous *BSD, Linux et Darwin il est très facile de la peupler. Concernant Mac OS X et son pseudo POSIX-compliant, le noyau Mach permet de récupérer une structure relativement semblable avec également des nanosecondes, mais la fonction POSIX clock_gettime() n’existe pas chez Apple. Que le champ nsec soit juste ou non ça n’a pas d’importance, pour autant qu’il ne soit pas faux dans les millisecondes. Finalement ces trois noyaux offrent les fonctions nécessaires et même plus. Mais on ne peut pas en dire autant de l’API Windows.

Une question de temps

GetSystemTime

Windows met à disposition des fonctions nommées GetSystemTime() et GetSystemTimeAsFileTime(). Elles sont sensées retourner une résolution à la milliseconde, respectivement à la centaine de nanoseconde. GetSystemTimeAsFileTime() est connu comme étant plus rapide que GetSystemTime(). Par contre cette fonction n’existe pas sous Windows CE et perd donc de son intérêt (dès le moment qu’on recherche la portabilité).

Voyez plutôt le résultat en pratique avec mon PC.

 WinXP                         GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetSystemTime ()
 1266227465.000000000          1266233962.000000000
 1266227465.000000000          1266233962.000000000
 1266227465.000000000          1266233962.000000000
 1266227465.000000000          1266233962.000000000
 1266227465.000000000          1266233962.000000000
 - wait 1 ms
 1266227465.015000000          1266233962.001000000
 - wait 2 ms
 1266227465.031000000          1266233962.003000000
 - wait 3 ms
 1266227465.046000000          1266233962.006000000
 - wait 4 ms
 1266227465.062000000          1266233962.010000000
 - wait 5 ms
 1266227465.078000000          1266233962.015000000

A gauche il y a donc les résultats directement depuis Windows XP. A droite c’est le même programme mais exécuté à travers Wine (le même PC est utilisé). Les attentes de 1 à 5 ms sont réalisées simplement par la fonction Sleep() également mise à disposition par l’API Windows. Il est intéressant de noter que Windows n’arrive pas à descendre à la milliseconde avec un Sleep(1). Problème connu ceci dit…

A noter également que la fonction GetSystemTime() n’est pas des plus performante. Elle est reconnue comme étant peu propice à offrir réellement 1 ms de résolution. J’ai fais ainsi une seconde mesure avec 10’000 lectures du compteur, pour détecter la résolution effective.

Après plus de 8’000 lectures, Windows retourne vraiment 15 ms de plus que la lecture précédente.

 1266484241.000000000
 1266484241.000000000
 ... ~8000 fois ...
 1266484241.000000000
 1266484241.000000000
 1266484241.015000000
 1266484241.015000000
 1266484241.015000000
 1266484241.015000000

GetSystemTimeAsFileTime

J’ai donc refais les mêmes mesures mais avec GetSystemTimeAsFileTime() pour voir si on arrive à des meilleurs résultats. Le MSDN parle de 100 ns, on peut donc espérer une résolution utilisable à la milliseconde.

 WinXP                         GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetSystemTimeAsFileTime ()
 1266227465.078125000          1266233962.015939000
 1266227465.078125000          1266233962.015941000
 1266227465.078125000          1266233962.015942000
 1266227465.078125000          1266233962.015944000
 1266227465.078125000          1266233962.015945000
 - wait 1 ms
 1266227465.093750000          1266233962.017012000
 - wait 2 ms
 1266227465.109375000          1266233962.019076000
 - wait 3 ms
 1266227465.125000000          1266233962.022139000
 - wait 4 ms
 1266227465.140625000          1266233962.026204000
 - wait 5 ms
 1266227465.156250000          1266233962.031268000

La première chose qui frappe ici, c’est que Windows semble donner que des valeurs multiples de 25. Donc d’une résolution de 25 us. On est encore relativement loin des 100 ns promis par le MSDN. Mais pour tester la vrai résolution, j’ai également fais tourner la lecture 10’000 fois.

On constate que Wine arrive à atteindre la microseconde. Néanmoins on n’a pas non plus la résolution de 100 ns. La raison est que Wine se base sur la fonction gettimeofday() qui sous les systèmes POSIX, ne donne pas une résolution meilleure que la microseconde. La structure est un timeval au lieu d’un timespec avec un champ usec au lieu de nsec.

Ici aussi, après environ 8’000 lectures, on constate une résolution d’exactement . C’est aussi mauvais qu’avant. Les microsecondes n’apportent absolument rien. Au début je me suis fais avoir car je pensais vraiment que les 25 us étaient atteints. Et bien que la fonction est sensée être plus rapide d’après mes recherches, en pratique (sous Windows XP), il n’y a pas de quoi en faire une montagne. Il a fallut presque le même nombre de lecture (un peu plus de 8000) pour environ 15 ms.

 1266484241.093750000
 1266484241.093750000
 ... ~8000 fois ...
 1266484241.093750000
 1266484241.093750000
 1266484241.109375000
 1266484241.109375000
 1266484241.109375000
 1266484241.109375000

Je pense qu’elle est considérée comme plus rapide car elle ne peuple pas une structure relativement complexe comme GetSystemTime (voir SYSTEMTIME). La structure utilisée avec la seconde fonction est FILETIME.

Finalement, comme première conclusion et pour garder la compatibilité avec Windows CE on peut utiliser GetSystemTime() sans regret.

clock_gettime

Il existe donc un moyen d’avoir une bien meilleur résolution. Le principe est d’utiliser l’horloge haute résolution (la TSC dans les processeurs x86) afin d’atteindre la nanoseconde. Pour ce faire, Windows met à disposition deux fonctions, QueryPerformanceFrequeny() conjointement avec QueryPerformanceCounter().

Le but final est de simuler la fonction clock_gettime() de POSIX qui permet d’atteindre une résolution de 1 ns.

La première fonction donne la fréquence de l’horloge haute résolution et la seconde donne le nombre de ticks depuis la mise en route. La fréquence donnée est toujours (à peu de chose près) un multiple de 1193182 Hz.

Le principe est donc de retrouver le tick qui correspond à un temps précis depuis EPOCH. Puis de retrouver le temps en divisant simplement le nombre de ticks par la fréquence. L’horloge étant au minimum cadencée à 1193182 Hz, on devrait avoir au moins une résolution de .

 WinXP                         GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Freq: 3579545                 Freq: 1193182
 1266227465.156298915          1266233962.031381633
 1266227465.156301150          1266233962.031384147
 1266227465.156302826          1266233962.031385823
 1266227465.156304502          1266233962.031387499
 1266227465.156306178          1266233962.031389176
 - wait 1 ms
 1266227465.171900059          1266233962.032571728
 - wait 2 ms
 1266227465.187522995          1266233962.034622547
 - wait 3 ms
 1266227465.203157943          1266233962.037689975
 - wait 4 ms
 1266227465.218764954          1266233962.041754736
 - wait 5 ms
 1266227465.234392918          1266233962.046825211

A noter que Wine donne toujours la fréquence la plus basse. Cette fréquence normalement dépend du matériel, mais Wine se base sur Linux pour récupérer le temps. Ainsi la fréquence peut être arbitraire. Windows XP me donne par contre une fréquence pas tout à fait correcte. Comme je l’ai dis avant, celle-ci devrait être un multiple de 1193182, pourtant pour que ce multiple soit vrai, il faudrait alors 3579546 au lieu de 3579545. Je suppose que la fonction QueryPerformanceFrequeny() n’arrondit pas la valeur.

On trouve ici un pas de 1676/1677 ns. Aussi bien avec Windows qu’avec Wine. Ce qui est très bon. Le temps perdu vient désormais des appels de fonctions et non plus de l’imprécision des valeurs de temps.

On pourrait crier victoire, mais en réalité il y a encore un problème potentiel. L’horloge haute résolution est indépendante. Ce qui veut dire qu’elle va forcément diverger par rapport à l’horloge qui donne le « vrai » temps. Ainsi sur une longue période, l’erreur entre les deux va s’agrandir linéairement.

Étant donné que la résolution de GetSystemTimeAsFileTime() est trop imprécise pour de courtes mesures, il est nécessaire de faire des mesures sur plusieurs heures pour avoir des résultats significatifs.  Seul la résolution de 15.625 ms peut servir de référence et une telle divergence ne peut pas être détectée sur quelques minutes (à moins que QueryPerformanceCounter() et QueryPerformanceFrequeny() soient complètement faux). Je n’ai donc rien à vous montrer au sujet de ce potentiel problème de divergence.

La synchronisation

Bien que je ne connaisse pas encore la divergence entre les horloges, on peu légitimement se poser la question de la resynchronisation.

Le principe est d’utiliser une information qui est fiable. Et donc a priori c’est la seconde. L’idée est de récupérer le tick qui correspond au changement de seconde. Ensuite ce tick est converti en un temps depuis EPOCH (un temps absolu en seconde). On mémorise cette seconde pour toute la durée de vie du programme.

Dès que clock_gettime() est appelé, on regarde la valeur du compteur de l’horloge haute résolution, puis on la soustrait à la valeur qui correspond aux secondes du début. On a donc une différence de valeur du compteur. On la divise par la fréquence du compteur ce qui nous donne la différence de temps. On additionne ce nouveau temps avec les secondes du départ pour enfin avoir le temps en nanoseconde depuis EPOCH.

Le potentiel problème avec la synchronisation vient spécialement du fait d’utiliser la seconde comme référence. Si la synchronisation commence au début d’une nouvelle seconde, il faut attendre quasiment une seconde pour terminer la synchronisation. Ainsi actuellement dans le libvalhalla pour Windows, il n’y a pas de resynchronisation. En fonction du décalage entre l’horloge haute résolution et l’horloge du temps, les timers finissent par se rentrer dedans ou alors par devenir de plus en plus écartés. Le fait qu’ils divergent ou convergent dépend du matériel.

Je vois deux solutions pour le moment.

1. Faire la resynchronisation en parallèle au reste du programme. Ainsi on peut continuer d’utiliser clock_gettime() avec la précédente synchronisation.
2. Synchroniser sur GetSystemTimeAsFileTime() avec son pas de 15.625 ms. Mais la compatibilité avec Windows CE est perdue.

Il reste aussi à déterminer quand est-ce qu’il faut resynchroniser.

Un autre problème vient des changements de l’heure du système. Si cela arrive, actuellement libvalhalla aura toutes les temporisations faussées sous Windows.

Les Pthreads

Finalement, on peut se demander si tout cela vaut la peine. Les Pthreads pour Windows ont été conçus pour fonctionner sur un maximum de versions de Windows. Ainsi la référence de temps utilisée se fait via GetSystemTime(). Le clock_gettime() utilisé dans libvalhalla à deux raisons d’être. D’abord il sert à donner un temps absolu aux fonctions Pthreads, et il sert à faire les mesures de temps pour les statistiques. L’aberration dans tout ce travail sur un clock_gettime() pour Windows est simplement que le temps donné aux fonctions Pthreads est de bien meilleur résolution que la résolution du temps interne au Pthreads-win32  (il faudrait néanmoins que je vérifie ce point, je n’ai fais que survoler les sources de Pthreads-win32). Et avoir une résolution à la nanoseconde pour des statistiques n’apporte rien.

Un des seul intérêt restant c’est donc le petit défi que ça représente.

J’hésite à enlever tout le code relatif à QueryPerformanceCounter() pour n’utiliser que GetSystemTime() avec sa misérable résolution. Ou alors rajouter un test sur la fonction GetSystemTimeAsFileTime() pour la préférer à GetSystemTime() si elle existe. Tout ces problèmes me rappel toujours un peu plus pourquoi Windows à un noyau  qui n’a rien de plus que les autres. Mais qui au contraire, ne créer que des problèmes supplémentaires.

Speedhack

Je profite de cet article pour présenter les speedhacks (ces logiciels de triches permettant par exemple de se déplacer plus vite dans un jeu, très prisé à l’époque sur Counter-Strike).

Si j’en parle ici c’est qu’ils reposent sur les fonctions de l’horloge haute résolution, et plus précisément QueryPerformanceCounter(). Il y a un peu plus d’un an, j’avais écris un article à ce sujet que vous pouvez lire à cette adresse. J’en ai profité pour y faire deux trois améliorations et corrections.

A bientôt,

Mathieu SCHROETER

Cela fait plus de 3 ans qu’on utilise Mercurial dans les projets GeeXboX (avant on travaillait avec TLA Arch). Néanmoins on a de la peine à se conformer aux nouvelles fonctionnalités. Je souhaite en fait parler des branches. Avec Subversion (par exemple), les branches se présentent sous la forme de répertoires. Ça a le mérite d’être clair mais c’est un peu comme collectionner des copies du dépôt principal. Je n’ai jamais trop aimé cette approche, car personnellement je trouve ça un peu brouillon (ça n’engage que moi).

En parlant de brouillon, je vous invite à consulter cette page http://hg.geexbox.org qui liste tous les dépôts existants sous GeeXboX. Si vous regardez la colonne « Last change », vous verrez des « 3 years ago » par exemple. Autant dire que certains dépôts sont complètement obsolètes aujourd’hui. Et c’est même confus, prenez par exemple « geexbox-v2« . Son nom est devenu absurde avec le temps. Car la dedans vous trouverez nos tentatives foireuses de supporter Freevo ;-). Je vous épargne la description des autres.

Bref, là où je veux en venir c’est que pour faire des branches, on s’y prend à l’ancienne et on clone les dépôts. Je pense donc spécialement à « geexbox-1.2 » qui est de loin pas obsolète, car c’est lui qui contient tous les backports (spécialement les corrections de bugs) qui ont permis les versions 1.2.1 à 1.2.4 de GeeXboX. Personnellement il ne me plait pas beaucoup. Toutes les versions 1.2.x devraient être dans le dépôt principal « geexbox« .

Ainsi depuis quelques temps je me suis un peu intéressé aux branches Mercurial. Et c’est sur ce point que je vais m’attarder dans ce billet. Il faut aussi savoir qu’en 2006-2007, une fonctionnalité que je vais présenter ici n’existait pas encore (en tout cas pas sous la même forme). Il n’y a donc pas vraiment de mal d’avoir trainé les bonnes vieilles copies de dépôts pour faire des branches…

Cet intérêt soudain pour les branches m’est venu spécialement depuis les releases de libnfo, libplayer et libvalhalla. Je pense par exemple à avoir des branches pour des éventuels corrections sur les versions 1.0.0. Et surtout, sans faire des copies à l’ancienne.

Les branches nommées (NamedBranches)

Mon but n’est pas d’écrire un tutoriel sur Mercurial. Je vais ainsi essayer d’aller à l’essentiel.  Un dépôt peut contenir des « heads » et des branches. Plusieurs « heads » apparaissent quand on commit des changements par rapport à une révision antérieure au « tip« . Ce qui demande donc de faire un « merge » et de le « comitter« .

Par défaut il y a toujours une branche dans chaque dépôt et elle se nomme « default ». Passons directement à la pratique. J’aimerais gérer les corrections de bugs pour libplayer-1.0.0. Admettons que je sois à la racine du dépôt, je créer alors une branche « v1.0″ à partir du tag « v1.0.0″.

$ hg update v1.0.0
33 files updated, 0 files merged, 7 files removed, 0 files unresolved
$ hg branch v1.0
marked working directory as branch v1.0

A priori j’ai bien une nouvelle branche. Mais voyons ce que dit `hg branch` et `hg branches`.

$ hg branch
v1.0
$ hg branches
default                     1326:cac53e7d727f

Du fait que je n’ai pas « commité » la nouvelle branche, on ne la voit pas dans la liste des branches. Mais la première commande confirme que je suis bien dans la « v1.0″ fraichement créée. Je vais donc « commiter » ce changement localement.

$ hg commit -m "new branch v1.0 for bugfix"
created new head
$ hg branches
v1.0                        1327:1c0c025f8a73
default                     1326:cac53e7d727f (inactive)

Si on désire passer d’une branche à l’autre, c’est très simple.

$ hg update default
40 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg branch
default
$ hg update v1.0
33 files updated, 0 files merged, 7 files removed, 0 files unresolved
$ hg branch
v1.0

A noter que s’il y avait des changements non « commités » dans le dépôt, il ne serait pas possible de passer d’une branche à l’autre sans qu’ils soient tous annulés ou « commités ». Mais regardons un peu ce que ça donne avec `hg view`.

On voit deux colonnes bien distinctes qui sont rattachées depuis le « tag » v1.0.0. Un petit tour dans `hg heads` nous montre bien qu’il y en a deux. Et chacun est sur une branche différente.

$ hg heads
changeset:   1327:1c0c025f8a73
branch:      v1.0
tag:         tip
parent:      1230:6b3e2fed5f7a
user:        Mathieu Schroeter <mathieu.schroeter@mycable.ch>
date:        Sun Jan 10 10:26:50 2010 +0100
summary:     new branch v1.0 for bugfix

changeset:   1326:cac53e7d727f
user:        Mathieu Schroeter <mathieu.schroeter@mycable.ch>
date:        Sat Jan 09 20:34:51 2010 +0100
summary:     set winid to 0 by default (fix warning if USE_X11 is not defined)

La branche « default » n’est pas montrée explicitement.

Ce qui m’intéresse maintenant c’est de gérer les corrections de bugs. Cette branche « v1.0″ est à considérer pour exister aussi longtemps que tout le dépôt.

Le « cherry picking »

C’est ce qu’on appel le « cherry picking » car seulement quelques « changesets » spécifiques m’intéressent. Les corrections de bugs sont toutes dans la branche « default ». Pour importer ces changements dans le dépôt « v1.0″ il y a plusieurs manières de faire. Mais personnellement la majorité des solutions que j’ai trouvé ne me plaisent pas. Et il y a peu de temps, je suis tombé sur une extension officielle (mais non activée par défaut) qui permet de faire exactement ce genre de traitements (et même plus). Elle s’appelle « transplant » et c’est elle que je vais utiliser pour mon exemple.

Il faut commencer par l’activer dans le fichier ~/.hgrc:

[extensions]
transplant=

Je vais prendre une partie des corrections intéressantes et les transplanter dans la nouvelle branche.

$ hg transplant 1242
application de 95461fb8613f
patching file Makefile
Hunk #1 succeeded at 18 with fuzz 1 (offset -3 lines).

Je répète pour chaque « changeset ». On peut spécifier plusieurs « changesets » en les séparant par ‘:’ pour une plage REV1:REV4 par exemple. Mais avec le Mercurial d’Ubuntu j’évite de le faire, simplement parce que l’extension me retourne une exception et un joli traceback Python. En prenant un après l’autre, aucun problème.

Le « screenshot » ci-dessus permet de voir les différents « changesets » appliqués sur la branche « v1.0″.

Pour continuer à travailler sur la devel (branche « default »), rien de plus simple.

$ hg update default
40 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ vi Makefile
$ hg commit -m "dummy commit"
$ hg heads
changeset:   1335:55589e41d0eb
tag:         tip
parent:      1326:cac53e7d727f
user:        Mathieu Schroeter <mathieu.schroeter@mycable.ch>
date:        Sun Jan 10 13:07:34 2010 +0100
summary:     dummy commit

changeset:   1334:81c124600c6b
branch:      v1.0
user:        Mathieu Schroeter <mathieu.schroeter@mycable.ch>
date:        Sat Jan 09 20:29:01 2010 +0100
summary:     fix 'make dist' in src

On voit clairement évoluer le « tip » de la branche « default » en parallèle à la branche « v1.0″.

Un « push » avec plusieurs branches

Tout ceci n’est qu’un exemple, ainsi pour montrer le « push » je vais utiliser un répertoire local. Admettons que je clone depuis http://hg.geexbox.org/libplayer.

$ cd ..
$ hg clone http://hg.geexbox.org/libplayer libplayer-local
requesting all changes
adding changesets
adding manifests
adding file changes
added 1327 changesets with 2268 changes to 111 files
updating working directory
104 files updated, 0 files merged, 0 files removed, 0 files unresolved

C’est donc le dépôt original où j’ai qu’une seule branche. Je retourne dans le dépôt qui contient la branche « v1.0″ et je vais faire un « push » sur libplayer-local.

$ cd libplayer
$ hg push ../libplayer-local
pushing to ../libplayer-local
searching for changes
abort: push creates new remote branch 'v1.0'!
(did you forget to merge? use push -f to force)

Le « push » est automatiquement annulé. Ce qui est très bien, ainsi Mercurial nous préviens qu’on a créé une nouvelle branche. Il est alors nécessaire de le forcer (la première fois). Mercurial nous demande aussi si on a pas oublié de faire un « merge ». C’est légitime dans le cas où on ne veut pas avoir deux branches séparées sur le dépôt distant.

$ hg push -f ../libplayer-local
pushing to ../libplayer-local
searching for changes
adding changesets
adding manifests
adding file changes
added 9 changesets with 6 changes to 2 files (+1 heads)

Mercurial nous confirme qu’on a bien ajouté un « head ». A partir de ce point je me suis posé la question de ce qui se passe si quelqu’un clone ce dépôt avec ces deux « heads ». Est-ce qu’il va avoir un avertissement s’il tente de faire un « push », du genre qu’il devrait faire un « merge » ou forcer le « push »?! Ce serait ennuyeux si c’était le cas, car les branches ne devraient pas intervenir. Le « head » n’étant pas sur la même branche. J’ai donc simplement testé pour m’en assurer:

$ cd ..
$ hg clone libplayer-local libplayer-foobar
updating working directory
104 files updated, 0 files merged, 0 files removed, 0 files unresolved

Cette manipulation revient au même que de cloner le dépôt sur hg.geexbox.org si j’avais « pushé » les modifications. Sans me soucier des branches, je vais faire une modification dans libplayer-foobar, la « commiter », puis faire un « push » dans libplayer-local comme si c’était hg.geexbox.org/libplayer.

$ cd libplayer-foobar
$ vi Makefile
$ hg commit -m "still a dummy commit"
$ hg push ../libplayer-local
pushing to ../libplayer-local
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

Il n’y a aucune remarque de Mercurial par rapport aux branches. Cela prouve que tout fonctionne correctement. Honnêtement j’avais toujours eu des doutes sur ces fonctionnalités. Au moins maintenant c’est clair. Je vais alors retourner dans le dépôt libplayer-local pour vérifier le résultat avec `hg view`.

Tout a fonctionné parfaitement..

Conclusion

Maintenant que j’en sais suffisamment sur les branches, je pense passer par ce moyen à l’avenir. Il pourrait être même judicieux (peut être) de repasser tous les backports de geexbox-1.2 dans le dépôt geexbox. L’idée serait de ne jamais écrire de nouveaux patchs dans les dépôts faisant références à des versions antérieures. Mais de toujours faire les modifications dans le « default » et uniquement des « transplant » dans les autres branches. Je pense par exemple au dossier debian/ dans les dépôts. Afin de garder l’historique, une nouvelle release tel que libplayer-1.0.1 par exemple, serait enregistrée dans les changelogs du « default », puis un « transplant » mettrait à jour la branche « v1.0″.

Il reste une utilisation des branches qui me pose encore un problème. Les cas où l’écriture d’une fonctionnalité ne devrait pas se faire directement dans le « default » car elle introduirait des régressions. Une branche supplémentaire tel que « experimental » pourrait faire l’affaire. On devrait ensuite faire un « merge » de cette branche dans le « default ». Ce qui me dérange c’est qu’on finit par collectionner les branches comme par exemple ici: http://hg.geexbox.org/enna/. Il y a « new_vfs » et « new_vfs_system ». Ces branches n’ont plus vraiment de raison d’être car elles ont été « mergées ». Dans le cas de l’exemple présenté au-dessus avec la branche « v1.0″, c’est parfaitement normal de la garder pour toujours. Je n’ai donc pas encore trouvé de solution propre (c’est une question de point de vue) pour travailler avec des branches de courtes durées de vie.

Si quelqu’un à une idée…

A bientôt,

Mathieu SCHROETER