Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de artefact :
- [17/05@08:44] Un IDE pour la Glib
- [06/01@14:50] Configuration de cartes à base de acx100
- [30/12@14:30] Wifi + ethernet + configuration réseau automatique sur Debian
Journal : De la difficulté de contribuer à des gros projets
Posté par Jean Parpaillon (Jabber id, page perso, ) le 27 juin 2005Utilisateur intensif du projet Struts, j'étais tombé sur un bug qui, d'ailleurs, avait déjà été découvert 1 an avant par une autre personne. Ce bug est toujours ouvert...
Comme je voyais d'où venais ce bug, j'ai décidé de le corriger mais, voilà, le projet Struts est un gros projet.
Résultat :
- j'ai passé 3 jours à télécharger les bonnes sources et à intégrer mon projet dans mon IDE favori,
- j'ai passé 2 heures à corriger le bug,
- les modifs sont restées sur mon ordi, faute de savoir comment les soumettre.
Je sais que la soumission du patch n'est pas très compliqué, je trouverais bien avant que le bug soit corrigé par quelqu'un d'autre...
Le problème, c'est que, il me semble, tous les gros projets doivent avoir le même problème. Comme tous les projets du libre tendent à devenir gros (je pense à Firefox, OO.org, Evolution, ou des projets largement utilisés comme ça), je pense qu'il faudrait sérieusement réfléchir à des moyens de pas rebuter les contributeurs non-régulier de tels projets.
J'aimerais avoir des retours de personnes qui ont essayé, avec succès ou pas, de contribuer à des projets de grosse taille...
Jean Parpaillon
> Lire le journal (132 commentaires, moyenne: 3).
...
2h pour corriger un bug ça me semble pas si énorme... Maintenant, si t'as passé 3 jours pour intégrer le projet dans ton IDE, je suis pas sûr que les auteurs du projet y puissent grand chose... Avait tu vraiment besoin d'un IDE pour ça ? :)
-
[^]Re: ...
Posté par Jean Parpaillon (Jabber id, page perso, ) le 27/06/2005 à 16:39. (lien). Évalué à 5.Ben justement, c'est le problème que je voulais soulever : je pense que dans beaucoup de projets, la plupart des bugs demandent peu de temps mais l'intégration du projet peut être rebutante. Et je cherche des solutions...
-
[^]editeur à la place de l'IDE
Posté par free2.org (page perso, ) le 27/06/2005 à 16:54. (lien). Évalué à 4.si tu maitrise un editeur comme vim / emacs, tu peux simplement décompresser l'archive des sources, rechercher les fichiers incriminés (avec un peu de chance les chaines affichées lors de l'erreur suffisent), les modifier et lancer un make.
en fait on peut configurer emacs/vim pour les transformer en IDEs capables de fonctionner sur n'importe quelle archive décompréssée, sans avoir à créer un projet à chaque fois-
[^]Re: editeur à la place de l'IDE
Posté par kaouete (page perso, ) le 27/06/2005 à 17:02. (lien). Évalué à 1.ah tiens ? des tutos ? liens ? ca m'interesse : ]
-
[^]Re: editeur à la place de l'IDE
Posté par free2.org (page perso, ) le 27/06/2005 à 18:56. (lien). Évalué à 1.pour vim il y a plein de tutos sur vim.org bien-sur et ci-dessous on a deja évoqué ctags qui marche pour vim et emacs
-
-
[^]Re: editeur à la place de l'IDE
Posté par Thierry Boudet (page perso, ) le 27/06/2005 à 17:04. (lien). Évalué à 10.rechercher les fichiers incriminés (avec un peu de chance les chaines affichées lors de l'erreur suffisent),
Pour les projets en C, je conseille vivement cscope qui roxorize les mamans ours. Il est parfaitement adapté à ce genre de recherches. Je suppose qu'il existe des équivalents pour d'autres langages, mais pour les "C-addicts", c'est vraiment d'la balle atomique.
http://cscope.sourceforge.net/index.html(...)-
[^]Re: editeur à la place de l'IDE
Posté par rangzen (page perso, ) le 27/06/2005 à 20:11. (lien). Évalué à 2."In April, 2000, thanks to the Santa Cruz Operation, Inc. (SCO) (since merged with Caldera), the code for Cscope was open sourced under the BSD license."
???-
[^]Re: editeur à la place de l'IDE
Posté par free2.org (page perso, ) le 28/06/2005 à 05:33. (lien). Évalué à 3.deja faut pas tout mélanger, le procès SCO concerne du code qui aurait été introduit par IBM dans Linux
Sinon ils ont été racheté depuis par Caldera, et c'est Caldera les méchants aujourd'hui (meme s'ils ont changé de nom pour s'appeler SCO)
et tant que un juge n'a pas pris de décision finale (mal embarquée pour SCO, cf le cour de l'action SCOX), on se contrefout de SCO
-
-
[^]Re: editeur à la place de l'IDE
Posté par gc (page perso, ) le 28/06/2005 à 07:32. (lien). Évalué à 5.roxorize les mamans ours
les mamans ourses. c'est féminin boudiou.-
[^]Re: editeur à la place de l'IDE
-
-
[^]Re: editeur à la place de l'IDE
Posté par Philippe Fremy (page perso, ) le 28/06/2005 à 11:15. (lien). Évalué à 3.cscope, c'est pour les losers. Le top, c'est source navigator (sourcenav.sf.net), qui gere la distinction entre utilisation d'une varible et declaration. C'est vraiment genial pour rentrer rapidement dans un projet. Et ca marche meme sous ouinouin.
-
[^]Re: editeur à la place de l'IDE
Posté par Thierry Boudet (page perso, ) le 03/07/2005 à 06:59. (lien). Évalué à 2.Le top, c'est source navigator (sourcenav.sf.net),
Je viens de regarder, effectivement ça semble bien. Je vais l'essayer dans la journée, peut-être...
Mais c'est un gros truc graphique, alors que cscope est en mode texte, et reste utilisable même sur des toutes petites machines ou à travers un lien ssh peu véloce. Sur ce, plouf-piscine.
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 17:16. (lien). Évalué à 4.C'est gentil emacs/vim, mais dans un gros projet t'es bien content de pouvoir faire "bouton droit > Aller à la définition", ou tout bêtement mettre des points d'arrêt et "tracer" dans le débuggueur pour repérer le problème. Bref rien ne vaudra un bon IDE dédié, et il est vrai que des projets comme Struts pourraient proposer en "standard" un projet Eclipse, ca faciliterait la vie à tout le monde.
-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 17:21. (lien). Évalué à 7.je fais tout ça avec emacs...
Pour le "aller à", tu utilises etags.
Pour gdb, tu fais M-x gdb.
Ça prend quoi...5min pour connaitre les commandes de base.
Si tu veux un projet eclipse, libre à toi de le fournir, mais pour bcp, ça servirait à rien et imposer un IDE, je trouve pas ça une très bonne idée.-
[^]Re: editeur à la place de l'IDE
Posté par Fabien Penso (Jabber id, page perso, ) le 27/06/2005 à 17:25. (lien). Évalué à 8.Pour le "aller à", tu utilises etags.
Tu me confirmes que etags a depuis mon dernier essai bien évolué pour t'amener à la définition de la bonne méthode dans le bon objet ? Sinon, c'est poubelle direct.
Enfin comparer Eclipse et Emacs c'est avoir une franche méconnaissance de Eclipse. En terme d'IDE il y a pas photo, mon choix est vite fait (et j'utilise Emacs depuis plus longtemps que Eclipse). Puis gdb c'est gentil, mais de même, le comparer au debugger Eclipse ça fait doucement sourire...-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 17:55. (lien). Évalué à 10.Laisse tomber, t'es passé du côté obscure de la force, réputé pour sa facilité ;)
-
[^]Re: editeur à la place de l'IDE
Posté par Frédéric RISS () le 27/06/2005 à 19:05. (lien). Évalué à 6.Je travaille sous emacs et j'ai essayé de passer mon environement sous eclipse 3 fois dans la dernière année. Il n'y a pas moyen que quelqu'un utilise CDT sur un project C++ un tant soit peu compliqué. Les indexeurs sont à la rue, prennent tout le CPU pendant 4/5 minutes à chaque modifcation de fichier et surtout ne sont pas capable de s'en sortir avec des templates ce qui les rend totalement inutiles pour moi.
De plus, le mode de saisie par défaut ne me plait pas et malgré des menus contextuels avec 50 options, pas moyen de lui dire comment identer mes sources.
Pour information, le debugueur d'eclipse est GDB, alors ta remarque me fait 'doucement sourire' :). En plus l'interfacage est très limité même au niveau des fonctionalités exposées par l'interface (impossible d'afficher l'assembleur brut, il y a toujours les lignes sources, ce qui fout la merde sur du code optimisé). La perspective de debug n'offre pas d'avantages 'graphiques' (comme la zone de graphe de gdv) et interdit l'usage de fonctions avancées...
Les parseurs d'erreurs GNU make/gcc sont extremement mauvais, ce qui fait qu'il faut regarder dans la console pour avoit le message d'erreur correpsondant au marqueur mis dans la marge.
Bref, Eclipse pour du Java c'est l'outil le plus formidable du monde, mais pour du C++ il n'est tout simplement pas prêt.-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 19:21. (lien). Évalué à 3.Bref, Eclipse pour du Java c'est l'outil le plus formidable du monde, mais pour du C++ il n'est tout simplement pas prêt.
Oué mais le fait est qu'on parle Java là, et même si Eclipse est pourri pour C++ par rapport à emacs, l'inverse est aussi vrai : emacs est pourri pour Java par rapport à Eclipse.-
[^]Re: editeur à la place de l'IDE
Posté par J A-G () le 28/06/2005 à 11:43. (lien). Évalué à 3.Oué mais le fait est qu'on parle Java là
Java a été nomé pour la première fois dans le post juste avant le tien, pas avant...
Donc, non, on ne parle pas de Java là ....
C'est un troll emacs/Eclipse (tiens, où est vi ?), pas un troll Java/C++...
Un peu de concentration messieurs !!!-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 28/06/2005 à 13:08. (lien). Évalué à 3.Java a été nomé pour la première fois dans le post juste avant le tien, pas avant...
J'ai voulu proposer une solution pour le cas du journal : en l'occurence le projet Struts est en Java.
-
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par Matthieu Moy (page perso, ) le 27/06/2005 à 19:41. (lien). Évalué à 4.etags marche très bien pour le C, ou le nom de la fonction suffit a trouver sa définition (pas de surcharge). Pour un langage avec surcharge, il faut tenir compte du contexte pour déduire le type des arguments, et etags est à la rue.
Sous Emacs, le mode qui fait ça est semantic, mais la dernière fois que j'ai essayé, autant j'étais bluffé par ce qu'il était capable de faire sur un mini exemple de quelques lignes, autant j'étais dégouté de voir à quel point il marchait mal sur mon vrai code.
Sinon, gdb doit pas être si pourri que ça vu qu'Eclipse l'utilise pour le C/C++ ...
-
-
[^]Re: editeur à la place de l'IDE
Posté par Pinaraf (Jabber id, ) le 27/06/2005 à 17:49. (lien). Évalué à 6.Si tu veux un projet eclipse, libre à toi de le fournir, mais pour bcp, ça servirait à rien et imposer un IDE, je trouve pas ça une très bonne idée.
Heu
J'ai du mal à comprendre là...
En quoi fournir un fichier de projet eclipse oblige les gens à utiliser eclipse ?
Par exemple sur Looking Glass on fournit un fichier de projet Netbeans, ben ceux qui veulent utiliser netbeans sont super contents, et les autres ils bossent comme ils veulent (y'en a qui préfèrent eclipse, donc ils utilisent eclipse sans se soucier des fichiers de netbeans)-
[^]Re: editeur à la place de l'IDE
Posté par neil () le 27/06/2005 à 19:21. (lien). Évalué à 2.Ça fait un fichier de plus à maintenir...
-
[^]Re: editeur à la place de l'IDE
Posté par Pinaraf (Jabber id, ) le 27/06/2005 à 19:32. (lien). Évalué à 2.Ha
J'ai jamais vu de modif de ce fichier depuis son apparition.
Les modifs liées à la compilation sont dans le fichier build.xml, qui est utilisé par ant. Et netbeans est capable de lire ces changements.
De même j'ai pas eu de soucis sur un projet géré avec kdevelop.
-
[^]Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (Jabber id, page perso, ) le 28/06/2005 à 08:33. (lien). Évalué à 3.Un fichier de projet Eclipse, c'est 10 lignes de XML, et le reste est généré par Eclipse...
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par kra () le 27/06/2005 à 17:51. (lien). Évalué à 8.ouais, enfin ca doit dependre des projets et des langages.
j'ai longtemps fait du java avec un simple emacs et des makefile, ca fait un peu plus d'un an que j'utilise intensivement eclipse..
bah franchement, ya pas photo sur un gros projet, eclipse est infiniment meilleur..
en vrac :
les differentes vues, les resumes de classes,
les copier/coller etendus,
gestion des classpath (et ce meme entre les projets)
gestion des workspace,
les builds automatique,
la compilation incrementale,
le debugger (genre tu peux modifier a la volee tes methodes), y compris dans des applis tierces, genre tomcat,
la navigation/recherche dans le projet (acces en lecture, en ecriture, definition, toutes les occurences),
les wizards de creation de classes,
les imports automatiques,
implementations/surdefinition automatique des methodes,
le refactoring,
l'integration d'un gestionnaire de conf (et tout ce qui va avec, les diffs, l'historique etc.),
la completion auto et intelligente (verification des types etc.),
les try/catch auto,
les erreurs de syntaxe etc. indiquees direct dans le source, avec la possibilite de parametrer la sensibilite du compilo (niveau d'erreur/warning, y compris pour javadoc),
ant,
possibilite de lier les sources des .jar,
les configurations de lancement,
et j'suis sur que j'en oubli.
je sais qu'emacs propose une certaine partie de tout ca, mais bon, la c'est tout integre out of the box et ca fait reellement gagner du temps.
-
[+] [^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 18:02. (lien). Évalué à -1.Ah bon avec gdb je peux suivre l'état de mes variables Java, afficher la stack et me surligner la ligne de code en cours d'exécution ?
Faudrait arrêter de délirer, à croire que t'as jamais essayé Eclipse.-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 18:40. (lien). Évalué à 3.on parle de java uniquement ou du problème en général ?
Si on parle de java, evidement gdb n'est pas l'outil le plus adapté, mais je pense que tu aurais pu deviner que je ne pensais pas utiliser gdb avec java.
Le titre du journal est
"Journal : De la difficulté de contribuer à des gros projets"
et l'auteur parle du problème en général. Si tu prend des cas particuliers, je pense que tu peux toujours trouver un truc que n'importe quel IDE ne fait pas.
Concernant la remarque sur etags, la dernière fois que j'ai utilisé oui, il me suffisait de me mettre sur une methode, de demander d'aller à la déclaration, et ça marchait.
En lisant les commentaires qui disent que je suis à coté de la plaque, je vois principalement des remarques sur java, j'imagine qu'on ne parle que de java donc (parceque les jar, les 'imports', la gestion du classpath, ça doit être super dur à gérer pour un projet en C quand même). (PS, je sais eclipse sait faire autre chose que du java, mais on s'en fou, c'est pas le problème)
bonne soirée-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 19:05. (lien). Évalué à 3.on parle de java uniquement ou du problème en général ?
Le monsieur a rencontré un problème général mais dans un cas particulier. Tu proposes une solution qui ne résoud pas son problème particulier. T'aura beau indiquer une solution qui marche dans un autre cas, dans son cas précis ce n'est pas adapté. Et dans son cas particulier, l'idéal reste un projet Eclipse.
Enfin à la pertinence des commentaires, je m'apercois qu'il y a encore beaucoup d'intégriste à penser que emacs est la solution ultime. Heuresement d'autres sont là pour faire évoluer l'informatique et proposer des outils agréables aux utilisateurs.
Pour prendre l'exemple du "diable", sous Windows, la plupart des projets "open-source" sont diffusés avec un projet Visual Studio. C'est tellement plus simple. Ah oui, ils n'ont pas accroché à la révolution emacs, ca doit être pour ca.-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 19:23. (lien). Évalué à 7.le prend pas mal hein. J'ai aucun doute que eclipse est formidable étant donné que j'en entend que du bien, mais je dois dire que parfois, ça me gonfle d'entendre dire "Eclipse c'est génial parceque X" et que X est un truc tout con. Si tu préfères eclipse, tant mieux pour toi, personne ne t'empeches de l'utiliser. A propos de VisualC, c'est peut être parcequ'il est bcp plus simple d'utiliser Visual C sous windows que d'installer gcc via cygwin ou autre ? Par contre, le truc pas drôle, c'est quand tu veux utiliser autre chose que VisualC sur un projet... Si je reprend le journal de façon générale, voilà ce que j'en tire. Le monsieur fait remarquer que c'est chiant de participer à un gros projet car il a mis plus de 3jours pour corriger un truc et qu'il ne sait pas comment distribuer ce truc. Il y a donc un problème. Si tu regardes ses chiffres, 95% du temps vient du fait que le projet n'était pas intégré à son IDE. Est-ce que ça vaut la peine de passer 3 jours à intégrer un truc dans un IDE pour seulement passer 2h dessus et sans savoir ensuite faire un diff ? Je suis pas sûr. Si eclipse rend la chose simple, alors il faut lui dire comment il aurait dû s'y prendre. Il se trouve qu'avec des éditeurs du genre vim/emacs, qui apportent peut être moins de facilités pour certains langages comme java, il aurait été possible, en moins de 3jours, d'arriver à se ballader dans les sources... Non ? Ensuite, faire un diff à la main, c'est pas le truc le plus dur non plus (sans compter que si les src viennent de CVS, dans le menu en haut d'emacs, y'a un truc qui te pond un diff tout seul, et en couleur)
-
[^]Re: editeur à la place de l'IDE
Posté par Fabien Penso (Jabber id, page perso, ) le 27/06/2005 à 19:49. (lien). Évalué à 3.Bof tout ça.
1. Déjà les coups du diff à la main, c'est marrant, mais si tu compares objectivement un truc comme pcl-cvs et Tortoise, le pcl-cvs tu le jettes direct. A se demander pourquoi l'équivalent de Tortoise existe pas sous Linux (pas tk/cvs hein...).
2. Bien sûr que dans Eclipse t'as pleins de fonctionnalités toutes con que t'as aussi dans Emacs, Emacs je l'utilise tous les jours même pour lire mes mails, c'est pas le problème. Le truc c'est que dans Eclipse t'as pleins d'autres super fonctionnalités, le tout intégré dans un seul outil (pas besoin d'installer ceci ou cela et que ca marche pas tu sais pas pourquoi). Evidemment pour comprendre la puissance de Eclipse faut faire du Java, les autres plugins sont pas à la hauteur (le plugin C++ par exemple, l'est pas du tout).
3. Tes coups de moins de 3 jours pour faire ceci ou cela, tu fais pareil avec un projet Eclipse vu que le code source... c'est le même. Si tu veux prendre Emacs pour le lire, tu peux. Maintenant clairement, quand tu t'habitues à Eclipse et que tu vois le temps que ça te fait gagner (exclus le temps de lancement ou t'as le temps d'aller pisser, mais Emacs se lance aussi lentement chez moi), bah tu regrettes pas l'investissement.
Fabien, utilisateur quotidien de vim, emacs _et_ de vrais IDE.-
[^]Re: editeur à la place de l'IDE
Posté par Matthieu Moy (page perso, ) le 27/06/2005 à 21:31. (lien). Évalué à 4.> 1. Déjà les coups du diff à la main, c'est marrant, mais si tu compares
> objectivement un truc comme pcl-cvs et Tortoise, le pcl-cvs tu le jettes direct. A
> se demander pourquoi l'équivalent de Tortoise existe pas sous Linux (pas tk/cvs hein...).
Question d'un inocent qui n'a jamais utilisé Tortoise : Il a quoi de si extraordinaire par rapport a PCL-CVS par exemple (< mode inocent >et par rapport au fantastique Xtla</mode inocent >).
Enfin, pour un windowsien "de base", habitué à l'explorateur, c'est clair que c'est cool de pouvoir faire sa gestion des versions depuis un outil qu'il connait, mais inversement, pour moi, ça me paraitrait abhérent de quitter mon Emacs pour ça ...
(pour le reste d'Eclipse, je m'y mettrai quand j'arrêterait d'entendre du mal des CDT ou quand je me remettrai au Java ;-)
-
-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 20:01. (lien). Évalué à 1.Si tu regardes ses chiffres, 95% du temps vient du fait que le projet n'était pas intégré à son IDE.
Pas la peine de mettre en gras le "son". Eclipse est LE IDE libre, gratuit et dispo sur toutes les plateformes, c'est quasiment un standard, et à ce titre un projet Eclipse serait parfaitement la bienvenue. Tellement standard que ce projet Struts a une partie "intégration dans Eclipse".
Le monsieur exprime clairement le besoin d'avoir autre chose qu'un "makefile" et les sources.
peut être moins de facilités pour certains langages comme java, il aurait été possible, en moins de 3jours, d'arriver à se ballader dans les sources... Non ?
Je l'ai déjà dis mais je le répète encore : il n'y a pas que la navigation dans le code, mais aussi la navigation dans le file d'exécution, bref du déboggage. IL y a aussi l'intégration de tests unitaires pour "valider" une modification, l'exécution de ces mêmes tests pour s'assurer qu'il n'y a aucune régression, et pourquoi pas imaginons un déploiement sur un serveur Tomcat. Tu m'expliques là avec ton emacs ?-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 20:10. (lien). Évalué à 9.Le monsieur exprime clairement le besoin d'avoir autre chose qu'un "makefile" et les sources.
je vais me repeter mais tant pis. Le monsieur nulle part n'a indiqué qu'il cherchait une solution adaptée uniquement à java, à C, à C++, ... pour des contributeurs non réguliers (j'imagine par là que c'est quelqu'un qui ne va pas garder 5Go pour pondre un patch tous les 6 mois).
D'ailleurs il demandait des retours d'expérience, par des comparaisons "la mienne est plus grosse".
Je m'arrete là, bonne fin de soirée, et bon trolls-
[^]Re: editeur à la place de l'IDE
Posté par Jonathan ILIAS (Jabber id, page perso, ) le 27/06/2005 à 22:37. (lien). Évalué à 2.Le monsieur nulle part n'a indiqué [...]
artefact va peut-être en avoir marre d'être appelé "le monsieur" ;)
Au sujet du troll, on va mettre ça sur le compte de la fatigue : on commence à être loin de la question initiale (qui ne se résume pas à un IDE) et votre désaccord est à peine discernable.-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 28/06/2005 à 06:56. (lien). Évalué à 3.et votre désaccord est à peine discernable.
C'est pourtant pas compliqué : certains essai de proner emacs et gdb comme solution "globale" pour répondre à une question "globale", moi je veux montrer qu'il n'y a pas UNE solution, mais DES solutions en fonction du contexte, et dans son cas précis la solution c'est un projet Eclipse.
-
[^]Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (Jabber id, page perso, ) le 29/06/2005 à 07:27. (lien). Évalué à 2.artefact va peut-être en avoir marre d'être appelé "le monsieur" ;)
C'est vrai, ça, y'en a marre...
Plus sérieusement, et pour revenir à ma question, je voudrais faire une comparaison avec d'autres projets que Struts.
Donc, en se situant toujours dans des grpos projets, imaginons que quelqu'un veuille contribuer à Xorg. On peut me répondre que n'importe qui ne peut pas contribuer à un tel projet et pourtant, je n'en suis pas si sûr. Sans y avoir regardé, je suis sûr que certains bugs ne doiventpas être inaccessible à des contributeurs occasionnels. Mais la difficulté viendrait alors de tester les corrections. Si il faut reconstruire X à chaque fois...
Alors là, j'ai une ébauche de solution : small is beautiful ! C'est d'ailleurs ce que fait Xorg et qu'essaye de faire Struts. Mais ce n'est pas encore la panacée, donc j'attendais des idées un peu dans le genre.
Quant à la guerre des IDE, bien que je trouve gênant, comme la plupart ici apparemment, de lier un projet à un IDE, il faut reconnaître qu'Eclipse n'a pas son pareil pour des projets Java et qu'il est libre :-) Donc, intégrer directement un projet Java à Eclipse ne me parait absurde. Pour revenir à Struts, par exemple, les conventions de codage sont telles qu'elles pourraient, pas exemple, être incluses dans le projet...
-
-
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par kesako () le 27/06/2005 à 19:43. (lien). Évalué à 0.Tu viens de tout resumer : ceux qui ont besoin d'un IDE ce sont ceux qui soit developpent pour windows (donc Visual Studio) soit font du java.
Les autres tous les autres ( c c++ sans mfc , python, perl, ruby, ...etc) n'ont pas ce besoin.
comme par hazard (?) le premiers se voient surtout en entreprise, les seconds sur le travail colaboratif sur internet.
Note bien que je n'ai pas dit que l'un et mieux que l'autre, je dit seulement qu'un IDE c'est mal adapté pour des projets auquels on veut voir participer bcp de monde.-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 19:53. (lien). Évalué à 3.Les autres tous les autres ( c c++ sans mfc , python, perl, ruby, ...etc) n'ont pas ce besoin.
Non il faut être honnête : sous Windows il y a Visual Studio, sous Linux il n'y a aucun équivalent sauf pour Java.
Conclusion : dès qu'il y a un IDE répendu et qui apporte un réel confort d'utilisation il est utilisé.
je dit seulement qu'un IDE c'est mal adapté pour des projets auquels on veut voir participer bcp de monde.
Ce journal montre clairement le contraire : le monsieur aurait double cliquer sur le fichier projet Eclipse, il aurait instantanément eu accès au source dans sa config Eclipse qu'il aime, en 1 cliques il débuggait, etc.
C'est pas pour rien que Eclipse ou Visual Studio sont capable de se synchroniser avec un serveur CVS. Quand à l'excetpion du travail collaboratif sur internet, c'est du vent : en entreprise aussi c'est du travail collaboratif. La seule différence, c'est la barrière humaine, pas la barrière technique. Quand soit dans la pièce à côté ou à l'autre bout de la terre, dans tous les cas tu synchronise sur CVS.-
[^]Re: editeur à la place de l'IDE
Posté par kesako () le 27/06/2005 à 20:50. (lien). Évalué à 2.Non
Dans une entreprise PEUT organiser les chose de facon a avoir tous les meme versions de compilos , de debugger. les meme libc les meme patches . C'est meme quasi obligatoire. Meme l'organisation des repertoires doit etre la meme ou tres proche. Dans ce cas tu peut refiler un fichier eclipse ou un fichier VC sans probleme aux collegues. tout se metra en place et compilera clic-clac .
Sur internet , c'est deja pas simple d'avoir un gcc et une libc qui convient alors si en plus on doit avoir un IDE telle version avec les plugins telle version , une jvm telle version ... c'est la galere
> le monsieur aurait double cliquer sur le fichier projet Eclipse, il aurait instantanément eu accès au source dans sa config Eclipse qu'il aime, en 1 cliques il débuggait, etc.
Tu prend le pb a l'envers. C'est a lui de s'adapter. Si les concepteur n'ont pas eu besoin d'un ide et on qd meme fait un enorme projet , ben , c'est tout simplement qu'il n'y en a pas besoin. Ce n'est pas a eux de preparer les choses comme le monsieur les aimes car ce n'est manifestement pas necessaire.-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 21:05. (lien). Évalué à 4.C'est meme quasi obligatoire.
Ah ?
Meme l'organisation des repertoires doit etre la meme ou tres proche.
Chez nous l'organisation c'est le CVS. Dans le libre c'est pareil : tout le monde a la même organisation du coup.
Dans ce cas tu peut refiler un fichier eclipse ou un fichier VC sans probleme aux collegues. tout se metra en place et compilera clic-clac
Fait leur découvrir CVS (ou Subversion tant que t'y es), tu vas voir tu vas faire progresser tes développeurs d'un bon en avant de 20 ans ;)
Je vois pas pourquoi sous prétexte qu'en entreprise tu peux voir ton voisin tu devrais te passer des outils "basique" que sont cvs ou svn. Visual Studio est intégré depuis des lustres à VSS (le CVS pourri de MS).
Sur internet , c'est deja pas simple d'avoir un gcc et une libc qui convient alors si en plus on doit avoir un IDE telle version avec les plugins telle version , une jvm telle version ... c'est la galere
Je vois pas le rapport avec la VM, avec ou sans IDE t'aura la contrainte. De plus tu n'obliges absolument personne à utiliser l'IDE, mais tu permets à ceux qui le souhaite d'utiliser un outil puissant et dédié.
Si les concepteur n'ont pas eu besoin d'un ide et on qd meme fait un enorme projet , ben , c'est tout simplement qu'il n'y en a pas besoin. Ce n'est pas a eux de preparer les choses comme le monsieur les aimes car ce n'est manifestement pas necessaire.
Réaction typique et insupportable des developpeurs "élitistes" dans la communauté du libre.
Il suffit pas de mettre un logiciel sous telle licence pour "aider" les utilisateurs/developpeur. Il faut aussi leur donner tous les outils nécessaire : documentation utilisateur, documentation développeur, etc.
On a toujours filé un makefile avec les bons vieux projets C, en Java c'est Eclipse ou Ant. Je vois pas en quoi sa requête est déplacée.
Tu prend le pb a l'envers. C'est a lui de s'adapter.
Faut savoir ce qu'on veut : si on veut faire un projet libre et "ouvert" aux autres, ou un projet "libre" de "guru", opaque, et avec de rares contributions extérieures.
Moi je préfères le problème comme tu dis "à l'envers".
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par Pinaraf (Jabber id, ) le 27/06/2005 à 21:15. (lien). Évalué à 2.Les autres tous les autres ( c c++ sans mfc , python, perl, ruby, ...etc) n'ont pas ce besoin.
Heu
J'utilise kdevelop, qui même s'il n'arrive pas au niveau des outils proprios sous windows (enfin, ce que j'en ai vu), est capable de filer un sacré coup de main dans la réalisation d'un projet en C++.
Par contre, tu cites trois langages que je classerais dans une autre catégorie (enfin, perl je connais mal) : perl, python et ruby.
Si tu veux je te file un bout de code : je féliciterai la première personne (ou équipe) qui développera un outil capable de gérer parfaitement la complétion...
Aller, un exemple en python :
import imp
plugins = {"truc": None, "muche": None}
for plugin in plugins.keys():
plugins[plugin] = imp.load_source("", "%s.py" % plugin)
plugins["truc"].
==> quels choix sont disponibles ?
Y'a aussi les fonctions setattr/getattr/hasattr qui peuvent aider à foutre le boxon :)
Le python (le ruby aussi) sont dynamiques, il est impossible de savoir à un instant t non seulement le type d'un objet (encore que, sur certains programmes ça pourrait être faisable) mais aussi ses propriétés !
Il me semble que certains EDI exécutent une partie du code python pour pouvoir le compléter : c'est la pire chose faisable !
import os
a = os.system("rm -fr /")
a.
==> c'est bon, t'as exécuté joyeusement un rm -fr /... D'accord c'est un cas extrême mais ça pourrait arriver (en moins grave)-
[+] [^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 23:38. (lien). Évalué à -1.ouai enfin ton exemple tu peux le faire avec à peu prêt n'importe quel langage...
-
[^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 28/06/2005 à 06:52. (lien). Évalué à 1.Dans un langage typé statiquement tu n'as absolument pas le problème décrit : la complétion marche toujours, et sans s'amuser à exécuter le code.
-
-
[^]Re: editeur à la place de l'IDE
Posté par mcjo () le 28/06/2005 à 10:26. (lien). Évalué à 2.Microsoft le fais depuis des années pour le vba et le fais aussi pour asp.net.
Même si ça m'ennuie de citer microsoft pour cet exemple il me semble que dans ce cas pour la complétion l'ide n'as besoin de savoir que comment ton objet ou variable est instancier pour vérifier ses propriétés. Ca ne change pas grand chose si ce n'est que ça demande un plus de travail à l'IDE qui est toujours obligé de reprendre depuis le début de ton pour voir comment ton objet est instancié avant le positionnement du curseur. Mais ça ne ralentira pas beaucoup plus l'ide par rapport à un language avec des variables typées à moins que tu ne t'amuses à mettre des 80000 lignes de code dans un même fichier...-
[^]Re: editeur à la place de l'IDE
Posté par Pinaraf (Jabber id, ) le 28/06/2005 à 19:09. (lien). Évalué à 2.Il me semble que tu n'as pas compris mon exemple.
vba ne gère pas ce genre de chose, par contre je ne connais pas asp.net
Reprenons mon exemple pour une petite explication :
import imp
plugins = {"truc": None, "muche": None}
for plugin in plugins.keys():
plugins[plugin] = imp.load_source("", "%s.py" % plugin)
J'espère que tu connais des bases de python.
Le module imp sert à pouvoir jouer avec import de façon beaucoup plus libre : en effet, tu n'as pas à savoir ce que tu veux importer. Ça te permet par exemple de créer sans te fouler un système de plugins (qui sont alors sous forme de modules python)
Ici j'ai décidé de stocker ces plugins dans un dictionnaire nommé plugins. Les clés sont les noms des modules, et les valeurs les modules eux même.
Ensuite, j'importe chacun de ces modules pour l'insérer dans le dictionnaire.
Et maintenant, plugins["truc"] a quelles fonctions et propriétés disponibles à ton avis ?
Même moi je ne le sais pas si j'ai pas l'accès au fichier truc.py. Mais comment un EDI pourrait gérer ça ? Tu veux qu'il interprète le code ligne par ligne ? Tu tombes dans le risque que j'ai évoqué précédemment : un code buggué qui serait exécuté. Tu veux qu'il "comprenne" le code ? Il doit donc connaître tous les modules python standards, ainsi que leur utilité... Charmant programme en perspective !
J'ai sur ma machine un bot IRC développé en utilisant notamment ces facultés. Si tu souhaites en savoir plus, contacte moi sur #testbot2@freenode.net (nick : PieD). Je me ferai un plaisir de t'expliquer plus en détail (ou à n'importe qui d'ailleurs) ce genre de joie pythonesque :)-
[^]Re: editeur à la place de l'IDE
Posté par mcjo () le 28/06/2005 à 21:03. (lien). Évalué à 1.Oui, tu pourras prendre des exemples où la complétion ne marche pas, mais si ça permet d'aider à 90% du code c'est pas trop mal.
C'était juste pour dire que la complétion pour les languages dynamique non typé ne nécessitent pas de compilation même si ça implique qu'elle ne fonctionnera pas pour des portions de code...-
[^]Re: editeur à la place de l'IDE
Posté par Pinaraf (Jabber id, ) le 29/06/2005 à 09:07. (lien). Évalué à 2.Bon, on va prendre effroyablement simple (toujours en python):
def truc (arg):
if arg.
==> il propose quoi ton super EDI de la mort ? surtout si c'est dans le cas d'une librairie que tu développes !-
[^]Re: editeur à la place de l'IDE
Posté par alenvers () le 30/06/2005 à 08:02. (lien). Évalué à 3.
Bon, on va prendre effroyablement simple (toujours en python):
def truc (arg):
if arg.
==> il propose quoi ton super EDI de la mort ? surtout si c'est dans le cas d'une librairie que tu développes !
Il n'est pas impossible de proposer un certain nombre de choix.
Mais dans le cadre de typage dynamique, l'analyse statique devient plus compliquée. Dans ce cas, de plus, il s'agit d'une analyse inter procédurale ce qui ne facilite pas les choses.
Dans ce cas précis, il faudrait faire une "Point-to" analysis. Mais bon, est-ce que ça en vaut bien la peine ?
-
-
-
-
-
-
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 18:46. (lien). Évalué à 7.Ah bon avec gdb je peux suivre l'état de mes variables C, afficher la stack et me surligner la ligne de code en cours d'exécution ?
Faudrait arrêter de délirer, à croire que t'as jamais essayé gdb
-
[^]Re: editeur à la place de l'IDE
Posté par Matthieu Moy (page perso, ) le 27/06/2005 à 19:32. (lien). Évalué à 3.J'ai pas d'expérience de déboggage en Java, mais en C++, oui, je peux suivre l'état de mes variables, surligner le code en cours d'execution et afficher la stack, avec un gdb lancé dans Emacs. (M-x gdb RET, display/watch variable, up, down, where, ...)
Je dis pas qu'Eclipse est mauvais, mais visiblement, toi, tu n'as pas du essayer beaucoup Emacs.-
[^]Re: editeur à la place de l'IDE
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 19:53. (lien). Évalué à 3.y'a même pas besoin de emacs... Dans mon gdb, je tape refresh et j'ai le code qui apparait avec la ligne surlignée...
-
[+] [^]Re: editeur à la place de l'IDE
Posté par TImaniac (page perso, ) le 27/06/2005 à 19:56. (lien). Évalué à -1.ouiiiiiinnnnnnnnnnnnnn Bien sûr que si j'ai de l'expérience avec emacs ! J'ai développer pendant 2 ans là dessous, mais on ne parle pas de C++, je sais pertinement que gdb sait faire ca avec du C++, mais en AUCUN CAS c'est une solution alternative à eclipse pour débugguer Struts qui est en JAVA.
-
-
-
-
-
[^]Re: editeur à la place de l'IDE
Posté par Jean Parpaillon (Jabber id, page perso, ) le 28/06/2005 à 08:31. (lien). Évalué à 3.Là, c'est vrai que j'avais pas précisé, mais j'utilise Eclipse comme IDE, parce que pour des projets Java, il y a des choses que je ne retrouverait pas ailleurs (déboguage, une vraie vue objet du code, etc, etc). J'utilise abondamment Emacs pour tout ce qui n'est pas Java, mais pour le reste...
-
-
ils ont pas d'attachements dans leur bug tracker ? sourceforge
ils offrent pas de possibilité d'attacher un fichier dans leur bug tracker ?
sinon sur sourceforge (où il y a de gros projets aussi), il y a une interface assez simple pour proposer des patches. idem pour savannah (où il y a aussi les projets GNU)
l'incapable
Euh, j'essai de participer à des projets du libre, criawips et PEAR particulièremet. Ce qui me manque le plus, c'est la compétence et/ou le parrain.
Je crois que les outils s'améliorent ainsi que les conceptions. Les exemples les plus flagrants sont bazaar-ng pour les outils et la modularisation de xorg pour la conception.
Par exemple, j'ai tenté de faire passer la carte clavier pour macintosh et le « new input layer » via les bugzilla de Xfree et xorg. du coté de Xfree86, il l'ont intégré sans broncher (plutôt expéditif) chez xorg, c'est l'inverse, ils attendent la modularisation afin d'avoir un mainteneur dédié, qui ne soit pas obligé d'avoir une vue d'ensemble.
La petite histoire a même fait irruption sur linuxfr : http://linuxfr.org/forums/10/7773.html(...)
E Ultreïa !
-
[^]Re: l'incapable
Posté par Croconux () le 27/06/2005 à 18:28. (lien). Évalué à 3.Ce qui me manque le plus, c'est la compétence et/ou le parrain.
Ou bien la documentation. Je ne parle pas de la doc utilisateur, qui existe en général sur les gros projets, mais plutot la doc développeur : Un guide du nouveau contributeur, en somme. Ceux qui ont l'habitude de bosser sur un projet connaissent l'architecture globale du logiciel et savent ou trouver ce dont ils ont besoin. Un nouveau venu risque par contre de passer un temps fou à chercher dans l'énorme tarball par où prendre le bouzin, où chercher les infos manquantes.
Un parrain c'est l'idéal mais ça ne tiens pas l'échelle. Il y a peu de chance de trouve un volontaire pour encadrer chaque nouveau padawan qui se présente. En revanche documenter ce qu'on fait, pourquoi on a choisi telle ou telle architecture après moult essais, ça c'est jouable et c'est nécessaire si on veut qu'un projet survive en cas de désintérêt/manque de temps de la part de ses piliers fondateurs.-
[^]Re: l'incapable
Posté par mcjo () le 27/06/2005 à 20:05. (lien). Évalué à 3.Je pense que les 2 peuvent être interressants, en effet l'idée du parrain ne me parrait pas si stupide que ça et à mon avis ça attiré surement d'avantage de jeunes padawans sur les petits projets. Et peut-être que ce temps perdu ne le serait pas sur le long terme, car justement les développeurs sont peux nombreux (je parle des petits projets) et se retrouvent principalement à faire du support aux utilisateurs, du débogage et finalement n'ont jamais le temps d'implémenter tous ce qu'ils voudraient alors que si une partie de ce temps était passé pour aider les mecs qui veulent contribuer au projet, celà permettrai de mieux répartir les taches...
A utopie quand tu nous tiens...
-
Pour info [ un peu de pub ]
Oui, c'est quelque chose de pas très évident, contribuer à un gros projet.
Quand je repense à l'impression que j'ai eue quand j'ai essayé de comprendre la première fois, c'est n'est plus la même chose :-)
Alors pour apporter ma petite pierre, et témoigner, je vais faire une présentation sur le sujet
"Méthodologie du libre" à Dijon lors des RMLL, au sujet d'OpenOffice.org
En gros : comment ça marche, être contributeur pour un tel projet.
Et je serai même là pour répondre à vos questions ~ du 5 au 9 juillet sur le stand
Francophone d'OpenOffice.org.
Surtout, n'hésitez pas, je viens exprès... :-)
--
ericb@openoffice.org
Mes contributions
Salut,
Il n'y a pas longtemps, je me suis un peu attardé à essayer de corriger des bugs de divers projets :
(1) Nautilus, ou plus exactement, libgnomeui : le système de génération de miniature (pour les images) utilisait +500 Mo pour générer une miniature d'une image vectorielle de 28 Ko. Mon patch est assez simple : je charge l'image en 128x128 plutôt qu'à sa taille originale (10000x10000 pour l'image vectorielle). Apparement, cela fonctionne aussi pour de grosses images PNG (7000x7000).
http://bugzilla.gnome.org/show_bug.cgi?id=307885(...)
Le soucis est que mon patch demande de casser l'API de libgnomeui. J'ai d'abord posté un bugreport pour gnome-session, puis librsvg, et enfin Nautilus. Mais en réalité c'était libgnomeui (et Nautilus?) qui est en cause. Aussi bien librsvg que Nautilus m'ont refoulé "arf, ton image est boguée, notre programme fonctionne normalement" ... Ils ont tous 2 Go de RAM les développeurs Gnome ???
(2) J'avais tenté un patch pour la librairie de jeu ClanLib il y a un an. J'ai largement amélioré le support de SDL dans ClanLib. Mon patch n'a jamais été intégré, et je me suis fait traité de gros connard ... Ca fait plaisir. J'ai passé environ 50h sur ce patch, et sûrement bien plus.
(3) Epsilon (librairie de chargement d'image pour Enlightenment) : j'ai corrigé un erreur de division par zéro que j'ai mis 3h à traquer. Mais mon patch est toujours en attente.
J'ai du oublié des patchs. Parfois, je m'y suis mal pris, mais n'empêche, c'est pas trop motivant ...
@+ Haypo
-
[^]Re: Mes contributions
Posté par Matthieu C () le 27/06/2005 à 20:02. (lien). Évalué à 3.pourtant en regardant http://sourceforge.net/mailarchive/forum.php?thread_id=5604252&(...) et http://sourceforge.net/mailarchive/forum.php?thread_id=5609927&(...)
le premier patch a ete applique et pour l'autre le developpeur semble avoir ses raisons.
Il faut comprendre que certains developpeurs sont sur des pb plus complexe et qu'ils n'ont pas forcement du temps a consacrer a ton patch, surtout s'ils touchent a la structure interne de l'appli.
Oui, c'est pas toujours facile de faire integrer ses patchs (moi aussi j'ai par exemple un truc pour mplayer qui traine depuis plus d'1 an).
Dans ces cas je me dis tant pis, j'ai reussi a faire que ca marche bien chez moi, s'ils le veulent pas en upstream tant pis.-
[^]Re: Mes contributions
Posté par Victor STINNER (page perso, ) le 28/06/2005 à 11:28. (lien). Évalué à 4.Oui, c'est ce que je disais : c'était en partie de ma faute. Les leçons que j'en ai retenu : il faut faire le patch le plus petit possible, et aussi dans la mesure du possible, ne pas toucher aux définitions des fonctions (encore plus quand il s'agit d'une API). Un gros patch est difficile à appliquer, et si en plus ça casse l'API, y'a peu de chance pour que le patch soit appliqué.
@+, Haypo
-
-
[^]Re: Mes contributions
Posté par Marc (Jabber id, page perso, ) le 27/06/2005 à 20:13. (lien). Évalué à 2.Je crois que l'auteur attendait plus qu'une liste de contributions... T'aurais au moins pu expliquer comment tu t'y prenais...
-
[^]Re: Mes contributions
Posté par Victor STINNER (page perso, ) le 28/06/2005 à 11:40. (lien). Évalué à 6.Comment je m'y prend ? Hum ... Y'a deux cas : signaler un bug, corriger un bug.
Signaler un bug consiste à donner le maximum d'informations pertinentes sur un bug et à envoyer le tout aux développeurs. Pour un plantage, il faut par exemple lancer l'application avec gdb, après copier/coller le résultat de la commande backtrace après plantage. Pour un bug qui ne plante pas, il faut expliquer pas à pas la démarche pour arriver au bug, et le comportement qu'on aurait désiré. Pour envoyer le bug, il faut voir le site web du programme. Gnome a son application dédiée. Chaque cas est différent donc.
Souvent, le bug est connu, est en cours de correction, ou alors déjà corrigé dans le CVS. C'est pour ça qu'il faut toujours commencer par signaler le bug.
Si c'est un nouveau bug, et qu'aucun développeur du projet ne s'y attarde, autant le corriger soit-même (on est jamais aussi bien servi que par soi-même :-D). Il faut commencer par télécharger la toute dernière version (surtout pas la dernière version stable qui comporte d'ancien bug déjà corrigé, ou une API désuette) : tarball, cvs, subversion, etc. (cf. le site web du projet) Ensuite, il faut compiler le projet, et vérifier que le bug existe toujours. Ben oui, rien ne sert de défoncer une porte ouverte avec un bazooka hein.
Si le bug existe toujours, il faut le traquer. Il vaut mieux connaître les commandes break et where de gdb, et avoir un peu d'expérience avec cet outil. Perso, je commence par laisser planter le programme et voir où je suis avec where (équivalent à backtrace au passage). Ensuite, je remonte à la source en posant un point d'arrêt sur la fonction ayant plantée et je relance le programme. Cette recherche est souvent longue et épuisante.
Une fois le bug cerné, 90% du boulot est fait :-D Il ne reste plus qu'à comprendre pourquoi ça plante, et corriger le bug. On recompile le programme. Si ça marche pas .... on recommence. Si ça passe, il FAUT envoyer son patch aux développeurs, sinon tout ce travail n'aura servi à rien. Au faut alors faire un diff -u ancien_fichier nouveau_fichier >~/mon.patch et l'envoyer par email. C'est pour ça qu'il vaut mieux faire un cp fichier fichier.old avant d'éditer n'importe quel fichier !
@+ Haypo-
[^]Re: Mes contributions
Posté par Victor STINNER (page perso, ) le 28/06/2005 à 12:38. (lien). Évalué à 1.Bon, je l'ai enfin écrit ce patch qui corrige le bug, sans pour autant casser l'API :
http://bugzilla.gnome.org/attachment.cgi?id=48444&action=view(...)
J'ai usé d'une astuce : j'ai écrit une nouvelle fonction plus élaborée, et l'ancienne fonction appelle la nouvelle avec les paramètres par défaut :
nouveau(filename, width, height);
ancien(filename) { nouveau(filename, -1, -1); }
Et voilà. En espérant que ça plaise aux développeurs Gnome ...
@+, Haypo
-
-
-
[^]Re: Mes contributions
-
[^]réponses
Posté par Vivi (page perso, ) le 27/06/2005 à 21:24. (lien). Évalué à 5.(pour le patch gnome)
- déjà ton ticket dans bugzilla date de 2 semaines, ça va ... laisse leur le temps
- ton anglais est trés approximatif, ça n'aide pas
- ensuite si tu veux proposer un patch, ben attache un patch ! et pas un mélange de texte et de "changez ça en ça, et plus loin remplacez ça par ça en ayant fait toutes les autres modifications qui s'imposent" (sans spécifier de quel fichier il s'agit)
- quand tu termines par "j'ai bricolé ça, ça a l'air de marcher mais j'suis pas trop sûr", ça n'incite pas à intégrer ton code direct
- de toutes façons, tu ne peux pas modifier l'API publique donc il faudra trouver autre chose.-
[^]Re: réponses
Posté par Victor STINNER (page perso, ) le 28/06/2005 à 11:31. (lien). Évalué à 1.Au début, je ne voulais que signaler le bug. Mais comme ils m'ont refoulés, ça m'a donné envie d'aller plus loin. J'ai donc isolé très précisément le problème, et j'ai cherché une solution.
Le but n'était pas de faire un patch, car je ne sais pas comment fonctionne Gnome dans son ensemble, mais plutôt de montrer la voie à suivre.
Bon, si j'ai le temps, je vais me coltiner un patch propre (genre qui ne casse pas l'API par exemple :-)).
@+, Haypo
-
Compliquer d'envoyer un patch ?
Noooon,
Tu fais le patch (si j'ai bien compris ce n'est pas ça qui pose problème) et tu l'envoie au responsable du projet :-)
Perso, j'ai contribué une fois pour X11, une petite connerie de rien du tout sur la vitesse du port sérier pour les tablettes graphiques, j'ai envoyé le mail et j'ai jamais eu de nouvelle (je me suis pas inquiété, c'est un gros projet, et puis chez moi ça marchait) et j'ai eu l'heureuse surprise de voir le patch intégré aux versions suivantes... Cool...
Si tu commences à contribuer des modifications / corrections plus importantes, n'oublie pas de lire la documentation livrée avec le projet. On y trouve souvent des informations sur les standards de codage a respecter... Si tes modifs ne les respectent pas, il y a peu de chance, vu le nombre de requete que les responsables ont a traiter sur ce genre de projet, que ton patch soit intégré !
a+
-
[^]Re: Compliquer d'envoyer un patch ?
Posté par dab () le 27/06/2005 à 21:06. (lien). Évalué à 5.j'ai envoyé le mail et j'ai jamais eu de nouvelle (je me suis pas inquiété
En même temps, ça ne fait jamais de mal d'avoir ne serait ce qu'un petit mail te prévenant de la prise en compte de ton patch, ça fait toujours plaisir, ça te fait dire que vivre le libre, belle communauté.-
[^]Re: Compliquer d'envoyer un patch ?
Posté par free2.org (page perso, ) le 28/06/2005 à 05:36. (lien). Évalué à 2.je crois qu'il faut aussi se mettre à la place de certains bénévoles qui sont débordés par les mails et/ou patchs qu'ils recoivent... d'ailleurs tu peux toujours te proposer pour les aider à répondre à leur courrier, ça peux les intéresser
-
[^]Re: Compliquer d'envoyer un patch ?
Posté par Philippe Fremy (page perso, ) le 28/06/2005 à 11:33. (lien). Évalué à 2.x11 est particulierement connu pour etre non reactifs. Des patchs important (corrigeant des bugs genatnts) proposes par des developpeurs KDE n'ont jamais ete integres, sans aucune raison. La situation devrait s'ameliorer avec Xorg
-
[^]Re: Compliquer d'envoyer un patch ?
Posté par Ph Husson (page perso, ) le 29/06/2005 à 14:11. (lien). Évalué à 2.X11R7 je dirais même!
(Dont le changement majeur c'est de devenir plus modulaire pour rappel)
-
-
-
contribuer à un gros projet
Le problème, c'est que, il me semble, tous les gros projets doivent avoir le même problème. Comme tous les projets du libre tendent à devenir gros (je pense à Firefox, OO.org, Evolution, ou des projets largement utilisés comme ça), je pense qu'il faudrait sérieusement réfléchir à des moyens de pas rebuter les contributeurs non-régulier de tels projets.
Euh, ce serait bien de ne pas généraliser ! Ce n'est pas parce qu'avec struts tu as eu des problèmes qu'il faut croire que, tous les gros projets ont ces problèmes .
(et puis bon, entre nous, struts, est *vraiment* un petit projet par rapport à Firefox ou OO.org... en terme de nombre de ligne de code, il est loin d'être dans la catégorie poid lourd, crois moi)
Conçernant Mozilla, ils ont réflechi à des moyens de ne pas rebuter les contributeurs, mais ce n'est finalement pas évident du tout. Pour "faciliter" les contributions ils ont développé bugzilla.
Alors certes, certains se plaignent que c'est compliqué, que recuperer les sources de Firefox et compiler, c'est compliqué, etc.. Mais c'est, je dirais, à la hauteur de la complexité d'un tel projet. Il est clair qu'il faut faire un gros effort au début, ne pas hésiter à lire les docs. Il faut aussi bien rechercher si le bug en question n'est pas déjà référencé, ou même corrigé.
Le plus dur en fait, le plus rébutant, c'est de s'immerger dans un tel projet, avec l'apprentissage des technos, des coding practice etc... Ça prend des mois (pour Mozilla/Firefox). Alors c'est sûr que dans ces conditions, ce n'est pas le developpeur lambda débarquant dans le projet qui va pouvoir pondre un patch en 2 jours. Plus c'est gros, plus c'est difficile (surtout pour un truc aussi complexe comme le moteur d'un browser). Le meilleur bugzilla-like du monde ne pourra rien y changer à ce niveau là.
Et donc, les contributeurs occasionnels n'existent pas vraiment sur de gros projets comme Mozilla. Il y a des rapporteurs de bug occasionnel, mais les "patcheurs" occasionnels sont trés rares.
-
[^]Re: contribuer à un gros projet
Posté par Jean Parpaillon (Jabber id, page perso, ) le 29/06/2005 à 09:15. (lien). Évalué à 2.Je ne me plaint ni ne blâme personne. J'essaye de réfléchir à des techniques qui peuvent résoudre ce genre de problème. Parmi des solutions déjà trouvée, citons :
- bugzilla
- modularisation plus importante (cf. le projet de Xorg de modulariser X), mais ça relève plus des bonnes pratiques que d'innovations
- Maven : utilisé pour Struts, je trouve que cet outil aide plus à la création d'un projet que pour les contributeurs. AMHA, ça vient du fait qu'un outil "intelligent" a beaucoup trop de comportements "implicites". C'est une autre histoire...
- Intégration d'un projet à un IDE, pour les normes de codage, notamment.
Pour moi, ce qui a vraiment posé problème avec Struts, c'est
1 - la mauvaise gestion des branches : des branches servent à maintenir des versions anciennes et d'autres servent pour les prochaines releases. On ne sait donc pas trop sur laquelle travailler. Ils en sont conscients, ils y travaillent...
2 - la mauvaise modularisation. Pour les releases, ont a un seul jar. Pour développer il faut créer plusieurs jar pour pouvoir travailler sur une partie et ne pas tout reconstruire à chaque fois. Mais du coup, le projet n'a pas la même architecture quand on développe et quand on release. Encore une fois, ça devrait évoluer.
[+] L'avenir des langages compilés pour les gros projets
Je me pose des questions sur l'avenir des gros logiciels programmés en langages compilés.
Les avantages des langages interprétés :
Le codage d'une fonction, nécéssite souvent moins de code dans un langage interprété que dans un langage compilé.
Le programme est plus donc facile à lire et à comprendre pour un néophyte.
La puissance des ordinateurs ne cessant d'augmenter, la lenteur des langages interpretés devient un mythe (*)
Les traitements devant être rapides peuvent être implémentés dans un langage de bas niveau.
De plus, les langages interprétés modernes tendent à être de plus en plus efficaces, ruby, perl, python, etc...
La majeure partie de temps, une application moderne affiche des IHM. Ce qui se code très bien en langage interprété.
La visualisation d'une modification est immédiate.
Pas de problème de compilation, d'édition de liens, etc...
Beaucoup de problèmes de bas niveau sont gérés par le langage : transtypage, gestion de mémoire, structures de données complexes, portabilité, etc...
Tout ceci évite une grosse partie des bugs : le(s) développeur(s) peuv(ent) donc se concentrer sur les fonctionalités du programme en lui même.
La maintenance d'une petite librairie, écrite dans un langage compilé, par exemple C/C++ est plus facile.
La segmentation de ses librairies est intrinsèque, ce qui diminue les effets de bords.
Un jour, les applications contiendront une entrée de menu 'Passer en mode développeur'.
On pourra rajouter des entrées de menu, des fenêtres, des boutons, puis associer du code en ruby, par exemple.
En mode développeur, cliquer sur un bouton affichera le code associé, avec la possibilité de le modifier.
Ainsi, chacun aura des applications ultra personalisées sur son Ordinateur.
Il y aura également une entrée de menu soumettre les modifications.
Chaque modification sera nomée, décrite, et envoyée sur un site internet, fans le style des extensions pour mozilla.
Là, elle sera testée et notée par des utilisateurs, et les meilleures seront intégrées dans la prochaine version.
@:@
(* Attention, si vous programmez comme un porc, il est vrai que vos programmes en python vont ramer, et qu'ils seront rapides en C/C++.)
-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par kra () le 28/06/2005 à 07:18. (lien). Évalué à 1.Le codage d'une fonction, nécéssite souvent moins de code dans un langage interprété que dans un langage compilé.
heuuu la je veux bien que tu m'expliques, je vois pas trop le lien interprete/pas beaucoup de code..-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par André Rodier (page perso, ) le 28/06/2005 à 07:36. (lien). Évalué à 1.Les exemples les plus pertinents sont les fonctions de manipulation de chaine de caractère en Perl et en C, ainsi que les structures de données complexes ( tables de hachage, arbres, tableaux associatifs, etc...)
-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par kra () le 28/06/2005 à 08:10. (lien). Évalué à 2.ok, comme l'indique le message suivant le mien, tu confond langage de haut niveau et langage interprete.
un langage comme java propose a peu pres tout ce que tu attribues aux langages interpretes. Tout comme caml, comme le souligne bien le message suivant le mien.
c'est sur que le C n'est pas franchement ce que j'appelle un langage d'avenir..-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton (Jabber id, page perso, ) le 28/06/2005 à 08:53. (lien). Évalué à 2.Excusez un béotien en programmation, mais je comprends de moins en moins l'apologie faite autour des langages de haut niveau. En quoi C n'est-il pas un langage d'avenir ? Pour moi, ça reste, et ça restera encore pas mal de temps le langage de base. Il y a surement plus adapté dans certains cas, mais je sais que si j'avais un projet de développement, j'utiliserais certainement le C/C++. Peut-être dis-je ça parce que ce sont les langages qui m'ont appris la programmation (avec le pascal).
-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (page perso, ) le 28/06/2005 à 09:00. (lien). Évalué à 4.En quoi C n'est-il pas un langage d'avenir ?
Le C n'est pas un langage d'avenir dans les problèmes purement logiciel. Avant (et encore aujourd'hui) le C/C++ était utilisé à tous les niveaux d'une application, des plus petits problèmes techniques du système jusqu'au modèle métier ou l'interface graphique.
Le langage C offre trop de liberté et pas assez de sécurité. Hors la plupart des applications actuelles tendent naturellement à être beaucoup plus conséquentes que leurs ainées, il est impératif de fournir une partie du "travail" aux machines, si on veut garder une certaine productivité : gestion de la mémoire, absence de scalpel (pointeur), intégration des notions de programmation objet (C++ comble "en partie" ce point), etc.
Le langage C restera un langage d'avenir (ama) pour les bibliothèques systèmes, les routines techniques qui doivent être optimisées ou qui doivent manipuler "manuellement" la mémoire, mais pour le reste le langage C n'a aucun atout.-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton (Jabber id, page perso, ) le 28/06/2005 à 09:16. (lien). Évalué à 2.Pour les très gros projets, je peux comprendre que C ne soit pas le langage adapté. Cependant, la quasi-totalité des outils que j'utilise personnellement ne sont pas des gros projets. Prenons coreutils que j'ai étudié le week end dernier pour me remettre au C. Des outils comme echo, cut, mkdir n'a aucune raison d'être dans un langage autre que C. Si on regarde des projets plus conséquents, comme rox-filer, C++ est tout à fait adapté. La conséquence, c'est un code maintenable et une optimisation non négligeable.
Maintenant, si on regarde anjuta2 versus eclipse, la différence est flagrante. Sur mon P3 1ghz 256Mo, il faut environ une minute pour lancer eclipse. L'intégralité de mon système rame profondemment et il devient impossible de bosser. Anjuta2 par contre parait d'une légèreté impressionnante. Bref, j'aime bien utiliser des outils développés en C, et ils ne sont généralement pas plus plantogènes que ceux développés en Java/python/etc...-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par kra () le 28/06/2005 à 09:18. (lien). Évalué à 1.c++ est un langage de haut niveau... :)
bon, ca manque de reflexivite ce genre de chose, mais ca permet deja de s'abstraire de pas mal de choses.-
[^]Re: L'avenir des langages compilés pour les gros projets
-
-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (page perso, ) le 28/06/2005 à 09:30. (lien). Évalué à 2.. Cependant, la quasi-totalité des outils que j'utilise personnellement ne sont pas des gros projets.
Oué mais justement c'est ce que j'expliquais : à l'avenir les nouveaux projets vont avoir tendances à être de "gros" projets, car ils doivent apporter de la valeur ajoutée par rapport à l'existant, et inévitablement la taille du code va augmenter.
La conséquence, c'est un code maintenable et une optimisation non négligeable.
Le C++ c'est du C bidouillé pour faire de l'objet. Les templates sont affreux, il n'y a pas de notion d'interface, et on n'a aucune possibilité de reflexivité (pas directement intégré dans la programmation objet, mais souvent utilisée conjointement). Pour une application comme Rox-Filler qui n'est qu'un front-end pour des outils de décompression, un langage de haut niveau "moderne" est beaucoup plus adapté : les mêmes avantages que C++ (programmation objet), mais sans les problème liés à la sécurité et donc indirectement à la qualité (je dis pas qu'on peut pas obtenir la même qualité, mais la productivité va s'en ressentir).
si on regarde anjuta2 versus eclipse, la différence est flagrante. Sur mon P3 1ghz 256Mo, il faut environ une minute pour lancer eclipse. L'intégralité de mon système rame profondemment et il devient impossible de bosser. Anjuta2 par contre parait d'une légèreté impressionnante.
Peut être parcque Anjuta fait pas la moitié du taf que fait Eclipse. Anjuta il te surligne en temps réelles les erreurs ? Visual Studio qui est lui aussi codé en C++ a pris un peu d'"embonpoint" lorsqu'il a intégré toutes ses "vérifications" et "aides" à la programmation.
ils ne sont généralement pas plus plantogènes que ceux développés en Java/python/etc...
Effectivement, mais l'effort qui a été mis derrière n'est pas du tout le même. Si dans les entreprises le buzz c'est C#/Java & Co c'est pas pour rien : c'est pour la productivité. Si après pour toi il faut continuer à perdre du temps en gérant la mémoire à la main, vérifier tous les pointeurs, etc. c'est toi qui voit.
Il faut un an pour être un "expert" en Java. Il faut de 3 à 5 ans pour l'être en C++. Il n'y a pas que des gurus sur terre.-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par lezardbreton (Jabber id, page perso, ) le 28/06/2005 à 09:37. (lien). Évalué à 1.Effectivement, mais l'effort qui a été mis derrière n'est pas du tout le même. Si dans les entreprises le buzz c'est C#/Java & Co c'est pas pour rien : c'est pour la productivité.
Ca me fait doucement rigoler, ça... Je te sens un peu naïf sur ce coup là :)
Il faut un an pour être un "expert" en Java. Il faut de 3 à 5 ans pour l'être en C++. Il n'y a pas que des gurus sur terre.
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage. Java, tu es obligé de réapprendre constamment, de te tenir au courant des nouveautés des différentes versions, etc... Bon, je suis un peu de mauvaise foi, mais toi aussi, il faut plus d'un an pour être expert Java :)-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (page perso, ) le 28/06/2005 à 09:48. (lien). Évalué à 3.Ca me fait doucement rigoler, ça... Je te sens un peu naïf sur ce coup là :)
?
C++, tu es garantie d'en avoir pour encore au moins 20 ans, vu la stabilité du langage.
Oué bah oué, et ? C'est pas pour autant qu'il a de l'avenir :) Sa mort sera lente ca c'est sûr. Autant je crois que le C a de l'avenir dans certains domaines, autant le C++ n'en a pas beaucoup à mon goût.
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
. Java, tu es obligé de réapprendre constamment
Gni ? Ce qui change c'est les API, ils évoluent, et ils faut effectivement se "tenir au courant". Mais en C++ tu n'utilises aucun API toi ?
il faut plus d'un an pour être expert Java :)
Pour être expert dans le langage si. Après pour les API c'est une autre histoire, mais c'est le même problème dans tous les langages.-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par Marc (Jabber id, page perso, ) le 28/06/2005 à 11:23. (lien). Évalué à 3.Oué bah oué, et ? C'est pas pour autant qu'il a de l'avenir :) Sa mort sera lente ca c'est sûr. Autant je crois que le C a de l'avenir dans certains domaines, autant le C++ n'en a pas beaucoup à mon goût.
Chez moi, un truc qui dure longtemps, c'est qu'il dure non ? S'il met 20 ans à mourir, c'est bien qu'il était fait pour durer :)
Et puis bon la stabilité du C++ mdr quoi :) Ca date de quand les dernières spécif déjà ? Y'a combien de compilateur capable de gérer toutes les spec parfaitement ?
Certe, java 5.0 date de y'a pas très longtemps... Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
En prenant un exemple simple comme le developpement de linux sur PDA (familiar linux), on voit effectivement que bcp de monde cherche à utiliser java. Le problème, c'est que parmis toutes les jvm qui existent très peu s'en sortent dès que tu sors des "hello world" en console/awt (swing semble avoir qqs probs). GNU Classpath avance, mais c'est pas encore le pied. Pour les compilateurs...euh :)
Et gcj, même s'il avance, reste un peu en retard.
Donc malgré le fait qu'aucun compilo c++ ne respecte pas à 100% les specs du langage, c++ garde un bon avantage (tout comme C)...
Ensuite, si tu pousses un peu, tu vois que python n'est pas non plus super d'un point de vue efficacité sur ce genre de plateforme, et je ne parle pas de chose système/bas niveau là...-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par kra () le 28/06/2005 à 11:34. (lien). Évalué à 1.Chez moi, un truc qui dure longtemps, c'est qu'il dure non ? S'il met 20 ans à mourir, c'est bien qu'il était fait pour durer :)
tu veux dire comme le cobol par exemple? :)
Certe, java 5.0 date de y'a pas très longtemps... Combien de compilateur/jvm sont capables de gérer totalement les specs (même 1.4.2) ? Sur combien de plateformes ?
ben au moins deux pour 1.4 (sun et ibm), j'ai envie de dire 3 meme (blackdown) et l'implementation de sun pour 1.5..
pour les plateformes, sun supporte quand meme un grand nombre d'archi/os differents (manquerait plus que ca, avec leur compile once run everywhere)..
-
[^]Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (page perso, ) le 28/06/2005 à 11:43. (lien). Évalué à 2.S'il met 20 ans à mourir, c'est bien qu'il était fait pour durer :)
Oué mais c'e
-
-
-
-
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.