Cher journal,
KDevelop 4.4 est sorti.
Quoi de neuf ? Pas grand chose, juste des corrections de bogues et des optimisations.
(Ah si, il y a un nouvel écran d’accueil)
Mais ça me donne juste l’occasion de faire un journal pour présenter mon IDE favori.
Celui que j’utilise tous les jours pour écrire, mais aussi et surtout pour lire du code.
KDevelop offre une bonne prise en charge du C, C++, PHP, Ruby, et plein d’autres langages. Mais comme je fais surtout du C++, je me concentre là‐dessus.
Commençons par une Nimage :
Et ce que j’aime, ce sont les couleurs ; une coloration sémantique digne de ce nom :
- toutes les occurrences du symbole sous le curseur mises en évidence ;
- des couleurs différentes (vives) pour chaque variable locale ;
- les classes en vert, les enums en bordeaux, les membres de cette classes en doré et les autres membres en mauve ;
- les erreurs sont soulignées, ce qui permet de les corriger immédiatement avant même de compiler.
Alors, certains diront que ça pique aux yeux et que c’est pire qu’un sapin de Noël.
Mais les sapins de Noël, c’est joli. Et puis, ces couleurs mettent en valeur le code et le rendent plus facile à lire.
Je dois admettre qu’il faut un moment pour s’y habituer. Mais, une fois qu’on a l’habitude, on ne peut plus s’en passer.
Quand je vois du code avec une bête coloration qui se contente de mettre les mots clefs en gras, je suis tout perdu et j’ai du mal à lire du code
Mais les devs ont tout prévu, et pour les dépressifs qui n’aiment pas les couleurs, il y a des glissières dans la configuration qui permettent de configurer la quantité et l’intensité des couleurs :
Chez moi, c’est au maximum.
Une autre fonctionnalité importante est la navigation du code.
« Ctrl + , » permet d’aller directement à la définition du symbole en question.
Et il est possible de naviguer avec « Meta + ← / → » pour aller à l’endroit suivant/précédent dans la navigation. Comme le bouton « précédent » du navigateur.
« Maj + Meta + ← / → » permet de naviguer à l’instance suivante ou précédente d’un symbole particulier. Je trouve ça très pratique.
Le complètement automatique est aussi extrêmement pratique. Presque plus besoin d’aller voir la doc.
En plus, KDevelop utilise un système d’heuristique en fonction du type pour trier les résultats du complètement automatique, ce qui fait que ce qu’on veut taper est presque tout le temps dans les premiers résultats.
À propos de la doc, si vous documentez votre code avec des commentaires Doxygen, ceux‐ci sont affichés dans la bulle d’aide.
Sinon, KDevelop a aussi tout ce qu’un bon éditeur doit avoir comme débogueur intégré et ce genre de chose.
Donc, quand je dois lire du code que je ne connais pas, rien de plus facile que de l’ouvrir avec KDevelop :
Importer un projet existant se fait en quelques clics, quel que soit le système de build.
Il suffit de choisir « Système de build générique » et d’ajouter les chemins d’inclusion dans le dialogue prévu pour, et c’est parti.
J’ai même codé un site pour naviguer dans le code en C++ depuis son navigateur.
Voilà, j’espère que ce journal vous fera essayer KDevelop si vous ne l’utilisiez pas encore pour développer votre code C++.
# Sortit avec quit?
Posté par ʭ ☯ . Évalué à 5.
Blaguet à par, j'attends de remplacer Quanta par Kdevelop depuis un bail… qui fait du php avec?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Sortit avec quit?
Posté par Gof (site web personnel) . Évalué à 3.
Mmmh, oui, j'ai sans doute fait pas mal de fautes d'orthographe. Y compris au premier mot, que j'ai rajouté après la relecture. Honte à moi.
[^] # Re: Sortit avec quit?
Posté par patrick_g (site web personnel) . Évalué à 3.
J'ai corrigé tout ce que j'ai pu repérer.
[^] # Re: Sortit avec quit?
Posté par Davy Defaud . Évalué à 4. Dernière modification le 24 octobre 2012 à 17:45.
Vraiment ?! Et tu n’as pas pu en repérer plus ? Je suis sûr que tu peux faire beaucoup mieux que ça Patrick ! J’en ai corrigé plus d’une quinzaine après toi, toutes de très grosses fautes d’accord, pas des subtilités de notre jolie langue.
Dommage qu’il n’y ait pas d’historique des changements sur les journaux, tu aurais pu te rendre compte de l’étendue des dégâts…
[^] # Re: Sortit avec quit?
Posté par patrick_g (site web personnel) . Évalué à 3.
En même temps j'étais en meeting. j'ai donc effectué mes corrections tout en écoutant d'une oreille le blabla de nos collègues de Mumbai ;-)
[^] # Re: Sortit avec quit?
Posté par Davy Defaud . Évalué à 3.
Me voilà rassuré. Je t’absous de tes péchés mon frère, au nom de Saint-Capelovici et Saint-Ignucius.
[^] # Re: Sortit avec quit?
Posté par zedS . Évalué à 1.
J'ai déjà fait un peu de php avec et j'ai trouvé ça vraiment pas mal. Surtout que même avec de grosse api, il ne rame absolument pas (contrairement à certains).
Un truc tout bête que je n'ai jamais réussi à faire par contre, c'est faire afficher simplement la liste des fonctions du fichier en cours (sans classe), du coup je ne l'utilise pas :/
Si quelqu'un peut éclairer ma lanterne
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Juste une question
Posté par fearan . Évalué à 1.
Non ce n'est pas l'utilité de kdevelop par rapport à emacs, qui fait le café lui, mais c'est l'existence de la possibilité d'envoyer directement une commande à gdb que je cherche.
Car toutes les interfaces à gdb que j'ai trouvé ne répondent pas à tous les besoins.
* possibilité de faire des rbreak (ou autre commande magique de gdb), ou plus globalement envoyer directement une commande à gdb.
* possibilité d'explorer les objets (kgdb, qtcreator)
* affichage de code et possibilité d'avoir des breakpoint placés à la sourie.
en gros ce qui se rapproche le plus c'est ddd, mais bon coté ergonomie on fait mieux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par Marotte ⛧ . Évalué à 2.
Anjuta le fait. Je suppose que KDevelop aussi. Ou alors je n'ai pas compris.
[^] # Re: Juste une question
Posté par fredix . Évalué à 3.
tu as essayé nemiver ?
[^] # Re: Juste une question
Posté par Maxime (site web personnel) . Évalué à 1.
Si tu as assez de ram, tu peux essayer avec Eclipse CDT.
[^] # Re: Juste une question
Posté par fearan . Évalué à 5.
mouais je vais voir la faq
Ce que les gens on l'air d'oublier c'est que gdb à évolué depuis l'épique époque des barbus piquant, et que maintenant il y a la complétion auto dans gdb, et j'ai pas non plus envie de devoir me poser la question de savoir si je peux ou non taper la ligne fatidique; quant à lancer Eclipse pour du c++, faut vraiment être désespéré (oups, déjà vendredi?)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par ckyl . Évalué à 1.
Ca va faire 7/8 ans que j'ai pas lancé gdb pour autre chose que des conneries mais y'a quoi comme fonctionnalité qui n'est pas accessible depuis l'IDE ?
[^] # Re: Juste une question
Posté par mackwic . Évalué à 4.
Au hasard, les commandes:
-
printqui est surpuissant (genreprint *(*argv + 2 * sizeof (size_t))oup *0x44ff006b-
disassemblecar oui, tout le monde ne compile pas avec -g -ggdb3 :-)- est-il nécessaire de spécifier
jumpetcall?-
dumpdumpe tout simplement la ram a un offset donné et l'interprete s'il le peut- le hardware watchpoint offrent souvent un support meilleur que ce que font la plupart des IDE
En tout cas, j'adore Kdevelop pour sa souplesse et son confort visuel, mais ce n'est pas pour son débuggueur que je le favoriserait…
Super astuce:
- compiler un fichier .c avec
gcc -g -ggdb3- lancer
emacs -f gdb- sélectionner votre exécutable
- M-x gdb-many-windows
- profit
Gdb est quand meme 'achement puissant. ;-)
[^] # Re: Juste une question
Posté par barmic . Évalué à 3.
gdb est vraiment superbien intégré à emacs, c'est la killer-feature de se dernier de mon point de vu. Du moins c'est celle qui peut me faire quitter vim. Quand j'utilise vim et gdb, je les lance chacun de leur coté, c'est moins intégré mais ça le fait quand même.
Par contre ça ajoute quoi -ggdb3 par rapport à -g ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Juste une question
Posté par mackwic . Évalué à 3.
Des options de débug spécifiques a gdb, plus d'information, des informations plus précises. Je met toujours les deux quand je sais que j'utiliserais gdb.
[^] # Re: Juste une question
Posté par fearan . Évalué à 2.
Là ça va dépendre de l'ide; mais le problème c'est que c'est un ensemble, j'ai pas envie de devoir changer d'IDE selon mes besoins en debugger, ni de devoir lancer un bouzin qui me pompe 500Mo de RAM rien que pour l'environnement (Eclipse out). Trouve moi un ide qui permet
bref un paquet de truc qui simplifient la vie quand on débug, on est pas obligé de devoir ouvrir tous les fichier un à un pour placer les breakpoint. Moi aussi j'ai utilisé gdb il y a longtemps, et effectivement je n'avais pas remarqué tout ce que je fais avec aujourd'hui, certains trucs sont dus à de grosse évolutions, mais il est probable que je n'ai pas cherché plus loin que run, break, cont, next, step, where, print, display et les répétitions.
Et s'il est vrai que généralement un debugger comme celui qu'on trouve dans qtCreator est suffisant, il n'y a rien de plus rageant que de se retrouver dans une sessions de debuggage, avec tout qui plante comme on veut et qu'on est désarmé parce qu'il manque la fonctionnalité de gdb que les devs ont estimé inutile, ou à devoir remettre à plus tard, ou encore plus simple ignorée.
Et encore la liste ci-dessus est très loin d'être exhaustive, tu as pleins d'autre détail que fait gdb.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par ckyl . Évalué à 2.
Juste pour préciser ma question n'était pas réthorique, quand je pose une question c'est que je pense que la réponse devrait être intéressante. Je comprends totalement l'intêret de pouvoir basculer sur gdb au besoin, mais je me demandais à quel point c'était actuellement nécéssaire.
Dans les langages que j'utilise depuis, tu as grosso modo un mapping 1-1 entre les debuggers bruts et l'intégration dans les IDE. Les IDE étaient tout moisis quand j'ai arrêter d'écrire du C. Donc ma question comportait deux volets: quelles actions ne sont actuellement pas disponibles dans les IDE et quelles actions de GDB ne sont conceptuellement pas insérable de manière satisfaisante dans les IDE.
Avec vos deux réponses je pense réussir à distinguer les deux catégories. Ca m'étonne que la plupart de ce qui a été listé ne soit pas dispo, les fonctionalités équivalentes existent dans d'autres langages (rbreak, tbreak, break conditionnel, catch, completion, print, remote debug) et sont "parfaitement" intégrés.
[^] # Re: Juste une question
Posté par fearan . Évalué à 2.
Clairement, ce que je vois difficilement implémentable :
Pour le reste une grosse partie des fonctionnalité sont dispos, mais cela dépend des IDE, pour les 4 premiers, il est fréquent qu'il en manque un ou deux, et j'aime beaucoup les rbreak ou la completion auto, notamment avec des templates quand on ne veux pas tout bloquer ;)
Les IDE intègrent la majorité des points cités, mais retire en 1, et tu pleures le jour où tu en a besoin, et je n'ai aucune envie de me poser la question avant le lancement de devoir choisir quel debugger.
Et plus généralement le pilotage à la main (n, s, c, d, c 10… ) est plus rapide qu'à la sourie, et lorsqu'on débug un process en communication avec un autre, être capable de faire du pilotage rapide pour pas chopper un time out est un certain avantage (mais avec des tracepoint en abondance on peut gérer)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par ckyl . Évalué à 2.
Hormis pour spécifier le ignore-count du continue (et plus généralement n'importe quel argument d'une commande usuelle qui va demenander un popup insupportable) j'ose prétendre que n'importe quel IDE fourni les mapping clavier et que tu n'as pas besoin du mulot.
Ce point m'interpelle. En général tu choisis ton environement de travail, tu y restes et tu le maitrise parfaitement. Tu ne lances ou choisi pas clairement un IDE pour debugger quelque chose. Par contre tu utilises son debugger si il fourni ce dont tu as besoin, autrement tu le degages et tu y vas a l'ancienne.
De vos commentaire je pense pouvoir en déduire que 1- Les dev C n'aiment toujours pas le IDE et donc ne les connaisses par forcément bien (ce qui fait une boucle). 2- Les IDE pour le C ne semblent pas avoir un stade fonctionnel où on ne se pose même plus la question de leur utilisation.
[^] # Re: Juste une question
Posté par fearan . Évalué à 2.
J'apprécie beaucoup qtCreator lorsque je fait du Qt, mais utiliser son debugger, s'il peut être très pratique peut aussi s'avérer très frustrant.
Au contraire, j'oscille entre plusieurs IDE, qtCreator, kdevelop, et (emacs + kde + bash + perl + …); si pour la prise en main rapide les deux premiers sont très pratique, sur le long terme, le dernier a encore quelques avantages qui se résorbent petit à petit. Mais comme on est encore bloquer à qt3 sur nos machines, emacs à encore de beaux jours devant lui ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par moi1392 . Évalué à 2.
C'est possible, tu as une invite de commande gdb, je m'en sers régulièrement.
J'ai pas compris, tu as un dock "variables" dans lequel tu peux demander à voir un objet que tu peux explorer sous forme d'arboréscence, ça marche aussi dans le tooltip quand tu es en mode déboguage. C'est de ça dont tu parles ?
ça marche sans soucis.
[^] # Re: Juste une question
Posté par fearan . Évalué à 2.
Ahhh merci mon Moi!!! J'ai plus qu'à trouver comment l'installer sur une centos 5.5 (on rigole pas dans la salle)
Exactement ;) Je n'en doutait point pour Kdevelop, mais le seul truc dont je doutait était la possibilité d'envoyer directement a gdb un rbreak Plop::set* (ou approchant) ou encore un rbreak Plop::Plop ou trace hop.cc:42 ; actions ; collect $args ; end;
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Juste une question
Posté par moi1392 . Évalué à 1.
Je n'ai jamais utilisé rbreak depuis la ligne de commande gdb de kdevelop.
En général, je m'en sers surtout pour affecter des valeur à des variables (p var = 24), à voir le type dynamique des objets c++ (set print object on, puis p mon_obj) et à activer les break sur les exceptions (catch throw, catch catch, …)
À priori ça devrait passer, mais faut voir si kdevelop ne se merde par sur le retour de gdb (il parse le retour de gdb, en ignorant, à priori, ce qu'il ne connais pas)
[^] # Re: Juste une question
Posté par Anthony Jaguenaud . Évalué à 2.
Si tu y arrives, fait signe avec même avec un gros package de lib, dépendance kde… je suis sur une machine virtuelle RHEL5…
# Merci
Posté par Frédéric COIFFIER . Évalué à 1.
Merci pour cette jolie présentation de l'état de KDevelop. Je ne l'ai plus utilisé depuis KDE 3.5 (vu qu'il était sorti bien après KDE 4) et je m'étais habitué à utiliser Kate.
Je vais lui redonner sa chance au boulot !
# Dépêche sur KDevelop 4.4
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 10.
Peu avant ce journal, j'ai démarré une dépêche sur KDevelop 4.4 dans l'espace de rédaction si vous voulez y faire un tour et l'améliorer avant son passage en modération (d'ici ce soir je pense).
Merci.
# Analyse syntaxique et plugin
Posté par Anthony Jaguenaud . Évalué à 2.
Bonjour,
pour compléter, je dirai que l’analyse sémantique du C++ est excellente. Elle est d’ailleurs disponible facilement pour ceux qui voudrait faire des plugin.
Dans les fonctionnalités que j’apprécie, c’est de pouvoir coder à la ligne, et tout d’un coup, paf j’utilise une variable de type structure à laquelle j’accole un champ qui n’existe pas. Après avoir fini la ligne, kdevelop demande : « le champ n’existe pas, voulez-vous le créer ? » en répondant « oui », il va l’ajouter directement dans la structure dans le bon fichier d’entête. Il propose également les inclusions quand il détecte qu’on utilise une fonction non déclaré.
À l’époque de kdev 4.2 je crois, il y avait un plugin en développement qui utilisait l’analyse sémantique pour faire en temps réel de jolis graphes d’appel… quelqu’un sait s’il est toujours maintenu ?
[^] # Re: Analyse syntaxique et plugin
Posté par moi1392 . Évalué à 2.
Pour compléter, je dirais que ce que j'aime le plus dans le gestion du c++, c'est les "best match" lors de la complétion.
Si par exemple, j'ai une variable de type int, et que je veux lui assigner une valeur depuis un appel de méthode d'un objet, il va me proposer en premier dans la liste les fonctions de cet objet qui renvoient un int.
Quand je suis dans une fonction, si je lui demande la complétion sans rien avoir tapé au clavier, il me propose en premier les varialbes, locales du bon type, puis les méthodes de la classe dans laquelle je suis du bon type et enfin, tout ce qui est global.
Enfin, il gère merveilleusement bien les templates.
Un std::vector est reconnu comme un conteneur de int, et tout ce que j'ai écrit plus haut s'applique !
Et ce, même avec des templates extrêment compliqués (templaytes de template, héritage de template, …)
C'est de très très loin l'ide le plus puissant pour l'analyse et la complétion en c++
# vim
Posté par Lutin . Évalué à 5.
Existe-t-il un plug-in pour pouvoir se balader et écrire dans son fichier avec les commandes de vim ?
(Chaque fois que j'essaye un IDE je retrouve mon code rempli de "dd", ":y2", ":vsplit truc.h", "/super_fonction", etc).
Merci.
[^] # Re: vim
Posté par Gof (site web personnel) . Évalué à 6. Dernière modification le 24 octobre 2012 à 17:06.
Oui, ça existe:
Configuration -> Configurer l'éditeur -> Édition -> « Mode de saisie dans le style VI » (avant dernier onglet, dans la traduction française, le titre de l'onglet est tronqué :-/ )
Je viens d'essayer 3 minutes et ça à l'air correct.
[^] # Re: vim
Posté par Anthony Jaguenaud . Évalué à 1.
Il y a des limitations :
Sur une ligne du genre :
Si tu mets le curseur après le premier . un
c2t.ne fonctionne pas bien. En fait, c’est surtout le 2 de la commande qui n’est pas pris en compte. (En tout cas sur la version que j’ai chez moi)[^] # Re: vim
Posté par Lutin . Évalué à 2.
Hourra, j'essaie ça dès demain.
# Kdevelop sur Windows
Posté par julien . Évalué à 2.
Super pour la release; quelqu'un a réussi à compiler ça sous Windows ??
Je m'arrache les cheveux dessus depuis des lunes… et ya personne pour partager sa build !
[^] # Re: Kdevelop sur Windows
Posté par Marotte ⛧ . Évalué à 8.
Pourquoi tu n'utilises pas GNU/Linux au lieu de t'arracher les cheveux ?
[^] # Re: Kdevelop sur Windows
Posté par Anthony Jaguenaud . Évalué à 5.
Dans le monde professionnel, tu n’as pas toujours le choix des armes… dans ce cas, il faut se débrouiller seul pour avoir de bons outils.
[^] # Re: Kdevelop sur Windows
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Prends Qt Creator alors.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Kdevelop sur Windows
Posté par Anthony Jaguenaud . Évalué à 2.
Oui, mais kdevelop est quand même plus pertinent dans les choix proposés… mais QtCreator peut-être une alternative intéressante.
Existe t’il une version portable (sans avoir à installer) ? car j’ai rarement/jamais les droits admin sur des machines Windows…
[^] # Re: Kdevelop sur Windows
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Rassure moi, il te donne quand même une chaise à ton boulot?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Kdevelop sur Windows
Posté par lendemain . Évalué à 2.
Non uniquement un bol de riz.
[^] # Re: Kdevelop sur Windows
Posté par Anthony Jaguenaud . Évalué à 1.
Et encore, retenu sur salaire ;-)
[^] # Re: Kdevelop sur Windows
Posté par Anthony Jaguenaud . Évalué à 1.
Il avait été compilé par l’équipe winkde pour la version 4.0 ou 4.1. Mais comme personne ne l’utilisait, ils ont arrêté. Les soucis de la version windows que je traine, viennent de l’implémentation de dbus, qui ne fait pas la différence entre la session et le système… du coup, il ne peut y avoir qu’une instance. Ce qui est ennuyeux quand on est nombreux sur la machine.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.