Metal3d - Fedogeek

Pool de thread avec limite de parallélisation

Metal3d — Sat, 02 Mar 2013 17:37:00 +0100

Je travaillais cette semaine sur un script python qui récupérait des centaines de milliers de données depuis un serveur. Pour gagner en temps de calcul, j'ai décidé de faire des threads. Limitant la taille de mes tâches parallèles à un nombre spécifique, le script bloquait... car j'utilisais des fonctions threadées qui lançaient récursivement d'autres threads. Sauf que la Queue que j'utilisais pour faire le pool se bloquait si trop de threads se lançaient en même temps attendant indéfiniment que quelqu'un veuille bien lire la Queue... J'ai alors trouvé ma solution, et je la partage avec vous. Je vous explique le problème, je vous montre un exemple, et ensuite on voit la solution.

J'ai cherché un peu partout sur le net, et je n'ai pas trouvé de solution à mon problème. Ainsi, pour vous montrer ce qui coince, je vous ai préparé un exemple de script très simple. Le script suivant lance 5 Threads qui eux même vont en créer... Pour limiter le nombre de tâche parallèles je passe par une classe assez connue (depuis python recipes) qui utilise la classe Queue avec une limite de taille.

Chaque fois qu'on ajoute une tâche dans la classe, la Queue est remplie... les workers vont alors lire en boucle dans cette dernière pour lancer la tâche et les arguments stoqués. Tant que la Queue est remplie, il faut attendre que quelqu'un la lise... sinon l'appel à "put" reste bloqué.

Voici la classe de base que j'ai utilisée (et modifié):

Edit: J'ai beaucoup joué avec ma classe et j'ai fait quelques corrections, notamment en ce qui concerne l'ajout d'arguments, vous pouvez suivre les fixes sur le gist suivant: https://gist.github.com/metal3d/507...

# -*- encoding: utf-8 -*-
# file threadingpoolbad.py
 
import logging
from threading import Thread
from Queue import Queue
 
class ThreadPool:
 
    class _ThreadQueue(Thread):
 
        def __init__(self, pool, *args, **kwargs):
            """ Get tasks queue then launch thread """
            super(ThreadPool._ThreadQueue, self).__init__(*args, **kwargs)
            self.tasks = pool.tasks
            self.daemon = True
            self.start()
 
        def run(self):
            """ Read tasks from limited size queue, then launch task """
            while True:
                # read bloking Queue ..
                task,args = self.tasks.get(True)
                try:
                    task(*args)
                except Exception, e:
                    logging.exception(e)
                    print "Error"
                finally:
                    self.tasks.task_done()
 
    def __init__(self, num=10):
        """ Create a limited pool with "num" threads """
        self.tasks = Queue(num)
 
        for _ in range(num):
            self._ThreadQueue(self)
 
    def add_task(self, target, args):
        """ Write in unlimited size queue which will be
        read in "run" method of a thread
        Block if tasks Queue is full !
        """
        self.tasks.put((target, args))
 
    def wait_completion(self):
        """ Wait for tasks to be completed """
        self.tasks.join()

Voilà comment utiliser cette classe:

import time
from threadingpoolbad import ThreadPool
 
def test(pool, num=0):
    num += 1
    print "num is %d" % num
    if num < 5:
        pool.add_task(target=test, args=(q, num))
        time.sleep(0.5)
 
#create a pool of 2 threads, launch test function
pool = ThreadPool(2)
pool.add_task(target=test, args=(pool,))

Jusqu'ici tout va bien... mais admettons que j'ajoute 5 ou 6 appels à add_task:

# ...
#create a pool of 2 threads, launch test function
pool = ThreadPool(2)
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))

Si vous lancez le test... ça coince. Pour arrêter le script faites CTRL+Z puis "kill %%".

Tout le souci se trouve entre deux méthodes:

add_tasks qui tente d'écrire dans une queue, l'appel à "put" bloque si la Queue "tasks" est pleine
dans "run" on libère un espace au moment où la fonction "task" est terminée

Or, dans notre exemple, la fonction "test" ne libère pas la queue de suite, car elle écrit dans la Queue via add_task... mais comme d'autres threads sont aussi en cours, la Queue est pleine et aucun espace n'est libre. On se retrouve en attente indéfinie...

Pour la plupart des scripts, vous n'allez pas vous retrouver dans cette situation, mais voilà... pour moi c'est arrivé.

Comment corriger le souci ? revoir l'algo ? c'est dommage... tout ce qui nous manque c'est de pouvoir écire dans la Queue sans limite, mais limiter quand même le nombre de threads.

La classe Queue peut tout à fait ne pas bloquer, et avoir une taille indéfinie. Si on lui passe un entier en argument de constructeur elle se limite à bloquer sa taille max à ce nombre. Mais si on ne lui donne pas de paramètres, ou "0" ou un nombre négatif, alors sa taille est illimitée.

Or, je veux tout de même limiter le nombre de process simultanés. Tout ce dont j'ai besoin c'est de ne pas bloquer l'insert de tâches... vous me suivez ?

C'est alors très simple ! il suffit de gérer tout ça avec 2 Queue:

une qui n'est pas limitée, elle gardera toutes les taches à lancer, quelque soit le nombre
une qui va limiter le nombre de thread, celle-ci sera limité à nombre qui correspond au nombre de threads. C'est quasiement le même fonctionnement que la classe de threadingpoolbad.py

On y va:

# -*- encoding: utf-8 -*-
#file threadingpool.py
import logging
from threading import Thread
from Queue import Queue
 
 
class ThreadPool:
 
    class _ThreadQueue(Thread):
 
        def __init__(self, pool, *args, **kwargs):
            """ Get task and pool Queue. Then launch thread.
            """
            super(ThreadPool._ThreadQueue, self).__init__(*args, **kwargs)
            self.pool = pool.pool
            self.tasks = pool.tasks
            self.daemon = True
            self.start()
 
        def run(self):
            """ Run unlimited while Queues are not joined """
            while True:
                # reinsert the nonblocking queue 
                # in blocking queue, that should block
                # if "tasks" queue is full
                self.tasks.put(self.pool.get(True))
 
                #and read this queue...
                task,args = self.tasks.get(True)
                try:
                    task(*args)
                except Exception, e:
                    logging.exception(e)
                finally:
                    self.tasks.task_done()
                    self.pool.task_done()
 
 
    def __init__(self, num=10):
        """ Create the thread queue with "num" thread in parallel"""
        self.tasks = Queue(num)
        self.pool = Queue()
 
        for _ in range(num):
            self._ThreadQueue(self)
 
    def add_task(self, target, args):
        """ Write in unlimited size queue which will be
        read in "run" method of a thread
        That should not block !
        """
        self.pool.put((target, args))
 
 
    def wait_completion(self):
        """ Wait for the all threads to be completed """
        self.pool.join()
        self.tasks.join()

Vous voyez ici les deux queues, "tasks" et "pool". La première est limitée, l'autre non.

Et cette fois ci, ça marche: j'ai bien deux threads qui tournent mais je ne bloque plus lors de l'appel à "add_task":

import time
from threadingpool import ThreadPool
 
def test(pool, num=0):
    num += 1
    print "num is %d" % num
    if num < 5:
        pool.add_task(target=test, args=(q, num))
        time.sleep(0.5)
 
#create a pool of 2 threads, launch test function
pool = ThreadPool(2)
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
pool.add_task(target=test, args=(pool,))
#...

Et voilà ! Désormais, mes 120 000 tâches que j'ai à lancer ne se bloquent plus, elles se placent en file l'attente et j'ai bien un nombre limité de tâches en parallèle.

Je ne vous montre pas mon script d'import, mais croyez moi, la récursion (bien contrôlée) est énorme, et avoir résolut mon problème a été un soulagement énorme.

Coloriser la sortie d'un programme

Metal3d — Mon, 18 Feb 2013 12:08:00 +0100

Développant sur Google Appengine en ce moment, en python, j'utilise les logs à foison. Ces logs sont pratique et ont un niveau d'information (WARNING, INFO, ERROR...). Mais la lisibilité n'est pas forcément adaptée, car en effet les logs sont simplement des lignes de texte. C'est alors qu'une idée m'a frappée (sans gravité, j'ai pas eut mal): et si je colorisai la sortie. Ma méthode fonctionne pour à peu près tous les programmes que vous utilisez dans un terminal, et peut être adaptée à pas mal de situations

L'idée est simple, il suffit de rediriger les sorties du programme dans un descripteur qui va modifier la sortie. Avant tout, laissez moi vous expliquer comment coloriser du texte dans un terminal (si vous ne savez pas comment), puis comment utiliser `sed` avec la subtilité. Enfin, on va passer par une commande `exec` qui va opérer notre transformation.

Premier point, les couleurs dans un terminal.

Bash (ou d'autres shell) permet de coloriser une chaine de caractères. Le principe étant de donner un caractère spécial, puis un code couleur, puis la chaine.

Ainsi, pour coloriser en rouge, en entre la séquence "\033[31m" puis la chaine. Il faut juste comprendre cela:

\033 => caractère qui prévient qu'on va changer de couleur, de poids de fonte...
[ => on va donner une couleur
33 => code couleur du rouge
m => terminé

Cette séquence retourne un caractère spécial c'est important de bien le comprendre, car en réalité toute la subtilité de ce que nous allons faire repose sur ce principe. Ce caractère est invisible, il est interprété par le terminal pour changer la couleur.

Cela ne suffit pas, il faudra que le terminal sache gérer les caractères échapés, je parle du "\033". La commande "echo" sait bien le faire:

echo -e "\033[31mEt hop une couleur"

Le souci, c'est que là votre console passe en rouge... et ne revient pas au mode "normal". Pour cela, on utilise la couleur "0"

echo -e "\033[0mOn revient à la normale"

Pour faire plus simple, on peut directement activer la couleur, entrer la chaine, puis revenir à la normale:

echo -e "\033[31mHoulla une erreur en rouge\033[0m"

Les couleurs qu'on va utiliser:

31 rouge => pour les erreurs
33 orange => pour les warnings
34 bleu => pour les infos

Bien, passons à `sed`. Cet outil permet de faire des opération sur du texte assez facilement en utilisant une syntaxe proche du perl. Ainsi, la commande "s" de sed permet de "substituer" du texte, comprennez "le remplacer"

Dans une commande sed "s", le caractère "&" correspond à la chaine trouvée. Ainsi, pour remplacer "WARNING" en "toto-WARNING-fin" on fera:

echo "WARNING there is an error" | sed 's/WARNING/toto-&-fin/'
#affiche: toto-WARNING-fin there is an error

Bon, vous avez compris, il faut remplacer maintenant "WARNING" en "\033[33mWARNING\033[0m". Sauf que voilà, sed ne sait pas utiliser le mode "échappé". Cela n'est rien, on va récupérer le caractère que retourne "echo -e" pour le placer dans la chaine de remplacement. Voilà un exemple:

NORMAL=$(echo -e "\033[0m")
ORANGE=$(echo -e "\033[33m")

echo "WARNING there is an error" | sed "s/WARNING/$ORANGE&$NORMAL/"

Simple en fait, relisez bien vous allez comprendre.

Bien, reste à faire ça pour toutes les lignes de sortie d'un programme. Reprenons notre exemple avec GAE, j'ai des message "WARNING, INFO et ERROR".

Le souci, c'est que la sortie est "en continue", mais on va utiliser une commande qui va gérer une redirection de flux: exec

Si vous ne le savez pas, un shell utilise des descripteurs connus: 1 = sortie standard, 2 = sortie d'erreur. Si je redirige une sortie dans un de ces flux, il sera traité de différente manières.

Pour rediriger dans un flux, on utilise la séquence "N>&M" où N est le flux d'entrée, et M le flux où on redirige. Ainsi:

#on redirige la sortie normale dans le flux d'erreur
echo "pouet pouet" 1>&2 
#1 est utilisé par défaut, donc cela fait la même chose:
echo "pouet pouet" >&2 

#Par exemple
echo "pouet pouet"  2>fichier_erreur 1>fichier_normal 1>&2
#ici, le fichier_normal ne contien rien, par contre fichier_erreur 
#contient pouet pouet

OK, même si cela reste obscure pour certains, ne paniquez pas... suivez juste le reste de mon article.

"exec" peut ouvrir un descripteur, simplement en lançant "exec 3> ..." On aura alors un nouveau flux portant le numéro 3.

Donc:

exec 3>fichier
echo "pouet pouet" >&3

ici, on redirige le flux 3 dans un fichier, donc en écrivant dans le flux, on écrit dans un fichier...

Autre subtilité des shells: ">(une commande)" (surtout pas d'espace après le >) la commande entre parenthèse est considéré comme un fichier

Ainsi:

exec 3> >(sed 's/toto/pouet/g')
echo "j'ai pas toto mais j'aime truc" >&3
echo "toto toto :)" >&3

Vous comprennez ce qu'il se passe: tout ce que j'écris dans le "descripteur 3" passe dans la commande "sed..." Ha... on y arrive !

NORMAL=$(echo -e "\033[0m")
ORANGE=$(echo -e "\033[33m")
RED=$(echo -e "\033[31m")
BLUE=$(echo -e "\033[34m")

exec 3> >(sed "s/WARNING/$ORANGE&$NORMAL/g;   s/ERROR/$RED&$NORMAL/g; s/INFO/$BLUE&$NORMAL/g" )

ma_commande >&3

Et voilà ! Toute mes sorties de "ma_commande" passerons dans le flux "3" et on verra un remplacement de mot par ce même mot en couleur.

Si "ma_commande" utilise les flux de sortie d'erreur, vous pouvez carrément faire:

ma_commande 1>&2 2>&3

Alors, ici, on utilise des couleurs, mais vous pouvez utiliser cette technique pour mettre des balises XML, mettre le texte en minscule, ou rediriger dans d'autre descripteurs... en gros la méthode est ouverte à pas mal de variantes.

Voilà pour aujourd'hui !

Vim en moteur de slide - Vroom

Metal3d — Thu, 02 Aug 2012 11:49:00 +0200

Si vous suivez un peu mon blog, vous connaissez mon adoration pour le terminal de commande, vim et tout outil fonctionnant en mode console. J'ai toujours trouvé plus clair ce fonctionnement que de passer par des outils graphiques pour la moindre action. Aujourd'hui, c'est un outil de présentation (un slide si vous préférez) que j'ai découvert. Ça va vite, c'est pratique, c'est fonctionnel et ça marche avec Vim... En clair, ça a tout pour me plaire. Laissez-moi vous présenter "vroom"

Vroom est un package Perl installable aisément avec cpan. Il est fourni avec un exécutable qui va vous permettre de créer rapidement un slide fonctionnant en mode console. Ça peut paraitre fou de faire un slide en mode console, et pourtant l'intérêt est là. Car en ayant simplement du texte vous vous forcez à rendre "lisible" le slide.

Il est clair que ce genre de slide est plutôt ciblé pour les présentations de technologies de développement. Vroom a par ailleurs la possibilité d'exécuter du code contenu dans un slide, ce qui vous permet de montrer un petit bout de code et de l'exécuter afin de présenter le résultat.

Quoiqu'il en soit, commençons par l'installer.

Je vous l'ai dit, Vroom est un package Perl. De ce fait, on utilise CPAN pour installer le paquet:

su -c "cpan install Vroom"

Acceptez toutes les questions proposées à l'installation. En quelques secondes vous allez avoir l'outil installé sur votre poste.

Vous pouvez maintenant créer un répertoire quelque part, ici j'utiliserai "~/slidetuto/" pour des raisons pratiques. La suite logique est la suivante:

on créer un répertoire pour la présentation
on génère un template de slide
on édite le slide, on ajoute des entrées, on configure un peu...
on affiche le slide

Mais avant tout, vous devez modifier un fichier qui va permettre à Vim de lire une configuration spécifique qui sera créée par Vroom dans votre répertoire de slide. Ouvrez le fichier "~/.vimrc" et ajoutez quelque part (à la fin du fichier par exemple):

" for vroom
set exrc

Voilà, maintenant on y va... On commence par créer un template:

mkdir ~/slidetuto/
cd ~/slidetuto/
vroom -new

Un fichier est alors créé: "slides.vroom". C'est le fichier qui va avoir tout le contenu. Il y a pas mal de commentaires dans ce template. Pour le moment, on ne va pas le modifier et simplement lancer le slide:

vroom -vroom slides.vroom

Vim se lance, et le premier slide apparait. Pressez la touche Espace et vous passez au second slide, pressez une nouvelle fois Espace et vous voyez des lignes apparaitre au fur et à mesure. Arrivé au slide 5 vous allez voir un bout de code Perl. Pressez alors la séquence "RR" (Shift R R) et voilà le code exécuté.

Vous pouvez revenir en arrière avec la touche Backspace (la touche d'effacement).

Bref, arrivé à la fin du slide, vous pouvez quitter en pressant QQ (encore une fois, avec la touche Maj enfoncée).

Si vous regardez dans le répertoire, vous voyez une série de fichiers qui a été générée. En fait, Vroom fait simplement une ouverture dans l'ordre de fichier, et passe de buffer en buffer via un map de commande (Espace mappé en ":n" pour passer au buffer suivant). C'est bête comme choux, mais ça marche.

Regardons le fichier slides.vrooms.

En haut, une partie sert à la configuration du slide. Vous pouvez ici surcharger un comportement de vim (par exemple, pour ma part, je dois forcer "set nonumber" pour ne pas avoir de numéro de ligne) ou encore forcer les dimensions de slide. Une option intéressante est justement de permettre le calcul automatique de la taille en fonction du terminal. Il suffit de décommenter "auto_size: 1" et le tour est joué.

Du coup, vous pouvez changer la taille de police de votre terminal pour la rendre plus lisible sur un rétroprojecteur, et tout va se caller correctement.

Ensuite, chaque slide est séparé par 4 tirets sur une ligne "". Cette ligne peut aussi permettre de spécialiser un slide, par exemple vous voyez dans le template de base qu'un slide est utilisé pour lancer du Perl (et avoir la coloration syntaxique). Les slides de code permettent d'utiliser Perl, PHP, Python, Sh, Haskell, et quelques autres...

Un double égal (==) permet de définir le titre (qui sera centré). Et si une ligne commence par "+" alors elle n'apparaitra qu'après avoir pressé Espace.

C'est simple... et ça fonctionne.

Pour ceux qui comme moi avez déjà un .vimrc fourni, et qui vous demande d'avoir une configuration forcée, voici comment faire.

Dans la partie de configuration, en haut, ajoutez simplement:

vimrc: |
    set nonumber

Ou tout autres options dont vous avez besoin.

Il est possible d'exporter votre slide en HTML, en texte brut, et il existe même un bindings pour envoyer vos slides sur github.

Le seul défaut que j'ai trouvé est que si vous vous trompez dans la configuration de votre slide, la commande "vroom -vroom slides.vroom" ne vous donne aucune information... mais je pense que cela va évoluer.

Voilà, j'ai tout simplement trouvé ce système intéressant, je m'en sers de plus en plus pour faire des vidéos didacticiels, et je pense que vous pouvez avoir un intérêt à l'utiliser.

Un OSD de capture clavier en bash

Metal3d — Sun, 29 Jul 2012 18:40:00 +0200

Impossible de trouver un outil OSD de capture clavier qui puisse fonctionner convenablement avec un tilling desktop... car évidemment tous les outils que j'ai trouvé me place la capture dans la mosaïque... Comme je suis en vacance, je me suis pris 25 minutes à coder un truc qui marche en bash, et qui fasse du vrai OSD (On Screen Display), c'est à dire "sans fenêtre". Et comme je suis gentil, je vous montre

Je cherchais sur le net un outil qui afficherait ce que je tape au clavier sur l'écran. Histoire de faire des captures pour des didacticiels vidéo. J'ai cherché un peu partout, rien ne me plaisait vraiment... je me suis alors penché sur une solution à coder. Deux outils sont utilisés: xosd et xinput. OSD voulant dire: On Screen Display, c'est à dire "Affichage sur l'écran"

Je suis d'abord parti en Python... puis en quelques minutes je me suis dit que "finalement, en bash, ce sera tout aussi simple à gérer"... vous me pensez fou, c'est pas faux...

Pourquoi utiliser un vrai OSD ? tout simplement parce que ça m'énervait d'avoir une fenêtre qui affiche les contrôles... je bosse sur Xmonad, et par conséquent le mode "tilling" en fait baver les outils que j'ai trouvé...

Avant de pouvoir utiliser mon script il vous faudra installer 3 paquets (je ne sais pas lesquels sont là par défaut):

yum install util-linux xosd xorg-x11-apps

Cela vous donne quelques commandes que mon script utilise:

xinput qui va capter ce que vous tapez
osd_cat qui affiche des choses sur l'écran
script qui va capturer une sortie terminal

Le script que vous allez voir par la suite fait quelques manipulations:

trouve le clavier par défaut: je cherche un clavier qui a "AT" dans "xinput --list"
lance la capture des touches via "xinput test ID" où ID est l'identifiant du clavier trouvé ci-dessus
faire tourner ça dans "script" qui écrit le typescript dans /dev/null, mais dont la sortie sera captée dans un FIFO
cherche la correspondance de clef clavier dans "xmodmap -pke" et écrit ça dans un autre FIFO
et enfin, en boucle, on lit le FIFO de sortie clavier qu'on inject dans "osd_cat" avec des options de couleur, de placement, de fontes...

Je me suis amusé à savoir si on pressait une touche de modification (Maj, Ctrl, Super...) pour concaténer les chaines.

Le script est loin d'être parfait, il affiche mal la touche "AltGr" et vous ne pouvez pas non plus faire des maintiens de touches trop complexe en séquence. Par exemple il est impossible de presser:

Ctrl+shift+a puis relacher shift et a en gardant Ctrl pessé et frapper une autre touche sans relacher Ctrl

Bref, le but était de faire un truc fonctionnel, rapidement, et qui me permette de faire à peu près ce que je veux... Je ferai évoluer le script et je le mettrai à jour ici.

Attention les yeux, voici le script:

#!/bin/bash
#author Patrice Ferlet
#Licence BSD
 
 
#some conf vars
COLOR="Purple"
FONT='-*-terminus-*-*-*-*-32-*-*-*-*-*-*-*'
DELAY="5"
XPOS="center"
YPOS="bottom"
OFFSET="15"
INDENT="80"
MAXLINE=3
 
#FIFOS
_tmp_opt=""
if [[ -d /dev/shm ]]; then
    #some unix can use shared memory instead of /tmp
    _tmp_opt=" --tmpdir=/dev/shm"
fi
 
OSDPID=""
TMP=$(mktemp -u $_tmp_opt)
OSD=$(mktemp -u $_tmp_opt)
mkfifo $TMP
mkfifo $OSD
 
 
#when script is closed, remove fifos
onexit(){
    echo "close..."
    kill $OSDPID
    rm -f $TMP
    rm -f $OSD
    exit 0
}
trap onexit INT TERM
 
#get valid keyboard input
kb=$(xinput --list | grep "keyboard" | grep "AT" | grep -Po "id=\d+" | cut -d"=" -f2)
 
#launch "script" to capture xinput, this is a trick !
script -c "xinput test $kb" -f /dev/null > $TMP &
 
#lauch osd command that read OSD fifo
tail -f $OSD | osd_cat -a -d $DELAY -l $MAXLINE -f $FONT -A $XPOS -o $OFFSET -i $INDENT -p $YPOS -c $COLOR &
OSDPID=$!
 
#be sure everything is launched
sleep 0.2
 
#now, read lines from xinput output to do the job
MOD=""
while read line; do
    #reading code, state (press, release) and get keyboard value
    #from xmodmap
    code=$(echo "$line" | awk '{print $3}')
    state=$(echo "$line" | awk '{print $2}')
    key=$(xmodmap -pke | awk "/keycode\s*$code\s+/ {print \$4}")
 
    if [[ $(echo "$key" | grep -Pi "Control|Shift|Alt|Super") ]]; then
        #this case should not be displayed, we only record mod key
        MOD="$MOD$key + "
        if [[ "$state" == "release" ]]; then
            #mod released, remove mod
            MOD=""
        fi
    elif [[ $state == "press" ]]; then
        if [[ $( echo "$MOD" | grep "Shift") ]]; then
            #shift pressed, we should read 5th column
            key=$(xmodmap -pke | awk "/keycode\s*$code\s+/ {print \$5}")
        fi
        echo "$MOD$key" > $OSD
    fi
done < $TMP
exit 1

Vous lancez ce script dans un terminal, puis n'importe où vous pressez des touches... Cela les affiches en OSD. Voilà, c'est ce que je voulais... rien de plus.

Pour arrêter le script, retournez sur le terminal et pessez CTRL+c, cela coupe le script, en supprimant les FIFO en passant.

Voilà, si vous avez des questions, des remarques... je suis preneur !

UPDATE: et oui, il manque un truc... je coupe pas osd_cat à la fermeture, je corrige le script de suite... désolé UPDATE: Voilà, corrigé

Correction orthographique et grammaticale avec Vim

Metal3d — Sun, 03 Jun 2012 21:28:00 +0200

J'en avais assez de voir que je tapais faute sur faute en préparant mes billets sous Vim... je suis mauvais en orthographe, et pire en grammaire. J'ai honte souvent de cette tare, alors j'ai décidé de fouiller pour trouver une méthode propre pour supprimer un bon paquets de fautes en utilisant mon éditeur favori. Voici ce que j'ai à vous proposer.

Vous êtes comme moi un mordu de Vim, vous tapez vos documents en RST, en Latex, ou je ne sais quel format brut. Vous avez un manque, celui d'avoir l'auto-correction orthographique et grammaticale. Je viens de me configurer mon éditeur favori pour avoir la correction des deux aspects.

Nous allons devoir installer quelques fichiers. En premier lieu, il faut récupérer les dictionnaires français de vim. La manière la plus simple est de faire:

mkdir -p ~/.vim/spell
cd ~/.vim/spell
wget http://ftp.vim.org/vim/runtime/spell/fr.latin1.spl
wget http://ftp.vim.org/vim/runtime/spell/fr.latin1.sug
wget http://ftp.vim.org/vim/runtime/spell/fr.utf-8.spl
wget http://ftp.vim.org/vim/runtime/spell/fr.utf-8.sug

Fermez vim si vous en avez déjà ouvert un. Cela permettra de s'assurer que tout soit pris en compte au démarrage.

Pour tester l'option spell, ouvrons un éditeur vim et rédigeons quelques phrases. Faites en sorte de faire des fautes, puis pressez: Echap, :set spelllang=fr spell

Cela permet d'activer la langue française, puis de mettre en surbrillance les mots erronés. Toujours en mode commande (donc en ayant pressé sur Echap), allez au début du document en pressant "gg", puis "]s". Le curseur se déplace au premier mot mal orthographié. Vous avez alors plusieurs options :

pressez "z=" et vous entrez dans le mode "choix de mot" - taper Enter ou le numéro du mot que vous voulez utiliser.
presser "zg" pour ajouter le mot dans le dictionnaire local
presser "zG" pour l'ajouter au dictionnaire global
presser "]s" pour aller au prochain mot
presser "[s" pour aller au prochain mot

Ce procédé est sympa pour une phase finale, après avoir rédigé. Mais si vous voulez avoir une mode de correction en cours de frappe, il existe une autre commande. Vim permet de compléter un mot lorsque l'on s'en sert d'éditeur de code. On utilise alors CTRL+X puis une lettre correspondant à un mode de complétion.

Le mode utilisé pour "spell" est "s". Donc, après avoir tapé un mot de la mauvaise manière, il suffit, sans quitter le mode "insert", de presser CTRL+X puis "s". Une liste de propositions de mots s'affiche. Sélectionnez celui qui vous plait, puis pressez "espace" ou tout autre caractère pour continuer la rédaction.

Reste maintenant à avoir une correction grammaticale. Pour cela, nous allons utiliser un outil en Java servi dans les options d'OpenOffice, et un plugin Vim fortement bien pensé.

Commençons par l'outil Java en question. Il se nomme LanguageTool et se trouve à l'adresse: http://www.languagetool.org/

Il suffit de décompresser le fichier zip dans un répertoire de votre choix, cela va vous proposer deux fichiers, un ".jar" et un ".oxt" qui vont vous permettre la correction grammaticale. L'intégration à vim se fait avec le plugin: http://www.vim.org/scripts/script.php?script_id=3223

Suivons le procédé recommandé, on télécharge la dernière version, puis:

cd ~/.vim
unzip /chemin/vers/LanguageTool.zip

On finit par configurer l'outil en ouvrant le fichier ~/.vimrc, et en plaçant quelque part cette ligne:

:set spelllang=fr
let g:languagetool_jar='/chemin/vers/LanguageTool.jar'

En remplaçant évidemment le chemin par la bon. Je vous conseille d'utiliser un répertoire simple à retrouver, genre /usr/local/LanguageTool ou comme moi dans un répertoire utilisé pour compiler vous même l'outil. J'utilise pour ma part la version SVN que je mets à jour souvent et que je compile simplement avec "ant". Si vous éditez votre vimrc avec vim, n'oubliez pas le racourcis (en mode insert) "CTRL+X f" qui complète le chemin.

Voilà, on rouvre notre texte, et on va s'amuser. Activez si vous le souhaitez le mode "spell" en tapant: "Echap, :set spell"

Tapez avec des fautes, faites vraiment des erreurs (accords, temps, double virgule...), puis pressez: Echap, ":LanguageToolCheck" (la touche tabulation complète les commandes je vous rappelle).

Après quelques secondes, un mini buffer apparaît et vous donne une liste complète des fautes possibles que vous auriez faites, avec si possible des proposition de correction. Allez dans ce minibuffer en pressant CTRL+W w et faites défiler la liste. En pressant sur la touche Entrée votre curseur ira à la faute, ou parfois (je ne sais pas pourquoi) au début de la phrase erronée. Il suffit de les corriger au fur et à mesure. Pour nettoyer le texte des surlignages, vous pouvez simplement taper: Echap puis ":LanguageToolClean".

Et pour supprimer le surlignage du mode spell, Echap, ":set nospell"

Bref, voilà de quoi vous amuser à corriger la plupart de vos erreurs dans un éditeur tel que Vim. Vous prendrez vite cette habitude de lancer la commande, et de mettre le mode "spell" en marche.

Certes, il restera des erreurs parfois, à vous de relire et de ne pas vous lasser de vérifier mot à mot les coquilles possibles. Mais ces outils vont au moins permettre d'éliminer un bon paquet d'erreurs. Alors ne vous en privez pas. Personnellement j'en avais tellement assez de vous poster des billets bourrés de fautes que je suis passé à ces outils... Ne m'en voulez pas s'il en reste encore... je vous promet de faire des efforts.

Notez que LanguageTool - l'outil java - permet aussi de prendre en argument le fichier à corriger. Donc, vous pourrez vous en servir en dehors de vim ou en l'intégrant dans Emacs, Gedit, ou quelques autres éditeurs acceptant les greffons (plugins)

En espérant vous avoir fait découvrir un outil sympathique

Ha oui un dernier truc, comme je suis dans un terminal, et que je veux copier mon billet depuis vim vers mon navigateur, je sauve mon fichier et je fais simplement:

Echap
:!xclip %

Le fichier est alors copié dans le presse-papier, reste plus qu'à le coller dans l'éditeur (bouton central de la souris, ou Maj+Insert). On gagne du temps...

Go, routines et canaux - introduction au langage

Metal3d — Mon, 28 May 2012 13:03:00 +0200

Il y tellement de nouveaux langages, quand un de ceux là sort du lot c'est en général parce qu'il offre des concepts particuliers. Go est un de ceux là, et les concepts de routines, de canaux et de fonctions différées ne sont qu'une infime partie des possibilités que vous pouvez découvrir dans ce langage. Testons un peu ce langage.

J’ai la chance d’aimer mon métier, et dans ce métier on apprend souvent de nouvelles choses, des concepts, des langages... Dans le panel de langages informatique que j’ai put entrevoir, certains m’ont vraiment surpris dans leur concept. Le premier dont j’ai eut beaucoup de mal à m’approcher est le Haskell, et depuis peu je me penche sur Go. Je m’empresse donc de vous montrer un peu l’intérêt que je vois dans ce langage.

C’est Nicolas Engel, avec qui j’ai travaillé sur un projet, qui m’en a reparlé et l’envie de me repencher sur Go s’est vite manifesté.

Alors Go c’est quoi ?

Ce langage a été créé par une équipe de Google depuis 2010 et a pour vocation de réduire des problématiques que beaucoup de développeurs doivent supporter dans d’autres langages. Vous pouvez utiliser le compilateur Go à télécharger ici: http://golang.org/ ou utiliser gcc-go (package Fedora disponible dans les dépots officiels)

C’est un langage compilé, performant et sous licence BSD... La seule complication, et vous allez voir qu’elle est dominante au début, c’est que le concept est vraiment différent de pas mal de langages. Amis développeurs Python, Java, PHP et même C/C++... vous allez être un peu surpris.

La raison principale de la création de ce langage a été motivée par la réduction de problématiques telles que les threads, les sémaphores, les transferts interprocessus, les fractures mémoire, et l’impérativité des langages communs. Vous allez voir que des concepts ont été ajoutés à Go pour rendre tout cela vraiment très simple... si si, c’est finalement très simple.

Tout d’abord, c’est un langage fortement typé, les habitués de langages typés dynamiquement vont devoir se faire une raison: il va falloir déclarer vos variables. Ensuite, Go n’est pas un langage purement objet mais vous allez facilement pouvoir déclarer des struct avec des méthodes attachées. J’entends d’ici pas mal d’entre vous rire doucement sur un fond de “huhu aujourd’hui faire un langage non objet... c’est juste revenir dans le passé, autant faire du C”. Je tiens à donner mon avis là dessus, les langages orientés objet ont leurs avantages certains, mais Go est surtout fait pour être performant dans un premier lieu, et le C n’a rien de vieillot car même votre Linux, votre Mac ou votre Windows est un système d’exploitation quasiment entièrement écrit en C.

Enfin, pour ma part, je n’ai aucun mal à imaginer développer une grosse infrastructure logiciel avec un langage structuré non objet. Et surtout si c’est en Go. Dans tous les cas, Go est adressé aux développeurs désirant un langage proche du processeur, un peu comme C/C++ tout en gardant des simplification en terme de threads, sémaphores et gestion mémoire. Bien que Go permette de créer aussi des application web, et se retrouve même dans Google AppEngine. Voyez le guide de démarrage: go appengine.

Bref, passons la polémique trollesque et passons au langage lui même.

On commence par installer le compilateur. Soit vous utilisez gcc-go (dans les dépots) soit vous utilisez le compilateur de google à cette adresse: Golang. Je vous conseille, pour commencer, d'utiliser celui de google et de suivre la manière dont on utilise le runtime. En général, cela revient à faire la commande

go run monfichier.go

Pour le compiler réellement:

go build monfichier.go

Je ne vais pas vous détailler les bases du langage, mais un exemple rapide pour vous donner la syntaxe de base:

package main
 
//fmt est le package de formatage de chaine
import “fmt”
 
//on retrouve une fonction main
func main () {
     fmt.Println(“Hello le mondo !”);
}

Bon rien de bien compliqué, un hello world bateau. Vous remarquez donc qu’on a une notion de package, et donc qu’on pourra séparer des fonctions et structures dans différent package (ce qui est un plus quand on se réfère au C). Cela ressemble fortement aux espace de nom (namespace) mais l’idée est plus claire selon moi.

Petite parenthèse, vous allez rapidement vous rendre compte au fur et à mesure que la plupart des concepts en Go se retrouve d’une manière ou d’une autre dans C.

Alors y’a quoi de nouveau ?

D’abord, comment on déclare une variable ? et bien de deux façons:

// i variable de type int
var i int
i = 4
 
//ou bien
//i est une entier valant 4, le typage est déduit par inférence
i:=4

Pour faire simple, utiliser ":=" (oubliez pas les deux points) pour déclarer en assignant, sinon l'assignation se fait avec un simple "="

Voilà, pas plus pas moins... on va pas parler de pointeur et de structure de suite, mais vous n’aurez pas de mal à comprendre en lisant la documentation ou en faisant le gotour (voir les liens en fin de billtet)

Je vais vous lister 3 concepts qui m’ont plut dans ce langage. Le premier est le concept de “goroutine” qui est foncièrement parlant une méthode pour créer des threads sans se prendre la tignasse et se taper le front sur le clavier. Le second concept est le principe de canal (channel) qui permet tellement de choses qu’on s’attriste de ne pas les avoir dans les autres langages (du moins pas sous cette forme). Un canal permet de faire transiter des valeurs d’un processus à l’autre, de bloquer un processus tant qu’un autre n’est pas terminé et en plus de bufferiser tout ça. C’est le concept de sémaphore (mutex) amélioré dans sa conception. Le troisième concept est la possibilité de différer un appel dans le temps (defer). Cela rend le code lisible à souhait.

Un autre concept, que l’on retrouve un peu en python, est le fait de pouvoir retourner plusieurs valeurs de plusieurs types depuis une fonction. Ceux qui n’ont pas compris l’intérêt devrait penser simplement à cela: imaginez une fonction qui retourne un résultat et un code d’erreur. Plutôt que de devoir retourner une structure, ou un objet pour les langages qui le permettent, on retourne une liste simple de variables.

Bref, passons aux goroutines de suite.

L’appel à une routine se fait simplement via le mot clef “go”. La fonction sera appelée dans un thread (mais dans le même processus, on ne parle pas d’un fork ici, mais bien d’un thread) et rien d’autre n’est à faire !

Je ne vous ai pas encore parlé des canaux, donc cet exemple ne va pas fonctionner exactement comme on le veut, mais le concept est là. Ne cherchez pas si ça fonctionne mal chez vous.

package main
 
import "fmt"
 
func hello(you string){
    for i:=0; i<5; i++ {
        fmt.Println("hello you:" + you)
    }
}
 
func main (){
    go hello("Pierre")
    hello ("Paul")
}

Ce qui va vous donner (selon la manière dont les threads sont créé sur votre OS):

hello you:Paul
hello you:Pierre
hello you:Paul
hello you:Pierre
hello you:Paul
hello you:Pierre
hello you:Pierre
hello you:Pierre
hello you:Paul
hello you:Paul

Vous l’avez remarqué, j’ai parfois 3 fois “Pierre” qui apparait, parfois 2 fois “Paul”. Cela est le fait que la routine est géré selon les disponibilités du CPU.

Bon, on passe aux canaux. Là vous risquez de perdre un peu le fil, mais je vous assure que la capacité de ce concept est tout bonnement génial.

Un canal est un type dont le principe est d’empiler des valeurs et de bloquer le processus si on cherche à lire dedans, et que celui-ci si il est vide. C’est le principe du FIFO. L’intérêt est sa syntaxe aisée et lisible.

Il faut utiliser la fonction “make” (genre de malloc, mais orienté fabrique ou factory) pour créer un “chan”.

//canal prenant des entiers
c := make (chan int)

Un canal peut prendre n'importe quel type, entier, flottants, chaines... et même des structures.

Ensuite c’est plutôt simple... On utilise “<-” pour placer des valeurs dans le flux.

Donc:

//empile un entier (1) dans le canal
c <- 1

Et pour lire le canal

//bloque tant que rien n’est empilé dans c
//on peut récupérer la valeur empilée
int val := <-c2
//ou simplement attendre une écriture dans la canal
<-c2

Faisons simple, on va juste comprendre le principe du canal:

package main
 
import "fmt"
 
func routine(a, b chan int){
     i := <-a
     fmt.Printf("je viens de lire dans le canal: %d\n", i);
 
     //'main' attend toujours, je vais écrire dans le canal b
     //pour le débloquer
     b <- 0
}
 
func main(){
    a,b := make(chan int), make(chan int)
 
    //on écrit dans a
    a <- 2
    //on lance une fonction en parallèle
    //qui reçoit les deux canaux en paramètres
    go routine1(a,b)
 
    //on va attendre la fin de la routine
    //la routine doit écrire dans le canal b 
    //pour que cette instruction se débloque
    <- b
    fmt.Println("voilà, j'ai fini, b a été lut")
}

Pour le moment on s'amuse à débloquer des canaux en écrivant dedans. Sachez que vous pouvez fermer un canal avec la fonction "close" mais si vous en avez besoin, c'est que vous être dans un cas particulier. Car en fait, Go n'aime pas que des canaux restent ouverts avec une valeur bloquée et non lut... pensez à traiter correctement les canaux, sinon forcez la fermeture avec "close"

Voyons un autre exemple de code qui va fonctionner avec un canal d’entier. Un peu plus salé par contre...

package main
 
import "fmt"
import "time"
 
 
func thread1 ( sem, done chan int) {
    fmt.Println("je suis le thread 1, je commence à bosser")
 
    //grosse fonction qui prend du temps
    time.Sleep(1 * 1e9)
 
    //on débloque le sémaphore
    sem<-0
    //on travaille encore un peu
    time.Sleep(1 * 1e9)
    fmt.Println("je suis le thread 1, je préviens main que je termine")
    //je préviens que la routine est finie
    done<-1
}
 
//voir plus bas (dans thread2), 
//cette méthode va permettre
//une exécution différée
func send(c chan int, num int) {
    c <- num
}
 
func thread2 (sem, done chan int) {
    //autre manière de s'assurer qu'on écrit bien à la
    //fin de la fonction :
    //defer permet de différer l'appel à "send" 
    //à la fin de ma fonction
    defer send(done, 2) 
 
    fmt.Println("je suis le thread 2, je commence à bosser")
 
    //on attend la fin de thread 1
    <-sem
    fmt.Println("je suis le thread 2, on m'a débloqué")
 
    //on bosse encore un peu
    time.Sleep(2 * 1e9)
 
    //quant sleep a terminé, la fonction différée va
    //être exécutée
}
 
func main(){
    //sem va me permettre de gérer les bloquage et débloquage
    //des goroutines
    sem := make (chan int)
 
    //ce canal sera emplilé par la seconde routine pour dire
    //à la fonction main qu'il a terminé
    done := make (chan int)
 
    //on lance les deux routine en parallèle, elle vont communiquer
    //au traver de sem
    //on remplira "done" pour dire que le thread est terminé
    go thread1 (sem, done)
    go thread2 (sem, done)
 
    fmt.Println("je suis dans main, j'attend la fin en lisant le canal 'done'")
 
    //les routines vont écrire dans "done",
    //j'attend que ce soit le cas pour les deux threads
    //donc on attend 2 fois
    //la variable i récupérera la valeur envoyé dans le canal
    var i int
    i = <-done
    fmt.Printf("routine %d vient d'écrire dans le canal 'done'\n", i)
    i = <-done
    fmt.Printf("routine %d vient d'écrire dans le canal 'done'\n", i)
 
    fmt.Println("je suis dans la fonction main, on m'a débloqué")
 
}

Voilà ce que donne mon programme:

je suis dans main, j'attend la fin en lisant le canal 'done'
je suis le thread 1, je commence à bosser
je suis le thread 2, je commence à bosser
je suis le thread 2, on m'a débloqué
je suis le thread 1, je préviens main que je termine
routine 1 vient d'écrire dans le canal 'done'
routine 2 vient d'écrire dans le canal 'done'
je suis dans la fonction main, on m'a débloqué

Ce qui est exactement ce que je voulais. La fonction main s’est mise en attente, les deux threads on commencé à travailler en parralèle. La routine 1 déblique la routine 2, mais cette routine 1 fini certaines choses en même temps. Enfin, la fonction “main” remprend la main (non c’est pas un jeu de mot)...

Plutôt que de créer une fonction "send" qui n'est utilisée que dans le thread 2, on peut utiliser un système de closure. Car en effet, les fonctions en Go sont des closures. Revoyons le code du thread 2:

func thread2 (sem, done chan int) {
    //autre manière de s'assurer qu'on écrit bien à la
    //fin de la fonction :
    //on crée une closure exécutée en fin de fonction
    //notez que c est local à la closure, la closure prend "done"
    //en argument, donc c correspondra à done
    defer func (c chan int) {
        c <- 2 
   }(done)
 
    fmt.Println("je suis le thread 2, je commence à bosser")
 
    //on attend la fin de thread 1
    <-sem
    fmt.Println("je suis le thread 2, on m'a débloqué")
 
    //on bosse encore un peu
    time.Sleep(2 * 1e9)
 
    //quant sleep a terminé, la fonction différée va
    //être exécutée
}

Vous pouvez donc supprimer la fonction "send". On retrouve ici un concept de fonction "inline" interne à une fonction. En bref, la capacité qu'à Go à vous simplifier la vie est vraiment intéressante.

Bref, là je n’ai fait qu’une introduction à Go... je n’ai pas le recul ni l’expérience nécessaire pour aller plus dans le détail (bien que je m’amuse comme un fou avec des tests bourrins). Je vous conseille d’aller lire le “gotour” ici : GoTour. Je vous conseille de bien vous pencher sur les notions de "range", de retour de plusieurs variables depuis une fonction mais aussi sur les concepts de structure et fonctions de structure. Ce billet ne visait qu'à vous éclairer sur ce que peut vous apporter Go coté parallélisation.

Go est désormais utilisable dans appengine, vous pouvez aussi créer votre propre miniserveur HTTP très facilement avec le package (inclu) "net/http" et que des portage de Gtk, WX etc... ont vu le jour et fonctionnenent.

En ce qui concerne les deux compilateurs, le compilateur (et runtime) Go de Google compile de manière statique mais donne de superbe résultats en terme de performances. Vous pouvez utiliser gcc-go (dans les dépots Fedora du moins) qui vous permettra de compiler dynamiquement vos programmes (le compilateur go faisant de la compilation statique...)

Un dernier point, Go vous permet aussi de récupérer très aisément des librairies C et d’utiliser les fonctions impémentées dans ce langage.

Google App Engine et le souci os_compat

Metal3d — Mon, 21 May 2012 18:46:00 +0200

Google AppEngine propose est un service de développement web assez puissant et très intéressant qui permet de faire une application "scalable" en Java, Python et maintenant en Go. Le souci, si comme moi vous avez "MyPaint" et par conséquent le paquet protobuf-python... vous allez vous taper une erreur monstrueuse au démarrage de votre application... on va trouver une méthode simple pour contourner ce souci

Car effectivement, au premier lancement de votre application:

 ./google_appengine/dev_appserver.py helloworld/
Traceback (most recent call last):
  File "./google_appengine/dev_appserver.py", line 125, in <module>
    run_file(__file__, globals())
  File "./google_appengine/dev_appserver.py", line 121, in run_file
    execfile(script_path, globals_)
  File "/home/patachou/Dev/google_appengine/google/appengine/tools/dev_appserver_main.py", line 138, in <module>
    from google.appengine.tools import os_compat
ImportError: No module named appengine.tools

Pourquoi ? tout simplement parce que le paquet protobuf contient un module nommé... google ! du coup, python ne va pas voir ailleurs que dans le site-package protobuf et plante misérablement, lachant son dernier souffle en vous insultant... et vous, vous n'avez que pour seule solution de vous rabattre tant bien que mal sur des discussions sur le net où tout le monde vous demande de supprimer protobuf.

Sauf que moi, j'utilise MyPaint et j'ai pas envie de me remettre le paquet à chaque fois que je veux dessiner. Et puis de toutes manières j'aime pas les méthodes où il faut supprimer un paquet tout simplement parce qu'une implémentation sent la fosse septique...

La solution ? oui oui deux secondes...

Elle est simple ma solution... utiliser un environnement virtuel ! Attention, pas un LXC ou une VM qui va vous plomber tout votre espace disque... non ! juste un outil python qui rend tellement service, et dont je me sers tout le temps pour tester mes "setup.py" et autres joyeusetés qui peut simplement foutre le boxon dans mes répertoires.

Bref, on va faire ça propre !

On crée un environnement virtuel

mkdir -p ~/Dev/appengine
virtualenv ~/Dev/appengine

Voilà, c'est fait... on copie maintenant le répertoire "google" fournis avec le SDK Python de Google App Engine:

cp -ra ~chemin/vers/google_appengine/google ~/Dev/appengine/lib/python2.7/site-packages/

Et pour lancer l'engin google, on active l'environnement:

source ~/Dev/appengine/bin/activate

Du coup, on voit notre prompt terminal commencer par: (appengine), chez moi ça donne:

(appengine)[patachou@patrice-laptop ~]$

Vous pouvez maintenant lancer votre programme (prenez le tutorial python 2.7 de google) de cette manières:

~chemin/vers/google_appengine/dev_appserver.py helloworld/

Pour sortir de l'environnement virutel:

deactivate

Voilà, c'est simple, assez propre, et en plus ça marche...

Typescript to gif - convertir une capture terminal vers un gif animé

Metal3d — Sun, 20 May 2012 16:01:00 +0200

Comment utiliser la commande "script" et un peu de bash + imagemagick pour en faire une animation en GIF (ou pourquoi pas une vidéo par la suite)

Cette semaine, un administrateur système m'a montré une commande que je ne connaissais pas du tout... "script". Ce petit utilitaire permet d'enregistrer le flux terminal vers un fichier afin d'être relu. En grattant dans le "man" j'ai découvert deux options intéressantes, l'une d'elle permet de garder les "temps" de commande + le nombre de caractères à lire... On peut alors utiliser "scriptreplay" pour relire la session ou bien, comme moi, jouer avec et créer une animation

Prenons le temps de comprendre. Si je tape la commande:

script --timing=/tmp/timing /tmp/script

alors commence une session enregistrée dans le fichier /tmp/script.

Tapons alors des commandes, par exemple

echo "hello world"

Puis pressez CTRL+D. La session "script" s'arrête. Vous pouvez rejouer la session (qui ne va pas rejouer les commandes, mais les afficher avec les résultats de l'époque...) en utilisant "cat"

cat /tmp/script

Or... on a besoin de voir "à la replay" la commande. Soit:

scriptreplay -t /tmp/timing /tmp/script

Et là, c'est déjà plus joli. Mais voilà, pour partager une capture de ce genre en vidéo (ou en gif animé) ce format ne nous convient pas encore. On va donc réfléchir recréer une belle vidéo de tout ce beau monde.

Première option, on fait un screencast (avec ffmpeg) mais bon... la souris peut apparaître... et puis pour en faire un gif c'est pas encore ça.

Seconde option, celle qu'on va mettre en place, est de faire ceci: - relire le fichier /tmp/timing - prendre séquence par séquence le texte depuis le typescript (fichier généré par la commande script) - afficher ça dans le terminal et faire une capture du terminal avec la commande "import" - relire une fois de plus le timing et cette fois ci: lire les temps d'attente - utiliser "convert" avec l'option -delay pour mettre frame à frame les images dans le gif animé.

Voilà... bon je vais pas passer par 4 chemins, le but n'est pas de vous apprendre à faire du bash mais au moins vous parler des "soucis" que j'ai dut régler: - lire un fichier d'un certain endroit à un autre: on utilise "dd" - créer des images numérotées avec 5 chiffres pour être à l'aise: printf

Le reste coule presque de source... Voilà le script:

#!/bin/bash
 
TIMING=$1
SCRIPT=$2
W=$WINDOWID
 
rm -rf /tmp/script-replay-gifs/
mkdir /tmp/script-replay-gifs/
 
t=$(mktemp)
cp $SCRIPT $t
 
#remove first line
sed -i '1d' $t
 
#clear screen
clear
 
#read timing file one by one
curr=0
i=0
while read line
do
    #capture time and chars to read
    cols=($line)
    chars=${cols[1]}
 
    #read from current char the number of chars to read
    dd if=$t bs=1 skip=$curr count=$chars 2>/dev/null
 
    #convert to gif frame with a nice frame-number
    n=$(printf "%010d" $i)
    import -window $WINDOWID /tmp/script-replay-gifs/$n.gif
 
    #and move to next position
    curr=$((curr+chars))
    i=$((i+1))
done <$TIMING
rm -f $t
 
#now, set gif with delay per frame
i=1
while read line
do
    cols=($line)
    timing=${cols[0]}
    #get next image
    file=$(ls -1 /tmp/script-replay-gifs/ | head -n $i | tail -n 1)
    timing=$(echo "$timing*100" | bc -l | awk '{print int($0)}')
    command=$command" -delay $timing /tmp/script-replay-gifs/$file"
 
    i=$((i+1))
done < $TIMING
 
convert $command /tmp/anim-notoptim.gif
convert /tmp/anim-notoptim.gif -coalesce -layers Optimize /tmp/anim.gif
 
rm -f /tmp/anim-notoptim.gif
rm -rf  /tmp/script-replay-gifs/

Ce script est très très lent à cause de "import" qui prend près d'une seconde par capture... de ce fait pour le moment c'est pas un modèle du genre... et en plus, vous ne pouvez pas quitter le bureau dans lequel vous être pour créer l'animation sous peine de messages d'erreur. Notez que ce n'est un qu'un petit test

Cela donne:

Pour le coup, j'ai quand même posé un petit coup de "gimp" pour optimiser le gif animé. Je vous laisse maître de me faire des remarques et pourquoi pas (si vous le demandez) je créerai un dépôt git quelque part pour qu'on le fasse évoluer.

Update: j'ai ajouté une opération d'optimisation de taille à la fin du script

Point de montage Google Drive

Metal3d — Fri, 27 Apr 2012 18:21:00 +0200

Google vient de sortir Google Drive, comprenez un espace de stockage dans le "cloud" (à distance, sur les serveur Google, avec mix des documents de google-docs). L'application de disque dur distant est accessible de plusieurs manières: Android, PC ou directement sur le net. Or sous Windows et Mac on a la possibilité d'utiliser un programme qui monte un disque sur l'ordinateur. Qui dit "monter" rappelle le point de montage Linux (unix...). Google a annoncé une version de Google Drive Linux pour bientôt mais en attendant vous pouvez encore utiliser le projet http://code.google.com/p/google-docs-fs/

Ce projet était à la base un système de montage simple utilisant fuse pour afficher les google-docs sur un disque monté localement. Mais comme Drive utilise le même point d'accès, ce (vieux) projet fonctionne très bien. Sous Fedora, il suffit de faire:

update merci à "hk", j'avais oublié le paquet python-gdata


su -c "yum install fuse-python python-gdata -y"

cd /tmp
hg clone https://code.google.com/p/google-docs-fs/
cd google-docs-fs
su -c "python setup.py install"

Reste alors à monter le dossier:

mkdir ~/GoogleDrive
gmount ~/GoogleDrive votre_user@gmail.com

On vous demande alors le mot de passe google, et hop le point de montage est créé:

mount
gmount.py on /home/patachou/GoogleDrive type fuse.gmount.py (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Vous pouvez dés lors visiter le dossier, créer des répertoires, copier des données, ouvrir vos documents... et y accéder depuis votre mobile, le net... Reste à voir ce que l'application Google offrira de mieux que ce petit projet python, parce que pour le moment cela me convient tellement bien...

PS: vous pouvez ajouter ce point de montage dans /etc/fstab pour l'avoir actif tout le temps, mais comme je ne sais pas comment placer le mot de passe. Je vous tiens au courant si je trouve

Intégration continue - PHP, Selenium et Xvfb - Partie 1

Metal3d — Sat, 31 Mar 2012 11:23:00 +0200

Depuis quelques mois je me suis penché sur les outils d'intégration continue pour les projets PHP. Il en existe un bon paquet, mais celui qui pour le moment répond le mieux à mes attentes reste phpUnderControl. L'installation reste tout de même assez complexe et il me parait bon de vous montrer comment mettre en oeuvre ce genre d'outil. Le but étant de vous aider pas à pas à installer les outils qui permettront d'utiliser un service d'intégration continue. Nous allons passer en revue les outils à installer depuis PEAR, puis Selenium et enfin comment intégrer tout ça dans phpUnderControl.

Certes, je ne vais pas vous donner "la solution dans les règles de l'art" car chaque projet est différent, chaque attente est spécifique... Mais vous pourrez adapter au besoin les explications.

Nous allons donc procéder à ces opérations:

installer les outils pear: phpcs, phpmd, phpcpd, phpunit
installer selenium IDE avec le plugin php (ces outils ne sont pas obligatoires mais rendent la tâche tellement plus simple...)
préparer un environnement X virtuel pour lancer les tests selenium
installer phpundercontrol
configurer la bête...

Les deux derniers points seront dans la partie 2, pour le moment il faut s'assurer d'avoir tous les composants nécessaires à la bonne conduite du projet.

En ce qui concerne Selenium et phpUnderControl, ce sont des outils développés en Java. On nous recommande d'utiliser le jre de oracle (comme ce n'est plus Sun...) mais pour ma part j'utilise openjdk sans aucun souci... alors pourquoi passer au propriétaire quand le libre fonctionne très bien ?

Donc, sur votre Fedora ou Centos, préparons un environnement propre... Je vous conseille d'utiliser un conteneur LXC pour bosser, mais si vous voulez utiliser votre système hôte je ne vais pas vous en empêcher.

On commence par installer les outils important:

php-cli, php-pear
openjdk

on ouvre un terminal, on se met en root et on installe tout ça

su -
yum install php-cli php-pear java-1.7.0-openjdk

Pour la suite, je sais que certains d'entres vous vont me taper sur les doigts, clamant haut et fort que les dépots Fedora ont les paquets PEAR demandés (ou pas...) mais je vais être très clair: les paquets sur les serveurs PEAR sont à jour, et certaines dépendances risquent de ne pas marcher si vous utiliser les RPM. C'est le cas aussi sur Debian (j'en ai fait les frais cette semaine). Donc ayez confiance et faites ce que je dis

On commence par faire deux ou trois manipulations sur PEAR pour être à l'aise (toujours en tant que root):

pear set-config auto_discover 1
pear upgrade pear
pear install --alldeps pear.phpunit.de/PHPUnit
pear install --alldeps phpunit/PHPUnit_Selenium
pear install --alldeps pear.phpunit.de/phpcpd
pear install --alldeps phpmd/PHP_PMD
pear install --alldeps PHP_CodeSniffer
pear install --alldeps channel://pear.phpdoc.org/PhpDocumentor-2.0.0a1

Si jamais il vous manque des paquets php, installez les, faites un "prear uninstall" du paquet qui a donné une erreur, et relancez l'installation du paquet.

Vous avez donc à présent:

phpunit pour faire des tests unitaires de vos développement php
phpunit-selenium qui est une classe permettant de piloter le serveur selenium qui lancera un navigateur pour tester des aspect fonctionnels
phpcpd (Copy Paste Detector) qui vérifie les "copier coller" de code
phpmd (Mess Detector) qui va vérifier des aspects complexe de code (variables non utilisé, code complexe, nom de variables ou fonctions...)
phpcs qui va vérifier si votre code est bien formaté selon des standards choisis
phpdocumentor qui permet de créer la documentation de vos projets

Cela étant fait, nous allons passer à la suite... Selenium !

Selenium est un ensemble d'outils qui permettent de piloter un navigateur au travers un serveur. Vous allez pouvoir vérifier si une page apparait correctement, si les liens sont bien présents sur une certaine page, et bien plus encore. Le principe est très simple:

on enregistre une séquence de manipulations et de tests
on l'exporte pour phpunit
on lance le test

Mais pour que cela fonctionne, il faut jouer un peu dans le terminal... rien de bien méchant mais important.

Dans votre terminal, en root, téléchargez le serveur:

mkdir /opt/selenium
cd /opt/selenium
wget http://selenium.googlecode.com/files/selenium-server-standalone-2.20.0.jar

Ce serveur, une fois lancé, pilotera un firefox tout seul. Sauf que voilà... si vous travaillez sur une machine de bureau alors aucun souci ne se profile... mais quand on travaille sur un serveur distant... sans écran... ça va aller mal !

La solution la plus simple, selon moi, est d'installer un firefox "standalone" sur /opt/selenium et de lancer tout ça dans un Xvfb (X virtuel). On va donc faire cela... toujours dans votre répertoire /opt/selenium:

wget "http://download.mozilla.org/?product=firefox-11.0&os=linux&lang=fr"
tar jxf firefox*.bz2

Si tout est ok, vous avez un répertoire "firefox" dans /opt/selenium

On va tenter de lancer firefox dans un X virtuel pour être certain que tout se passe bien:

Xvfb :99 &
DISPLAY=:99 /opt/selenium/firefox/firefox &
DISPLAY=:99 import -window root /tmp/snapshot.png

Maintenant, ouvrez /tmp/snapshot.png et vérifiez que vous voyez bel et bien un firefox ouvert. Si oui: nickel ! si non... heu vérifiez si il ne manque pas une librairie pour firefox (genre gdlib-dbus...)

Bref, si Xvfb et firefox ont marché alors on coupe:

killall Xvfb

Notez qu'on aurait put utiliser "xvb-run /opt/selenium/firefox/firefox" et utiliser le port retourné pour faire la capture, mais les lignes su-citées me paraissent plus explicites pour comprendre comment ça fonctionne.

Bref, utilisons maintenant le serveur selenium pour lancer un test.

Xvfb :99 &
sleep 2
PATH=/opt/selenium/firefox:$PATH DISPLAY=:99 java -jar selenium-server-standalone-2.20.0.jar &

Attendez un peu...il faut voir une ligne indiquant que le serveur tourne, ce genre de ligne:

INFO org.openqa.jetty.http.SocketListener - Started SocketListener on 0.0.0.0:4444
INFO org.openqa.jetty.util.Container - Started org.openqa.jetty.jetty.Server@1ff4689e

Cela peut prendre entre 5 et 30 secondes, soyez patient... A partir de là, le serveur écoute le port 4444, on va donc jouer un peu !

Créer un fichier test.php:

<?php
class Example extends PHPUnit_Extensions_SeleniumTestCase
{
  protected function setUp()
  {
    $this->setBrowser("*chrome");
    $this->setBrowserUrl("http://www.google.fr/");
  }
 
  public function testMyTestCase()
  {
    $this->open("/");
    $this->waitForPageToLoad("30000");
    //on vérifie que "Google" est sur la page...
    $this->verifyTextPresent("Google");
 
    //ce teste doit donner une erreur
    $this->verifyTextPresent("foo bar baz");
 
  }
}

Ce teste ne fait rien de compliqué... il ouvre Google et vérifie si le texte "Google" est sur la page...

Vous pouvez lancer le test:

phpunit test.php

Le résultat doit être:

PHPUnit 3.6.10 by Sebastian Bergmann.

F

Time: 5 seconds, Memory: 5.75Mb

There was 1 failure:

1) Example::testMyTestCase
foo bar baz
Failed asserting that false is true.


FAILURES!
Tests: 1, Assertions: 2, Failures: 1.

Cela indique donc que le serveur selenium a bien lancé firefox, la page google et vérifier qu'un texte "Google" apparait. En ce qui concerne "foo bar baz" cela donne une erreur. Donc:

1 test
2 assertions : texte "Google" et texte "foo bar baz"
1 erreur, et une seule erreur !!! si vous en avez 2 alors c'est que cela n'a pas marché !

Voilà, on peut couper selenium et Xvfb:

killall Xvfb
kill $(ps ax | grep selenium | grep -v grep | awk '{print $1}')

Maintenant, on se crée un service pour lancer Xvfb et Selenium.

Avant tout, pour des raison pratiques, je vous conseille de ne *plus du tout* lancer Xvfb et Selenium en root, mais avec un utilisateur précis. Comme nous allons utiliser phpUnderControl qui est un plugin de cruisecontrol, et que ce dernier lancera son service avec un utilisateur recommandé, nous allons le créer de suite et l'utiliser pour lancer Xvfb et Selenium.

useradd -m -s /bin/bash cruisecontrol

Notez ici que je demande la création du répertoire personnel (via l'option -m) car firefox aura besoin de créer un répertoire de profil, de ce fait, /home/cruisecontrol va être créé.

Voilà, maintenant créons le service qui lance Xvfb et Selenium via cet utilisateur. Créer le fichier /etc/init.d/xselenium et déposez ce code:

#!/bin/bash
 
XLOCK="/var/lock/Xvfb.pid"
SLOCK="/var/lock/selenium.pid"
 
 
startXVFB(){
        [[ -f $XLOCK ]] && echo "Already Running" && return 1
        local PID
        PID=$(su cruisecontrol -c 'Xvfb :15 >/dev/null  2>&1 & echo $!')
        echo "Xvfb pid $PID"
        echo $PID > $XLOCK
 
}
 
startSelenium(){
        [[ -f $SLOCK ]] && echo "Selenium Already Running" && return 1
 
        local PID
        PID=$(su cruisecontrol -c 'PATH=/opt/selenium/firefox:$PATH DISPLAY=:15 java -jar /opt/selenium/selenium-server-standalone-2.20.0.jar >/dev/null 2>&1 & echo $!')
        echo "Selenium pid $PID"
        echo $PID > $SLOCK
}
 
case $1 in
        start)
                echo "Starting XVFB"
                startXVFB
                sleep 2
                echo "Starting Selenium server"
                startSelenium
                sleep 2
                ;;
 
        stop)
                kill $(cat $SLOCK)
                sleep 2
                kill $(cat $XLOCK)
                sleep 2
                rm -f $SLOCK $XLOCK
                ;;
       *)
               echo "$0 start|stop"
               ;;
esac

Rendez le executable:

chmod +x /etc/init.d/xselenium

Et lancez le service:

/etc/init.d.xselenium start

Vous devez donc avoir désormais un Xvfb et un selenium actif. Attendez un peu que le port 4444 soit ouvert pour commencer à lancer les tests, pour vérifier le port:

netstat -taupen | grep 4444

Si aucune ligne n'apparait, c'est que le service ne tourne pas.

Voilà pour la partie pear, selenium-server et Xvfb. Dans la partie 2 nous utiliserons Selenium IDE pour créer des tests, mais surtout nous installerons phpUnderControl afin de piloter notre intégration continue.

En espérant avoir donner quelques clefs...

lxc 0.7.5 recompilé

Metal3d — Sun, 04 Sep 2011 11:53:00 +0200

J'ai eu du mal à faire fonctionner lxc sur ma fedora (pour une fois qu'un truc marche mal, je me suis penché sur le cas). Avec l'aide de number80 (un des habitués du canal #fedora-fr sur IRC freenode) j'ai pu patcher et recompiler des rpm pour la version 0.7.5 de lxc.

Le souci qui se posait, outre les désastreuses erreurs liées à cgroup, était l'absence de templates. En fait, je ne sais pas pourquoi le mainteneur a supprimé les templates d'installation (apparement ils ne devaient pas être bons à l'époque). Toujous est-il que le template fedora fonctionne bien.

J'ai patché le template "debian" qui demandait à utiliser dpkg pour avoir l'architechture procésseur de la machine. Pour remplacer cela, j'effectue un test autre (via uname -i) et je permet une option -a ou --arch qui peut prendre en charge amd64 ou i386. L'architechture est par défaut celle de votre cpu.

Autre partie que j'ai patchée, le template debian ne créait pas d'interface réseau... chose réparée

Bref, pour installer mes paquets, comme pour le moment je n'ai pas de dépot, il vous suffit de prendre l'archive de 1.1Mo ici: http://www.metal3d.org/rpms/lxc-0.7....

Pour installer tout ça:

su 
tar zxvf lxc-0.7.5-rpm.tar.gz
#pour les 32bits:
yum install --nogpgcheck lxc/{lxc-0.7.5-1.fc15.i686.rpm,lxc-templates-0.7.5-1.fc15.i686.rpm,lxc-libs-0.7.5-1.fc15.i686.rpm}
#pour les 64bits:
yum install --nogpgcheck lxc/{lxc-0.7.5-1.fc15.x86_64.rpm,lxc-templates-0.7.5-1.fc15.x86_64.rpm,lxc-libs-0.7.5-1.fc15.x86_64.rpm}

Je vous remercie d'avance si vous avez des retours particuliers, notez que je n'ai testé que les templates fedora et debian pour le moment.

Configurer Mutt pour gmail

Metal3d — Fri, 26 Aug 2011 19:37:00 +0200

Il est évident que nous ne sommes pas tous accrocs aux outils en mode texte (dans un terminal) mais personnellement j'y trouve mon compte: vitesse, exécution claire, lisibilité... et modularité. Je suis un Google Fan (houuu je vais m'en prendre plein la poire moi) et j'ai beaucoup de mes données sur Google: mail, documents, agenda... Voici donc comment pouvoir envoyer des mails et lire ces derniers convenablement avec Mutt, y compris l'autocompletion des contacts Gmail

La configuration ne sera pas compliqué. Il faudra juste se farcir 3 fichiers de configurations:

un pour mutt lui même, configuration du compte
un pour permettre les macros de lecture de mail en HTML
un fichier netrc pour permettre à goobook de fonctionner

Bref, passons en premier lieu à l'installation proprement dite des logiciels:

su -c "yum install mutt python-setuptools links"
su -c "easy_install goobook"

Le première commande installe mutt et les utilitaires pytyon pour installer un paquet python, puis links, le lecteur html en console. L'autre installe goobook, un outil qui permet de récupérer un carnet d'adresse google.

Goobook est un outil python que j'ai testé après en avoir essayé plusieurs, c'est de loin le plus pratique et le plus abouti que je connaisse. Vous pouvez voir la page du projet ici: http://pypi.python.org/pypi/goobook...

Maintenant, passons à la configuration de Mutt

#fichier ~/.muttrc

#enregistre les messages envoyés et brouillons dans Gmail
set record="+[Gmail]/Messages envoyés"
set postponed="+[Gmail]/Brouillons"

#configuration du serveur
set hostname=gmail.com
my_hdr From: PRENOM NOM <USER@gmail.com>
set use_envelope_from
set envelope_from_address="USER@gmail.com"

unignore Date Message-ID In-Reply-To

set move=no
set spoolfile=imaps://imap.gmail.com:993/INBOX
set imap_user = "USER@gmail.com"
set imap_pass= "VOTRE MOT DE PASSE"
set imap_authenticators="login"
set imap_passive="no"
set folder="imaps://imap.gmail.com:993"
set imap_check_subscribed="yes"
set imap_list_subscribed="yes"

set smtp_url="smtps://USER:VOTRE MOT DE PASSE@smtp.gmail.com:465"
set ssl_starttls="yes"

set locale="fr_FR"
set date_format="%A %d %b %Y à %H:%M:%S (%Z)"
set attribution="Le %d, %n à écrit:"
set forward_format="[Fwd: %s]"
set forward_quote

mailboxes !

set pager_index_lines="7"
set pager_stop

#gérer un cache
set message_cachedir="~/.mutt_msg_cache"
set header_cache="~/.mutt_header_cache"

#force l'utilisation d'un programme exterieur pour les mails en HTML
auto_view text/html

#et ici la config pour les contacts
set query_command="goobook query '%s'"
bind editor <Tab> complete-query
macro index,pager a "<pipe-message>goobook add<return>" "add the sender address to Google contacts"

Et enfin il faut configurer les commandes pour lire les mails HTML:

#fichier ~/.mailcap
text/html;  links %s; nametemplate=%s.html
text/html;  links -dump %s; nametemplate=%s.html; copiousoutput

Bien. Reste à gérer goobook, on commence par créer un fichier:

#~/.netrc
machine google.com
    login USER@gmail.com
    password Votre Mot de passe

Voilà, testez rapidement que ça passe en tapant:

goobook reload
goobook query un_nom_au_choix

Et bien voilà, lancez maintenant la commande mutt et appréciez un peu la lecture de mail dans un terminal.

Souvenez vous de quelques racourcis:

Maj+D pour supprimer un ensemble de mail correspondant à un motif que vous tapez (par exemple si vous tapez microsoft, tout les mails correspondants seront marqué comme "à supprimer")
d pour supprimer le message sélectionné
m pour envoyer un message (les contacts sont auto complétés via la touche tabulation)
r pour répondre
c por changer de dossier de mail
/ pour chercher un mail, selon le nom, le sujet...
$ pour valider les changements (suppressions)

Voilà, personnellement j'ai adopté mutt et j'en suis très content. Je classe et nettoie ma boite mail en 4 fois moins de temps qu'avant.

Notez que nous pourrons ensuite utiliser mcabber pour tchater avec nos contacts google on en reparlera

EDIT: j'ai supprimé la phase de création de goobookrc qui est inutile en fait...

Xmonad, le bureau productif orienté terminal

Metal3d — Sun, 21 Aug 2011 13:28:00 +0200

Vous utilisez certainement Gnome, KDE, ou XFCE (entre autre) pour afficher vos programmes. Le gestionnaire de fenêtre vous permet de déplacer le programme sur votre écran via la souris, vous avez des menus, des racourcis qui vous permettent de gérer tout ça. Je ne critique pas ce principe, il est pratique, assez standard et bien adapté à la plupart des utilisateurs. Mais nous ne sommes pas tous identiques. Certains, comme moi, utilisent surtout des terminaux, et n'aiment pas devoir passer la main du clavier à la souris pour gérer son espace de travail. Pire encore, nous n'avons en général pas besoin de la barre de titre, et devoir placer les fenêtres sur le bureau est une chose qui peut vraiment être un frein à la productivité.

Outre le coté production, il y a l'ergonomie. L'ergnonomie ne signifie pas forcément "pouvoir tout déplacer à la souris et avoir plein d'infos sur les fenêtres". En fait, tout est relatif. Si un bureau me propose de placer mes fenêtres et que j'ai juste les informations nécessaires, je trouve cela ergonomique. Car je n'ai finalement que ce dont j'ai besoin. Mais sans pour autant me limiter, car dans tous les cas, je peux retrouver les informations supplémentaires si je connais mon outil.

Je trouve le terminal ergonomique. Ça peut vous étonner, mais la plupart des utilisateurs du terminal qui ont passé un peu de temps à apprendre à s'en servir vous le dira. Le terminal est finalement bien plus simple et plus adapté à un travail quotidien. Je n'enlève pas l'utilisation du navigateur internet, ni des outils de création (image, films, 3D, musique...) mais pour le reste, tout est gérable via des lignes de commande. Je sais ce que vous vous dites... "il est fou, tout faire en ligne de commande...", mais pourtant si vous passiez un peu de temps à apprendre le principe, vous vous rendrez compte de la puissance et de la simplicité de son utilisation.

Revenons au gestionnaire de fenêtre. J'ai toujours au moins 4 ou 5 terminaux ouverts, et passer de l'un à l'autre n'est pas si ergonomique que cela sous Gnome ou KDE pour ne citer qu'eux. ALT+TAB ou souris, dans tous les cas je ne vois pas clairement quelle fenêtre je vais avoir tant qu'elle n'est pas affiché. Le fait est que dans 80% des cas, les fenêtres se recouvrent les unes sur les autres. Encore une fois, je concois que cela peut être utile et agréable pour certain, mais pas pour moi.

Et là, une fois de plus, avoir un système d'exploitation libre vous donne un choix, adapté, et vraiment viable. Il existe une autre famille de gestionnaire de fenêtre nommé "tiling desktop" ou "bureau en mosaïque". Ce genre de gestionnaire de fenêtre permet de placer les fenêtre selon des "layout" (mise en page) automatisés et modifiables. Pour en citer quelques uns: awsome, wmii, ion3, Xmonad...

Alors pourquoi mon choix se porte sur XMonad ? Parce que ce dernier est très poussé en terme de configuration et n'a pas de décoration de fenêtre. C'est selon moi la meilleure gestion de bureau que je connaisse dans le domaine des tiling desktop.

Pour vous expliquer le fonctionnement, et surtout pour configurer votre bureau, je vais vous donner quelques clefs.

Tout d'abord, sous fedora, on va installer les outils nécessaires pour:

utiliser xmonad
avoir quelques outils pratiques
avoir des terminaux bien plus sympas
se passer de la plupart des outils "graphiques" forcés sous d'autres gestionnaires (navigation de fichier par exemple)

On commence:

su -c "yum install xmonad xmobar dmenu mc xscreensaver feh rxvt-unicode"

Bien, si vous quitter votre session, vous aurez donc le choix d'utiliser xmonad dans le gdm ou kdm (la fenêtre de connexion). Si vous choisissez Xmonad vous allez avoir un terminal qui va s'ouvrir avec le manuel de Xmonad... et rien d'autre.

C'est bien Xmonad... épuré au maximum. Vous avez compris... il va falloir configurer un peu le bureau pour avoir un truc plus sympa. En premier lieu, ne paniquez pas et pressez ALT+Shift+c pour fermet le manuel puis ouvrez un autre terminal avec ALT+shift+Enter.

Dans ce terminal, vous allez ouvrir avec vim le fichier ~/.xmonad/xmonad.hs

Placez y ce contenu:

import XMonad
import XMonad.Config.Azerty
import XMonad.Hooks.DynamicLog


-- The main function.
main = xmonad =<< statusBar myBar myPP toggleStrutsKey myConfig

-- Command to launch the bar.
myBar = "xmobar"

-- Custom PP, configure it as you like. It determines what's being written to the bar.
myPP = xmobarPP { ppCurrent = xmobarColor "#429942" "" . wrap "<" ">" }

-- Keybinding to toggle the gap for the bar.
toggleStrutsKey XConfig {XMonad.modMask = modMask} = (modMask, xK_b)

-- Main configuration, override the defaults to your liking.
myConfig = azertyConfig { 
    terminal           = "urxvt -depth 32 -tr -tint rgb:2222/2222/2222 +sb -fg white -bg rgba:0000/0000/0000/7777 -fade 15 -fadecolor black -pr black -pr2 white"
    , logHook = dynamicLog
 }

Fermez, et tenter de compiler la configuration:

xmonad --recompile

Si une erreur apparait, vérifiez bien le contenu du fichier.

Avant de relancer xmonad, on va aussi configurer xmobar... et ce dans le fichier ~/.xmobarrc

Config { font = "-*-Fixed-Bold-R-Normal-*-13-*-*-*-*-*-*-*"
       , bgColor = "black"
       , fgColor = "grey"
       , position = TopW L 100
       , commands = [ Run Weather "LFLY" ["-t"," <tempC>°","-L","64","-H","77","--normal","green","--high","red","--low","lightblue"] 36000
                    , Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10
                    , Run Memory ["-t","Mem: <usedratio>%"] 10
                    , Run Swap [] 10
                    , Run Date "%a %b %_d %H:%M" "date" 10
                    , Run StdinReader
                    ]
       , sepChar = "%"
       , alignSep = "}{"
       , template = "%StdinReader% }{ %cpu% | %memory% * %swap%    <fc=#ee9a00>%date%</fc> | %LFLY%"
       }

Dans ce fichier, remplacer le code "LFLY" par celui de votre ville (ici Lyon Bron), dans le fichier il est à deux endroits, donc remplacez bien tout. Pour trouvez votre code, allez à la page http://weather.noaa.gov et prenez le code qui apparait dans l'url...

Bon, cette fois ci, on peu relancer xmonad... Pressez ALT+q

Hop, xmonad se recharge. Pressez ALT+1 ou 2, 3... changement de bureau. Le clavier azerty est donc bien géré et vous avez théoriquement une barre en haut qui indique quelques infos.

Bon, fermez le terminal en cours ALT+shift+c et relancez en un: ALT+shift+Enter... ha voulà urxvt en mode semi transparent ouvrez en un autre, hop l'écran se coupe en deux

Puis un autre... et un autre....

Pour vous déplacer, utilisez la souri (haaan) ou simplement alt+k ou alt+j. Et pour redimensionner les colonnes: alt+h ou alt+l

Pour augmenter le nombre de fenêtre possible sur la colonne principale (à gauche) alt+, et pour en retirer alt+.

Bon assez jouer... on va maintenant faire en sorte de lancer pulseaudio, xscreensaver et changer ce foutu fond d'écran.

Créé un fichier, par exemple j'utilise ~/bin/xmonad-startup et posez ceci dedans:

#!/bin/bash

#prevent running commands on xmonad restart
#I choose xscreensaver because it is stopped at xmonad shutdown
[ "$(ps --noheader -C xscreensaver -o pid)" ] && exit 0

#commands to lauch
xscreensaver &
feh --bg-fill ~/Images/backgrounds/OTHER-Tuxsta_1600x1200.png
synclient VertTwoFingerScroll=0 VertEdgeScroll=1
pulseaudio --start

Reste à demander à xmonad de les lancer au chargement:

import XMonad
import XMonad.Config.Azerty
import XMonad.Hooks.DynamicLog


-- The main function.
main = xmonad =<< statusBar myBar myPP toggleStrutsKey myConfig

-- Command to launch the bar.
myBar = "xmobar"

-- Custom PP, configure it as you like. It determines what's being written to the bar.
myPP = xmobarPP { ppCurrent = xmobarColor "#429942" "" . wrap "<" ">" }

-- Keybinding to toggle the gap for the bar.
toggleStrutsKey XConfig {XMonad.modMask = modMask} = (modMask, xK_b)


-- my startup
myStartup :: X ()
myStartup = do
    spawn "~/bin/xmonad-startup"

-- Main configuration, override the defaults to your liking.
myConfig = azertyConfig { 
    terminal           = "urxvt -depth 32 -tr -tint rgb:2222/2222/2222 +sb -fg white -bg rgba:0000/0000/0000/7777 -fade 15 -fadecolor black -pr black -pr2 white"
    , logHook = dynamicLog
    , startupHook = myStartup
 }

On recompile: xmonad --recompile et on relance ALT+q

Bon, reste à connaitre quelques outils pour utiliser xmonad sans avoir besoin d'utiliser trop d'outils graphique:

dans un terminal: alsamixer => gestion du volume
dans un terminal: mc => gestionnaire de fichier
pour lancer un programme sans passer par un terminal: ALT+p et commencez à taper le nom du programme, l'auto completion est gérée

Vous pourrez trovuer des fichier "ini" de "+mc" pour le rendre plus joli. Utilisez aussi weechat pour aller sur IRC, vous allez voir que finalement c'est plus clair et efficace.

Un dernier racourcis ? ALT+Shift+Q et vous quittez Xmonad

Bon, sinon, utilisez des petits scripts pratique pour votre utilisation, par exemple j'ai un script "~/bin/dodo" qui met en veille "mémoire" mon pc:

#!/bin/bash
su -c "echo -n mem > /sys/power/state"

ou encore un script pour lancer weechat en me connectant avec mon login/pass + ouverture des canaux que j'aime bien:

#!/bin/bash
weechat-curses irc://VOTREUSERICI:VOTREMOTDEPASSEICI@irc.freenode.net/#fedora-fr,#blender-fr,#node.js,#blendercoders,#xmonad

VOTREUSER et VOTREMOTDEPASSE sont les user et mot de passe que vous utilisez sur IRC...

Bon voilà... à vous d'apprendre les trucs et astuces, vim ou emacs, uzbl-brower au lieu de google-chrome (étonnant ce truc, merci WilQu) et j'en passe... vous allez vous rendre compte aussi que "mc" permet de connecter un serveru distant sur la vue de gauche (cherchez un peu dans les menu avec F10) et permet même l'édition. Essayez aussi le racourcis CTRL+O dans mc... sympa non ?

Bon allez une capture, parce que vous êtes gentils (faites avec scrot):

Voilà, bon ba à vous hein.

Point de montage d'archives

Metal3d — Fri, 19 Aug 2011 21:42:00 +0200

Si comme moi vous avez besoin d'utiliser le contenu d'un tar.gz, d'un zip, ou tout autre archive et que cela vous agace de devoir le décompacter pour le modifier et le compresser par la suite pour le déplacer... ce billet va vous intéresser. Nous allons parlons ici de "archivemount", un outil sympa comme tout, utilisant "fuse", et qui va vous faire gagner un peu de temps.

Il m'arrive souvent ce genre de chose. Devoir récupérer une archive tar.gz ou tar.bz2, ou encore un zip, et devoir le décompresser pour l'utiliser avec une application (par exemple un storage pour ezPublish que je déplace pour bosser chez moi, ou la création d'une archive de release que je veux manipuler et vérifier simplement). Le fait est que l'archive est parfois lourde, et devoir ajouter des fichiers ou en supprimer, ou même en modifier est parfois un peu... suante. Gnome, KDE, proposent bien un outil de montage dans le navigateur de fichier, mais moi je suis sur Xmonad et j'aime le terminal. C'est donc le moment de vous montrer l'outil qui rend bien service "archivemount"

Sur Fedora il est dans les dépôts standard, donc un simple:

su -c "yum install archivemount"

et le tour est joué.

Alors comment ça marche tout ça ?

Imaginons une archive monarchive.tar.gz que je veux utiliser comme un répertoire. Encore une fois, les systèmes UNIX sont bien sympa en ce qui concerne la gestion de point de montage. Fuse va être utilisé avec archivemount. C'est simple comme tout:

mkdir ~/monarchive
archivemount monarchive.tar.bz ~/monarchive

Et voilà... c'est tout. dans le répertoire ~/monarchive se trouve le contenu de l'archive. Toute modification dans ce répertoire se répercute (au démontage) dans monarchive.tar.gz.

C'est donc un point de montage, simple, clair et efficace. A peu près tout fonctionne: tar (compressé ou non en gz, bz2...), xv, cdrom iso, zip... et les options de mount sont évidemment utilisables (ro, rw, nosuid...) comme avec n'importe quel point de montage.

Notez que le mode d'écriture asynchrone force donc la recompression au démontage.

Configuration spécifique de iptables

Metal3d — Wed, 10 Aug 2011 18:23:00 +0200

Fedora offre un outil de configuration rapide de par-feu iptables assez simple, pratique dans la plupart des cas. Comme vous le savez certainement, CentOS est proche de Fedora dans le sens où la base est quasiment identique, à la différence des paquets et de l'aptitude de la distribution. CentOS est orientée serveur. Bref, j'ai eu besoin de créer une machine virtuelle sur ma Centos et de permettre une redirection de port sur la machine hôte pour me connecter directement à cette dernière. Or, toucher à iptables ne sauve pas votre configuration directement, et l'outil de gestion de base ne permet pas de faire des ip-forward.

Car en fait, créer une règle de port fowrading est plutôt rapide. Exemple, ici ma VM a l'ip locale "192.168.122.18" et n'est vu que de ma CentOS hôte (adresse public 1.2.3.4). Ajouter le port forward se fait de cette manière:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 10222 -j DNAT --to 192.168.122.18:22
iptables -A FORWARD -i eth0  -p tcp -d 192.168.122.18 --dport 22 -j ACCEPT

Donc j'admet ici que si on se connecte au port 10222 de ma CentOS, je redirige la connexion sur la machine 192.168.122.18 port 22 (ssh). Cela se fait par la table PREROUTING qui va manipuler les paquets en changeant les données ip source et port source, et la table FORWARD qui assigne la redirection. Bref, sympa

Mais voilà, si vous voulez redémarrer votre machine, vos deux commandes sont oubliées car non inscrites dans la configuration de base du service iptables installée sur votre machine. Donc la solution est simple.

On va sauver notre ancienne configuration, sait-on jamais, et forcer la nouvelle configuration depuis la commande iptables-save.

cat /etc/sysconfig/iptables > /etc/sysconfig/iptables.save
iptables-save > /etc/sysconfig/iptables

C'est simple non ? en fait, par bonheur, le service iptables utilise le format standard de "iptables-save" et "iptables-restore" donc la manipuation est aisée.

Voilà, vous pouvez tester en relançant le service iptables, et ne plus avoir peur de perdre votre forward si le serveur redémarre.

Un chroot si rapide à créer

Metal3d — Wed, 03 Aug 2011 02:15:00 +0200

J'avais travaillé sur la documentation de chroot sur cette page: http://doc.fedora-fr.org/wiki/Utili... mais depuis, les choses ont changé. Febootstrap ne marche plus du tout comme avant... et j'ai trouvé une manière encore plus simple de créer une base chroot sans manipuler des fichiers de dépôts. Vous allez voir, c'est tellement simple que ça en est presque indécent.

Voilà la manière la plus facile que j'ai trouvé, par exemple pour encapluser "php-cli" dans un chroot:

cd ~
mkdir -p chroots/fedora-15-chroot
cd chroots
su -c 'yum --installroot=`pwd`/fedora-15-chroot --releasever=15 install php-cli -y'

C'est simple comme choux en fait...

Je crée un répertoire dans mon "home" (cd ~ et mkdir -p chroots/fedora-15-chroot). Ensuite je demande à yum d'installer php-cli dans le répertoire fedora-15-chroot. Comme je n'ai pas créé de fichier de dépots Fedora dans le répertoire de chroot, je spécifie simplement que je veux utiliser la version "15" de fedora. Notez que "releasever" est une contraction de "release version".

Et comme par enchantement, j'ai un chroot fonctionnel !

Là où c'est intéressant, c'est que je me passe de pas mal de configuration un peu compliqué. Il est alors facile de changer de --releasever en 16 pour tester la rawhide, ou une version inférieure...

Me reste plus qu'à voir comment fonctionne lxc (et je n'ai pas la dernière version de libvirt donc je n'ai pas encore l'accès facilité par virt-manager) et je vais pouvoir tester pas mal de choses, comme faire marcher des bases en jail, compiler des choses tordus ou voir comment péter un système sans avoir peur

Radeon et Blender font mauvais ménage

Metal3d — Sat, 30 Jul 2011 11:00:00 +0200

En fait, ce n'est pas seulement pour Blender que je vais parler, mais certaines applications 3D qui peuvent avoir tendance à planter misérablement en utilisant une carte ATI (AMD) sur notre Fedora 15... Car voilà, depuis mon passage à Fedora 15, tout se passe bien sauf un truc: travailler sous Blender. J'ai tout tenté: passage à Xfce pour éviter Mutter, recompilation de Blender, debugage, ... et rien n'y faisait. Après quelques minutes, un plantage et pas moyen de trouver une solution. Sauf que j'ai trouvé un tour de passe-passe qui permet, pour le moment, de palier le souci.

Bon avant toutes chose, un petit tour vers le rapport de bug que j'ai commenté: libllvmcore-2.8.so.debug has no usable debug info Ça donne pas envie hein... En fait pour faire court, un souci bien dégoûtant apparaît avec le pilote radeon et en plus de cela on a pas les infos de débogage pour notre problème. Raaa la rage m'envahissait et comme je voulais finir un boulot sur Blender, me fallait vite une solution.

Et bien j'ai finis par y aller "bourrin"... en utilisant une compilation du pilote "gallium". C'est en fait une compilation "grotesque" qui va me permettre d'utiliser une librairie openGL très épurée. Donc certes je vais perdre l'antialiasing et certainement avoir une visu assez moche dans Blender, mais au moins ça ne plantera pas. Et pour vous rassurer, seule la vue 3D est impactée, le rendu et le traitement image/vidéo ne sont pas impactés.

Bon et bien voici la méthode:

#on va dans notre répertoire perso
cd ~
#on clone le dépot mesa
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa

#on compile le driver gallium, donc pas de DRI pour radeon et consorts
make  linux-x86-64 -j4
#make  linux-x86-32 -j4 pour les cpu 32 bits

#si vous avez un core i7, vous pouvez mettre -j8 au lieu de -j4
#on attend un peu la fin de la compilation puis
cd lib64 #ou cd lib si vous êtes sur un pc 32 bits

#à faire avant de lancer blender...
export LD_LIBRARY_PATH=~/mesa/lib64
#puis on lance blender
cd ~/blender-2.58
./blender -w

Deux choses, d'une part évitez le mode plein écran, perso ça fait un truc tout bizarre sur mon pc... et secondo, utilisez l'option "-w" comme spécifié, ça évitera des ennuis de bordure que j'ai vu sur mon poste.

Si vous avez des soucis, passez de Gnome à Xfce. Ca limitera les appels OpenGL et les court-circuits d'affichage. Toujours est-il que ça marche, ça marche même pas mal du tout... c'est moins beau, oui, mais ça marche.

Aussi, pour couper l'herbe sous les pieds des trolls qui vont arriver en commentaire: oui, ATI sur linux c'est pas bien, je sais, mais j'ai pas le choix pour deux raisons: d'une j'ai un laptop (ordinateur portable) et le prix était intéressant avec cette carte, et secondo j'utilise de temps en temps un kernel RT qui ne marche pas avec les pilotes nvidia. Donc je sais, j'ai pas une bonne config, mais je suis pas le seul. Et quand bien même, un matériel ne doit pas engendrer un souci de ce genre alors qu'il est récent.

Soit dit en passant, bien que le bug soit là, on apprécie tout de même d'avoir utilisé des logiciels libres. Car si tout ce que j'utilise était propritaire, je n'aurai pas de solution pour contourner le problème. Là, encore une fois, en suivant quelques indications, on arrive à se dépêtrer d'un gros problème parce que nous pouvons compiler et/ou modifier des sources.

Alors dans notre malheur, vous et moi qui avons des soucis avec cette radeon, réjouissons nous de pouvoir travailler en mode dégradé grâce à la philosophie du logiciel libre, et de ne pas rester coincé !

Tester des paquets sans tout casser

Metal3d — Sat, 30 Jul 2011 00:40:00 +0200

Une des raisons pour laquelle j'utilise Fedora depuis des années c'est l'aptitude (clin d'oeil de geek...) de yum à permettre des manipulations de paquets assez rapide. J'avais justement besoin de tester llvm 2.9 qui est pour le moment dans les dépôts rawhide (c'est à dire dans les dépôts de développement de la future version de fedora). Donc, me voilà avec un dilemme: comment tester sans tout casser et sans me prendre la tête à installer une VM? La réponse est dans yum l'ami.

yum a deux options (en fait une commande et une option) qui me permettent de tester sans massacrer mon système: distro-sync et --releasever. La première fait en sorte de synchroniser mes versions de paquets à la version de fedora en cours, et l'autre me permet de spécifier la version de fedora à utiliser.

Et bien allons y gaiement:

su -
yum clean all
yum --releasever=rawhide --nogpgcheck --disablerepos=rpmfusion\* update llvm

Cela à pour effet de lancer une installation en spécifiant que je cherche des paquets pour rawhide. L'installation terminée, j'ai bien un llvm 2.9 qui est installé alors que sur Fedora 15 nous sommes en version 2.8.

Mes tests terminés (et non concluant) j'ai eut envie de revenir à ma version de base. Et bien c'est simple:

yum clean all
yum distro-sync

Et voilà, yum trouve des paquets à downgrader (réduire la version) et me réinstalle tous les paquets estampillés pour la version fedora supérieure à la version actuelle (ici fedora 15). Du coup j'ai resynchronisé ma fedora. Attention tout de même à ne pas faire ça pour n'importe quoi... n'oubliez pas que des fichier .rpmnew peuvent apparaître ou encore peuvent vraiment planter le système.

Personnellement j'évite de faire ça pour tout, par exemple pour le moment j'évite de jouer avec des version de gnome qui se trouve dans rawhide, mais pour ce qui est de certaines librairies, compilateurs, ou encore apache, php... j'aime bien tester de la sorte.

Effectivement lxc ou carrément une machine virtuelle pourrait faire l'affaire, mais c'est tellement sympa avec yum... non ?

Faire parler son pc

Metal3d — Wed, 27 Jul 2011 14:53:00 +0200

Ça peut paraître gadget, mais on se rend compte assez vite que la synthèse vocale sur un poste peut être intéressante dans pas mal de cas. Par exemple, j'ai tendance à compiler des applications assez lourdes, et pour être prévenu, j'aime avoir une voix qui me dit "la compilation de blender 2.58 pour cycles est terminée sans erreur"... Ou encore, me prévenir vocalement que j'ai un souci sur un serveur distant... Cela permet d'avoir une annonce clair et de ne pas avoir constamment sous les yeux un panel de tests. En gros, c'est pratique, gadget oui, mais pratique.

Alors comment faire causer notre coucou. Il existe des méthodes libres et/ou gratuites. Je vais vous montrer une procédure pas à pas qui va vous permettre d'avoir une jolie voix sur le pc (si on est pas trop regardant) et comment utiliser cela pour pas mal d'opérations. Le but est de faire simple, pratique et utile.

Première approche, espeak seul.

Espeak est un projet libre, facilement installable sur votre Fedora puisque dans les dépots officiels. Pour l'installer vous pouvez passer par l'outil d'ajout de paquets ou via une console:

su -c "yum install espeak -y"

A partir de maintenant, vous avez la commande espeak qui vous permet de faire parler le pc. Avant de vous lancer en vous disant "ça y est mais trop bien !!!" je tiens à vous prévenir: ça va pas être super beau. En effet, la voix anglaise est à peu près écoutable, par contre en Français... mon dieu. Je veux bien être indulgent, mais honnêtement là vous allez voir c'est pas super joli.

Exemple:

espeak -vfr "bonjour à toi humble utilisateur de la console"

Ça pique un peu non ?

En anglais c'est à peine mieux:

espeak  "Hi dude, this is better, isn't it ?"

Bref, si cela vous plait vous pouvez utiliser epseak tel quel... mais personnellement j'ai eut envie de trouver mieux. Et la solution a été "mbrola". Notre méthode va utiliser espeak et mbrola, le premier pour générer des phonèmes et l'autre pour parler.

Deuxième approche: espeak + mbrola

mbrola est un projet gratuit mais non libre. Je suis pas fan de la politique qu'ils utilisent, d'autant que le projet a l'air de sombrer doucement dans les abîmes des ligiciels qui auraient put devenir des références pour des années... Mais toujours est-il qu'à l'heure actuelle on peut encore s'en servir.

Donc, on va préparer notre installation.

su -
mkdir -p /opt/mbrola
cd /opt/mbrola
wget http://tcts.fpms.ac.be/synthesis/mbrola/bin/pclinux/mbr301h.zip
unzip mbr301h.zip
rm -f mbr301h.zip

Oui, que vous soyez sous 64bits ou 32bits, on devra utiliser la version 32bits.

mbrola a besoin de fichier de voix. On va récupéré l'une de celle qui va le mieux pour notre test:

mkdir fr4
cd fr4
wget http://tcts.fpms.ac.be/synthesis/mbrola/dba/fr4/fr4-990521.zip
unzip fr4-990521.zip
rm -f fr4-990521.zip
exit

N'oubliez pas de bien taper "exit", nous ne devons plus être "root" à partir de maintenant.

Bon, maitenant que le paquet est là... on passe au "pipe" qui permet de faire parler mbrola. Il faut savoir que espeak embarque quelques "voix" de mbrola par défaut. Donc nous allons utiliser cela pour faire causer l'ordinateur.

Bon je vous explique rapidement, on va pas trop détailler le principe

espeak -vmb/mb-fr2 "texte à donner" retourne une sortie qui correspond aux phonèmes au format reconnu par mbrola
mbrola fichier-de-voix phonèmes fichier.format: va lire l'entrèe de phonèmes et sortir un fichier au format désiré "au, wave..."

Comme nous ne voulons pas créer des fichiers sur le disque, on peut "piper" les sorties. De ce fait:

mbrola fichier_de_voix - -.au | play - 2>/dev/null

aura pour effet de récupérer les phonèmes depuis l'entrée standard et créera un fichier "au" directement envoyé à la sortie standard. "play" va alors lire cette sortie standard et nous redirigeons toutes les erreurs dans /dev/null pour ne pas polluer notre console...

Donc le pipe complet est:

espeak -vmb/mb-fr4 "Bonjour à toi humble utlisateur de la console" | /opt/mbrola/mbrola-linux-i386 /opt/mbrola/fr4/fr4 - -.au | play - 2>/dev/null

Ha oui, elle parle vite la nana hein

Et bien nous allons palier la vitesse via les options de mbrola.

-t 1.2 par exemple va réduire la vitesse de parole d'un ration de 1.2

Ce qui nous donne:

espeak -vmb/mb-fr4 "Bonjour à toi humble utlisateur de la console" | /opt/mbrola/mbrola-linux-i386 -t 1.2 /opt/mbrola/fr4/fr4 - -.au | play - 2>/dev/null

Mieux n'est-ce pas ?... On peut encore jouer avec quelques options, comme le "pitch" (hauteur de voix) et le volume:

-v 0.8 volume à 80%
-f 1.1 monte le pitch de 10%

espeak -vmb/mb-fr4 "Bonjour à toi humble utlisateur de la console" | /opt/mbrola/mbrola-linux-i386 -f 1.1 -v 0.8 -t 1.2 /opt/mbrola/fr4/fr4 - -.au | play - 2>/dev/null

Comme je vous le disai, c'est mieux que espeak mais on est encore loin de la beauté extême. Le souci n'est pas mbrola, mais la création des phonèmes. Car les exemples proposés par mbrola vous montre qu'on pourrait s'y tromper.

Automatisation

Bon il nous reste une chose à faire, rendre utilisable aisément cette commande. Et bien faisons ça simple:

su -
cat > /usr/local/bin/sayit<<EOF
espeak -vmb/mb-fr4 "\$@" | /opt/mbrola/mbrola-linux-i386 -f 1.1 -v 0.8 -t 1.2 /opt/mbrola/fr4/fr4 - -.au | play - 2>/dev/null
EOF
chmod +x /usr/local/bin/sayit
exit

Voilà nous avons créé une commande "sayit" qui va nous permettre de faire cela:

sayit "Que c'est bien de travailler sous linux"

Reste alors à utiliser notre commande comme je vous le disais au début de l'article. Par exemple, quand je compile un programme:

make && sayit "Compilation de Blender terminé avec succès" || sayit "Compilation de Blender avec erreurs"

Et j'en passe, vous pouvez faire un petit programme en bash qui lit des logs et vous annonce une erreur, ou encore un module XChat qui vous préviens que quelqu'un vient de vous parler.

Ce gadget est intéressant quand on est comme moi à travailler sur plusieurs machines en même temps, souvent en train de préparer du café, ou sur plusieurs taches en même temps.

Voilà, j'espère que vous avez apprécié mon explication et si vous avez des idée d'utilisations ou script, faites passer !

Evolution et le «marquer comme lut»

Metal3d — Sun, 24 Jul 2011 03:09:00 +0200

Depuis mon passage à Gnome 3 j'ai quelques mauvaises surprises dans quelques applications... Rien de bien méchant, mais il arrive que certaines nouvelles applications perdent des options que je trouvais agréables. C'est le cas pour Evolution Mail 3, j'ai cherché un bon moment avant de me rendre compte que "non je ne suis pas fou, l'option «marquer comme lut après X secondes»" a bel et bien disparut... Mais n'ayant pas donné mon dernier mot, j'ai pensé que comme beaucoup d'applications gnome, la configuration a dut passer dans "gconf"

Et je n'ai pas eut tort... en fouillant un peu dans "gconf-editor" j'ai trouvé ça:

Il a suffit de mettre cette valeur à 0 pour qu'enfin un mail soit marqué comme lut immédiatement, et pas après 1.5 secondes.

Autre méthode plus rapide, dans une console:

gconftool-2 --set /apps/evolution/mail/display/mark_seen_timeout 0 --type int

Cela revient au même...

Alors pour ne pas m'arrêter à cette mésaventure, je tiens à donner un avis sur la direction que prend Gnome dans certains cas qui me gêne. J'ai toujours été un détracteur de la base de registre Windows, selon moi c'est un truc imbuvable pour le commun des mortels et en plus de cela vous remarquez que ce n'est pas franchement trivial.

Alors qu'un fichier de configuration suffirait, et que des options aisées sont plus adéquates, surtout sur un outil aussi basique que la lecture de mails, on se retrouve à chercher un terme dans une liste énorme de valeur typée et ce dans un système de configuration imbitable.

Bien que l'interface Gnome 3 me plaise énormément, que je trouve que l'avancée ergonomique que montre le développement de ce gestionnaire de bureau est impressionnant, et que l'innovation de ce dernier m'a vraiment plut, j'ai l'impression de régresser sur le sujet de la configuration.

Oui, je conçois bien que gconf est un outil vraiment intéressant, techniquement parlant, car cela permet une homogénéité des données pour la configuration de l'environnement. Et d'autant plus que cela permet un échange de configuration inter logiciel. Mais ce coté qui force l'utilisation d'un outil de configuration pour changer des valeurs m'horripile fortement.

Bon, cela étant dit, j'ai utilisé gconf que peu de fois pour modifier ce genre de valeur... en général, les développeurs pensent bien à mettre une option dans l'interface dédiée de configuration du programme... mais pour le coup, là, Evolution porte son nom à l'envers, car on a régressé sur pas mal de points.

Seul plaisirs vraiment intéressant que je trouve à Evolution 3, outre le fait qu'il puisse se connecter à Exchange, c'est qu'il est devenu bien plus performant. Et l'interfaçage avec Google pour l'agenda et les contacts synchronisés m'ont charmé (Thunderbird peut le faire, mais honnêtement je trouve qu'Evolution le fait mieux)

Voilà pour ma partie coup de gueule du dimanche à 3h du matin...