Quand il s'agit de déboguer du code python la plus part des gens utilisent un print "debug" bien placé pour savoir si on passe à un endroit ou un print "ma_variable = '%s'" % ma_variable pour connaitre la valeur d'une variable dans le flux d'exécution.

Pourtant python dispose d'un débogueur intégré très puissant: pdb. Que ceux qui sont allergiques à gdb, le débogueur C/C++, soient rassurés: bien qui pdb ressemble à bien des égards à gdb c'est un débogueur python pour python. Il est à la fois simple et très puissant.

Nous allons voir deux cas simples d'utilisation qui seront utiles, je l'espère, aux développeurs expérimentés comme aux développeurs occasionnels. Pour l'exemple nous utiliserons le script suivant :

#!/usr/bin/env python

def func1(i):
    if i == 0:
	    raise Exception("Exception in func1")
	
def func2(i):
    func1(i)
    
def func3(i):
    func2(i)
    
if __name__ == '__main__':
    func3(0)

La traceback surprise

Vous développez ou utilisez votre logiciel préféré et BOUM une traceback :

Traceback (most recent call last):
  File "test.py", line 14, in <module>
    func3(0)
  File "test.py", line 11, in func3
    func2(i)
  File "test.py", line 8, in func2
    func1(i)
  File "test.py", line 5, in func1
    raise Exception("Exception in func1")
Exception: Exception in func1

Vous n'avez pas accès au code en écriture ou le cas est trop complexe pour être géré avec des print bien placés ; pdb va vous aider. Depuis python 2.5 vous pouvez exécuter des modules python comme des scripts.

On va donc lancer le script en utilisant pdb :

python -m pdb test.py

On se retrouve dans pdb :

[chicha@grogro Bureau]$ python -m pdb test.py
> /home/chicha/Bureau/test.py(3)<module>()
-> def func1(i):

A ce stade le programme n'a toujours pas été lancé. On le lance via la commande pdb continu (c). Le programme entre en mode "post mortem" dès qu'il se prend une exception non catchée :

Traceback (most recent call last):
  File "/usr/lib64/python2.6/pdb.py", line 1276, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python2.6/pdb.py", line 1193, in _runscript
    self.run(statement)
  File "/usr/lib64/python2.6/bdb.py", line 366, in run
    exec cmd in globals, locals
  File "<string>", line 1, in <module>
  File "test.py", line 14, in <module>
    func3(0)
  File "test.py", line 11, in func3
    func2(i)
  File "test.py", line 8, in func2
    func1(i)
  File "test.py", line 5, in func1
    raise Exception("Exception in func1")
Exception: Exception in func1
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /home/chicha/Bureau/test.py(5)func1()
-> raise Exception("Exception in func1")

Voilà la séance de debugging peut commencer ...

Bye bye print

Pour commencer on aimerait bien savoir où l'on est dans la pile de fonction et à quoi ressemble le code autour de là où on est. C'est le role des commandes backtrace (bt) et list (l) :

(Pdb) bt
  /usr/lib64/python2.6/bdb.py(371)run()
-> sys.settrace(None)
  <string>(1)<module>()
  /home/chicha/Bureau/test.py(3)<module>()
-> def func1(i):
  /home/chicha/Bureau/test.py(11)func3()
-> func2(i)
  /home/chicha/Bureau/test.py(8)func2()
-> func1(i)
> /home/chicha/Bureau/test.py(5)func1()
-> raise Exception("Exception in func1")
(Pdb) l
  1  	#!/usr/bin/env python
  2  	
  3  	def func1(i):
  4  	    if i == 0:
  5  ->		    raise Exception("Exception in func1")
  6  		
  7  	def func2(i):
  8  	    func1(i)
  9  	    
 10  	def func3(i):
 11  	    func2(i)
(Pdb)

Ensuite on aimerait bien connaitre la valeur des arguments passés en paramètres, c'est le rôle de la commande args :

(Pdb) args
i = 0
(Pdb)

Enfin on peut afficher la valeur de n'importe quelle variable ou expression python valide à l'endroit où l'on se trouve dans le code, en utilisant la commande print (p) :

(Pdb) p i
0
(Pdb) p 2 * 2
4
(Pdb) 

pdb fournit évidemment bien plus de commandes que cela, vous pouvez par exemple :

• Monter et descendre où vous voulez dans la pile d'appels de fonctions,
• Mettre des breakpoint, conditionnels ou non, temporaires ou non,
• Associer des commandes à des breakpoints,
• Exécuter du code ligne par ligne, fonctions par fonctions,
• etc ...

Vous avez tout ce qu'il faut dans la documentation de pdb Si vous avez une question n'hésitez pas à me contacter !

Mais avant de terminer cet article je voudrai vous montrer une autre façon d'utiliser pdb :

pdb ou le debugging chirurgical

Vous avez accès au code en écriture, Vous exécutez un programme très long et vous n'avez pas envie de débugger tout, mais seulement le bout de code qui vous intéresse ? Alors pdb.set_trace() est fait pour vous !

Je reprend le code précédent, j'importe pdb et je place un petit pdb.set_trace() là ou je veux commencer à débugger :

#!/usr/bin/env python

import pdb

def func1(i):
    pdb.set_trace()
    if i == 0:
	    raise Exception("Exception in func1")
	
def func2(i):
    func1(i)
    
def func3(i):
    func2(i)
    
if __name__ == '__main__':
    func3(0)

Je lance mon pogramme normalement (sans utiliser -m pdb) et pouf ! Le programme s'exécute jusqu'à la ligne pdb.set_trace(). Ensuite pdb se lance et vous avez le debuggeur à votre disposition !

Bien sûre avec mon exemple simpliste on voit mal l'intérêt de la chose. Mais dès que le code se complique avec des boucles for sur des milliers d'éléments avec un bug au 700 ième on est bien content de pouvoir faire un truc du genre :

for i in range(1000):
    if i = 700:
        pdb.set_trace()
        ...

J'espère que ça permettra aux plus réticents, que gdb a effrayé, de se lancer !

Quand vous commencez à contribuer à la communauté autour d'une distribution vous êtes vite confronté à l'infrastructure mise en place pour les contributeurs : sites web, wiki, planet, bug tracker, forums, mailing list, packaging ...

Jusqu'ici pour moi il y avait 2 modèles :

• Le modèle Ubuntu : avec le très célèbre Launchpad qui intègre un tracker de bug, gestion de code source (avec Bazaar), gestion des spécifications (blueprint), aide aux utilisateurs ... Viennent ensuite une myriade de sites comme le brainstorm, le wiki ...

• Le modèle Archlinux : avec la tout autant célèbre philosophie Kiss. Un wiki (Wikimedia), un forum (punBB), un bug tracker (Flyspray), un outils maison pour accueillir les paquets des contributeurs (AUR). Le tout intégré au sein du site archlinux.org.

Personnellement je préfère le modèle Archlinux qui établie très peu de barrières pour permettre à n'importe qui de contribuer. Mais pour une distribution de la taille d'Ubuntu ou Fedora avec des entreprises derrière (Canonical, Redhat) avec une très grosse communauté d'utilisateurs et de contributeurs une infrastructure conséquente est justifiée.

Chez Fedora les fonctionnalités de Launchpad sont divisées en plusieurs sites :

• Bodhi pour monitorer, tester et promouvoir les mises à jour de paquets,
• Kojhi pour construire des paquets,
• Un bug tracker ...

A tout ceci s'ajoute les classiques wiki, forums, mailing lists, pages d'equipes ....

Bref ! Quand on débute on est un peu perdu, et quand on connait on passe son temps à jongler d'un site à l'autre.

Fort heureusement les équipes de design et d'infrastructure de Fedora ont travaillé en commun pour créer Community.

C'est un principe totalement différent de Launchpad : au lieu d'avoir une seule application qui gère tout, on garde toutes les applications séparées et on a un site permettant d'agréger toutes les fonctionnalités sur une seule page !

Concrètement sur un seul site vous accédez à la liste des paquets compilés, à tester, mis à jour, ainsi qu'aux récents posts du planet.

Pour un paquet donné vous accédez à toutes ses compilations, ses versions, à tous ses bugs ...

C'est franchement très bien léché. Pour l'instant c'est surtout orienté gestion de paquets mais ça va très vite évoluer vers plus de fonctionnalités. C'est utile autant pour un contributeur que pour un utilisateur.

Techniquement c'est basé sur moksha, un framework en python pour justement créer des "mashup" de sites web.

Je trouve que c'est une excellente approche. On garde les fonctionnalités détaillées de chaque site tout en proposant un site central pour tout gérer ! A suivre de près ...

Bonjour à tous !

C'est mon premier post sur le Planet Libre. Je vous suis tous depuis un petit moment grâce à ce génial planet et l'envie m'a pris moi aussi de partager avec vous ma passion pour les logiciels libres et l'univers GNU/Linux.

Au menu :

• Des points réguliers sur des technologies, des logiciels et des projets qui me tiennent à coeur.
• Des trucs et astuces accumulées au fil du temps.
• Des revues de sortie de logiciels et de distros.
• Des astuces orientées développement, je suis développeur dans la vie.

Bref un blog tout ce qu'il y a de classique par un geek tout ce qu'il y a de classique pour des geeks tout ce qu'il y a de classique !

Un grand merci à vous tous pour vos posts précédents, un grand merci à tous ceux qui s'occupent du Planet Libre ... et un grand merci à toute l'équipe du projet Dotclear !

A très bientôt,
Chicha

Si comme moi vous usez et abusez de la complétion de votre shell, que vous avez une arborescence avec des noms de fichiers et répertoires commençant par des minuscules ou des majuscules, et que pour vous appuyer sur la touche 'Maj' de votre clavier est une perte de temps précieux alors cette astuce est pour vous :

Bash comme de nombreux outils interagissant avec la ligne de commande utilise la librairie Readline pour lire/éditer les commandes tapées dans le terminal.

Readline peut se configurer via le fichier .inputrc à la racine de votre répertoire utilisateur (~/.inputrc). Parmis les options magiques voici celle qui nous intéresse :

set completion-ignore-case On

Relancez votre shell et voilà : Bash complètera les noms de dossiers en majuscules sans avoir besoin de rentrer le début du nom en majuscule !

L'accélération 3D n'est pas disponible pour votre carte graphique et vous aimeriez pouvoir bénéficier de la vrai transparence des fenêtres, des ombres portées, d'un dock à la MacOS X, ou encore d'un aperçu des fenêtres quand vous faites ALT+Tab ? Tout ceci est possible grâce à une technologie Xorg appelée le "compositing".

Et bien sachez qu'un certain nombre de gestionnaires de fenêtres permettent d'activer le compositing sans accélération 3D. C'est le cas d'Xfwm (XFCE), Metacity (Gnome) et KWin (KDE).

Selon votre matériel le compositing est activé ou non par défaut dans Xorg. Pour le vérifier :

grep Composite /var/log/Xorg.0.log

Sinon vous pouvez l'activer à la main en modifiant votre fichier /etc/X11/xorg.conf pour y rajouter l'option suivante :

Section "Extensions"
        Option "Composite" "Enable"
EndSection

Redémarrez le serveur X pour prendre en compte les changements.

Voilà il vous reste une étape : activer le compositing dans votre gestionnaire de fenêtre si ce n'est pas le cas par défaut. Pour Metacity :

gconftool-2 -t bool -s /apps/metacity/general/compositing_manager true

En plus d'effets graphiques sympathiques le mode composite permet d'exploiter d'avantage votre carte vidéo et moins votre CPU : l'utilisation des fenêtres de votre bureau (ouverture, menu, changement de fenêtre, ...) sera plus rapide.

Pour finir voici une petite vidéo du mode composite de Metacity :

Introduction

Pour mon premier post sur les drivers libres pour cartes graphiques ATI une petite introduction s'impose. J'ai choisis de n'utiliser que du matériel pour lequel un driver libre officiellement maintenu dans le noyau Linux est disponible, et ce pour les raisons suivantes :

1. Je ne veux pas de soucis à gérer lors des mises à jour du noyau.
2. Les drivers libres s'intègrent parfaitement avec les nouveautés du noyau Linux.
3. Les drivers libres sont de meilleur qualité que les drivers propriétaires dans leur ensemble.
4. Par idéologie libriste pure et simple.

Dans ce contexte je me suis débarrassé de ma carte NVidia pour une ATI équivalente en performance. Certes il existe des drivers libres pour les cartes NVidia (nv et nouveau) mais NVidia ne joue pas le jeux du libre et ne fournit pas les spécifications de son matériel. Je me suis donc tourné vers ATI. Intel répond aussi à ces critères mais ne fournit pas de cartes PCI/PCI Express ...

Les drivers

Il existe 2 drivers libres pour les cartes ATI : radeon et radeonhd. Pourquoi deux ? Quand AMD a choisit de fournir les spécifications de ses cartes elle s'est associé avec Novell pour développer un driver libre rapidement et supportant les cartes récentes. Or il existait déjà un projet de driver libre, le driver radeon. Pour des raisons que j'ignore les gens de Novell et du driver radeon n'ont pas réussi à s'entendre et à travailler en commun.

Fort heureusement les diverses parties en question ont commencé à se rendre compte de la situation idiote vers laquelle ils allaient et ont commencé à travailler en commun sur les nouvelles fonctionnalités dont nous allons parler plus bas.

Le driver radeonhd supporte seulement les cartes récentes (chipset >= R500). De sont côté le driver radeon ne supportait, au début que les cartes anciennes (chipset < R500). Maintenant il supporte les mêmes cartes que le driver radeonhd.

Depuis que les deux projets travaillent ensemble sur les nouvelles fonctionnalités les différences entre les deux drivers deviennent quasi nulle. Si vous avez une carte ancienne vous n'avez pas le choix et c'est radeon qu'il vous faut. Si vous avez une carte récente et bien essayer les deux et gardez celui qui marche le mieux avec votre matériel et votre distro !

Concrètement la différence entre les deux c'est quoi ?

• radeon support le "tear-free video playback" pour faire simple c'est un meilleur rendu des vidéos
• radeon support la sortie TV.
• radeonhd supporte l'audio HDMI.

En Bref : Les deux projets radeon et radeonhd convergent vers le meilleur des deux mondes. Le driver par défaut d'Xorg est le driver radeon (sous le doux nom de xf86-video-ati). C'est celui que j'essayerai en premier à votre place. Si vous n'êtes pas satisfait et que vous avez du matériel récent alors tentez le coup avec le driver radeonhd (xf86-video-radeonhd).

La 3D

La 3D c'est le Saint Graal que tout geek cherche à obtenir pour bénéficier des derniers effets graphique à la mode de son bureau préféré, ou plus simplement pour pouvoir jouer à des jeux en 3D sous Linux ou avec Wine.

Le statut est assez clair :

• Si vous avez une carte de génération < R500 (Radeon 9500 – Radeon X1950) alors vous avez le support de la 3D stable et accélérée via le driver radeon. Comme ça fait un moment que ça existe vous n'avez pas besoin d'une version particulièrement récente du noyau ou de Xorg.
• Si vous avez une carte de génération >= R600 alors vous n'avez pas la 3D ... sauf si vous voulez tenter le support très expérimental et très instable (que je n'ai pas testé) tout juste codé par nos amis de chez radeon et radeonhd (qui ont travaillé en commun sur le coup).

Je vous laisse à la documentation, je cite, "not ready yet, don't use it! " du site officiel.

La 2D

Et oui, surprise, là aussi il y a des fonctionnalités particulières supportées ou non. Si tous les drivers libres sont capables d'afficher correctement vos applications en 2D et ce pour toutes les cartes (c'est le minimum quand même), ils ne sont pas, en revanche, capable d'exploiter au maximum les capacités d'accélération de certaines cartes graphiques (au hasard les plus récentes ...) et laissent le soin à votre processeur de se débrouiller au lieu d'utiliser la carte graphique. Résultat l'affichage peut ramer pour des vidéos ou du traitement d'images lourdes avec The Gimp par exemple.

L'accélération 2D c'est la technologie EXA dans Xorg. Elle est supporté pour les anciens modèles de cartes (< R500) depuis un moment et depuis très récemment pour les nouvelles cartes (R600, R700).

Si vous avez une carte récente et que vous voulez l'accélération 2D (pour regarder des vidéos en plein écran ...) alors il vous faut la dernière version du driver radeon (ou radeonhd) et le noyau Linux tout chaud 2.6.30. Si comme moi vous êtes sous Fedora 11 (noyau 2.6.29) alors vous avez les patchs noyaux nécessaires et vous avez aussi l'accélération 2D. L'accélération 2D est activée par défaut si votre modèle le supporte. Pour vérifier c'est assez simple :

grep EXA /var/log/Xorg.0.log

KMS - Kernel Modesetting

Je vais laisser le fameux patrick_g vous expliquer dans sa news sur le sortie du noyau 2.6.29 ce qu'est le kernel modesetting :

Après l'entrée du gestionnaire de mémoire pour cartes graphiques GEM dans le noyau précédent c'est maintenant KMS (kernel-based mode-setting) qui arrive dans le nouveau noyau 2.6.29. Le mode-setting c'est tout simplement la configuration de la carte graphique pour qu'elle puisse afficher correctement les données graphiques sur l'écran. KMS permet d'effectuer ce travail dans le noyau ce qui apporte de nombreux avantages.

On peut citer tout d'abord le fait que le mode setting, puisqu'il est unifié dans le noyau, se retrouve donc partagé entre tous les pilotes. C'est la fin d'une multitude de lignes de codes redondantes au profit d'une seule implémentation plus robuste.

KMS permet également de pouvoir enfin faire tourner le serveur X sans les droits root ce qui est un énorme avantage sur le plan de la sécurité du système.

Enfin avec KMS le changement rapide d'utilisateur (fast user switching) est facilité puisqu'il n'y a plus besoin de changer de terminal virtuel, les phases de mise en veille/réveil sont plus simples donc plus fiables, le boot de la machine est plus agréable (plus de bascules des modes d'affichage) et les messages de panique du noyau peuvent éventuellement être graphiques.

KMS est disponible depuis le noyau linux 2.6.29. Si vous êtes sous Fedora 10 les patches ont été backportés dans le noyau 2.6.28, normal étant donné que ce sont ces messieurs de chez Redhat qui ont développé KMS. En ce qui concerne les drivers ATI le KMS a été implémenté. Mais pour être franc la technologie est assez récente et sur ma radeon HD 3450 (chipset RV620) c'est pas super stable, je l'ai désactivé sur ma Fedora en passant 'nomodset' au démarrage du noyau. En fait tout dépend de votre carte graphique. Tentez le coup et si ça marche bien tant mieux pour vous ! Dans tous les cas ça n'ira quand s'améliorant !

Conclusion

Ça bouge vite du côté des drivers libres ATI ainsi que du côté d'Xorg et du noyau. En quelques mois on a vu arriver l'accélération 2D, KMS et maintenant la 3D expérimentale pour les cartes récentes. Il est clair que la libération des spécifications par AMD et le dynamisme des développeurs de Novell et Redhat a donné une réelle impulsion à ces projets.

Je ferais bien sûr un nouveau point sur les drivers libres ATI dès qu'il y a du nouveau.