Logiciel : PTT : outil de trace pour la NPTL
Posté par Guillaume Duranceau (). Modéré le 24 avril 2006.
Le processus de débogage d'une application multi-threadée utilisant la NPTL est souvent complexe : bugs non reproductibles, dépendants de la charge du système et du nombre de CPUs, emploi de débogueurs modifiant la dynamique de l'application et donc son comportement...
PTT (POSIX Thread Trace Toolkit) est un outil distribué sous licence LGPL ayant pour but de faciliter l'analyse et le débogage d'applications multithreadées utilisant la NPTL. Il permet de tracer les évènements internes de la NPTL (entrées/sorties des routines, prises et relâchements de verrous...) tout en ayant un impact très faible sur les performances.
PTT est fourni sous la forme d'un patch pour la glibc et d'outils de récupération et d'analyse des traces. Son utilisation ne nécessite pas les droits de super-utilisateur et n'altère en rien le noyau ou les librairies du système.
La nouvelle version 0.10.0 de cet outil est disponible sur SourceForge. Les processus d'installation et d'utilisation ont été grandement simplifiés.
![[en]](../images/en.png)
La page de PTT (737 hits)-
Téléchargement de PTT (243 hits)
-
NPTL (Wikipedia) (373 hits)
> Lire la dépêche (13 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #705117.
Run by 
Cette page a été générée par Templeet en 0.0646s (dont 0.0065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Pajé
La page officielle de Pajé est sur la forge d'ObjectWeb maintenant :
http://forge.objectweb.org/projects/paje/
Ce projet est toujours très actif et très utilisé mais son principal point faible est qu'il est développé en Objective C.
[^]Re: Pajé
Oui, j'ai essayé Pajé à l'occasion. C'est une horreur à compiler (y'a pas de paquet disponible sous Mandriva), et l'interface est vraiment pas agréable. La même chose en Gtk2 serait beaucoup plus simple à compiler et beaucoup plus agréable à utiliser.
[^]Re: Pajé
Sous Debian, j'ai installé les paquets « gnustep gnustep-make gnustep-devel libgnustep-gui0.10-dev (qui installent plein de trucs dont gobjc) (rien que ça). Ensuite, commandes pour compiler et installer :
Enfin, pour le lancer : « openapp Pake.app ».
Bon, le problème est la détection des dépendences un peu foireuse et que nul part il y a écrit : il faut évaluer /usr/share/GNUstep/Makefiles/GNUstep.sh dans votre shell :-/
Houlà, c'est moche, ça me rappelle ce bon vieux WindowMake ... rah là là, c'est pas gagné GNUstep ...
Haypo
[^]Re: Pajé
pourquoi pas un simple :
apt-get install paje.app
On le trouve dans unstable/testing/stable (même si les versions sont un peu vieilles pour testing/stable.
Et sinon, recompiler à partir des sources du paquet Debian permet de profiter du travail d'adaptation du mainteneur pour Debian...
vdanjean@cayuga:~$ apt-cache search paje
paje.app - generic visualization tool (Gantt chart and more)
vdanjean@cayuga:~$ apt-cache policy paje.app
paje.app:
Installé : 1.4.0-1
Candidat : 1.4.0-1
Table de version :
*** 1.4.0-1 0
990 ftp://ftp.debian.org unstable/main Packages
100 /var/lib/dpkg/status
1.3.2-4 0
500 ftp://ftp.debian.org testing/main Packages
1.3.2-3 0
500 http://ftp.debian.org stable/main Packages
[^]Re: Pajé
pour la compilation, sourcer GNUstep.sh est (encore) nécessaire, mais pour l'exécution normalement non... en tout cas avec une version récente de gnustep.
Quand au look, ben hein.. faut voir avec camaelon non ? au pire, utiliser preferences.app pour virer le gris sombre par un gris plus léger :)
'fin bon.
[^]Re: Pajé
C'est aussi son point fort à mon humble avis. Son point faible c'est que le toolkit GNUstep est pour l'instant à la traîne par rapport à GTK2 ou Cocoa. Mais bientôt j'intégrerais l'équipe d'étoilé et ... ... TUT TUT TUT.... Haaaaaaaaaa ! Merde il est quelle heure ! chui en retard pour le boulot ! Il était pourtant bien ce rêve
[^]Re: Pajé
« GNUstep est pour l'instant à la traîne par rapport à GTK2 ou Cocoa » : ben franchement, je trouve qu'il est mort ce projet. On dirait qu'ils n'y ont pas touché depuis 1990 (bon, disons depuis que j'ai remplacé WindowMaker par XFCE4 ou Gnome2, y'a longtemps donc).
Haypo
[^]Re: Pajé
En effet, mais c'est dommage. Si on regarde au niveau du design du langage, c'est de loin le meilleur des descendants du C.
D'autre part, windows maker fait partie du projet GNUstep mais n'ai pas programmé Obj C (c'est du pure C) et donc ne s'appuie pas sur le toolkit GNUSTEP.
Ce qui manque pour moi à ce toolkit c'est :
1) plus de programmeurs ;)
2) un bureau attractif, un truc joli pas tout gris quoi (etoilé, étoilé étoilé !!!!!! [2] )
3) une compatibilité niveau source avec Cocoa (et ça c'est dur parce que c'était pas le but du projet initial [...blablablabla...] openstep [...blablablabla...], que c'est dur à entendre par certains "lead developper" à un moment où le projet arrive au terme de ce qui était fixé au départ et, enfin, qu'il n'ont pas envie d'être encore en train d'être à faire de la réimplémentation sans la prise de decision qui fait plaisir... Je les comprends ... Mais y'a qu'a voir les sources de GNUmail [3] pour voir que c'est bien prise de tête de supporter les 2 architectures à coup de #ifdef )
[1] => http://gnustep.org/developers/whoiswho.html et http://www.etoile-project.org/etoile/mediawiki/index.php?tit(...)
[2] => http://www.etoile-project.org/etoile/mediawiki/index.php?tit(...)
[3] => http://www.collaboration-world.com/gnumail/
Ps: Un jour j'y participerais, un jour ...
[^]Re: Pajé
arg merdouille
"mais n'ai pas programmé" : bien ouej :) la grande classe...
[^]Re: Pajé
>On dirait qu'ils n'y ont pas touché depuis 1990
Tu as regardé les ChangeLog et la quantité de code ?
http://svn.gna.org/viewcvs/gnustep/
Moi je dirais pas qu'il est mort ( et loin de là )
Par contre je dirais qu'il y a beaucoup trop de code même pour les 30 développeurs GNUstep ( ce qui est beaucoup même comparé à QT ou gtk/Glib) .....
Je pense que le code GNUstep est dans bien des points largement supèrieur à QT ou Glib/GTK.
Le problème c'est que les développeurs de Framework / Libraries ne développent pas d'applications ......
Et sans applications ... ça reste juste une belle implementation de belles spécifications
[^]Re: Pajé
Oui, GNUstep avance, tranquillement... ceci dit, 30 développeurs GNUstep ... oui, plus ou moins; mais quand j'ai dit ça au fosdem (je subodore que ce chiffre vient de là, me trompes-je ?), après coup j'ai réalisé que je m'était vraiment mal exprimé (le fameux esprit d'escalier!) -- je ne voulais pas dire qu'il y a 30 devs qui bossent sur le repository gnustep aujourd'hui, mais plutôt donner un ordre d'idée de la "communauté gnustep", eg combien de devs plus ou moins actifs...
Malheureusement, tous ne travaillent pas sur les frameworks eux-mêmes.. et en plus, pour ceux qui bossent dessus, on est loin d'avoir tout le monde committant en coeur tous les soirs ;-) (dommage !)
Si c'était le cas, punaise, ça ferait longtemps que tout serait nickel :D
Sur gnustep -core lui même, il y a plutôt un coeur de 4-6 développeurs assez réguliers, mais c'est tout... (et encore, -gui est le mal aimé). Après il y a des gens qui participent plus épisodiquements, puis d'autres qui bossent sur des applis, etc.
Je sais pas pour Gtk, mais à mon avis il y a un tout petit peu plus de monde qui bosse sur Qt que sur GNUstep ;-)