Il y a une discussion intéressante sur la liste de développement de LLVM ce mois-ci, partie du constat que les temps de compilation de LLVM augmentent au fil du temps—avec l'évolution du code. En particulier j'ai trouvé ce message de Daniel Berlin très intéressant: il parle du rapport entre les compilateurs industriels et la recherche en compilation, et de l'effet que ça peut avoir sur la maintenabilité du code. Traduction à la rache (le début est la citation d'un autre message):
Sean Silva a écrit:
Un truc qui m'a frappé en me promenant dans les sources de GCC est qu'il semble utiliser des algorithmes bien plus sophistiqués (par exemple beaucoup de fichiers ont des commentaires au début citant des articles de recherche et tout; compter les citations ne veut pas dire grand chose, mais c'est une approximation du fait de se tenir au courant de littérature scientifique). Dans LLVM, j'ai l'impression que la plupart des choses sont faites maison, ou en tout cas pas reprises très souvent pour utiliser un algorithme plus récent. Et une fois qu'on a accumulé un tas de petits cas particuliers, ça devient de plus en plus difficile de remplacer le code par une meilleure approche, parce que personne ne voudra jeter les vieux trucs tant que la nouvelle approche ne couvre pas au moins tous ces cas.
C'est précisément ce qui s'est passé avec la passe de Global Value Numbering (et qui se passe avec d'autres choses comme InstrCombine, LVI, BasicAA…). Toutes ces passes ont commencé avec un rôle clairement défini et une certaine durée de vie prévue. Elles avaient du sens pour ces usages. Et puis les gens les ont poussés au-delà de leurs usages initiaux, mais sans les reconcevoir ou les repenser. Très vite on se retrouve avec du désordre qu'il est très difficile de nettoyer pour les raisons que tu dis—en pratique, il faut découper les analyses ou les passes en plusieurs morceaux, et accepter qu'on ne peut pas et ne doit pas essayer de tout gérer en une seule passe.
Heureusement, il y a des entreprises et des gens dans notre communauté qui peuvent trouver le temps de travailler sur la "dette technique" (technical debt) au lieu de juste améliorer les performances, mais à mon avis on est toujours trop en faveur de la performance quel que soit le coût. Ça arrive à tous les compilateurs, bien sûr, pas juste à LLVM.
Sur la question de pourquoi GCC utilise plus la littérature scientifique, voici encore mon avis. GCC a plus de parties du code avec des mainteneurs/propriétaires attitrés que LLVM, ce qui a l'avantage qu'il y a quelqu'un qui réfléchit vraiment à ces choses et a un avis sur là où cette partie du code devrait aller. Les maintenurs peuvent diriger le développement, s'assurer que ça va dans la bonne direction. L'inconvénient bien sûr c'est que ça ajoute de la bureaucracie (mais LLVM a aussi de la bureaucracie je trouve, elle est juste mieux cachée), et parfoit un peu moins d'innovation (ça varie). Ça veut dire aussi que les gens ne doivent pas le voire comme un simple titre, quand ils passent à autre chose où s'en déintéressent il faut réassigner le code à quelqu'un d'autre. L'autre inconvénient c'est que souvent ces personnes se retrouvent à dire "non, on ne va pas faire comme ça, il faut plutôt faire comme ça", et ça ne plaît à personne quand la personne en face essaie juste de faire intégrer un changement qu'on lui a demandé de faire.
La seule chose que ces approches changent, en fin de compte, c'est la durée de vie du résultat final. Ça ne veut pas dire qu'on obtient quelque chose de parfait, mais on peut avoir un truc qui va bien marcher pour 10 ans, au lieu de bien marcher pour 5 ans seulement. Ça peut être ou ne pas être le bon choix, ça dépend de ce qu'on fait (ça ne sert à rien de passer 6 mois à concevoir un truc qui ne va pas être utilisé plus de 6 mois).
Enfin je ne veux pas dire, bien sûr, que le fait-maison est forcément mauvais. Mais le faire bien demande au moins d'avoir assez bien lu et compris la théorie sur le sujet, pour comprendre comment bien faire son propre truc, ou alors faire un truc si petit que ça n'a pas d'importance.
Personellement j'ai appris les compilateurs et l'optimisation dans un environnement où j'étais entouré de gens qui avaient en gros déjà tout fait avant, et donc j'ai appris à aller chasser pour voir quel est l'état de l'art sur un sujet, et les aspects théoriques derrière, avant de faire du fait-maison. Ça ne veut pas dire que cet état de l'art était toujours bon, raisonnable, ou même implémentable, mais au moins on y pensait, et souvent, même quand les articles étaient complètement dans les nuages, ils avaient des idées et des approches qu'on a pu réutiliser.
Que retirer de ce message ? Pas mal de choses. Que LLVM commence à prendre de l'age et que les gens ont du mal à maintenir certaines parties du code. Que GCC a su bien faire des choses dans son développement que les développeurs LLVM savent admirer. Que les articles de recherche, c'est parfois utile. Que les mainteneurs grincheux peuvent améliorer le résultat final mais aussi introduire un peu de friction dans le développement. Que les mailing-list où on écrit des messages détaillés, c'est toujours intéressant.
# Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je sais que c'est dans l'air du temps de discuter des "mainteneurs grincheux", alors je vais prendre un peu le contre-pieds, en étant régulièrement justement du côté "mainteneur" (ou "reviewer" de code, ce qui peut souvent être vu similairement pas un contributeur) de la barrière.
La partie du message à laquelle — j'imagine — tu fais référence en parlant de mainteneur grincheux qui introduit de la friction dans le développement, est:
Moi quand j'ai lu cette phrase, je n'ai pas du tout interprété ça comme toi, mais plutôt qu'y a beaucoup de contributeurs qui ne veulent pas se faire chier, ni même forcément faire du bon code, et surtout pas interagir avec l'équipe et collaborer. Donc de leur point de vue, tout se passe bien si on leur dit "c'est génial, on intègre", mais dès qu'y a un peu de revue détaillée et qu'on leur demande de changer leur code pour intégration, y a plus personne au bout de la ligne (ou du mécontentement).
Daniel Berlin parle des gens à qui on a assigné une tâche (donc typiquement des gens qui contribuent essentiellement parce qu'ils sont payés pour le faire; notons que ça ne signifie pas toujours qu'ils aiment l'idée du Libre, ou de l'OpenSource, plus que ça). Mais il y a d'autres cas. On voit souvent des gens qui font vraiment du lâchage de patch, mais dès qu'on répond avec une revue de code (pas méchante, polie et amicale, mais on leur demande de changer des trucs), on n'a pas de réponse. Bien sûr, ça peut aussi être des problèmes de manque de temps (ça m'arrive moi-même régulièrement de laisser passer des mois avant de revenir sur un patch car j'avais d'autres priorités). Des fois aussi, les jeunes, étudiants ou développeurs moins expérimentés ont beaucoup de mal à corriger leur patch en suivant les indications donnés, etc. Y a plein de raisons possibles.
Pourquoi leur demande-t-on de corriger leur patch? Certains (beaucoup même, j'ai l'impression) projets ont cette tendance à intégrer tout et n'importe quoi. Parfois ils corrigeront après coup, dans un nouveau commit, parfois même pas, alors que le patch de base a clairement des manques, ne suit pas le style du projet, etc. Je pense que l'envie d'avoir de nouveaux contributeurs pour certains mainteneurs surpasse l'envie d'avoir du code de haute qualité. Surtout pour les plus petits projets.
Dans GIMP, on a tendance à demander un haut niveau de qualité pour un patch. Déjà qualité du code même, mais aussi le respect de l'architecture du logiciel (on ne peut pas inclure des headers de n'importe quelle partie du code vers n'importe quel autre partie. Par exemple le
corede GIMP n'a aucune notion de GUI, etc.), ou même le style de code. C'est la base: si je contribue sur un projet tiers, je regarde toujours quel est leur style (tabulations, espaces, accolades en début ou fin de ligne?…). On s'en fiche quel style j'aime personnellement quand je contribue. J'impose mon style seulement sur mes projets persos.Alors bien sûr, c'est un choix et les 2 se défendent: vaut-il mieux tout intégrer et faire plaisir aux contributeurs (quitte à prendre beaucoup de temps après coup pour tout nettoyer derrière) ou demander un haut niveau d'entrée et risquer de perdre des contributeurs (en se faisant appeler "grincheux")? Ce que j'ai tendance à penser sur le sujet:
beaucoup de petits patchs seraient bien plus vite et bien mieux écrits si on les faisaient nous-même que si on en fait la revue et le commentaire. Alors pourquoi le fait-on? Parce qu'avoir des contributeurs est important et qu'on "utilise" du temps maintenant mais pour potentiellement en gagner beaucoup plus tard si certains contributeurs décident de rester dans le coin, et pourquoi pas devenir des contributeurs majeurs. C'est donc un investissement de temps sur le long terme.
Alors d'un certain point de vue, vaut-il mieux faire plaisir à un max de ces petits contributeur au cas où on a notre futur contributeur majeur dans le lot? D'un autre côté, si on ne l'a pas habitué à faire de la qualité dès le début, à quoi s'attend-t-on pour la suite? Veut-on vraiment de quelqu'un qui n'est pas capable de suivre un style donné, de revenir sur son code, d'écouter des critiques constructives, de lire et comprendre des revues de code et réorganiser le sien? Peut-être que cela est bien plus rentable sur le long terme. Après tout, comme je le disais, intégrer les petits patchs peut vraiment prendre un temps fou, donc autant que ce temps soit utilisé à bon escient pour le futur du programme. Parfois même, le patch en soi est moins important que la relation qui peut se construire avec le contributeur.
on essaie d'avoir un code toujours stable sur master, même s'il est expérimental. Il ne faut pas intégrer un commit qui ne compile pas, ou va faire crasher le programme, ou autre mauvais "comportement". Intégrer un patch qu'on sait ne pas être parfait est donc une mauvaise idée. Évidemment on peut rétorquer que si on fait immédiatement un commit de correction derrière le patch du contributeur et on
pusheles 2 en même temps, alors on a un changement atomique (quelqu'un quifetchele dépôt aura les 2 commits d'un coup), mais cela reste non-idéal.Une autre possibilité peut être de corriger direct le commit du contributeur (
--amend). On le fait souvent d'ailleurs, surtout quand les seuls changements sont des problèmes de style de code. Parfois aussi pour des changements plus importants, voire parfois on fait du gros élagage. Mais on laisse le nom du contributeur en tant qu'auteur du commit. Y a la question alors: jusqu'à quel niveau de changement peut-on toujours considérer ce contributeur comme auteur du commit? C'est pour ça que je rechigne à faire trop souvent cela personnellement, hormis pour des changements vraiment mineurs, et fait plutôt des commits juste après. Mais idéalement on préférerait que les contributeurs nous fassent un patch parfait qu'on n'aura pas à corriger. Et pour cela, ils doivent simplement suivre nos indications de revue de code.Ensuite il y a les choix de design de l'application. On ne peut pas accepter tout et n'importe quoi. Et beaucoup de contributeurs semblent penser que changer un "petit" (d'après eux) truc n'a pas besoin d'être discuté. Déjà beaucoup de choses ne sont pas si "petites" même si un contributeur va essayer de vous en convaincre (or s'il est si attaché à voir ce patch intégré, c'est justement que le changement n'est pas si petit à ses yeux). Ensuite chaque fonctionnalité a son fan-club. Même si on se rend compte qu'une fonctionnalité est fondamentalement mauvaise, il y aura toujours quelqu'un pour l'apprécier. Et ça veut dire qu'une fois acceptée, elle sera très dure à retirer plus tard sans se prendre des plaintes et des menaces. En gros quoiqu'on fasse (garder, retirer, changer…), y a toujours quelqu'un pour ne pas être content et le faire savoir, souvent de façon virulente.
Ça signifie donc qu'il vaut bien mieux bien réfléchir sur chaque changement de fonctionnalité et chaque nouvel ajout, avant de l'accepter. Pas se dire "on pourra toujours revenir sur la décision plus tard". Car ce n'est pas similaire. Dans un cas, il ne se passe rien; dans l'autre on se prend des coups quoiqu'on fasse. Il est donc tout naturel de calmer les ardeurs et de réfléchir posément les nouvelles fonctionnalités, non seulement sur leur qualité intrinsèque, mais aussi sur le choix d'implémentation. Et donc oui, des fois, ça en revient à dire "non on va pas faire ça, on va faire ça à la place" (ce qui n'est pas un refus, mais une alternative ou différente implémentation — souvent pour des raisons qualitatives du code, donc maintenabilité — pour un comportement final similaire). Et oui, des fois, ça plaît pas forcément.
Mais ça veut pas forcément dire qu'on est grincheux. :P
Perso j'essaie d'être toujours le plus agréable et ouvert possible aux nouvelles idées. Mais ça veut pas dire que je dois laisser mon esprit critique au vestiaire et me passer de prendre des décisions finales quand il le faut. C'est pas facile tous les jours, d'ailleurs. Ensuite, soyons clair: globalement cela se passe bien et la plupart des contributeurs le prennent bien. Mais il arrive des couacs par moment.
En tous cas c'est assez marrant de voir que selon les personnes et leur niveau d'implication dans des projets, à quel point on a un niveau de lecture différent de la même phrase. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par barmic . Évalué à 5.
Oui mais pas de la même phrase. Pour moi grincheux était juste pour dire que c'est la personne qui dit souvent non. Comme on parle des dictateurs sur les projets pour des gens qui ont juste une vision de là où doit aller le développement. Rien de péjoratif là dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mainteneurs grincheux
Posté par gasche . Évalué à 9.
Je suis parfois du côté du mainteneur et je suis d'accord avec ce que tu dis. La différence principale est sans doute, comme le fait remarquer, la valeur que l'on attache au mot "grincheux"—chez moi il y avait un effet non-sérieux voulu mais ce n'était pas vraiment péjoratif.
Merci d'avoir développé autant, je suis sûr que ça va intéresser des gens. Quelques compléments:
Tu dis "les deux se défendent" comme s'il y avait deux positions discrètes, le tout-va et le toujours-nickel. En pratique il y a un continuum et on peut être "plus souple" ou "plus strict" sans passer d'un extrême à l'autre.
Tu ne parles que des "bons cas" dans les deux scénarios. Il y aussi les cas où ça ne se passe pas bien. Par exemple, parfois le mainteneur n'est pas satisfait avec un patch, mais il ne sait pas exactement expliquer pourquoi ou ne sait même pas quelle est la meilleure approche, il n'a pas envie de demander au contributeur de faire ce travail de recherche mais il n'a pas le temps de le faire lui-même non plus, et donc il évite le problème, ne dit rien, et le patch stagne. Dans les conflits dont on entend parler où un mainteneur bloque un projet, c'est souvent ce genre de problèmes à la base, où les gens s'accrochent à une notion de qualité qui a l'effet de geler le projet. C'est très facile de tomber dans ce travers là, ça m'est arrivé à moi aussi, et je pense que que c'est important d'en être conscient.
Je me suis posé aussi la question de quand rebaser de mon côté pour faire les petits correctifs mineurs qui ont du sens pour moi mais pas forcément pour les contributeurs non fréquents. À ma surprise à l'époque, les contributeurs m'ont demandé d'arrêter: ils n'aiment pas qu'on modifie leurs patchs "derrière eux" parce qu'ils ont vraiment envie d'apprendre comment faire le patch parfait et ils préfèrent donc que je leur explique les changements à faire. Maintenant je ne le fais que très très rarement.
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 21 décembre 2016 à 18:07.
Bien sûr. Mais comme c'est une histoire de philosophie de maintenance, on rencontre souvent les extrêmes.
C'est marrant (et j'imagine, le hasard) car justement le journal qui te suit parle de cela, mais de l'autre point de vue.
Pieter Hintjens est un développeur récemment décédé et ce serait sa pensée qu'il explique dans des articles:
C'est vraiment à l'inverse de ce qu'on fait dans un logiciel qui va contrôler plus sérieusement les patchs. Même s'il y a aussi un entre-deux possible, ici on voit plus des philosophies opposées. C'est pour ça que je fais ce genre de séparation (même si tu as raison). Ensuite je comprends bien ce point de vue laxiste aussi et je pense qu'il marche mieux pour les plus petits projets (petit notamment en nombre de lignes/fichiers). Pourquoi? Parce qu'un peu de bordel est acceptable dans ce cas. Ça reste lisible. Pour lancer un projet, c'est sûrement idéal même d'être très laxiste sur la revue de patch. Je n'étais pas là à l'époque, mais je suis sûr que ça a dû être le cas au début de GIMP aussi.
De nos jours, GIMP est un projet gigantesque en terme de fichiers, lignes de code, et fonctionnalité. Et pourtant il est globalement extrêmement bien organisé. L'architecture sépare bien les diverses parties du code (le "core" fonctionnel, les actions, la peinture, la gestion de fichier, les opérations graphiques, le GUI… et bien plus de sous-séparations encore). Le style de code est plutôt bien respecté partout (rendant le code très lisible). Etc.
Si on se mettait à accepter un patch qui casse nos diverses règles juste parce qu'il "marche", je pense que ce serait le début de la fin et qu'au bout d'un an, le code ne serait plus aussi maintenable.
C'est pas parfait mais c'est une base de code étonnamment bonne pour un projet de 21 ans. En fait je me rends compte que pas mal de gros projets sur lesquels j'ai contribué ont des bases globalement saines, alors que beaucoup de petits projets sont des bordels sans nom. Cela correspondrait donc à mon intuition comme quoi le laxisme du réviseur de code est probablement une bonne méthode pour les projets naissants, mais pas forcément autant pour les gros projets.
C'est vrai, ça arrive très souvent, surtout quand y a peu de développeurs. Et là aussi GIMP est un parfait exemple car nous sommes trop peu. Je ne crois pas qu'il y ait de vraie solution, et en particulier, je doute que transiger sur la qualité soit vraiment la solution. Comme je le disais, ce serait le meilleur moyen de bousiller le projet en rendant son code non-maintenable à moyen terme. On en accepte 1, puis 2, puis 10, puis 100. Et voilà, la base de code est flinguée.
Le second problème est les problématiques de design d'UI. Beaucoup de patchs bloquent sur les choix UI car les utilisateurs et contributeurs ont tous ce "petit quelque chose qui va rendre GIMP 1000 fois mieux!", disent-ils. Bien sûr, ils ne voient que leur utilisation, et parfois même pas forcément une utilisation habituelle. Genre ils basent leur patch sur leur expérience d'un projet où ils ont dû faire une tâche assez répétitive et ils se sont alors dit que si y avait tel bouton là pour faire ça, ça aurait vachement simplifié leur tâche donc ils font un patch et le défendent corps et âme. Mais je suis même pas sûr qu'une fois ce projet terminé, ils aient jamais besoin d'utiliser ce bouton encore. Et quand bien même, y a des millions d'autres utilisateurs de GIMP.
Le truc, c'est que si on devait accepter tous les patchs pour ajouter des boutons, à ce jour y aurait 1000 boutons dans chaque dock. En fait je trouve qu'y en a déjà trop. Je parle même pas de l'ordre des boutons ou fonctions. C'est simple, on a dû avoir des demandes pour toutes les combinaisons possibles. Si on acceptait chaque fois un patch pour changer l'ordre, GIMP serait totalement schizophrène et changerait l'ordre de ses boutons constamment.
Ce qu'il nous fait, c'est une GUI plus personnalisable, mais forcément ce patch n'est pas aussi simple si on veut le faire bien (c'est d'ailleurs dans mes cartons). ;-)
Tout ça pour dire que même si ce que tu dis est vrai, je ne suis pas sûr que ce soit une mauvaise chose de "s'accrocher à une notion de qualité" et s'y tenir. Mais encore une fois, un projet comme GIMP (ou gcc, et probablement même LLVM, ainsi que tout gros projet avec beaucoup de code et une base d'utilisateur énorme) doit être géré différemment. On ne doit pas s'empêcher d'expérimenter (et on le fait vraiment beaucoup; si t'as l'occasion d'essayer la version de dév, essaie!), mais on ne peut pas non plus faire tout et n'importe quoi.
Encore une fois, je pense donc que ce que tu dis s'appliquera bien mieux à un petit projet qui a tout intérêt à avoir des contributeurs et qui peut se permettre de changer plein de petits trucs très régulièrement.
Ah ça m'est jamais arrivé. Mais bon dans mon cas, je ne le fais que soit parce que le contributeur ne répond pas (mais que son patch est suffisamment intéressant pour être intégré moyennant quelques corrections), soit après déjà 3 ou 4 patchs corrigés (mais le contributeur n'a pas compris ou vu tous les problèmes qu'on lui soumettait); donc je pense qu'à ce moment le contributeur est soulagé de ne pas avoir à faire un autre aller-retour revue-patch.
Dans mon cas, j'essaie aussi de le faire aussi rarement que possible.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par Sufflope (site web personnel) . Évalué à 6.
Attention à un éventuel biais de sélection. Peut-être vois-tu beaucoup plus de gros projets bien organisés car ils l'étaient plus que la moyenne dès le début, et ont survécu par rapport à des petits bordels qui en sont mort rapidement.
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
C'est vrai. C'est aussi une possibilité que beaucoup de projets bordéliques aient pu disparaître justement pour cette raison.
Ceci dit, il est toujours possible de réorganiser un projet, surtout quand il est encore petit. Et la qualité du code d'un même développeur va en augmentant avec le temps (d'habitude). On a tous été débutant, et donc on a fait des erreurs en tant que tel, qu'on ne fait plus 10 ans plus tard (on en fait d'autres! :P). Donc y a beaucoup de projets qui peuvent commencer bordéliques et avec une archi mal barrée qui peuvent encore être sauvés avant de devenir in-maintenable. J'imagine qu'un meilleur critère pour la survie est donc de savoir rattraper les erreurs de jeunesse à temps.
Ensuite, qui peut dire? S'il y avait une recette pour faire des gros projets à succès et que tu la trouves, tu es riche! ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
Est-ce que ça ne veut pas dire que tout gros projet est destiné à être forké ?
Si à partir d'une certain taille critique, cela devient trop risqué de le bouger, ne devrait-on pas appeler au fork pour permettre à une version expérimentale qui évolue rapidement d'émerger ?
[^] # Re: Mainteneurs grincheux
Posté par barmic . Évalué à 3.
Je pense que ce qu'il faut c'est de l'émulation, que ce soit via un fork pour redynamiser ou une alternative suffisamment crédible pour représenter une concurrence.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Hmm… Je ne vois pas du tout par quelle logique tu es passé de mon commentaire au tien.
J'imagine que sur ce point, tu fais référence à ce que j'ai dit y a plusieurs commentaires sur la revue stricte. Mais ce n'était pas le sens. "Revue stricte" ne signifie pas "on ne bouge pas". Non un projet avec revue stricte, quand il bouge, il met un point d'honneur à le faire bien. Bien souvent, "faire bien" veut cependant dire "prendre son temps", pas accepter des patchs à la va-vite parce qu'ils "marchent" et tant pis pour l'archi, les règles de code et pour la réflexion sur une meilleure UI et sur l'expérience utilisateur en général !
"Destiné", je ne sais pas mais l'histoire montre que c'est courant, oui. GIMP a eu au moins 2 forks qui ont fait parlé d'eux. Ensuite les forks sont-ils souhaitables? Parfois oui bien sûr mais si la raison est essentiellement "ils sont chiants à prendre du temps et à vouloir vérifier mon code", je trouve cela dommage. Des 2 forks de GIMP, l'un (GIMP Painter) a des fonctionnalités qu'on voudrait vraiment avoir, on a manifesté notre intérêt, discuté avec le dèv… le problème ? Alors que la 2.8 était sortie, il développait sur des tarballs de la 2.6. De nos jours, il développe sur la branche 2.8 alors que le core a énormément évolué avec l'intégration de GEGL pour la 2.10. En gros il ne semble pas intéressé par notre processus de développement et fait tout à sa sauce. Personnellement je trouve que c'est très dommage et une raison de forker un peu triste. On veut de ses innovations, mais bien entendu elles ne valent pas un reset de tout notre code depuis 2.8! En fait, je lui ai redemandé récemment s'il ne veut pas travailler sur notre branche master et j'ai l'impression qu'il se fait beaucoup d'idées et qu'il s'imagine nos pensées. Quand il dit par exemple qu'il pense que la core team et lui ont des visions du design d'UI différente… je me demande vraiment d'où il peut tirer cela. Déjà même si on parle souvent de "core team" pour simplifier, il n'y a pas une pensée similaire en notre sein. On est surtout un groupe d'individuels. Parfois on a des idées similaires, parfois non, puis on discute, on argumente, parfois on change d'avis…
En plus je crois pas du tout qu'on bloquerait l'idée d'une toolbar horizontale (au contraire, j'y pense même très régulièrement et j'ai pas eu besoin de connaître GIMP-painter pour y penser), ce qu'il semble dire, etc. Quand il dit qu'avec le "succès" de GIMP painter, ça permettra aux dévs de GIMP de se rendre compte des vrais besoins des utilisateurs et aussi ça nous montrera comment implémenter ces fonctionnalités, je pense que ce développeur se fait beaucoup d'illusions sur son travail. Je pense qu'il est un dév très compétent et avec de bonnes idées, mais comme tant d'autres le sont. Il serait un très bon ajout à notre équipe pour faire évoluer GIMP plus vite et mieux (surtout s'il bénéficie de revue de code! Mais il semble ne pas vouloir subir cela); mais seul de son côté, non il n'est pas notre "modèle" à suivre. Et non on n'a pas le temps de regarder son code, surtout si celui-ci se base sur une branche totalement obsolète (vieille de très nombreuses années)!
Dans ce cas, pourquoi donc appeler au fork ici par exemple? C'est pour moi un exemple typique de gâchis de ressources de qualité. :-/
Ensuite, oui y a eu des cas où le fork a été très bénéficiaire (libreoffice vient à l'esprit immédiatement). Mais le fork est un outil qui a un poids et un prix conséquents. Il faut bien peser le pour et le contre avant de s'y lancer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
Je faisais surtout référence à cette phrase dans mon commentaire (j'aurais du la citer) :
Sinon pour le fork en général, je ne pense pas qu'il faut le prendre comme une chose négative. Je dis simplement que l'historique d'un projet, et surtout son nombre d'utilisateurs, crée de l'inertie. Donc au bout d'un moment, voir le projet forké pour lui permettre de retrouver du dynamisme et de confronter des points de vue différents me parait une étape logique dans la vie d'un projet à succès.
Pour ton cas de GIMP, c'est bien que quelqu'un tente quelque chose dans son coin (bon codeur ou non). Ca ne l'empêche pas de réintégrer ses ajouts plus tard ou tout simplement donner une seconde vie au projet si tout le monde le suit.
[^] # Re: Mainteneurs grincheux
Posté par Ph Husson (site web personnel) . Évalué à 6.
Le comportement de mainteneur que j'ai le plus vu de mon expérience de petit contributeur, c'est qu'un certain nombre de mainteneurs recodent la fonctionnalité/le bug fix, en disant merci sur le bug tracker/mailing list, en faisant éventuellement référence à la discussion dans le commit, mais en se mettant en auteur.
Personnellement c'est ma version préférée de contribuer:
Je sais que des systèmes critiques ne vont pas mourir par ma faute, que personne ne va s'arracher les cheveux sur mon code, mais j'ai quand même la fierté d'avoir contribué.
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
C'est intéressant ce que tu dis. Mais ne préférerais-tu pas et ne serais-tu pas encore plus fier d'avoir une revue de code juste mais stricte, qui te demande de revenir sur ton code, d'intégrer les changements demandés par le réviseur (est-ce la bonne trad pour "reviewer"?), puis que ton patch final soit intégré dans le logiciel sous ton nom à toi (et pas juste une vague citation)?
Personnellement je fais tout mon possible pour que le nom du contributeur reste l'auteur du commit. Bien sûr, si le contributeur ne répond plus, et que je suis obligé de réécrire totalement son patch (car il ne correspond pas à nos critères de qualité) qui à la fin n'a plus rien à voir, je suis bien obligé de me mettre en auteur. Mais j'essaie d'éviter d'arriver à cela. S'il le faut, je laisse du temps passer et attend quelques mois (parce que tout le monde a une vie et je comprends bien qu'ils ne peuvent pas forcément réagir immédiatement à une revue de code) en re-demandant 1 ou 2 fois où ça en est avant d'éventuellement me décider à committer quelque chose moi-même.
Personne ne s'arrachera les cheveux sur ton code et aucun système critique ne mourra par ta faute car ce sera alors du bon code. Ou du moins si problème il y a, ce sera tout autant (voire plus) la faute du réviseur de code (Si on doit absolument chercher un fautif — en reprenant tes termes — mais ce n'est absolument pas la logique habituelle, du moins dans les projets auxquels je participe où on fait du travail collaboratif et tout le monde a le droit à l'erreur; j'ai moi-même de temps en temps des commits qui doivent être annulés, ça arrive, c'est pas la fin du monde et personne ne lance la pierre). Et en plus ton nom sera dans les auteurs. J'aime donner ce petit bout de fierté aux contributeurs et je pense que c'est important de les faire se sentir part au logiciel auquel il contribue.
C'est pour moi l'une des meilleures fonctionnalités des systèmes de versionnement décentralisés. À l'époque de SVN, un contributeur occasionnel n'était qu'une bref citation dans le commit du message au nom d'un autre, même si le commit était 100% de vous (seuls les développeurs "core", c'est à dire ceux avec accès écriture sur le dépôt pouvaient être dans le champs "auteur", et donc un patch d'un contributeur revenait à celui qui le poussait). De nos jours, avec git, mercurial et co., on est capable de donner la véritable paternité d'un code et c'est réjouissant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par gasche . Évalué à 3.
Je me suis un peu renseigné sur la position du dev ZeroMQ sur ce sujet je pense qu'elle est beaucoup plus fine que le "laisser faire" dont tu parles—le journal ne lui rend pas vraiment justice sur ce point. Regarde le document Collective Code Construction Contract par exemple. L'idée globalement est que chaque projet devrait décider un ensemble de critères pour les patch proposés, qui puissent être jugés objectivement (par une personne qui connaît bien le code), et ensuite que le travail du mainteneur devrait se limiter à vérifier que les critères ont été appliqués, et si oui inclure le patch.
C'est vachement plus fin que "j'accepte si ça marche". Par exemple deux des règles proposées sont:
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Je pense que tu as répondu sur le mauvais message, mais c'est pas grave. ;-)
Ok. Pour ma part, je n'ai pas cherché plus loin et me suis juste basé sur les dires du journal. Ça m'amusait que juste quelques heures après mon message, il y ait justement un journal qui parle du même sujet.
Bon bah au final, c'est donc plus une revue stricte de contribution (ça m'a même l'air complètement le contraire de ce que dit le journal, donc tu as bien raison en disant que ça ne rende pas justice!) et ça se rapproche du type de revue que fait un logiciel comme GIMP (ou beaucoup d'autres).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par gasche . Évalué à 3.
L'idée je crois c'est de réussir à formaliser l'attente sur les contributions, de façon à ce que la décision d'acceptation des patches devienne la plus mécanique possible, pour simplifier le travail du mainteneur—et aussi, passer mieux à l'échelle, et le rendre plus facilement remplaçable ou faisable en groupe. C'est assez intéressant, mais ça demande aussi beaucoup de travail de spécification/clarification et une très bonne connaissance du projet.
Il s'agit plutôt d'une méthodologie de travail du mainteneur que d'un choix sur l'axe entre exigence et permissivité. Je ne crois pas que Gimp (ou que les projets sur lesquels je travaille moi-même) aient adopté cette méthodologie pour l'instant—même si je me rends bien compte que j'ai bien des critères en tête que j'applique de façon relativement uniforme sur les petites contributions peu invasives.
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
C'est forcément plus fin, car j'ai résumé en quelques paragraphes plusieurs talks et écrits.
Je comprends pas pourquoi tu dis que je ne lui rends pas justice. Il insiste beaucoup sur le fait d'intégrer rapidement les contribs des autres. Dans un de ses talks, il invite même ses mainteneurs principaux à faire la course pour merger le plus vite possible un patch. Il indique également qu'il n'a pas peur de casser ses tests.
Je mentionne bien par la suite que certaines règles doivent être respectées. Mais que celles-ci sont établies à l'avance. Pieter Hintjens parle de contrats. C'est le rôle des mainteneurs principaux de les établir car ils ont une bonne connaissance du projet.
D'ou ma question, est-ce que tu peux me dire en quoi je ne lui rends pas justice ?
[^] # Re: Mainteneurs grincheux
Posté par kantien . Évalué à 2.
Je réponds ici de mon point de vue, et de la façon dont j'avais perçu sa méthodologie et ses principes suite à la présentation de ton journal. S'il est vrai, qu'en conclusion de ton paragraphe sur le sujet, tu précises qu'il y a des règles établies et que le rôle des mainteneurs est de veiller à leur respect; il y a néanmoins un passage qui peut induire en erreur (ce qui fut mon cas) sur la compréhension de ses principes :
Lorsque je lis ce texte, cela m'apparaît être le contre-pied de ce que l'on trouve dans le C4 (Collective Code Construction Contract). Il désirait effectivement que tout le monde puisse devenir contributeur :
Cependant, l'existence même de ce contrat impose des conditions d'acceptabilités pour une contribution, là où ta formulation laissait sous-entendre que c'était totalement inconditionné et même laxiste. Les huit règles rangées sous la catégorie patch requirement me semble relever de tout sauf du laxisme. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
Je pense qu'il y a ambiguité parce que tu te réfères au contrat qu'il a écrit et moi à ses talks et bouquins. Effectivement, il propose et recommande le C4, mais dans ses publications, il parle de contrat avant tout. Ensuite dans les 8 lignes que tu cites, il fait peu référence à l'architecture du logiciel. C'est surtout en ce point qu'il propose de laisser passer beaucoup de choses (et mon paragraphe commence en parlant de l'architecture).
Je suis d'accord que le terme laxiste est un peu fort et que j'aurais du mettre plus l'accent sur le contrat. J'aurais du aussi insister sur le fait que le patch doit résoudre un problème bien identifié.
Mais de mon point de vue, le message principal reste qu'il faut faciliter la contribution au maximum. Pour cela on peut se permettre de faire des bons compromis sur l'architecture et la qualité du code.
[^] # Re: Mainteneurs grincheux
Posté par gasche . Évalué à 2. Dernière modification le 24 décembre 2016 à 16:26.
J'observe les résultats: une partie des personnes qui ont lu ton journal ont fait un contresens, ils en ont compris quelque chose qui est assez éloigné de la réalité. Ça veut dire qu'il y a sans doute quelque chose de pas clair dans ta présentation.
Je trouve que le paragraphe
est très bien (même si tu aurais pu creuser un peu sur la question de quelles sont ces "règles") mais, comme le précise kantien ci-dessus, j'imagine que la partie
peut induire en erreur.
Après, ce n'est pas un drame. Mais quand quelqu'un me dit "j'ai lu le billet X et dedans il est expliqué que le mainteneur de ZeroMQ accepte tous les patchs, c'est radicalement à l'opposé de ce qu'on fait dans le projet GIMP", je suis bien obligé de dire que ce que la personne a compris de X ne correspond pas à la réalité. J'aurais pu dire "tu as mal compris X" au lieu de "X ne décrit pas bien la réalité", mais je pense que les torts sont, comme souvent, partagés.
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
Ce n'est pas un contresens complet que de comprendre qu'Hintjens est extrême et que globalement il accepte beaucoup de patchs. Là où mon journal est effectivement ambiguë c'est que ce n'est pas clair de savoir s'il prend les patchs qui n'ont pas de sens ou ne sont pas pertinents. Je te remercie pour avoir complété avec les critères d'acceptation du C4 qui permettent de clarifier ça.
Pour la phrase que tu cites elle est mal tournée en effet car on peut supposer qu'elle est en contradiction avec la notion de contrat. Par contre, elle a aussi son contexte : un paragraphe qui parle d'architecture (et un paragraphe précédent qui commence par "En très résumé" et qui invite donc à creuser si intéressé). Sur le plan de l'architecture, je vois rien dans le C4 en contradiction avec le fait qu'il prend presque tout.
[^] # Re: Mainteneurs grincheux
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Il faudrait être un peu plus clair: il prend tout et n'importe quoi, même des patchs qui cassent l'architecture actuelle? Ou bien des patchs qui revoient (et donc améliorent) l'architecture?
C'est pas du tout la même chose. En effet, je suis totalement d'accord qu'il faut pas être à cheval sur une architecture, même si c'est soi-même qui l'a conçue, on peut toujours faire mieux (ou évoluer progressivement). Un gars qui propose un changement profond qui remanie entièrement certaines parties architecturales du programme (ces changements doivent avoir du sens bien sûr!) est tout à fait viable et peut même être très bon. À partir de l'inclusion, cela devient donc simplement la nouvelle architecture (donc rien n'est cassé).
Ce genre de contributions arrivent d'ailleurs régulièrement et sont les bienvenues. Ce qui importe, c'est d'avoir un code propre qui respecte les dernières règles fixées.
Par contre, si tu parles vraiment d'accepter des patchs qui cassent les choix architecturaux sans les revoir (donc on se retrouve avec du code hybride où les règles établies ne sont pas suivies), alors je suis absolument pas d'accord.
Note que je n'ai aucune idée si Pieter Hintjens pense ainsi ou pas, et cela ne m'intéresse absolument pas de savoir. Il n'est pas nécessaire de continuer sur la discussion de savoir si on lui rends justice ou pas (pas pour moi en tous cas). Je parle de l'idée générale d'accepter n'importe quel patch qui casse l'architecture, que ce soit ce que cette personne promouvait ou pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Mainteneurs grincheux
Posté par gelnior (site web personnel) . Évalué à 2.
Oui je parle de prendre des patchs qui ne respecte pas l'architecture. Pour moi il faut les prendre pour assurer une plus grande diversité de contributeurs (Hintjens m'a convaincu). On est donc effectivement pas d'accord :)
# Dommage alors
Posté par saltimbanque (site web personnel) . Évalué à 4.
N'y connaissant rien en compilation, me voilà très surpris : je pensais naïvement que llvm apportait une fraîcheur nouvelle, que d'ici quelques temps le noyau Linux aurait migré, que gcc était l'un des des derniers gnous.
Le fait que Apple soit derrière m'a peut être induit en erreur, puisque d'autres techniques poussées par Apple me semblent des succès sur linux. Ou peut être certains articles.
De plus le post se plaint de moins d'étude scientifique. Je m'attendais à ce que llvm soit le Wayland de la compilation, le produit de nombreuses années d'expérience. On m'aurait menti? Si ce n'est pas llvm y'a t'il d'autres compilateurs intéressants ?
[^] # Re: Dommage alors
Posté par Lutin . Évalué à 7.
gcc
[^] # Re: Dommage alors
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ah oui, lesquelles ?
[^] # Re: Dommage alors
Posté par kantien . Évalué à 2.
CUPS ?
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par gasche . Évalué à 6.
CUPS n'est pas vraiment un exemple puisqu'il a été racheté récemment par Apple après des années d'usage dans le libre. Personne ne se plaint que son mainteneur ait maintenant un boulot, et je suppose qu'il continue à améliorer aussi la partie du code libre utilisée par Linux (je ne sais pas, je ne suis pas le développement de près), mais on ne peut pas dire que c'est la participation d'Apple qui a fait son succès.
Un autre non-exemple serait MySQL: ce n'est pas la participation d'Oracle qui fait son succès. (Les grincheux auraient envie de dire "au contraire" et ils n'auraient pas forcément complètement tort, même si je suis surpris de la ténacité de MySQL alors qu'il existe un fork communautaire très compatible, MariaDB; on n'est pas au niveau de flingage qu'on a pu voir pour OpenOffice).
[^] # Re: Dommage alors
Posté par kantien . Évalué à 3. Dernière modification le 21 décembre 2016 à 15:48.
Il est vrai, mais je pense (ai-je tort ?) que ça doit faciliter la disponibilité de pilotes d'imprimantes : un constructeur s'intéressera plus facilement au marché de Apple qu'à celui de nos systèmes.
De même pour LLVM, qui n'est pas non plus un projet de Apple à l'origine et ils ne sont qu'une des organisations le soutenant, est-ce la participation de Apple au projet qui en a fait un succès ?
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par gasche . Évalué à 4.
Dans le cas de LLVM, c'est clair que oui : une grande partie des mainteneurs de LLVM et Clang sont payés par Apple pour bosser à temps plein sur le projet. LLVM était prometteur au moment où Apple a mis le grapin dessus (ils cherchaient un truc pour se débarasser de GCC et sa licence), mais il ne serait pas forcément arrivé depuis à ce niveau de maturité sans le soutien d'Apple. C'est une bonne affaire pour cette boîte, puisqu'ils ont aussi acquis les talents pour faire Swift et redevenir compétitifs en terme de confort de programmation mobile. (Apple est une entreprise détestable par de nombreux aspects, mais qui a toujours fait de beaux paris techniques et, de façon intéressante, a souvent cru en le choix de meilleurs langages de programmation (HyperCard, Dylan, etc.).
[^] # Re: Dommage alors
Posté par lolop (site web personnel) . Évalué à 2.
Ça a été un succès sur les Unix avant d'être racheté par Apple…
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Dommage alors
Posté par gasche . Évalué à 5.
Je pense que c'est bien de tempérer l'image assez injuste "GCC c'est un truc de vieux maintenant le futur c'est LLVM", mais il ne faut pas non plus verser dans l'excès inverse: LLVM et GCC sont deux bons projets qui se font une concurrence très sérieuse et sans doute bénéfique des deux côtés. Par ailleurs les critiques sur la difficulté à se plonger dans le code source de GCC, qui avaient motivées en grande partie les contributeurs passant à LLVM au départ, sont sans doute toujours valide en grande partie—et le fait que le code de LLVM prenne de l'âge est un peu indépendant.
Peut-être que l'erreur vient de toi, c'est d'espérer trouver un compilateur miracle qui réponde au rêve du projet parfait à soutenir et défendre contre tous les autres. Ce compilateur miracle n'existe sans doute pas. (Ou ça dépend ce qu'on cherche; CompCert a un côté miraculeux.)
Pour ce qui est de la recherche, j'espérais le dire dans mon journal mais j'ai un peu oublié : il y a des gens qui font de la recherche en compilation et qui contribuent et à GCC et à LLVM. Ils ne travaillent pas forcément sur les parties du compilateur citées dans le message de Daniel Berlin, qui sont en train d'accumuler des couches, mais par exemple le travail sur Polly est développé et maintenu par des chercheurs et chercheuses, à la fois dans GCC et dans LLVM.
Pour revenir sur la question de quels sont les "compilateurs intéressants", je pense que ça dépend de ce qu'on veut y trouver. Pour un compilateur qui intègre régulièrement des résultats de recherche en compilation, GCC et LLVM sont plutôt raisonnables; il y a des projets de recherche plus ciblés et peut-être plus innovants (au sens noble du terme), mais ils ne cherchent pas forcément à couvrir les besoins des utilisateurs arbitraires de C ou C++—si ton rêve c'est les optimizations backend tu ne vas pas forcément te farcir un frontend C++.
Après mon rêve à moi c'est plutôt les langages que les compilateurs, et j'aurais tendance à m'intéresser plutôt aux langages qui font des choses chouettes, même quand leur backend est un peu simple (OCaml, Haskell) ou simplement délégué à LLVM (Rust, Pony, Pure, Julia).
[^] # Re: Dommage alors
Posté par kantien . Évalué à 0. Dernière modification le 21 décembre 2016 à 16:27.
Qu'entends-tu par backend et frontend pour un langage ?
Pour ce qui est des langages chouettes, il n'y en a qu'un : le lambda-calcul ! :-P
Depuis que Perthmâd a posté le lien vers cette histoire brève, incomplète et globalement erronées des langages de programmation, je ne m'en lasse pas.
Et puis, comme le rappelle Philipp Wadler dans cette vidéo sur le thème "propositions as types"1, même Turing considérait que c'était le meilleur langage pour exprimer la notion de calculabilité, le concept de sa machine servant avant tout à résoudre la polémique entre Church et Gödel.
De toute façon, je soutiens que tous ces travaux (de même que la question de la vidéo de Wadler : is mathematics invented or discovered ?) sont contenus, en germe et en puissance, dans l'œuvre kantienne, en particulier dans son concept de schème et sa théorie du schématisme. Surtout que contrairement au langage du même nom, ses schèmes sont statiquement typés via le principe : propositions as types. :-)
D'ailleurs pour la question de Wadler, je préfère la formulation : « la mathématique est-elle inventée ou créée ? »; ce à quoi je réponds : inventée, en prenant le concept dans l'acception qu'il a chez les juristes où est qualifié d'inventeur la personne qui découvre un trésor, trésor qui préexiste à sa découverte.
dans le papier qui l'accompagne, il publie une correspondance avec William Howard très intéressante à lire. ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par barmic . Évalué à 9. Dernière modification le 21 décembre 2016 à 18:29.
Grosso modo, le frontend décode le source pour en faire un code intermédiaire qui sera traduit dans le langage de destinataion par le backend.
Je te laisse troller sur les langages, je vois pas le rapport avec la compilation :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dommage alors
Posté par lasher . Évalué à 10.
Pour compléter un peu : traditionnellement le front-end s'occupe de l'analyse lexicale (« l'orthographe »), de l'analyse syntaxique (« la grammaire ») et de l'analyse sémantique (analyse des types, etc.).
Il y a très peu d'optimisations faites dans les 2 premières phases, qui se bornent à vérifier que le programme est bien formé. Ceci étant dit, faire une séparation claire de l'analyse lexicale et syntaxique est bien niveau « génie logiciel » mais peut avoir un mauvais impact sur les performances du compilateur lui-même. Du coup certains compilateurs entrelacent les deux phases pour accélérer l'analyse du programme (Clang fait ça si je me souviens bien; je ne sais pas/plus pour GCC).
Le front-end produit un arbre de syntaxe abstraite (AST), qui, lui, peu être « décoré » pendant la phase d'analyse sémantique. Cette dernière est la seule des trois phases du front-end (à ma connaissance) qui apporte non seulement un aspect feedback pour le programmeur via des erreurs de compilations (« tu ne peux pas affecter un entier à une chaîne de caractères : pas les mêmes types »), mais aussi qui peut potentiellement effectuer certaines optimisations grâce à une connaissance poussée du système de types, ou bien à la reconnaissance de motifs dans l'AST (par exemple, le compilateur d'Intel reconnaît les formes simples d'opérations d'algèbre linéaire, et va remplacer une boucle naïve par un appel à la fonction qui va bien dans la bibliothèque mathématique qui vient avec le compilateur).
Puis vient le middle-end : dans cette partie, on part d'un AST, et on construit une représentation intermédiaire (« IR » : GIMPLE pour GCC, et un code à trois adresse pour LLVM1, qui est essentiellement une forme de langage d'assemblage « générique »/abstrait). C'est ici que la plupart des transformations optimisantes de haut niveau sont effectuées (déroulage, fusion, fission de boucle; suppression de code mort; propagation de constantes; etc.). À la sortie du middle-end, on se retrouve avec une représentation intermédiaire substantiellement modifiée.
Enfin, vient le back-end, qui se charge de générer du code. À ce niveau, on doit savoir quel processeur on vise. Traditionnellement il y a trois phases : sélection d'instructions, ordonnancement d'instructions, et allocation des registres. La première se charge d'associer des morceaux de la représentation intermédiaire à une instruction particulière. Par exemple, si dans mon IR j'ai quelque chose du genre :
… Alors, en fonction du jeu d'instruction de la machine cible, je vais peut-être simplement copier-coller ces deux lignes, ou bien, si l'architecture a une instruction « fused multiply-add », je vais la sélectionner et générer le code suivant :
… Ce qui me fait économiser une instruction et sans doute un ou deux cycles processeur.
Une fois que j'ai sélectionné les instructions à exécuter, il faut que je décide dans quel ordre je vais les déclencher. L'idée étant qu'on veut recouvrir les latences mémoire par des calculs, tout en préservant les dépendances de données. À ce niveau, on considère qu'on a un nombre infini de registres à notre disposition.
Enfin, on passe à l'allocation de registres. Dans cette phase, on associe un ordonnancement donné, qui utilise un nombre infini de registres au jeu de registres réel de la machine. Ça implique d'ajouter du code pour sauvegarder/restorer les valeurs contenues dans les registres lorsqu'il n'y a plus de place (on fait « déborder les valeurs des registre en mémoire— aka « register spill »).
En règle générale, il y a un aller-retour entre phase d'ordonnancement et phase d'allocation de registres, puisque du code est rajouté et peu du coup influer sur l'ordonnancement initial.
Il y a tout plein d'optimisations qui peuvent être effectuées au niveau du back-end et qui sont spécifiques à l'architecture, comme par exemple l'optimisation du « voyeur » / « trou de serrure » (« peephole optimisation »).
si je suis trop imprécis, voire incorrect, n'hésitez pas à me corriger ! ↩
[^] # Re: Dommage alors
Posté par kantien . Évalué à 2.
Merci pour ces précisions, je comprends mieux à quoi faisait référence les termes backend et frontend.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par kantien . Évalué à 3.
Merci pour ces précisions. Si je comprends bien, il y a un langage intermédiaire (agnostique vis à vis du langage source) que cible le frontend, puis le backend part de cette représentation intermédiaire pour traduire vers le langage cible qui dépendra de l'architecture machine. C'est cela ?
C'est pas du troll, c'est une boutade. ;-) Même avec des emoticônes, le second degré ne passe pas sur linuxfr ?
Ce n'est pas, directement, en rapport avec la compilation, mais avec la fin du message de gasche. Et deux des langages qu'il cite (OCaml et Haskell) dérivent explicitement du lamba-calcul. D'ailleurs gasche est relecteur des patchs soumis sur le compilateur OCaml et a les droits de commit sur le dépôt, et Philipp Wadler est un des grands contributeurs au langage Haskell et l'implémenteur de generics en Java (ça c'est pour toi, il me semble que c'est le langage que tu utilises le plus; et dans la vidéo il explique d'où vient l'idée ;-).
En tout cas, la vidéo a bien un lien avec le thème du journal : quand on s'occupe de faire un langage et d'écrire un compilateur, il vaut mieux bien maîtriser la théorie. Et cette théorie, elle vient d'une source principale : la logique mathématique et la théorie de la démonstration. ;-)
Par contre, je me suis trompé pour la vidéo où il montre un extrait d'un article de Turing, c'est celle-ci (mais le contenu des deux conférences est similaire). L'article date de 1937 et l'abstract est :
Enfin si tu ne vois pas le rapport à la théorie des langages (et donc in fine avec la compilation), c'est peut être que tu n'en connais que succinctement le contenu, ou que tu ne connais pas le contenu de philosophie kantienne. ;-)
Juste une illustration, dans un article de 1905, au cours d'une polémique qui l'opposait avec des logiciens comme Russell ou Hilbert, Henri Poincaré écrit en introduction :
Puis continuant, à la fin de son introduction il émet une très très grande objection au travaux des logiciens qui lui étaient contemporains :
Et pour cause : ils ne pouvaient pas la satisfaire; et cette impossibilité devait être prouvée, par Gödel, 26 ans plus tard1 sous le nom de théorème d'incomplétude ou, dans la version de Turing, indécidabilité du problème de l'arrêt.
Donc qui avait raison ? Kant et Poincaré ! ;-)
Tout ça pour dire : l'ordinateur, les langages de programmations, l'informatique, ce n'est pas venu du jour au lendemain dans la tête de Turing. Ça s'inscrit dans une tradition historique qui relève de la logique, de la philosophie et des fondements de mathématiques : c'est ça les bases théoriques des langages de programmation. ;-)
soit en 1931, c'est à dire 150 ans après la première édition de la Critique de la Raison Pure (1781) dans laquelle on trouve un énoncé analogue au théorème d'incomplétude (et donc au problème de l'arrêt). ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par barmic . Évalué à 6.
C'est ça. Sauf que la représentation intermédiaire n'est pas toujours totalement agnostique.
Celui de llvm est particulièrement bien documenté (pour un langage intermédiaire), c'est parce qu'il est considéré comme une interface du compilateur (alors que gcc considère ça comme une représentation interne). Un petit peu de lecture : https://en.wikipedia.org/wiki/LLVM#LLVM_intermediate_representation
C'est surtout celui que je connais le mieux.
Si si c'est juste que tes postes volent trop haut pour quand je suis en vacances ^^
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dommage alors
Posté par kantien . Évalué à 2.
C'est ce à quoi je m'attendais.
Pour moi, un compilateur c'est une fonction qui prend en entrée un texte écrit dans un langage et qui renvoie un texte écrit dans un autre, tout en préservant certains invariants dont le plus important est la sémantique du code. En gros : c'est un morphisme avec certaines propriétés qui sont propres aux compilateurs.
Dans les faits, pour écrire ce morphisme, on le décompose en fonctions distinctes et séparées aux rôles spécifiques, et on l'obtient par composition. Que certains groupes de fonctions se nomment backend et frontend (voire middle-end d'après la réponse de lasher) était le sens de ma question initiale. Cela semble relever du vocabulaire du génie logiciel, soit de l'ingénierie, vocabulaire que je ne connais pas spécialement.
Après, une représentation intermédiaire, pour moi, c'est juste le domaine d'arrivée (puis de définition) d'une des fonctions qui composent le compilateur. Dans des compilateurs comme GCC ou LLVM, qui prennent une multiplicité de langage sources en entrée et une multiplicité d'architectures cible en sortie, il faut bien à un moment donnée un langage commun, pivot; ce qui semble être le rôle du langage succinctement décrit, pour LLVM, dans le lien wikipédia que tu as donné.
Arf désolé, j'essayes de me retenir pourtant et je ne pensais pas que celui-ci volait si haut que cela. La conférence de la vidéo est surtout une conférence d'histoire de la logique et de l'informatique théorique au cours du XXème siècle. Je l'ai trouvé sur la page history of logic and programming languages sur le site de Philipp Wadler. Mais si j'en juges à la note de mon commentaire, la science et l'histoire des sciences ne semblent pas intéresser grand monde ici, à moins (ce qui est sans doute plus probable) que ce ne soit mon sens de l'humour qui ne fasse rire que moi.
Dans le même genre (compilation et histoire), il y a l'article (de vulgarisation, rien de bien théorique ni de très pointu dedans) la comptine des neufs divisions sur le site images des maths du CNRS. Son chapeau est :
Il parle d'une comptine que les enfants chinois apprenaient pour pratiquer la division sur un boulier, qui n'est autre qu'un algorithme de division pour un machine (non automatisée) avec un nombre de registres limités, plus connu sous le nom de : boulier. :-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par lasher . Évalué à 7.
Je réagis bien plus tard, mais les vacances étant finies, je peux enfin procrastiner au boulot ! :)
Deux choses :
Mon deuxième point répond en partie à cette phrase :
(c'est moi qui grasse œuf corse)
Justement, ;-) ça va plus loin que ça selon moi. Il y a une séparation nette entre les phases qui ont des effets de bord (front-end, back-end), et celles qui n'en ont pas (le middle-end), à l'exception du changement de représentation. Même dans le back-end on cherche le plus possible à garder des abstractions (sinon les itérations entre ordonnancement d'instruction et allocation de registre seraient infernales à gérer, surtout si on considère certaines optimisations de bas-niveau qui ne peuvent se faire qu'à ce moment).
Bref, ça ne contredit pas ton interprétation (qui est somme toute correcte), mais je voulais renforcer le « pourquoi » on architecture un compilateur ainsi. Au passage, ça permet aussi à LLVM de proposer une interface pour insérer ses propres passes d'optimisation dans le middle-end, et ça explique aussi pourquoi pendant longtemps GCC avait le back-end et le front-end « mélangés » pour des raisons idéologiques (pour éviter que les efforts de la communauté du libre soient fagocités par des éditeurs propriétaires qui brancheraient leur middle/back end proprio en dessous du front-end de GCC).
Donc pas de « voire middle-end », quelque part. À de très très rares exceptions près, tout compilateur « industriel » moderne est architecturé selon ces trois parties distinctes. ↩
Il y en a beaucoup, notamment le fait qu'il faut insérer des pseudo-fonctions phi lorsque plusieurs chemins de contrôle se rejoignent avec des valeurs potentiellement différentes. L'insertion est facile à identifier, c'est la reconversion du graphe SSA en graphe « normal » (interprétable par le back-end) qui peut devenir compliquée. Les auteurs du premier papier démontrant comment mettre un programme sous forme SSA efficace et opérer une « dé-SSA » proposent un mécanisme simple mais potentiellement coûteux en registres/opérations de chargement/déchargement (mais au moins la complexité est correcte). ↩
À noter que par exemple dans le middle end, il n'est pas rare que l'inversion de deux passes d'optimisation résultent en une performance clairement différente (par exemple, le déroulage d'une boucle avant/après sa fission peut avoir une importance lorsque l'IR est ensuite passée au back-end). Il n'est aussi pas rare de devoir opérer exactement la même transformation plusieurs fois d'affilée. ↩
[^] # Re: Dommage alors
Posté par kantien . Évalué à 1.
Au passage un message totalement hors-sujet, tant que je te vois dans les parages.
Il y a un projet de dépêche en cours de rédaction sur le thème Outils de développement OCaml par une personne venant de terminer le MOOC OCaml. Peut être pourrais tu y apporter ta contribution si tu as du temps, tu connais mieux le sujet que moi, en particulier sur la partie consacrée à Batteries. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Dommage alors
Posté par barmic . Évalué à 10.
Les projets ne migrent pas de GCC à LLVM que je sache, ils deviennent agnostiques. C'est assez différent ^_^
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dommage alors
Posté par saltimbanque (site web personnel) . Évalué à 2.
ils deviennent agnostiques parce qu'ils renoncent aux spécifiques gcc, tandis que llvm ne propose "que" du standard? j'ai bon?
[^] # Re: Dommage alors
Posté par gasche . Évalué à 6.
Je pense que non. Peu de projets utilisent des fonctionnalités non-standard de gcc. Par contre beaucoup de projets sont codés en langage C qui ne respecte pas vraiment les règles sémantiques imposées par le standard, et sont donc à la merci d'un changement d'avis du compilateur sur la façon de compiler telle ou telle entorse aux règles. Quand on passe d'un compilateur à l'autre (ou d'une version à une autre du même compilateur, parfois) on se retrouve avec des choses qui marchaient avant et qui échouent à la compilation, ou qui font n'importe quoi à l'exécution. Je pense que ce genre de problèmes de portabilité, lié à la fragilité du langage C, est majoritaire.
[^] # Re: Dommage alors
Posté par Renault (site web personnel) . Évalué à 5.
LLVM reprend des extensions de GCC, notamment ceux nécessaires pour compiler le noyau Linux. LLVM va au delà du C ANSI, C99 ou C11, il sait gérer des situations nécessaires pour compiler les bibliothèques ou applications bas niveaux (rien que l'assembleur inline dans le C c'est une extension non standard).
LLVM n'a pas tout et ne reprendra pas tout. D'ailleurs Linux s'est aussi débarrassée de quelques constructions problématiques. Pour que LLVM soit utilisé par Linux, cela progresse dans les deux sens. Mais ce n'est pas fini. Et je suppose que c'est vrai pour pas mal d'outils GNU bas niveaux tel que glibc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.