Ne pouvez-vous proposer des trucs pas optimisés, disons en «pré-version», pour mettre l'eau à la bouche ?
Le problème est que ça ne marche pas comme ça. Les gens sont juste déçus et nous engueulent comme un support client d'un produit qui ne remplit pas ses promesses (pas tous, mais il suffit de quelques uns pour que ce soit pénible).
Et puis soyons francs, même pour nous, c'est décevant. On aimerait vraiment pouvoir utiliser ces outils sur nos images de tous-les-jours. GIMP n'est pas un jouet et on l'utilise vraiment nous-même, on veut pas perdre notre temps de mainteneurs à juste proposer des démos faites par des étudiants qui cherchent du boulot (ça ne serait qu'une "preuve" pour ces gens qui disent que le libre n'est qu'une vitrine de ceux qui veulent se faire des CVs; c'est une triste vision du libre!).
Ce serait aussi mettre la pression sur les contributeurs qui ne voudraient peut-être pas laisser ce bout de code pas fini trainer sur la place.
On n'a pas pour habitude de mettre la pression aux contributeurs! ;-)
(ajout: et puis si on se pose la question autrement, quand t'as eu une fonctionnalité qui marchait pas dans un logiciel libre, tu es souvent allé en parler au contributeur précis? Est-ce que tu connais même un contributeur d'une fonctionnalité d'un logiciel? Non, si tu te plains, tu le fais sur le tracker pour toute l'équipe, et surtout les contributeurs core, ceux qui sont là en permanence, ce qui ne sera pas le cas de celui qui droppe du code et disparaît jusqu'au prochain drop; alors au final, qui la reçoit la pression du bout de code pas fini, à ton avis? 😵💫)
Ma méthode de maintenance est que les contributeurs ont le droit de travailler sur ce qu'ils veulent. Pour moi c'est le meilleur moyen de les faire rester à long terme, en faisant en sorte qu'ils se plaisent et s'amusent à améliorer GIMP. En un sens, si vraiment quelqu'un se fait chier en codant GIMP et le fait juste pour sa vitrine personnelle, j'ai pas plus envie que ça que cette personne reste. Ça m'amuse pas plus d'avoir des contributeurs pas heureux (qu'eux de ne pas l'être). Et puis tant pis si on attend quelques années de plus pour l'outil rêvé.
Surtout que je pense qu'optimiser du code est aussi une activité tout à fait sympathique. J'ai déjà travaillé sur des outils que j'ai passé un temps fou à essayer d'optimiser (par exemple la colorisation intelligente qui était un algo du CNRS originellement mais que j'ai rendu plus utilisable et surtout beaucoup plus instantané).
Franchement c'est aussi jouissif d'arriver à soudain avoir une utilisation quasi temps réelle d'un outil qu'on attendait constamment que ça l'était d'obtenir un outil qui marche (lentement) lors de l'implémentation initiale. De même que ces derniers temps, Aryeom et moi avons fait beaucoup d'itérations pour maintenant améliorer l'interface de cet outil de colorisation et son utilisation (notamment la compréhensibilité des options). Ça aussi (travail UX) est super intéressant. Ce sont toutes des étapes différentes mais chacune vraiment prenante à sa façon. Peut-être qu'un développeur qui va jamais jusqu'au bout et veut juste la partie facile s'est trompé de voie? Je sais pas... je m'interroge (perso je ne fais pas partie des gens qui pensent que le travail est juste un "gagne-pain" en attendant la retraite; on y passe une majeure partie de sa vie, il faut y être heureux aussi). 🤷 En tous cas, on devrait pas avoir à leur mettre la pression, ça c'est certain!
un ami bosse sur du code C ultra-optimisé (pour des chaines de fabrication de téléphone). Il me dit que ce savoir faire est recherché.
Un petit détail sur ce point précis. On ne cherche pas particulièrement l'ultra-optimisation de code. J'ai déjà lu des articles de gens qui parlent de certaines techniques, et ce que je vois dans les articles, c'est que ça peut rendre parfois le code tellement imbitable que ça en serait in-maintenable. Rien n'est pire que le code qu'on ne comprend pas sans y passer des jours (les bugs y restent des années et des années parce que personne veut toucher ce code).
Ensuite qu'on me fasse pas dire ce que je n'ai pas dit: bien connaître les structures de données, etc. c'est important. Mais parfois la lisibilité du code est bien plus importante que des centaines de micro-optimisations basée sur une connaissance avancée du langage.
Disons juste qu'il y a un intermédiaire entre du beau code très simple (l'implémentation "naïve" qui est souvent la plus belle et compréhensible mais aussi parfois trop lente) et du code imbitable qui va utiliser des techniques obscures et inconnues de compilateurs ou des structures de données sous-jacentes.
Ensuite je sais pas si c'est ce que ton ami appelle le C ultra-optimisé (ça m'a juste fait penser à des articles que j'ai lu, dont un y a vraiment pas longtemps, mais j'arrive plus à me rappeler où)! 😜
En contre-exemple, j'explique un peu dans ce document comment j'ai fait évolué l'algorithme de colorisation intelligente de l'équipe G'MIC/CNRS, voire ai changé des morceaux ou bien ai utilisé des astuces d'interface pour l'améliorer: https://developer.gimp.org/core/algorithm/line-art-bucket-fill/
On notera que pour toute la partie "optimisation", en plus des optimisations habituelle sur le code C lui-même (sans pour autant aller jusqu'à des techniques ultra-avancées en optimisation C), déjà j'ai fait évoluer l'algorithme lui-même (on y gagne 100 fois plus que toute "ultra" optimisation C). Par exemple pour l'étape 3 de "flooding", j'ai simplement utilisé un algo perso basé sur la connaissance qu'on avait déjà des traits et de leur épaisseur locale (info qu'on a calculée pour l'étape 2).
En plus de l'amélioration algorithmique, j'ai travaillé sur des logiques de travail en "interface graphique", notamment le fait qu'on sait que le graphiste n'est pas aussi instantané qu'une machine et donc il y a du temps entre 2 clics. Donc autant simplement pré-calculer le plus possible dans ce "temps mort" dans des threads (quitte à faire parfois du calcul qui sera perdu comme tout pré-calcul qui est un pari sur l'avenir).
Puis il y a plusieurs optimisations au niveau de l'UI et même la possibilité d'exclure explicitement (par les options) les parties complexes (ce qui implique pour l'artiste de comprendre un peu la logique interne de l'outil, mais c'est ce que les utilisateurs avancés font de toutes façons).
Serait-ce intéressant pour des étudiants du Summer Of Code d'apprendre à optimiser ?
Sincèrement pour les étudiants, déjà trouver ceux qui sont des développeurs sérieux tout court me semble une denrée rare. On en a eu un(e) cette année, qui en plus est très intéressé(e) (et intéressant!) et qui continue à contribuer! C'est d'ailleurs la raison pour laquelle on a fait le GSoC cette année, après 9 ans sans le faire. Cette personne nous avait en effet proposé d'y participer (après quelques patchs où elle a montré faire du bon travail), on s'est donc inscrit et répandu la nouvelle pour avoir potentiellement d'autres étudiants.
Dans les autres propositions qu'on a reçues, presque aucun ne semble même avoir lu notre news, n'a tenté de corriger quelques bugs au préalable, ni n'a montré avoir même déjà compilé le code (on peut voir venir gros comme une maison de passer les 2 premières semaines à essayer d'expliquer comment compiler GIMP!). Ou simplement personne (enfin presque, y en a un autre en fait — je suis mauvaise langue — mais c'est pas allé loin!) n'a essayé de nous contacter pour discuter avec nous sur IRC. Je parle même pas d'être un développeur de génie (cela ne m'intéresse pas plus que ça), mais juste quelqu'un de curieux et qui intéragit avec nous.
Donc avant de leur parler d'apprendre à optimiser, ou même d'apprendre à coder bien, ou autre truc avancé, faut déjà leur apprendre à discuter, prendre contact (comme le font les humains) et à apprendre à apprendre. Une chose que j'ai apprise en tant que développeur, c'est que rien n'est réellement difficile, par contre tout est simplement du boulot: ça prend du temps, on se torture les méninges, on est frustrés constamment... jusqu'au moment où on y arrive. Un bon développeur n'est donc pas celui qui est expert dans une technique particulière ou sait faire du code ultra-optimisé ou ceci ou cela. Il fait juste ce qu'il faut faire en fonction de la situation et s'adapte, en utilisant son cerveau pour décider. Et aussi rester toujours humble sur ce qu'on sait ou pas (sincèrement, y a tellement de sujet possibles, on apprend constamment).
Donc non, on cherche pas forcément des experts de l'ultra-optimisation et je pense pas forcément que ce soit l'une des compétences les plus importantes à apprendre pour ces étudiants. Ce n'est pas ce qu'on leur demande. 😆
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: quelques questions sur GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Conférence "GIMP et ZeMarmot" à Vandœuvre-lès-Nancy. Évalué à 8. Dernière modification le 01 novembre 2022 à 15:26.
Le problème est que ça ne marche pas comme ça. Les gens sont juste déçus et nous engueulent comme un support client d'un produit qui ne remplit pas ses promesses (pas tous, mais il suffit de quelques uns pour que ce soit pénible).
Et puis soyons francs, même pour nous, c'est décevant. On aimerait vraiment pouvoir utiliser ces outils sur nos images de tous-les-jours. GIMP n'est pas un jouet et on l'utilise vraiment nous-même, on veut pas perdre notre temps de mainteneurs à juste proposer des démos faites par des étudiants qui cherchent du boulot (ça ne serait qu'une "preuve" pour ces gens qui disent que le libre n'est qu'une vitrine de ceux qui veulent se faire des CVs; c'est une triste vision du libre!).
On n'a pas pour habitude de mettre la pression aux contributeurs! ;-)
(ajout: et puis si on se pose la question autrement, quand t'as eu une fonctionnalité qui marchait pas dans un logiciel libre, tu es souvent allé en parler au contributeur précis? Est-ce que tu connais même un contributeur d'une fonctionnalité d'un logiciel? Non, si tu te plains, tu le fais sur le tracker pour toute l'équipe, et surtout les contributeurs core, ceux qui sont là en permanence, ce qui ne sera pas le cas de celui qui droppe du code et disparaît jusqu'au prochain drop; alors au final, qui la reçoit la pression du bout de code pas fini, à ton avis? 😵💫)
Ma méthode de maintenance est que les contributeurs ont le droit de travailler sur ce qu'ils veulent. Pour moi c'est le meilleur moyen de les faire rester à long terme, en faisant en sorte qu'ils se plaisent et s'amusent à améliorer GIMP. En un sens, si vraiment quelqu'un se fait chier en codant GIMP et le fait juste pour sa vitrine personnelle, j'ai pas plus envie que ça que cette personne reste. Ça m'amuse pas plus d'avoir des contributeurs pas heureux (qu'eux de ne pas l'être). Et puis tant pis si on attend quelques années de plus pour l'outil rêvé.
Surtout que je pense qu'optimiser du code est aussi une activité tout à fait sympathique. J'ai déjà travaillé sur des outils que j'ai passé un temps fou à essayer d'optimiser (par exemple la colorisation intelligente qui était un algo du CNRS originellement mais que j'ai rendu plus utilisable et surtout beaucoup plus instantané).
Franchement c'est aussi jouissif d'arriver à soudain avoir une utilisation quasi temps réelle d'un outil qu'on attendait constamment que ça l'était d'obtenir un outil qui marche (lentement) lors de l'implémentation initiale. De même que ces derniers temps, Aryeom et moi avons fait beaucoup d'itérations pour maintenant améliorer l'interface de cet outil de colorisation et son utilisation (notamment la compréhensibilité des options). Ça aussi (travail UX) est super intéressant. Ce sont toutes des étapes différentes mais chacune vraiment prenante à sa façon. Peut-être qu'un développeur qui va jamais jusqu'au bout et veut juste la partie facile s'est trompé de voie? Je sais pas... je m'interroge (perso je ne fais pas partie des gens qui pensent que le travail est juste un "gagne-pain" en attendant la retraite; on y passe une majeure partie de sa vie, il faut y être heureux aussi). 🤷 En tous cas, on devrait pas avoir à leur mettre la pression, ça c'est certain!
Un petit détail sur ce point précis. On ne cherche pas particulièrement l'ultra-optimisation de code. J'ai déjà lu des articles de gens qui parlent de certaines techniques, et ce que je vois dans les articles, c'est que ça peut rendre parfois le code tellement imbitable que ça en serait in-maintenable. Rien n'est pire que le code qu'on ne comprend pas sans y passer des jours (les bugs y restent des années et des années parce que personne veut toucher ce code).
Ensuite qu'on me fasse pas dire ce que je n'ai pas dit: bien connaître les structures de données, etc. c'est important. Mais parfois la lisibilité du code est bien plus importante que des centaines de micro-optimisations basée sur une connaissance avancée du langage.
Disons juste qu'il y a un intermédiaire entre du beau code très simple (l'implémentation "naïve" qui est souvent la plus belle et compréhensible mais aussi parfois trop lente) et du code imbitable qui va utiliser des techniques obscures et inconnues de compilateurs ou des structures de données sous-jacentes.
Ensuite je sais pas si c'est ce que ton ami appelle le C ultra-optimisé (ça m'a juste fait penser à des articles que j'ai lu, dont un y a vraiment pas longtemps, mais j'arrive plus à me rappeler où)! 😜
En contre-exemple, j'explique un peu dans ce document comment j'ai fait évolué l'algorithme de colorisation intelligente de l'équipe G'MIC/CNRS, voire ai changé des morceaux ou bien ai utilisé des astuces d'interface pour l'améliorer: https://developer.gimp.org/core/algorithm/line-art-bucket-fill/
On notera que pour toute la partie "optimisation", en plus des optimisations habituelle sur le code C lui-même (sans pour autant aller jusqu'à des techniques ultra-avancées en optimisation C), déjà j'ai fait évoluer l'algorithme lui-même (on y gagne 100 fois plus que toute "ultra" optimisation C). Par exemple pour l'étape 3 de "flooding", j'ai simplement utilisé un algo perso basé sur la connaissance qu'on avait déjà des traits et de leur épaisseur locale (info qu'on a calculée pour l'étape 2).
En plus de l'amélioration algorithmique, j'ai travaillé sur des logiques de travail en "interface graphique", notamment le fait qu'on sait que le graphiste n'est pas aussi instantané qu'une machine et donc il y a du temps entre 2 clics. Donc autant simplement pré-calculer le plus possible dans ce "temps mort" dans des threads (quitte à faire parfois du calcul qui sera perdu comme tout pré-calcul qui est un pari sur l'avenir).
Puis il y a plusieurs optimisations au niveau de l'UI et même la possibilité d'exclure explicitement (par les options) les parties complexes (ce qui implique pour l'artiste de comprendre un peu la logique interne de l'outil, mais c'est ce que les utilisateurs avancés font de toutes façons).
Sincèrement pour les étudiants, déjà trouver ceux qui sont des développeurs sérieux tout court me semble une denrée rare. On en a eu un(e) cette année, qui en plus est très intéressé(e) (et intéressant!) et qui continue à contribuer! C'est d'ailleurs la raison pour laquelle on a fait le GSoC cette année, après 9 ans sans le faire. Cette personne nous avait en effet proposé d'y participer (après quelques patchs où elle a montré faire du bon travail), on s'est donc inscrit et répandu la nouvelle pour avoir potentiellement d'autres étudiants.
Dans les autres propositions qu'on a reçues, presque aucun ne semble même avoir lu notre news, n'a tenté de corriger quelques bugs au préalable, ni n'a montré avoir même déjà compilé le code (on peut voir venir gros comme une maison de passer les 2 premières semaines à essayer d'expliquer comment compiler GIMP!). Ou simplement personne (enfin presque, y en a un autre en fait — je suis mauvaise langue — mais c'est pas allé loin!) n'a essayé de nous contacter pour discuter avec nous sur IRC. Je parle même pas d'être un développeur de génie (cela ne m'intéresse pas plus que ça), mais juste quelqu'un de curieux et qui intéragit avec nous.
Donc avant de leur parler d'apprendre à optimiser, ou même d'apprendre à coder bien, ou autre truc avancé, faut déjà leur apprendre à discuter, prendre contact (comme le font les humains) et à apprendre à apprendre. Une chose que j'ai apprise en tant que développeur, c'est que rien n'est réellement difficile, par contre tout est simplement du boulot: ça prend du temps, on se torture les méninges, on est frustrés constamment... jusqu'au moment où on y arrive. Un bon développeur n'est donc pas celui qui est expert dans une technique particulière ou sait faire du code ultra-optimisé ou ceci ou cela. Il fait juste ce qu'il faut faire en fonction de la situation et s'adapte, en utilisant son cerveau pour décider. Et aussi rester toujours humble sur ce qu'on sait ou pas (sincèrement, y a tellement de sujet possibles, on apprend constamment).
Donc non, on cherche pas forcément des experts de l'ultra-optimisation et je pense pas forcément que ce soit l'une des compétences les plus importantes à apprendre pour ces étudiants. Ce n'est pas ce qu'on leur demande. 😆
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]