Metal3d - Fedogeek

Aller au contenu | Aller au menu | Aller à la recherche

samedi, mars 2 2013

Pool de thread avec limite de parallélisation

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.

Lire la suite...

lundi, février 18 2013

Coloriser la sortie d'un programme

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

Lire la suite...

jeudi, août 2 2012

Vim en moteur de slide - Vroom

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"

Lire la suite...

dimanche, juillet 29 2012

Un OSD de capture clavier en bash

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 :)

Lire la suite...

dimanche, juin 3 2012

Correction orthographique et grammaticale avec Vim

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.

Lire la suite...

lundi, mai 28 2012

Go, routines et canaux - introduction au langage

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.

Lire la suite...

lundi, mai 21 2012

Google App Engine et le souci os_compat

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

Lire la suite...

dimanche, mai 20 2012

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

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)

Lire la suite...

vendredi, avril 27 2012

Point de montage Google Drive

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 :)

samedi, mars 31 2012

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

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...

dimanche, septembre 4 2011

lxc 0.7.5 recompilé

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.

Lire la suite...

vendredi, août 26 2011

Configurer Mutt pour gmail

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

Lire la suite...

dimanche, août 21 2011

Xmonad, le bureau productif orienté terminal

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é.

Lire la suite...

vendredi, août 19 2011

Point de montage d'archives

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.

Lire la suite...

mercredi, août 10 2011

Configuration spécifique de iptables

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.

mercredi, août 3 2011

Un chroot si rapide à créer

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 :)

samedi, juillet 30 2011

Radeon et Blender font mauvais ménage

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

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 ?

mercredi, juillet 27 2011

Faire parler son pc

Ç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 !

dimanche, juillet 24 2011

Evolution et le «marquer comme lut»

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:

Gconf - Evolution - Mark as read

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...

- page 1 de 2