PDA

Afficher la version complète : Débugger



atlas
22/11/2004, 23h09
lol

Encore moi , sachant que j'utilise kwrite pour taper mon code .Comment débugger , espionner les variables , poser des breakpoints , voir le code s'executer ligne à ligne ?

De ce que j'aie vu des outils de développement seul Gambas intègre un débuggueur à son IDE .(mais c'est pour du basic)
Kdevelop n'a pas de débuggueur intégré .Anjuta en possède un mais il plus prévu pour gnome
et je suis KDE ; de plus je m'intérresse à Qt pas à Gtk .

Enfin bref comment pratiquez-vous ?

NB : coder avec Kylix en c++ me paraissait la meilleure solution mais l'installation a échoué ... http://www.alionet.org/style_emoticons/<#EMO_DIR#>/arrow.gif

atlas
05/01/2005, 10h21
je me permet de relancer ce sujet .
Je fait le point sur mes tentatives à la recherche d'un débogueur digne de ce nom pour du C++ Qt .

Résultat des courses pour les déboggueurs suivants :

Kgdb = pas au point ,nécessite des patches , bugs etc ...
kylix = quel dommage tres prometteur mais on s'arrache les cheveux pour l'installer et pas sur qu'il fonctionne avec du Qt
anjuta = bien fait mais encore bugué partout et pas fait pour du Qt je crois .

Ceux qui tiennent à peu prés la route

DDD = quelques réserves tous de meme , je suis pas une réference mais j'aie du mal à tracer avec , certains breakpoint ne plantaient pas en dépit du bon sens .

gdb = eh oui lui meme en personne y fonctionne pour les programmes consoles par contre pour des programmes plus graphiques avec Qt .Et bien j'obtient ceci comme message

(gdb) run
Starting program: /home/atlas/droiteA1/droiteA1
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

droiteA1: cannot connect to X server :0.0

Program exited with code 01.
(gdb)
Une recherche avisée sur ce programme me donne pléthore de thread auquel personne ne répond correctement .
Et pis quel rapport entre un déboggueur et un serveur ?
Je craaaaaaaque !!!! http://www.alionet.org/style_emoticons/<#EMO_DIR#>/bang.gif http://www.alionet.org/style_emoticons/<#EMO_DIR#>/diablo.gif : http://www.alionet.org/style_emoticons/<#EMO_DIR#>/biggrin.gif

abgech
05/01/2005, 12h02
Atlas, tu te plains, tu te lamentes sur l'absence de debugger interactif "digne de ce nom". Tu devrais au contraire t'en féliter.

Je risque de passer pour une vieille barbe, de parler de mon expérience, j'estime avoir écrit entre 500'000 et 1 milion d'instructions dans ma vie, dans une quinzaine de langages différents, les divers assembler comptant pour un seul langage.

J'estime que les debugger interractifs ne sont pas utiles, ils sont même nuisibles, dans la mesure où ils favorisent le bricolage, et le bricolage, en informatique c'est l'horreur absolue.

Le meilleur des debuggage commence lors de la conception de son programme: on ne se précipite pas sur un clavier, mais sur un crayon, une gomme et du papier, et on réfléchi.
Ensuite, une fois le programme écrit, face à un bug, on commence par réflèchir, dans le cas vraiment rétifs, on peut utiliser des outils simples, permettant de faire une trace de l'exécution.
Par exemple, en C, on peut utiliser le préprocesseur pour créer une macro d'affichage servant au "debugging":

#define bug_trace(x) printf(#x " = %g\n",x)
bug_trace(sqrt(v)/t) va se développer en:

printf("sqrt(v)/t" " = %g\n",sqrt(v/t))
comme les chaînes adjacentes se concatènent, on obtient:

printf("sqrt(v)/t = %g\n",sqrt(v)/t)

Tu met dans ton code:

#ifdef DEVERMINAGE
bug_trace( ...)
#endif // DEVERMINAGE
C'est amplement suffisant. En définissant ou non DEVERMINAGE, tu passe ou non en configuration de debugging.

Je ne vois un peu l'intérêt des debugger interactifs que pour les programmes multi-tâches, et encore, tous ceux que je connais ne gèrent pas la notion de délai, ils sont donc très limités en programmation temps réel. Dans ce cas, de nouveau, réflexion approfondie et bonne représentation temporelle font merveille.

atlas
05/01/2005, 15h27
<div class='quotetop'>Citation </div>
J'estime que les debugger interractifs ne sont pas utiles, ils sont même nuisibles, dans la mesure où ils favorisent le bricolage, et le bricolage[/b]

I am a bricoleur .La bricole c'est mon truc , j'y peux rien je suis comme ça ... http://www.alionet.org/style_emoticons/<#EMO_DIR#>/biggrin.gif

molodoi
05/01/2005, 16h24
Originally posted by abprfr@mercredi 05 janvier 2005 à 11:02
Le meilleur des debuggage commence lors de la conception de son programme: on ne se précipite pas sur un clavier, mais sur un crayon, une gomme et du papier, et on réfléchi.
Ensuite, une fois le programme écrit, face à un bug, on commence par réflèchir, dans le cas vraiment rétifs, on peut utiliser des outils simples, permettant de faire une trace de l'exécution.
<div align='right'><{POST_SNAPBACK}> (index.php?act=findpost&pid=13696)[/quote]

http://www.alionet.org/style_emoticons/<#EMO_DIR#>/blink.gif J'ai l'impression de me lire.

Dans mes bras, mon autre moi-même

http://www.alionet.org/style_emoticons/<#EMO_DIR#>/beer.gif

atlas
05/01/2005, 16h25
Ceci étant pour l'histoire du serveur avec gdb , j'aie résolu le problème .C'est tout simple ne pas lancer le prog en mode su .

Quand à mes breakpoints qui plantent pas avec DDD je pense que c'est du au fait que je ne comprend pas dans quel ordre est lu mon code .Un bon traçage animé me l'aurait appris alors si il existe une astuce avec gdb je suis preneur .
Et pis j'aurais besoin aussi d'un cerveau de secours avec des nano-implant de silicium athlon 500Ghz , autonomie minimale 4heures .Personne n'a ça en déstockage ?

molodoi
05/01/2005, 16h27
Originally posted by atlas@mercredi 05 janvier 2005 à 14:27
<div class='quotetop'>Citation
J'estime que les debugger interractifs ne sont pas utiles, ils sont même nuisibles, dans la mesure où ils favorisent le bricolage, et le bricolage

I am a bricoleur .La bricole c'est mon truc , j'y peux rien je suis comme ça ... http://www.alionet.org/style_emoticons/<#EMO_DIR#>/biggrin.gif
<div align='right'><{POST_SNAPBACK}> (index.php?act=findpost&pid=13729)</div>
[/b][/quote]

Etre un bricolo de la progra ne pose pas trop de problèmes (et encore) qd il s'agit d'une appli que tu fais tout seul et qu'elle compte 15 lg.

Le hic, c'est qd tu t'insères dans un projet de plus grande envergure (par exemple, un projet open source qui compte 10000 lg de code - un min pour une appli valable) qui compte une armée de programmeur. Là, c'est l'horreur absolue!

C'est d'ailleurs souvent ce que ne comprennent pas les étudiants...

molodoi
05/01/2005, 16h29
Originally posted by atlas@mercredi 05 janvier 2005 à 15:25
je ne comprend pas dans quel ordre est lu mon code .Un bon traçage animé me l'aurait appris alors si il existe une astuce avec gdb je suis preneur .
<div align='right'><{POST_SNAPBACK}> (index.php?act=findpost&pid=13737)[/quote]

A moins que ton appli ne soit multi-threads et/ou multi-processus, ton code est executé de manière séquentielle, instruction après instruction.

abgech
05/01/2005, 17h43
<div class='quotetop'>Citation </div>
A moins que ton appli ne soit multi-threads et/ou multi-processus, ton code est executé de manière séquentielle, instruction après instruction.[/b]
Je nuancerais le propos, avec un compilateur optimiseur, la séquence d'exécution n'est pas forcément la même que la séquence du source.

Bien sûr, avec un programme écrit proprement, l'optimiseur va très peu réarranger les instructions. Mais s'il s'agit d'un programme écrit par un sagouin, la séquence d'exécution n'a, souvent, que peu de rapport avec la séquence du source. Ce qui rend d'autant plus aléatoire l'utilisation d'un debugger. Et comme les utilisateurs de tels debugger programment souvent de façon olé-olé ... Leur debugger a pour effet de leur faire perdre un temps considérable.