Julien Jorge a écrit 718 commentaires

Je suis un peu du même avis que Tanouky. ZeMarmot est un projet génial et j'admire tout ce que tu produis pour GIMP mais je pense que tu mènes trop de combats simultanément. Sur certains aspects je retrouve ce que j'ai vécu en mon temps alors que je développais Plee the Bear.

J'apprécie réellement le regain d'énergie dans GIMP, les sorties fréquentes, la réactivité améliorée, etc. J'en profite pour te remercier d'ailleurs car c'est clairement grâce à toi. Tu es un excellent développeur pour GIMP, c'est un métier, ça te demande beaucoup de temps et d'énergie et ça ne t'apporte pas de quoi vivre.

Tu rédiges d'excellents articles pour parler de GIMP et de ZeMarmot que je lis avec grand plaisir sur LinuxFr. De fait, tu t'occupes des relations publiques (RP). C'est un métier aussi ; te voilà avec deux jobs. Je ne sais pas quel est ton débit d'écriture, personnellement il me faut plusieurs jours pour écrire des articles comme les tiens, le temps d'appuyer les affirmations, concevoir les illustrations et corriger en relecture. Là encore c'est du temps, de l'énergie, et ça ne t'apporte pas de quoi vivre.

À côté de tout ça tu t'occupes de l'association LILA et tu organises des ateliers, expositions, etc. Hop, ça te fait un troisième job :)

Félicitations, très sincèrement. Ce que tu construis est titanesque.

Maintenant laisse-moi te parler de ma propre expérience. Il y a 13 ans je me suis lancé avec un ami développeur dans le développement de Plee the Bear, un jeu vidéo libre. Quand je dis « libre » je parle bien d'un projet totalement libre ; code en GPL, assets en CC-by-sa, et développé uniquement avec des logiciels libres : sous Linux, avec GIMP, Emacs, Rosegarden… D'ailleurs je notais même dans les notes de la première version que « même la version Windows est compilée sous Wine avec des logiciels libres. » Je pense que tu te retrouves dans cette approche, non ?

L'expérience fut plutôt agréable, nous avions beaucoup de plaisir à développer le jeu, nous l'avons présenté aux RMLL à deux reprises, nous l'avions présenté dans des soirées dans un bar nantais. Ce furent de bons moments et nous avions des retours très encourageants. Nous avions écrit une bible du jeu et nous avions fait une demande de financement au CNC (que nous n'avons pas obtenu). Quand je regarde tout ça j'apprécie encore la richesse de ce que nous avions imaginé et toute l'expérience de production que cela nous a apporté.

Nous avons passé énormément de temps à développer notre jeu sans voir, comme quasiment tous les jeunes développeurs indépendants, que nous allions dans le mur. La finalité n'était même pas de gagner de l'argent avec ce jeu, mais simplement de le finir pour que les joueurs le voient. Nous étions convaincus que le projet serait plié en trois ans.

En réalité nous avons passé notre temps sur des problématiques techniques, à ajouter des trucs dans le moteur pour que le développement soit plus simple, pour que notre jeu soit plus fun ; tout sauf la réalisation du jeu en lui-même. Nous n'allions nulle part.

Un peu comme toi, nous avions un point de vue produit très orienté technique et outils, et éthique bien sûr : tout est libre ! Quand il fallait parler du produit c'était un énorme effort de notre part et les retombées étaient très faibles. La rédaction d'articles comme tu le fais était une vraie corvée pour moi et lorsque je les publiais je voyais surtout la quantité de choses que nous souhaitions et qui n'était toujours pas commencée. Nous aurions voulu des contributeurs, des dons, ne serait-ce qu'en guise de motivation, mais l'effort pour les obtenir étaient démesurés. Toi tu gères bien la communication et pourtant j'ai l'impression que les contributions sont aussi très faibles.

Maintenant tout cela est loin, j'ai un peu de recul et j'ai l'expérience du développement de jeux vidéos dans un vrai studio. Maintenant je me dis « qu'est-ce que j'imaginais ? ».

Après quelques mois dans ce studio je me disais déjà que c'était incroyablement confortable d'avoir quelqu'un de différent sur chaque poste : programmeur, producteur, illustrateur, UI/UX, mais surtout un commercial, un responsable RP… Nous avons développé de nombreux jeux, certains ont coûté énormément d'argent, d'autres ont étés développés en mode éco. Et finalement, comme tout le monde dans le métier, nous devons admettre qu'il n'y a pas de recette. Il ne suffit pas d'y croire, ni d'investir énormément ; des fois ce que l'on croit être un hit est un flop, ce que l'on croit être sans valeur met à manger dans nos assiettes. Nous sommes quarante et nous sommes tous bons dans nos métiers respectifs, pourtant nous ne somme pas à l'abri de l'échec. Alors franchement, qu'est-ce que j'imaginais ?

Et toi, qu'imagines-tu ?

Que ZeMarmot, LILA et GIMP t'apportent une satisfaction personnelle, je n'en doute pas. Que tu obtiennes un salaire régulier via des dons, ça commence à être chaud. Que tu trouves des mécènes pour couvrir tout le développement de ZeMarmot, je pense que c'est utopique. Tu parles de construire un studio autour d'un produit et je me demande surtout si ce produit sortira un jour.

Si je comprends bien ton discours tu investis du temps dans tes projets et les financements serviront au final à acheter plus temps, celui de l'équipe en place pour qu'elle s'investisse complètement et celui de tiers qui viendront grossir l'équipe. Ça me semble assez classique. D'où ces financements peuvent-ils venir ?

• Les dons. Tu en demandes et en reçois depuis longtemps maintenant, et c'est loin de couvrir un salaire. Je pense qu'aujourd'hui tous ceux qui étaient prêts à te faire un don sont au courant, l'ont fait ou le font régulièrement. Je doute que ça puisse encore augmenter de manière suffisante. D'ailleurs, connais-tu d'autres personnes qui vivent convenablement de ce genre de dons ? Que représentent-ils dans la masse des gens qui souhaitent vivre de ce mode de financement ? Beaucoup de projets très utiles sont développés par des passionnés qui n'en tirent aucun bénéfice financier, pas même de quoi vivre dans le confort qu'ils souhaitent. Comment vas-tu faire mieux ?

• D'un appel à financement type Ulule, Kickstarter… Organiser une campagne de financement est déjà un job à plein temps, te voilà avec un nouveau métier :) Combien vas-tu demander ? As-tu une idée du coût de production pour terminer ZeMarmot ? Pour le diffuser ensuite ? Demanderais-tu une petite somme juste pour prendre la température ? Comment financerais-tu la suite ?

• D'un job alimentaire, de commandes client qui vont te demander du temps de prospection, de suivi, de réalisation et qui peuvent entrer en conflit avec tes principes. C'est jouable et ça revient à gérer deux entreprises en simultané. As-tu du temps pour ça ? Veux-tu doubler ta charge de travail ? Es-tu prêt à déléguer le développement pour devenir gérant ?

• D'investisseurs, d'un prêt bancaire. Ces gens te prêteront de l'argent contre une promesse de remboursement dans un délai raisonnable et contre un investissement de ta part en fonds propres. Arriverais-tu à les convaincre ? As-tu une grosse somme d'argent à investir dans ton projet en guise de preuve que tu y crois ? As-tu réalisé un budget prévisionnel ? Comment les investisseurs récupéreront leur argent ? Comment financeras-tu les productions suivantes ?

Toutes ces questions, je les ai ignorés en mon temps. Tout d'abord je n'en avais pas conscience, puis lorsqu'on m'a orienté sur ces problématiques mon cerveau de techos les a gentiment ignorées et est retourné se pencher sur des problématiques de développement. Malheureusement c'est hyper classique, tous les jours des créatifs sortent des produits qu'ils aiment de toute leur âme et qui tombent dans l'oubli en une minute. Nous avons les yeux sur notre produit et nous ignorons que le monde c'est avant tous les autres. Le monde est fait de beaucoup, beaucoup de gens qui ne sont pas dans notre délire ; beaucoup de gens qui sont tout simplement inconscients de ce qui est nécessaire pour produire ce qu'ils consomment.

Moi et d'autres nous avons ignoré ces problématiques, et toi es-tu prêt à te pencher dessus ? Je suis quasiment sûr que lire tout cela t'es désagréable mais, sincèrement, je te souhaite de passer au niveau au dessus et de réussir sur ces points où beaucoup ont échoué avant toi.

Imagine : ZeMarmot est réellement terminé, complètement monté, les DVDs sont pressés. Ignorons un instant comment le projet en est arrivé là. Que se passe-t-il ensuite ? Qui vend le produit ? Où ? Combien ? Disons que l'asso ne doive d'argent à personne pour en arriver là, que va rapporter ce film ? Quelle est sa durée d'exploitation ? Combien doit-il rapporter pour couvrir une seconde production ? Pendant combien de temps supporteras-tu le mode de financement aux dons ?

Tu es très talentueux, de même qu'Aryeom, et vous investissez beaucoup d'énergie dans ces projets. C'est très bien si le but est d'acquérir de l'expérience, de devenir meilleurs dans vos métiers. Mais si vous souhaitez en vivre je vous conseille de reprendre les bases : combien ça coûte, où est l'argent, comment le récupérer. Adoptez un commercial ou un producteur, adaptez votre produit aux potentiels de revenus. Pour l'instant je vois malheureusement surtout beaucoup d'énergie dépensée dans un projet à l'avenir incertain et prenant une route extrêmement difficile :/

Ainsi que http://www.lebottindesjeuxlinux.tuxfamily.org/en/home-en/

Si un modérateur pouvait gentiment corriger

Fait.

Là où les autotools faisai en t : (petite erreur d'accord)

Corrigé, merci.

Alors, comme je suis l'auteur du journal cité je peux préciser :)

Je n'ai jamais utilisé Meson et par conséquent je n'ai pas d'avis sur la façon dont l'outil est développé ni sur son approche de la gestion du build.

Je suis néanmoins déçu de voir que la caractéristique mise en avant est « ça va vite » parce que le temps de configuration et de compilation sont loin d'être les premiers de mes soucis. Pour les tailles de projets sur lesquels je travaille il n'y a pas de problème de temps de configuration avec CMake et pour la compilation de ces projets ninja ne fait pas mieux qu'un make -j$(nproc). Mon principal problème est surtout d'avoir des builds simples à gérer pour quatre plates-formes. Moins j'ai de spécificités à gérer, mieux je me porte.

Chromium est souvent pris en exemple pour appuyer le fait que Ninja (principal backend de Meson) est bien plus rapide que Make mais il ne faut pas oublier que c'est un projet de plusieurs dizaines de millions de lignes de code. C'est loin d'être un projet de taille moyenne.

Quelque part je me dis que le temps passé à développer Meson aurait été mieux investi à améliorer CMake (qui peut aussi générer des scripts Ninja), mais bon la concurrence a aussi du bon. Quand je vois les progrès de Firefox depuis l'arrivée de Chrome je me dit que ça peut avoir de bons côtés.

Où sont passées les recettes ? Et la rubrique nécrologique ? Et les critiques de films ?

Quand je suis arrivé il y avait aussi des jeux amateurs, on présentait nos projets et c'était cool. Maintenant c'est 0 A.D. ou 0 A.D.

Pour les motards je sais ! Le dernier journal de motard a été suivi par un journal qui dénonce grave d'un utilisateur moqueur à son sujet, et au sujet de mon dernier journal en date. C'était d'ailleurs la première contribution de cet utilisateur, qui en profitait pour nous annoncer son départ ! Un bien beau journal bien noté, quelle tristesse.

Moi j'aimais bien tout ça, et je ne suis même pas motard, ni même bronsonnisé. Il reste encore le rituel des journaux qui précèdent et suivent les keynotes Apple mais même eux se font descendre.

LinuxFr.org change, tant pis ou tant mieux.

Ma première réaction était « mais pourquoi met-il les résultats en cache alors que le compilateur va tout calculer à la compilation ? ». prime_sieve::operator()(uint64_t) est constexpr, du coup le compilateur peut l'exécuter pour les paramètres connus à la compilation. Autrement dit, ça fonctionne très bien sans memoized :

int main(int argc, char** argv) {
  prime_sieve ps;
  // les appels à ps(…) sont remplacés par le résultat dès la compilation.
  std::cout << ps(7) << " " << ps(100) << "\n";
  return 0;
}

En fait là où c'est très intéressant c'est quand les paramètres ne sont pas connus à la compilation. Dans ce cas memoized::operator() sera effectivement appelée au runtime et l'appel pourra profiter des valeurs qui auront été mises en cache à la compilation.

PS : je pense qu'il y a une typo dans la condition d'arrêt de ta boucle, i < v devrait être i < n, non ?

Une des nouveautés que je préfère dans GIMP 2.10 est l'aperçu des filtres directement sur le canvas. Est-ce que cela est possible avec les filtres de G'MIC ?

Quid des calques d'effets et de l'édition non destructive qui devraient arriver un jour ?

Christie Poutrelle dit :

[…] un bon éditeur saura faire du surlignage de différentes couleurs selon la portée de la variable […]

Barmic dit :

[…] une info que mon éditeur est tout à fait en mesure de me restituer via la couleur.

Je sais que c'est un débat sans fin mais je demande juste pour comparer nos méthodes, sans vouloir militer :

Comment vous en sortez vous quand vous devez lire du code hors de l'éditeur ?

Perso je me retrouve régulièrement à lire du code un peu partout : un bête terminal, parfois en remote sur un serveur peu equipé, un navigateur web (GitHub, UpSource), dans un courriel, sur mon téléphone… Je ne peux pas toujours compter sur une coloration sémantique.

Pour faire un truc générique je pense que j'aurais mis une association entre les tuples de paramètres et les instances créés. Forcément j'aurais du user de type erasure et ça serait devenu hyper compliqué pour un truc qui n'aurait géré que deux ou trois instances au final.

Comme barmic je pense que ton besoin est une factory plutôt qu'un singleton. Plus précisément, une factory de shared_ptr<A>, pas de A. Mais je me demande quand même si ça vaut le coup de détruire l'instance de A si elle risque d'être recrée par la suite. Pourquoi ne pas là garder ? D'ailleurs ne pourrais-tu pas simplement créer l'instance au lancement, dans une étape de setup, ce qui te permettrait d'utiliser une autre instance pour tes tests.

Ça oblige à compiler deux fois et c'est la porte ouverte à des comportements différents en test et en prod :/

Moi j'aime bien quand il n'y a qu'un seul flot d'instructions et quand les tests utilisent les mêmes binaires que le produit principal.

L'interface n'est pas très claire, quand on passe des paramètres à createA il n'y a pas de garantie qu'ils soient utilisés pour instantier A. Par exemple :

int main()
{
    auto a = createA(1, 2);
    auto b = createA(2, 3);
    return 0;
}

Le deuxième appel ne va pas créer de A mais c'est impossible à deviner pour l'appelant. Et du coup les paramètres sont passés pour rien.

Est-ce qu'il y a beaucoup de libs déjà packagées avec Conan ? Par exemple j'ai cherché un jsoncpp compilé pour Linux, pour faire simple, je ne l'ai pas trouvé. Est-ce qu'il y a des libs précompilées pour Android, iOS et OSX ?

Nous l'avions considéré fut un temps mais au final nous sommes partis sur un autre outil car nous avions besoin de gérer des dépendances plus variées comme des frameworks de divers fournisseurs de services ainsi que le SDK et le NDK d'Android.

Pour être tout à fait honnête je pense que le temps de build un peu long avec Gradle est surtout lié au fait que la cible soit Android. Il y a des étapes d'empaquetage (assets, apk) et de fusion de dex qui sont bien coûteuses et que l'on ne trouve pas dans un projet Java classique.

En dehors de l'excuse « pas-le-temps-après-tout-ça-marche » nous n'avons pas encore remplacé Premake par CMake car il y a des subtilités dans la génération du projet XCode dont j'ignore si elles sont gérables par CMake. Je parle de patches que nous avons dû appliquer à la génération du pbxproj dans Premake.

Tout d'abord il y a le fait que nous utilisons encore la sélection manuelle du provisioning profile. Il faut mettre la propriété ProvisioningStyle = Manual dans les attributes.TargetAttributes des targets dans le pbxproj.

Ensuite il y a les capabilities (push notifications et autres). Il faut les lister dans SystemCapabilities.

Nous avons aussi dû ajouter une option SKIP_INSTALL sur les libs pour éviter qu'elles soient embarquées dans l'ipa.

Enfin nous avons dû ajouter un moyen de marquer les frameworks comme optionnels afin de pouvoir lancer l'app sur de vieux appareils qui n'ont pas l'OS nécessaire pour la fonctionnalité (par exemple quand ReplayKit est arrivé nous voulions que l'application puisse se toujours se lancer sur les versions précédentes d'iOS. Nous testons alors à l'exécution si le framework est disponible).

Tous ces problèmes ont été trouvés au fil de l'eau et le système de plugins en Lua de Premake nous a permis de trouver des solutions assez rapidement. Je ne sais pas si cela aurait été aussi simple avec CMake.

Alors suite à ton commentaire j'ai fait le test sur iscool::core et le gain n'est pas flagrant.

$ time make -j 4
real    0m29,490s
user    1m36,778s
sys 0m5,436s

$ time ninja -j 4
real    0m28,451s
user    1m39,555s
sys 0m4,701s

C'est peut-être un projet trop simple, pas assez gros. D'expérience le changement le plus efficace pour accélérer les builds a été de passer aux single compilation units (SCU), où on inclut plusieurs .cpp dans un seul pour les compiler en une seule fois et d'utiliser des instanciations explicites de templates. Après ça je n'ai pas vu de gain radical.

Quelqu'un a-t-il vu une comparaison de temps de build de projets utilisant des SCU avec Ninja, Make ou autre ? Il y a bien ce comparatif sur le site de Meson mais on ne parle pas de SCU ici.

C'est un peu dommage que les premières nouveautés listées soient techniques (un moniteur système et les rapports de crashs). J'aurais plutôt mis en avant les nouveautés concernant le dessin numérique qui viennent après.

Cela dit c'est cool de voir la sortie s'approcher :)

Ça me semble délicat de faire plus petit tout en restant dans le style du site, en gardant l'avatar, les tags et les divers liens, mais si quelqu'un veut tenter je veux bien voir ce que ça donne.

Après l'affichage en table comme par exemple dans l'espace de rédaction ça me perturbe plus qu'autre chose pour un contenu chronologique. Je ne sais pas s'il faut lire les lignes avant les colonnes sans regarder les dates.

Ça me semble délicat de faire plus petit avec l'avatar, les tags et tout le reste. Il y a peut-être moyen de présenter la page autrement avec la CSS mais il faut quand même que ça colle au style du site.

Il n'y a pas de critère d'unicité pour l'instant mais c'est une bonne idée. En attendant on peut faire comme pour les journaux : moinser et faire remarquer que ça a déjà été posté :)

La question de mettre un champ de description plus long a été discutée avec les modérateurs lors du développement. Je ne l'ai pas mis pour l'instant car je pense que cela ferait doublon avec le fonctionnement des journaux. L'idée est ici de simplement relayer une information. Si l'auteur souhaite ajouter une description libre à lui de faire un journal plus détaillé.

Quant à la formulation du titre, sensationnel ou pas c'est une question qui concerne celui qui soumet le lien. La fonctionnalité en elle-même n'impose rien et ne peut rien imposer à ce niveau.

C'est pour moi toute la difficulté de la gestion des dépendances. Faut-il lier une bibliothèque externe, la gérer comme un bloc immuable et ainsi profiter de l'expérience des autres ? Faut-il la copier-coller dans le projet pour en faire la base d'un outil interne que l'on peut modifier librement au risque de compliquer ses mises à jour ?

Il y a des outils que l'on prend tels quels, Boost bien sûr, Google Breakpad, Google Test, JsonCPP, entre autres. Ce sont des outils assez gros et nous ne ferions probablement pas mieux en les réécrivant. Néanmoins si nous avions au moins fait une interface à JsonCPP nous aurions sans doute pu simplement changer pour rapidjson ou autre le jour où nous l'avions envisagé. Celui là a par exemple été à la fois un accélérateur et une gêne.

À côté de ça il y a des outils que l'on aurait bien voulu prendre tels quels, Cocos2d-x, MoFileReader, Spine, Soomla, mais le besoin a appelé des modifs et les mises à jour sont de plus en plus difficiles.

Alors est-ce qu'on aurait vraiment gagné du temps ou de la performance en piochant dans libc++ ? Pour l'inclusion d'optional par exemple, on part sur Boost, la compilation est lente (300 ms. sur mon pc pour un g++ -c test.cpp où test.cpp ne contient que #include <boost/optional.hpp>). Je teste avec la STL en c++17 : 250 ms. bof. Alors nous l'implémentons à notre sauce, ça coûte quelles que heures de dev, je teste la même compilation : 30 ms. Et quand je teste en essayant de copier la version de libc++ ça ne compile même pas car il manque des dépendances :/

Dès fois c'est plus simple de prendre un outil existant tel quel, d'autres fois c'est la plaie. Parfois, comme avec libc++ ici, il faut passer du temps à gérer la compilation ou à extraire la seule partie qui nous intéresse. Pour moi le problème est loin d'être simple. Et encore là je parle de compilation desktop mais en pratique nous faisons des builds iOS, Android, OSX et Linux.

En ce moment je regarde d'ailleurs la gestion de dépendance avec Conan et je dois me faire violence pour plonger dedans plutôt que de bêtement compiler des .a et les archiver sur un bucket S3. Il me semble que tu avais regardé ces outils de gestion de dépendance en c++, en utilises-tu ?

Oui beaucoup d'éléments sont déjà présents dans d'autres libs. Pour les exemples std::integer_sequence et std::make_unique que tu cites c'est tout simplement que notre développement est calé sur c++ 11 et tout cela n'est dispo qu'à partir de c++ 14, donc indisponible pour nous. Nous aurions pu utiliser les versions de Boost ou autres mais comme dit dans le journal nous avons eu de mauvaises surprises sur les temps de compilation avec Boost, donc nous sommes parti sur une version maison maîtrisée. L'idée étant d'avoir cette implémentation en attendant de faire le passage à c++ 14 ou plus, après quoi nous les supprimerons ou les remplacerons par des alias vers la STL.

Les tableaux ne sont pas gérés par make_unique simplement parce que nous n'en avions pas besoin. Si nous l'avions implémenté ça aurait été l'équivalent d'un code mort pour nous, qui aurait coûté du temps de compilation et de maintenance pour aucun gain.

Le dépôt GitHub a été créé avec le code dans l'état dans lequel nous l'utilisons, ce qui ne colle pas toujours à un besoin général, j'en suis conscient. Il y a un paquet d'autres trucs moyens que je ne réutiliserais probablement pas à titre perso et d'autres que j'apprécie assez (heterogeneous_map, le module jni, par exemple). Cela dit si nous avions pris le temps de tout rafraîchir et d'améliorer tous les points faibles que nous voyons nous n'aurions jamais été suffisamment satisfaits pour le sortir.

Justement non :) c'est le type de doc que je trouve plus polluante qu'autre chose. Je pensais plutôt à des trucs comme la doc de Boost, hors du code, bien structurée et pédagogique, avec un point de vue global sur la lib.

Je te rejoins sur l'intérêt d'une doc meta et c'est ce que j'ai en tête quand je dis que je cherche une solution pour faciliter la compréhension du dépôt sans pour autant rédiger deux cent pages de doc. L'idée serait d'avoir une description générale du fonctionnement des modules, sans aller dans la description des détails dans le code.

Ce que nous avons supprimé ce sont les commentaires du type

/** The size */
std::size_t _size;

}; // class container

Et autres descriptions de classes et fonctions qui ne font que reformuler ce que dit le nom de la classe ou de la fonction. Ce genre de commentaire se trouve malheureusement assez facilement, même dans des projets de sources respectables (un exemple, un autre et il nous semble que cela est plus gênant qu'autre chose. Du coup le commentaire systématique de chaque identifiant, nous le faisions il y a quelques années et nous avons laissé tomber.

Là il n'y a pas de doc globale simplement parce qu'en pratique nous n'en avons pas besoin : tous les développeurs font les revues de tous les autres, y compris les nouveaux venus. Si nécessaire on échange sur les points peu clairs. À notre échelle ça suffit mais je suis bien conscient que ça ne suffit pas pour le grand public ou si tous nos développeurs partaient en même temps.