Mind... - GeekTime

Yet another policy daemon for postfix

Florent Bruneau — Mon, 06 Apr 2009 22:04:00 +0200

MadCoder announced it months ago, he has been working on the pfixtools. The second tool of the postfix-related toolsuite is named postlicyd.

postlicyd is a versatile policy daemon written in C. It does greylisting (far faster than postgrey), it performs R(H)BL access (both locally directly from rbldns zone files and remotely by using DNS), ... So, it can be used as a replacement for whitelister and postgrey with a significant improvement of the performances.

On the same server (with the same email trafic), postlicyd is more than 20 times faster than postgrey:

Process load: postgrey ~20% CPU, postlicyd less than 1% CPU
Data base cleanup for 1M entries: postgrey 20 minutes, postlicyd 40 seconds

Moreover, it is aware of the 'session' feature of the POLICY protocol. Thus, you can write complex configurations and define policies that do not depend on a single SMTP command (like RCPT) but on the whole SMTP transaction...

More informations: http://pfixtools.mymind.fr

Compter les fichiers

Florent Bruneau — Thu, 30 Aug 2007 23:12:00 +0200

C'est un peu la suite de mon post "Outils pratiques" où je donnais deux scripts permettant de rendre les commandes SVN plus conviviales. Encore une fois, je réinvente sans doute la roue (des outils équivalents doivent déjà exister... sans doute en mieux), mais je pense que chercher ce genre d'outils sur internet m'aurait pris plus de temps que ce qu'il m'a fallu pour le développer.

En ce moment je manipule des fichiers, beaucoup de fichiers (et même, beaucoup de gros fichiers), que j'ouvre, rouvre, et ferme et puis referme. Et à force d'ouvrir, on oublie parfois de refermer, et là, c'est comme une fuite de mémoire, sauf que le nombre limite de fichiers ouverts est beaucoup plus rapidement atteinte que la limite de mémoire... dans la configuration de base sur un linux, un programme n'a le droit qu'à 1024 descripteurs de fichiers. D'où mon problème : comment traquer les "file-handle leaks" ?

Pour le faire, je me suis fait rapidement un petit script qui permet d'analyser les données issues d'un strace. strace est, pour ceux qui ne le savent pas, un programme très pratique qui permet de lister les appels systèmes. Dans mon cas présents, surveiller les ouvertures fermetures de fichiers revient à traquer les commandes open (ouverture d'un fichier), et les commandes close. Donc, je récupère simplement la liste des appels à open et close :

[bash]
strace -f -e trace=open,close mon programme 2> /quelque/part

Et ainsi, le fichier /quelque/part contient la liste complète des appels à open et close effectués par mon programme (et ses processus fils). Il ne reste plus alors qu'à analyser le contenu de /quelque/part. Pour ceci, il suffit de peu de lignes de code (en perl pour ma part, mais d'autres auraient fait la même chose en shell, python... ou n'importe quel langage de scripting) :

[perl]
#!/usr/bin/perl 
 
my %files; 
my %modes; 
my %lines; 
 
my $lineNb = 0; 
my $maxOpened = 0; 
my $currentOpened = 0; 
my $totalOpened = 0; 
 
for $line (<STDIN>) { 
  if ($line =~ /open\\("([^""]+)", ([^\\)]+)\\)\\s*=\\s*(\\d+)/) { 
    $files{$3} = $1; 
    $modes{$3} = $2; 
    $lines{$3} = $lineNb; 
    $totalOpened++; 
    $currentOpened++; 
    if ($currentOpened > $maxOpened) { 
      $maxOpened = $currentOpened; 
    } 
  } 
  if ($line =~ /close\\((\\d+)\\)/ && $files{$1} ne '') { 
    $files{$1} = ''; 
    $currentOpened--; 
  } 
  $lineNb++; 
} 
 
print "$totalOpened files opened, max. $maxOpened at the same time
"; 
print "$currentOpened files not closed
"; 
for $id (keys %files) { 
  local $file = $files{$id}; 
  local $mode = $modes{$id}; 
  local $line = $lines{$id}; 
 
  if ($file ne '') { 
    print "[line $line] id=$id, open $file with mode $mode
"; 
  } 
}

Pour simplifier le tout, on rajoute une fonction dans le zshrc pour wrapper tout ça, et ça donne (attention, ceci ne fonctionne que sous linux, mktemp n'a pas la même syntaxe sur MacOS, et surtout, strace n'est pas disponible sur Mac

[bash]
function checkFiles() { 
  TEMPFILE=`mktemp` 
  strace -f -e trace=open,close $* 2> $TEMPFILE 
  cat $TEMPFILE | ~/.zsh/trackFiles.pl 
  rm $TEMPFILE 
}

Avec, ça, il ne me répond :

% checkFiles cp test test2
12 files opened, max. 2 at the same time
0 files not closed

Si maintenant, je fais un programme minimaliste qui oublie de fermer un fichier :

[c]
#include <stdio.h> 
 
int main() { 
  FILE* file = fopen("test", "r"); 
  return file != NULL ? 0 : 1; 
}

% gcc test.c -o tester
% checkFiles ./tester
3 files opened, max. 1 at the same time
1 files not closed
[line 4] id=3, open test with mode O_RDONLY

Voilà, maintenant je sais que mon programme oublie de fermer un fichier, que ce fichier s'appelle "test", et qu'il est ouvert en read-only. La ligne "4" est la ligne dans la sortie de strace, et n'a aucun rapport avec la ligne 4 du fichier source (contrairement aux apparences).

Templates en C

Florent Bruneau — Thu, 16 Aug 2007 22:53:00 +0200

En C++, il existe un mécanisme extrêmement pratique pour généré du code générique : les templates. Une fonction templatée est une fonction dont le code comporte un trou qui sera remplacé à la compilation par le nom d'un type, ou une valeur... Par exemple :

template <class T> 
T read(const char *buffer) 
{
    T val;
    memcpy(&val, buffer, sizeof(T));
    return val;
}

Cette fonction lit un objet de type T sur un buffer. L'intérêt de cette fonction est très compréhensible : quel que soit le type qu'on fournit à la fonction, elle va fonctionner, en adaptant la taille à lire au type. C'est donc beaucoup plus rapide que d'écrire une fonction pour chaque type... et l'utilisation est également très simple :

read<int>(const char* buffer) // lit un entier sur le buffer
read<double>(const char* buffer) // lit un double sur le buffer
read<MaClass>(const char* buffer) // lit un objet de type "MaClass"

Mais cette syntaxe n'est qu'un sucre syntaxique, car en fait, on peut également faire des templates en C...

Comment fonctionne les templates ?

En fait un template est, comme son nom l'indique, qu'un modèle de fonction. Lors de la compilation d'un programme qui utilise des templates, le compilateur regarde la liste des instances de cette fonction qui sont utilisées et les génère. Plus explicitement, si j'appelle read<double>(), le compilateur va générer cette fonction :

[cpp]
double read<double>(const char *buffer) 
{
    double val;
    memcpy(&val, buffer, sizeof(double));
    return val;
}

Ainsi, l'appel à read<double> devient un appel de fonction classique.

Jeu de préprocesseur

Le préprocesseur en C possède des outils sympathique... Nous nous attarderons particulièrement sur le ##. Il s'agit tout simplement d'un opérateur de concaténation. Donc :

[c]
#define Truc(Machin) Truc ## Machin

Truc(Bidule) /* génère TrucBidule */

C'est donc très pratique. On peut facilement par exemple, imaginer une petite macro du genre :

[c]
#define maFonction(Type) maFonction_ ## Type

Si dans ce cas, on défini par exemple maFonction_int, maFonction_double, maFonction_MaStruct (oui, les classes n'existent pas en C), on pourra faire

[c]
maFonction(int)(args); /* appelle maFonction_int */
maFonction(double)(args); /* appelle maFonction_double */
maFonction(MaStruct)(args); /* appelle maFonction_MaStruct */

Maintenant, il ne reste plus qu'à générer les fonctions... sans avoir à toutes les écrire une à une. Pour ceci, nous allons encore une fois profiter de la présence du préprocesseur.

[c]
#define maFonctionBuild(Type) \\
  Type maFonction_ ## Type(const char* buffer) { \\
    Type val; \\
    memcpy(&val, buffer, sizeof(Type)); \\
    return val; \\
  } 

maFonctionBuild(int) /* génère maFonction_int */
maFonctionBuild(double) /* génère maFonction_double */
maFonctionBuild(MaStruct) /* génère maFonction_MaStruct */

Il ne reste donc qu'à appeler maFonctionBuild(Type) sur chacun des types pour lesquels nous avons besoin d'instancier la fonction, et d'appeler maFonction(Type) chaque fois qu'on veut appeler maFonction pour le type en question. D'une certaine manière on peut dès lors dire que les fonctions sont :

[c]
Type maFonction(Type)(const char* buffer);

Et voilà !

Nous avons donc une implémentation générique grâce au préprocesseur associé à un appel typé. Ce n'est évidemment qu'une astuce de préprocesseur, mais cela donne une souplesse syntaxique agréalble : "J'appelle maFonction appliquée sur les entiers avec les arguments args".

Tout ceci est certes, moins souple que les templates C++ :

il n'y a pas d'auto-instanciation par le compilateur : il faut "manuellement" instancier la fonction pour tous les types pour lesquels ont l'appelle
il n'y a pas de "type check" : les seules limites sont celle de la compilation
le correction des erreurs de compilation est fastidieuse car toutes les erreurs apparaissent comme étant à la ligne d'appel à maFonctionBuild
il est rapidement fastidieux de rajouter l'antislash à la fin de chaque ligne de la définition de la fonction

Comme on le voit dans les choix de l'exemple, pour les entrées/sorties, ça permet d'avoir une seule fonction à écrire tout en gardant la flexibilité d'une fonction par type de données.

Comprendre du code

Florent Bruneau — Wed, 15 Aug 2007 01:28:00 +0200

J'ai tenté cet après-midi une petite expérience sur IRC. J'ai posté 3 lignes de code en demandant "que font ces trois lignes". Après quelques minutes (sans doute trop peu), j'ai donné la solution car personne n'avait vraiment trouvé. En effet, même si on réussi facilement à lire le code et à reconstituer la suite d'opération qu'il génère, il est très difficile de vraiment comprendre ce qu'il fait, d'imaginer son application dans un contexte et d'en déduire son usage.

Juste pour continuer à m'amuser, et pour amuser ceux qui se perdraient ici, voici le code en question.

[c]
do {
  ++(*pos);
} while (*(pos++) == 0);

Vous pouvez remarquer dès à présent que ce code n'est pas volontairement rendu illisible (il serait facile de supprimer des parenthèses et de changer le test de nullité en une négation. Le but est donc de comprendre la suite d'instruction, de dire ce qu'elle fait et ensuite de comprendre dans quel contexte elle est utilisable. La question est aussi de savoir en combien de temps vous allez trouver la solution.

Cliquer ici pour afficher la répondre

Fonctionnement

Si on lit le code, on voit qu'il fait la suite d'opération suivante :

on incrémente la valeur pointée par pos
on regarde si la valeur obtenue est nulle
on incrémente le pointeur pos
si le test 2 est vrai, on retourne en 1, sinon, on quitte la boucle

Il s'agit donc d'une petite boucle qui incrémente des objets successifs jusqu'à ce qu'elle en trouve un qui, une fois incrémenté, n'est pas nul.

Voilà donc la solution du pauvre au problème, celle qu'on peut trouver en lisant le code, sans chercher à le comprendre.

Interprétation

Mais en fait, ce code va plus loin. Imaginons maintenant la zone mémoire sur laquelle pos pointe initialement :

 oct1 oct2 oct3 oct4
  ^
 pos

L'octet 1 à une certaine valeur. Je l'incrémente et je m'aperçois que sa nouvelle valeur est 0. Quand un octet incrémenté peut-il retomber à 0 ? Quand il fait un overflow. On a donc fait déborder le premier octet... et quand cet octet déborde on incrémente le suivant :

    _+1__
   |     |
 oct1 oct2 oct3 oct4
       ^
      pos

Il s'agit donc ni plus ni moins que d'une retenue (comme quand on apprend à faire les additions ou les multiplications) : quand je fais déborder un octet, je déplace le surplus vers le suivant. Finalement, ces 3 lignes de code ne sont que l'implémentation d'une incrémentation, mais sur plusieurs octets... et même sur un nombre non défini d'octets (puisqu'il n'y a pas de limite explicitée sur le nombre d'étapes autorisées).

Pour être plus précis, il s'agit d'un incrémenteur d'entier stocké en Little Endian sur un nombre illimité d'octets.

Encore ?

Bon, pour ceux qui tiennent vraiment à s'assurer que ce n'est pas du code illisible, voici une version vraiment illisible de la même machine :

[c]
for(++*pos;!*pos++;++*pos);

(Merci Falco)

Tout ceci n'était bien sûr qu'un exemple. Il est toujours très dur de comprendre du code, alors pour éviter de passer dix minutes sur 3 lignes lors de la prochaine relecture il suffit de documenter ce qu'on écrit.

Khtml2png 2.6.5 est sorti

Florent Bruneau — Tue, 05 Jun 2007 22:31:00 +0200

Après 3 mois d'un travail pas très intensif, une nouvelle version de khtml2png est disponible. Cette version est partie du fait que les versions précédentes du programme ont parfois du mal à gérer les grandes captures d'écran (en fait, des bugs peuvent apparaître dès que la taille de la zone à capturer est plus grande que la taille affichable).

Donc, rapidement après la sortie de la 2.6.0, j'avais envoyé un correctif (en fait une réécriture du moteur de rendu) au développeur de khtml2png. Malheureusement, ce correctif ne fonctionnait pas correctement chez lui. Donc, pendant 3 mois, j'ai fait du débuggage à distance : j'envoie une version modifiée (1 ou 2 lignes à chaque fois), j'attends 2 ou 3 semaine une réponse, etc... Du développement efficace !

Bon, toujours est-il que maintenant, la version 2.6.5 fonctionne à la fois chez moi (à la fois Debian + xvnc et sur MacOS X), et chez Hauke (sur Debian également, mais avec des réglages différents).

Le Changelog annonce :

fix: Now produces screenshots on my Debian Etch system under KDE 3.5.5 without glitches.
fix: Maybe better working on other systems too. Please test.

J'aimerais y rajouter quelques points :

meilleur moteur de rendu (qui ne scroll plus, mais déplace la fenêtre pour s'affranchir de certains bugs de KDE et/ou Qt)
meilleure détection de la taille de la capture à réaliser
possibilité de choisir le comportement de khtml2png face aux redirections, au javascript, au java, au flash... via la ligne de commande
la détection automatique de la dimension par un id devient compatible avec le format utilisé dans les version <= 2.5

Comme d'habitude, vous pouvez télécharger ma dernière version du programme.

Spaces

Florent Bruneau — Sat, 02 Jun 2007 14:44:00 +0200

Comme un certain nombre de personnes le sait déjà, j'ai repris le développement de VirtueDesktops depuis quelques semaines. Dans un premier temps je n'avais pas regardé le fonctionnement bas niveau du programme, mais la semaine dernière j'ai commencé à rechercher dans les sources "Comment Virtue fait-il pour cacher les fenêtres, faire les transitions etc... ?".

A ma grande surprise, tout ceci est en fait géré nativement par MacOS X... la bibliothèque CoreGraphics contient en effet quelques fonctions cachées qui gèrent l'attribution d'une fenêtre à un Workspace et les transitions entre ces Workspaces. On peut trouver la liste complète de ces fonctions sur la SVN de VirtueDesktops.

[c_mac]
extern OSStatus CGSMoveWorkspaceWindowList(const CGSConnection connection, CGSWindow *wids, int count, int toWorkspace);
extern OSStatus CGSGetWorkspace(const CGSConnection cid, int *workspace);
extern OSStatus CGSGetWindowWorkspace(const CGSConnection cid, const CGSWindow wid, int *workspace);
extern OSStatus CGSSetWorkspace(const CGSConnection cid, int workspace);

VirtueDesktops (et également DesktopsManager) n'est qu'une interface graphique qui tente d'utiliser ces fonctions. Et là Spaces part avec une longueur d'avance car contrairement à VirtueDesktops, il sera facile pour Apple de gérer les ouvertures, fermetures et masquage d'application ce qui est à mon avis le plus gros point faible de Virtue. J'ai beaucoup travaillé là-dessus et je pense arriver actuellement aux limites de ce qu'il est possible de faire avec un gestionnaire de bureaux virtuels sur Tiger.

Un autre problème de VirtueDesktops est l'accès à l'ordonnancement des fenêtres. Comment être sûr que lorsqu'on arrive sur un bureau les fenêtres sont dans le bon ordre ? Idéalement il faudrait enregistrer l'ordre en temps réel et le restaurer lors du retour sur le bureau. Ceci permettrait également de toujours savoir quelle application activer lorsqu'on arrive sur un bureau, simplement en utilisant la fenêtre qui se trouve au premier plan.

Voilà, je me suis certes lancé dans une cause perdue d'avance, mais je suis tout de même content du résultat obtenu lors de ces dernières semaines. Virtue a désormais un comportement qui correspond à ce que j'attends d'un gestionnaire de bureaux virtuels : quand je change d'application il va sur le bureau adéquat, et quand je change de bureau, il active bien la dernière application que j'ai utilisée sur ce bureau.

Et si on oubliait les bases ?

Florent Bruneau — Sat, 26 May 2007 11:40:00 +0200

MacOS X est un Unix... compatible POSIX. Voilà ce qu'un certain nombre de personnes semblent oublier assez fréquemment. C'est assez dommage quand ces personnes programment pour MacOS, on se retrouve parfois avec du code complexe pour réécrire des fonctions POSIX (en moins bien ?).

En fait si je parle de ça, c'est parce que je viens de rencontrer le problème dans le cadre du développement de VirtueDesktops. Il se trouve qu'en parcourant le tracker du projet je suis tombé sur le ticket 115 qui s'intitule :

Patch to check group id of 'procmod' group

C'est intéressant... jusqu'à maintenant Virtue suppose que le gid du groupe procmod est celui par défaut de MacOS (c'est à dire qu'il vaut 9)... et le problème est donc que si un utilisateur a un procmod différent (ou si Apple décide un jour de changer le gid du groupe), le code actuel peut avoir des résultats inattendus, il faut donc faire un code plus portable qui recherche le gid de procmod au lieu de le stocker en dur. Ce n'est clairement pas une mauvaise idée ! Seul problème, le patch soumis est le suivant (au cas où certain voudrait réutiliser ce code, je tiens à signaler que c'est une mauvaise idée !) :

[c]
#define NI_DOMAIN	"."
#define NI_PATH		"/name=groups/name=procmod"
#define NI_KEY		"gid"

// Sucked from netinfo-369.5/tools/niutil/niutil.c
ni_status ni_read_single_prop(char **property)
{
	const char *args[] = {NI_DOMAIN, NI_PATH, NI_KEY};
	
	char myname[] = "ni_read_single_prop";
	const bool opt_tag = false;
	const int timeout = 30;
	
	ni_namelist nl;
	void *domain;
	ni_id dir;	
	ni_status ret;

	if ((ret = do_open(myname, args[0], &domain, opt_tag, timeout, NULL, NULL)) != 0) return ret;

	/* args[1] should be a directory specification */
	ret = ni2_pathsearch(domain, &dir, args[1]);
	if (ret != NI_OK) {
		fprintf(stderr, "%s: can't open directory %s: %s
", myname, args[1], ni_error(ret));
		ni_free(domain);
		return ret;
	}

	/* get the property values for args[2] */
	NI_INIT(&nl);
	ret = ni_lookupprop(domain, &dir, args[2], &nl);
	if (ret != NI_OK) {
		fprintf(stderr, "%s: can't get property %s in directory %s: %s
", myname, args[2], args[1], ni_error(ret));
		ni_free(domain);
		return ret;
	}
	
	
	if (nl.ni_namelist_len != 1) {
		fprintf(stderr, "%s: expected length = 1, found length = %d
", myname, nl.ni_namelist_len);
		return NI_FAILED;
	}
	
	*property = (char*)calloc(strlen(nl.ni_namelist_val[0]) + 1, sizeof(char));
	strcpy(*property, nl.ni_namelist_val[0]);
	
	ni_namelist_free(&nl);
	ni_free(domain);
	
	return NI_OK;
}

Donc que fait cette fonction ? C'est assez simple : elle utilise l'utilitaire NetInfo d'Apple pour lire les informations relatives au chemin /groups/procmod. Une fois là dedans elle copie la valeur stockée à la clé gid et renvoie cette chaîne dans le pointeur passé en argument.

Il n'y a pas à dire... c'est une solution qui devrait fonctionner (enfin j'ai même un doute, car je ne vois pas le groupe procmod apparaître quand je regarde dans NetInfo). Seulement cette solution montre clairement que la personne qui l'a écrite savait que MacOS utilise un système de groupes, mais avait oublié qu'en fait c'est avant tout un système POSIX. Et là, ce qui est intéressant c'est que sous MacOS X on a accès à l'API POSIX... en particulier à la fonction getgrnam qui retourne les informations sur un groupe à partir de son nom.

Donc, pas besoin de dépendance vers NetInfo, pas besoin d'une recherche dans une arborescence abstraite : NetInfo n'est qu'une abstraction de la couche Unix pour simplifier l'accès aux données par les utilisateurs... mais ça ne doit pas être un framework d'abstraction de l'API POSIX ce qui entraîne nécessairement du code moins portable (et surtout, moins lisible dans le cas présent), moins rapide et plus lourd.

Ici, le code est utilisé dans un programme en C qui est chargé de mettre un objet dans le groupe procmod pour autoriser Virtue à effectuer certaines actions qui nécessitent un accès privilégié au serveur graphique... ce programme ne fait que changer les permissions. Pourquoi utiliser une API lourde et spécifique à MacOS alors que ce type de programme pourrait clairement être utilisé sur n'importe quel Unix ?

Voici donc une solution qui fait la même chose que la fonction ci-dessus, en mieux et surtout en beaucoup moins de lignes :

[c]
#include <grp.h>

static int getProcmodGid()
{
    struct group* groupDesc; 
    int gid = -1; 
    groupDesc = getgrnam("procmod"); 
    if (groupDesc) {
        gid = groupDesc->gr_gid; 
        free(groupDesc); 
    } 
    return gid; 
}

Pourquoi cette solution est-elle meilleure ?

elle retourne un entier... on a donc pas besoin de faire une conversion a posteriori
elle utilise l'API POSIX et est donc utilisable sur n'importe quel OS POSIX (donc quasiment tous... à l'exception de Windows)
elle évite toute manipulation inutile de chaîne de caractères
elle est ne nécessite pas de charger une bibliothèque supplémentaire : getgrnam est dans la libc
elle est drôlement plus courte non ?

VirtueDesktops revient...

Florent Bruneau — Fri, 18 May 2007 12:25:00 +0200

Voici plus ou moins trois mois que j'ai découvert synergy, c'est vraiment très agréable de pouvoir contrôler les deux ordinateurs sans changer de clavier/souris continuellement. Seul problème, c'est que sur la machine qui héberge le serveur synergy, VirtueDesktops, un excellent gestionnaire de bureaux virtuels pour MacOS, n'arrête pas de crasher. J'avais donc posté un bugreport sur le trac de Virtue... malheureusement pour diverses raisons, Tony Arnold a décidé peu après de stopper le développement de Virtue.

J'ai donc pris mon courage à 2 mains, et je me suis doucement plongé dans le code de VirtueDesktops (c'est vraiment bien les applications OpenSource). Il y a maintenant deux semaines, j'ai soumis le patch permettant de corriger le crash dont je souffrais. Depuis, ce patch a été publié ce qui a conduit la release de la bêta 3 de Virtue 0.54.

Je me suis relancé dans le développement cette semaine en me fixant comme objectif de corriger plusieurs comportements énervants de Virtue. Par exemple, si je dis que Mail.app doit être sur le bureau Mail, je veux que toutes les fenêtres de Mail.app aillent forcément sur ce bureau. Seul problème, c'est que lorsque je reçois une notification de l'arrivée d'un nouveau mail et que je clique sur cette notification, une fenêtre avec le message s'ouvre sur le bureau courant, et Virtue tourne pour atteindre le bureau de Mail.app... résultat : j'ai changé de bureau mais je n'ai pas accès à la fenêtre que je voulais voir. J'ai corrigé ce comportement, désormais, la fenêtre est automatiquement déplacée sur le bureau de Mail.app lors de son ouverture.

Autres corrections diverses :

lorsqu'on ferme une application Virtue reste sur le bureau courant (sauf si il n'y a plus rien sur le bureau courant)
lorsqu'on choisi de changer de bureau, Virtue active désormais la dernière application active connue pour le nouveau bureau
lorsqu'on restaure une fenêtre qui était dans le Dock, soit l'application a le droit d'être sur le bureau courant et la fenêtre est affichée sur ce bureau sans chercher à changer de bureau, soit l'application est attribuée à un bureau et dans ce cas la fenêtre est restaurée sur le bureau de l'application et Virtue change de bureau
...

Ces changements ont abouti à la bêta 4 et se résument à :

Changing to desktops when you launch, activate, deactivate, minimise, restore or quit an application should be much more consistent;
Window ordering when changing desktops should be much more consistent;

Stats

Florent Bruneau — Sat, 21 Apr 2007 00:59:00 +0200

Depuis le début, j'ai installé awstats pour avoir des statistiques sur l'utilisation de mon serveur web.

J'ai choisi awstats un peu par hasard :

on avait utilisé webalizer au BR et je n'étais pas spécialement convaincu par le résultat obtenu : beaucoup de chiffres, graphiquement peu attirant et d'ergonomie d'utilisation assez mauvaise.
à Polytechnique.org par contre, on utilise awstats, même si je n'ai pas fait le bilant complet des fonctionnalités, il a au moins l'avantage d'être lisible et agréable à l'oeil.

Donc je l'ai installé, personnalisé... en particuliers j'ai ajouté des browsers (principalement des syndicateurs) et robots, amélioré les spécifications de certains OS, et j'avais également ajouté à l'outil de configuration le support de MAMP. J'ai envoyé le patch au mainteneur du projet. Aujourd'hui je fais un cvs up sur mon installation du projet et je vois :

P docs/awstats_faq.html
RCS file: /cvsroot/awstats/awstats/tools/awstats_configure.pl,v
retrieving revision 1.6
retrieving revision 1.7
Merging differences between 1.6 and 1.7 into awstats_configure.pl
M tools/awstats_configure.pl
M wwwroot/cgi-bin/awstats.model.conf
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/browsers.pm,v
retrieving revision 1.54
retrieving revision 1.55
Merging differences between 1.54 and 1.55 into browsers.pm
M wwwroot/cgi-bin/lib/browsers.pm
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/operating_systems.pm,v
retrieving revision 1.20
retrieving revision 1.21
Merging differences between 1.20 and 1.21 into operating_systems.pm
M wwwroot/cgi-bin/lib/operating_systems.pm
RCS file: /cvsroot/awstats/awstats/wwwroot/cgi-bin/lib/robots.pm,v
retrieving revision 1.44
retrieving revision 1.45
Merging differences between 1.44 and 1.45 into robots.pm
M wwwroot/cgi-bin/lib/robots.pm

Bizarrement, tous les fichiers que j'ai modifié ont été modifié également sur la CVS... donc je suis allé faire un tour sur le webvc du projet, et sur les fichiers correspondants, il y a le commentaire Patch florent bruneau.

Voilà, une bonne surprise ! Je suis juste un peu déçu de l'avoir vu uniquement sur un update de cvs.

Trous de mémoire

Florent Bruneau — Wed, 04 Apr 2007 00:01:00 +0200

Quand j'utilise mon ordinateur, j'aime bien que son fonctionnement soit fluide. C'est à dire que lorsque je passe d'une application à l'autre (ce qui arrive régulièrement), je ne veux pas qu'il y ait 10 secondes de latence parce que ma machine "swap". Malheureusement, je ne connais aucun OS sur lequel ça ne swap pas. Par exemple, sur mon portable à l'instant même j'ai 2Go de swap (donc 700Mo utilisés) sachant qu'à côté j'ai 600Mo de RAM utilisés (et les quelques 400Mo de RAM qui restent servent de cache disque...).

Comment un ordinateur sur lequel tourne un navigateur web, un client IRC et un client mail peut avoir autant de RAM occupée ???

La réponse n'est pas très dure à trouver... il suffit de se munir de différents petits outils :

un logiciel de monitoring (par exemple le Moniteur d'activité de Mac OS)
d'un outil comme le programme leaks qui détecte les zone de mémoire perdues (les memory-leaks)

Et là, c'est assez surprenant. Commençons par trier les programmes par mémoire occupée dans le moniteur :

Le noyau arrive en premier... bon, je ne sais pas ce qui est compté comme mémoire utilisée par le noyau, on va dire que c'est normal
Le serveur graphique en deuxième...
Colloquy (client IRC) avec 47Mo de mémoire réelle (284Mo de mémoire virtuelle)
Mail avec 39Mo/270Mo
Vienna (syndicateur RSS) 34Mo/286Mo
Safari (browser) 31Mo/240Mo... mais je viens juste de le relancer et je n'ai que 2 onglets ouverts dessus
VirtueDesktop (gestionnaire de bureaux virtuels) 27Mo/247Mo
GeekTool (un petit outil qui permet de plaquer des logs/images... sur le bureau) 26Mo/230Mo

Bon, là où ce n'est pas drôle je viens de relancer Safari et GeekTool. A la rigueur, à part GeekTool qui n'a absolument rien à faire dans le top8, le classement n'est pas très surprenant. Là où il y a un problème c'est quand on regarde la sortie de leaks. Pour ceux qui ne peuvent pas tester, ça ressemble à ça :

Leak: 0x0066abd0  size=16       string ''
Leak: 0x006e1680  size=16       string ''
Leak: 0x0d5f8cf0  size=16       instance of 'NSCFString'
        0xa080c260 0x0001078c 0x74737504 0x4346006c     `........ustl.FC
Leak: 0x0d590470  size=16
        0x00000000 0x00000000 0x00000000 0x00010001     ................
...

Donc, comme je ne vais pas lire toute la sortie, je vais faire leaks programme | grep Leak | wc -l sur les programmes qui tournent sur mon Mac ce qui donnera le nombre de trous de mémoire. Tout d'abord commençons par ceux que je viens de relancer (GeekTool et Safari) :

GeekTool : 1632 leaks dont la taille varie de 16 à 1024 octets
Safari : 6 leaks dont la taille varie également de 16 à 1024 octets

Puisque Colloquy est en tête du top des programmes qui utilisent le plus de mémoire... un petit test s'impose : 15212 leaks (je l'ai relancé il y a 24 heures). Le temps de faire ce test je revérifie GeekTool qui lui même est passé à 1747 leaks (juste pendant le temps que j'ai pris pour écrire ces quelques lignes).

Pour me rassuré je décide de tester sur différents autres programmes :

WindowServer (le serveur graphique de Mac OS) : 360 leaks
Address Book : 1460 leaks (bon, il a 11 jours d'uptime aussi, c'est pas rien)
Terminal : 0 (mais je viens de le relancer... il a planté alors que je lançais leaks sur Terminal)
Finder : 334
Mail : 321
Dock : 15
GeekTool : 1995 (et oui, ça a encore augmenté)
ssh : 6 !
Vienna : 10824 (il a 24 heures d'uptime)

Je me décide à lancer Firefox, juste pour voir... juste après le lancement, Firefox est déjà à 1580 memory leaks... bon, peut-être que Camino est plus léger, c'est vrai qu'avec ses 236 leaks, il fait bonne figure.

Pour résumer :

Les programmes Apple sont peut troués (la plupart de ceux que j'ai cité ci-dessus ont un uptime comparable à celui de ma machine, c'est à dire 11 jours... 300 trous de mémoire en 11 jours, ce n'est pas miraculeux, mais c'est tolérable).
Les programmes de tierce partie sont des monstres. Comment un navigateur comme Firefox qui cherche à s'imposer comme une référence peut-il se permettre d'avoir déjà perdu 1580 zones mémoires en 5 secondes de fonctionnement ? Comment un outil qui ne fait rien comme GeekTool peut-il prendre plus de mémoire que Safari (il vient juste de le dépasser dans mon moniteur d'activité) et perdre plusieurs centaines de zones mémoire par minute ?

Quand on développe un programme, la gestion de la mémoire est une priorité... et ce, quel que soit le langage qu'on utilise. Je n'ai pas envie d'acheter 1Go de RAM supplémentaire alors que tous les programmes que j'utilise devrait rentrer dans 512Mo de RAM, mais malheureusement, comme les programmeurs semblent avoir oublié qu'un programme ce n'est pas que un tas de fonctionnalités mises bout à bout, ma machine rame de telle sorte que parfois il faut plusieurs secondes pour passer d'un programme à l'autre.

Je me demandais pourquoi Apple avait mis en place un GC pour l'objective-C dans le prochain MacOS, au moins maintenant je suis fixé : ça permettra aux programmes faits par des personnes qui ne savent pas coder de ne pas pourrir ma machine. Heureusement que les gens qui savent programmer se mettent au service de ceux qui ne le savent pas pour faire des outils qui transforment les mauvais programme en programme correct.

Désolé d'être aussi méchant, mais ça m'énerve (tiens GeekTool prend encore 2Mo de RAM supplémentaires^[1]^[2]^[3]).

Notes

[1] Le temps de relire, GeekTool et Safari ont supplanté Vienna au top8, GeekTool est passé à 7135 leaks !!!, Colloquy est passé à 15318 et Safari reste à 6

[2] Après une bonne nuit de sommeil le classement a changé : GeekTool est désormais entre le noyau et le serveur graphique avec plus de 36222 leaks et 106Mo de mémoire utilisés, Vienna est passé à 11400 leaks, Colloquy à 16300 et Safari à 111

[3] Avec 24h d'uptime, Safari et GeekTool tiennent la tête du classement avec respectivement 117 et 114Mo de RAM utilisée. 683 leaks pour Safari et 43479 leaks pour GeekTool. Colloquy est monté à 18110 leaks et Vienna à 14902

Deux approches...

Florent Bruneau — Wed, 28 Mar 2007 00:52:00 +0200

Les deux APIs avec lesquelles j'ai eu le plus la chance de travailler sont celle de Qt et celle de PHP... il n'y a pas à dire, entre ces deux bibliothèques, c'est comme le jour et la nuit.

L'API de Qt est intuitive et est conçue pour l'être. Si je veux avoir l'âge du capitaine, je ferais toujours capitaine->age(), et si je veux définir son âge, ce sera capitaine->setAge(42). Cette API est tellement prévisible qu'au bout de quelques jours d'utilisation, on n'utilise la documentation que pour chercher de nouvelles fonctionnalités, mais très rarement pour chercher des fonctions courantes. En plus, ce qui est remarquable, c'est qu'au fur et à mesure des versions de Qt, l'accent est mis sur la simplification de l'API... Qt 4 est bien plus intuitive que Qt 3 qui est pourtant déjà très facile à utiliser.

La qualité de la documentation de Qt y est également pour quelque chose : toutes les méthodes sont documentées, avec la plupart du temps un exemple. Le tout étant très facilement accessible grâce à l'assistant, un petit programme qui permet de consulter la documentation en intégrant des outils pour naviguer simplement entre les pages.

Par contre, je ne sais pas pourquoi, mais en PHP, l'API est incohérente... l'exemple le plus simple est sans doute celui du remplacement et de la recherche dans une variable. Si, par exemple, je veux rechercher un élément :

[php]
//Dans une chaîne de caractères :
strpos($string, $findme);
//Dans un tableau, c'est l'inverse :
in_array($findme, $array);
array_search($findme, $array);

Si je veux faire un remplacement dans une chaîne de caractères :

[php]
strtr($string, $search, $replace);
str_replace($search, $replace, $string);
preg_replace($search, $replace, $string);

Chic ! Grâce à ça, même si je connais le nom de la fonction à utiliser, je suis quasiment forcé à chaque fois d'aller regarder dans la documentation de PHP (ce que j'ai fait pour écrire ce paragraphe, sinon j'aurais 'forcément' inversé les arguments)... heureusement que celle-ci est bien faite et permet de trouver rapidement les fonctions dont on connaît le nom.

Quand est-ce que PHP se décidera à revoir son API pour qu'elle soit aussi intuitive que celle de Qt ? Malheureusement, sans doute jamais : il faut garder (autant que possible) la compatibilité avec les versions précédentes de PHP. Dommage, parce qu'à mon avis, si PHP continue à étoffer son API sans la rendre cohérente, sa popularité va diminuer progressivement dans les années qui viennent.

Joie ! (bis)

Florent Bruneau — Wed, 21 Mar 2007 20:19:00 +0100

Voilà, la nouvelle version de khtmld vient d'être releasée...

Vous pouvez consulter la page principale du projet.

Outils pratiques

Florent Bruneau — Tue, 13 Mar 2007 19:21:00 +0100

Etant donné que je travaille énormément avec SVN. C'est un outils très addictif... à tel point que je l'utilise dès que je travaille sur un projet (seul ou à plusieurs), je crée un reposoire pour le projet (c'est un excellent moyen de ne pas perdre son travail suite à une fausse manoeuvre). Comme en plus je ne supporte pas les front-end pour SVN, je travaille toujours en ligne de commandes...

Pour pouvoir améliorer la sortie des commandes SVN dans mes consoles, j'ai fait surchargé la commande svn par une fonction zsh :

[bash]
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi
}

Cette fonction est donc très simple :

si la commande nécessite un interaction de l'utilisateur, on appel directement le programme svn (le cas de help permet de ne pas casser la tab-completion de zsh)
sinon on envoi la sortie de svn dans un script qui réalise sa coloration syntaxique

Ceci donne un résultat de la forme suivante :

C'est donc extrêmement pratique ; ça permet de distinguer facilement les modifications, ça permet aussi de voir d'un seul coup d'oeil les conflits et la liste des fichiers modifiés. En plus ça fonctionne également avec des commandes comme cvs ou diff :

[bash]
# SVN
function svn() {
    if [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/local/bin/svn $*
    elif [[ $1 == "preci" || $1 == "precommit" ]]; then
        /usr/local/bin/svn status | grep -v '?' | ~/.zsh/zshcolorsvn
    else
        /usr/local/bin/svn $* | ~/.zsh/zshcolorsvn
    fi; fi
}

# SVN avec conversion de la sortie en latin1
function svn_utf8() {
    if [[ $1 == "ci" || $1 == "commit" ]]; then
        svn $*
    else
        svn $* | iconv -f utf8 -t iso-8859-1
    fi
}

function cvs() {
    if [[ $1 == "diff" ]]; then
        shift 1
        /usr/bin/cvs diff -ubN $* 2> /dev/null | ~/.zsh/zshcolorsvn
    elif [[ $1 == "ci" || $1 == "commit" || $1 == "propedit" || $1 == "propset" || $1 == "help" ]]; then
        /usr/bin/cvs $*
    else
        /usr/bin/cvs $* 2> /dev/null | ~/.zsh/zshcolorsvn
    fi;
}

function diff() { /usr/bin/diff -u $* | ~/.zsh/zshcolordiff }

Les scripts nécessaires sont disponibles : zshcolorsvn et zshcolordiff

Seul défaut : pour pouvoir utiliser les commandes sans coloration... il faut taper chemin complet.

Joie !

Florent Bruneau — Tue, 13 Mar 2007 12:41:00 +0100

Mon travail sur khtml2png vient d'être releasé (version 2.6.0) par Hauke (le programmeur principal du projet). Cette version corrige tous les bugs dont j'ai pu parler dans mes précédents billets :

Des failles de sécurité
Problème de bandes grises si X n'est pas assez grand
Blocage du programme en cas de popup

Elle supprime la dépendance à ImageMagick (ce qui permet au passage de simplifier le code). Ainsi, mon code permettait de passer de 600 lignes à 320 lignes, avec le travail de Hauke au dessus (principalement de l'alignement de code), le fichier source fait 390 lignes...

Pourquoi ?

Florent Bruneau — Wed, 07 Mar 2007 14:05:00 +0100

Pourquoi est-ce que les utilisateurs se sentent obligés de laisser des commentaires sur les articles qu'ils lisent dès que c'est possible ? Dans certains cas, ces commentaires sont intéressants, mais dans 95% des cas, c'est uniquement du "Kikoo lol asv mdr :) :) :) ;) ;)"... insupportable !

Le problème c'est que ça ne concerne pas uniquement les Skyblog... mais également les sites d'informations (même les sites plutôt sérieux), les sites de documentation (comme celui de PHP par exemple)...

Par exemple, pourquoi un gars poste-t-il un algorithme pour remplacer str_repeat sur php.net :

[php]
<?php
if(!function_exists("str_repeat")) {
    function str_repeat($word, $length) {
        $repeated = "";
        for($i=0; $i < $length; $i++) {
            $repeated .= $word;
        }
        return $repeated;
    }
}
?>

Non seulement, j'espère que les utilisateurs qui n'ont pas la fonction en question (PHP < 4) sauront d'eux-même reproduire cette algorithme sans avoir à le recopier (sans quoi on peut se demander pourquoi ils utilisent PHP vu qu'ils ne savent tout bonnement pas programmer un algorithme trivial)... mais en plus cet algorithme est absolument sous-optimal (à chaque tour de boucle il faut réallouer le buffer stockant $repeated et le recopier...) et il n'y a donc pas de quoi être fier d'avoir écrit cette fonction.

Pourquoi à la suite d'un article indiquant de l'arrivée prochaine du SATA 2.6, quelqu'un vient poster (et uniquement ce texte) :

Vite vite dépecher vous

Quel est l'intérêt de ce commentaire ?
Le pire est que pour trouver cet exemple j'ai choisi au hasard un article sur Clublic et que le commentaire que j'ai pris était le premier sur cet article... Bon effectivement vu qu'il ne doit pas y avoir plus d'un commentaire intéressant par jour sur Clubic, c'était facile d'en trouver un inintéressant.

Et je ne parle pas des commentaires sur les articles d'actualité en référence avec la campagne électorale en cours...

Donc, si c'est possible : avant d'ajouter un commentaire sur Internet, réfléchissez pour savoir si ça vaut vraiment le coup, ça permettrait au moins à ceux qui cherchent vraiment des informations de ne pas avoir à lire 90% de texte inintéressant avant de trouver le commentaire intéressant de la page de doc de php.net (par exemple).