Julien Jorge a écrit 530 commentaires

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.

Il y a une implémentation de Spectre en Javascript, décrite dans le papier original. Il risque donc de voir sa mémoire lue par un script tiers juste en navigant sur le web.

Ça fonctionne super bien. J'ai mis le script sur mon portable et je ne remarque pas de latence :)

Pour les samples j'ai trouvé quasiment tout sur freesound.org sauf le bass drum.

Merci bien d'avoir partagé.

Comment gères tu le proxy sur un ordinateur portable qui peut rester longtemps loin du NAS ?

Pour ma part j'ai un script /etc/NetworkManager/dispatcher.d/99SetAptProxy avec le contenu suivant :

#!/bin/sh

SERVER=<hostname du nas>
PORT=3142
PROXY_FILE="/etc/apt/apt.conf.d/99Proxy"

if nc -w 1 $SERVER $PORT
then
    printf 'Acquire::http::proxy "http://%s:%s";' $SERVER $PORT \
        > $PROXY_FILE
else
    rm -f $PROXY_FILE
fi

En gros ça teste si le NAS est dispo, auquel cas ça active le proxy, sinon ça le désactive.

Effectivement je ne suis pas passé par les SSII, cela doit jouer. Les entreprises où j'ai travaillé étaient des éditeurs et plutôt petits.

Ah la négociation, les salaires, les primes :) je te retourne la question : as-tu déjà été tellement déçu de te voir refuser une augmentation que tu t'es mis à surestimer ta charge de travail et à prendre des notes pour pourvoir retourner les choses contre tes patrons ?

Mmmh j'ai un peu de mal à te suivre. J'ai pourtant l'impression d'être dans le monde du travail (le vrai, pas celui des Hainounours). Sans être un monde idéal il est loin du monde amer que tu décris où les hauts gradés veulent écraser les plus petits qui en retour sont sur la défensive.

Ce que tu nous décrit ressemble plus à l'image du monde de grand papy, où le travail était avant tout une corvée et où on bossait pour rien jusqu'à se faire virer. Enfin j'imagine, je n'ai jamais connu ça. Heureusement pour nous l'informatique est un domaine où on peut encore choisir son employeur et où beaucoup, beaucoup, de personnes sont passionnées ; ce qui fait qu'on peut facilement se trouver dans une équipe que l'on est content de rejoindre quotidiennement.

À vrai dire, dans la mesure où le travail consomme quasiment un tiers de notre temps, si quelqu'un se lève tous les jours pour faire quelque chose qui lui déplait et passer sept heures par jour sur la défensive et dans le conflit alors qu'il a la possibilité de simplement traverser la rue pour vivre autre chose, j'ai l'impression que le problème est chez cette personne, sûrement pas dans le métier. Je ne doute pas que certains sont coincés par une raison où une autre, mais dans l'absolu je doute que ça vienne du fait d'être dans l'informatique.

Ce principe du conflit par défaut entre les patrons et les salariés, dans l'informatique au moins, me semble éculé. Peut-être suis-je naïf et que je changerai d'avis si un jour un patron me fait un sale coup que je n'aurai pas vu venir. Peut-être serai-je alors incapable de lui dire « au revoir, et merci » pour partir chez un autre. En attendant aujourd'hui je vois partout des boites où il fait bon travailler et où on peut aller en souriant.

Ton commentaire et celui de Christophe B. me font remarquer que je ne m'étais jamais demandé ce qu'était un professionnel en fait. Je suis loin des trente années d'expérience et à vrai dire j'avais plutôt le sentiment que le terme « professionnel » était un peu galvaudé aujourd'hui. Il me semble, mais mon regard est peut-être déformé, qu'on trouve assez facilement des gens avec ce libellé qui s'avèrent finalement être surtout de beaux parleurs dont les actes ne sont pas au niveau de leurs promesses ou bien dont le comportement est douteux.

Dans ma courte expérience je n'ai pas eu le sentiment que ces comportements que nous décrivons étaient attendus ou encouragés. Je les ai observés mais j'ai toujours eu l'impression que c'était plus le résultat d'une motivation individuelle que d'un désir commun ; comme s'ils étaient implicites. Cela me semble bizarre en particulier vis-à-vis des juniors qui entrent dans le métiers et qui se retrouvent à devoir deviner par eux-même quels sont les comportements qui agissent pour le bien commun et lesquels sont parasites. Pour prendre une analogie, c'est comme si on entrait dans le métier aux côtés de Linus Torvalds, Ulrich Drepper, Jeff Atwood et Robert C. Martin et qu'on nous disait « choisis ton modèle ». Quelle proportion de débutants comprendraient qu'on peut être d'un haut niveau technique tout en ayant des rapports humains intéressants ? J'ai personnellement le sentiment que l'on a tendance à négliger les retours positifs, ne serait-ce que « nous avons fait du bon boulot » ou « je trouve que l'équipe a bien fonctionné ».

Concernant ta remarque sur les paroles et les écrits, que Christophe B. et blabla ont l'air de rejoindre, je trouve, peut-être naïvement, que cela fait un peu vieille informatique. Peut-être est-ce un problème d'échelle de boîte car dans celles où j'ai travaillé, où les équipes sont de taille humaine et le patron est à n+1 et derrière une porte (toujours ouverte) dans la pièce d'à côté, je n'ai jamais vu quelqu'un chercher un coupable pour quoi que ce soit. Quand tout va bien c'est parce que nous avons tous assuré, quand tout va mal c'est parce que nous avons tous raté. Il y a évidemment parfois des désaccords, qui sont simplement évoqués dans les rétrospectives de sprint, puis tout le monde s'arrange pour trouver un compromis et s'y tient. Bien sûr ce n'est pas sans accrocs, il y a aussi des disputes, des démissions ou des licenciements, mais globalement j'ai le sentiment que tout le monde fait simplement de son mieux pour que ça se passe bien. C'est très différent du comportement défensif que blabla et toi décrivez. À nouveau, peut-être est-ce lié à l'échelle de la boîte ?

Ça aurait pu ! En l'occurrence c'était du Visual Basic…

Le plus terrible dans l'apport de nouvelles fonctionnalités est pour moi de n'avoir aucun retour sur la contribution. Il y a plusieurs outils tiers dans lesquels je me retrouve à faire des modifications au boulot, soit parce que j'ai des soucis à la compilation, soit parce que j'ai besoin d'une fonctionnalité, et depuis quelques temps j'essaie de remonter les modifications pour jouer le jeu du libre et aussi pour éviter d'avoir à les réappliquer quand je mets l'outil à jour. Bilan des courses, cinq pull requests, zéro merge et un seul retour.

Par exemple, ajouter la composition de skins à un outil d'animation. Aucun retour. Est-ce trop gros ? Est-ce inintéressant ? J'appuie ma demande en citant trois entrées de forums qui demandent cette fonctionnalité mais les devs laissent dormir la requête.

Sur un autre projet, je modifie la gestion des polices pour avoir un comportement homogène sur iOS, Android, Linux et OSX. Premier retour en une semaine et une demande de correction en un mois. Je traîne un peu et presque trois mois plus tard j'envoie les corrections. Et là c'est le silence. Je me dis que la pull request est trop grosses et je tente d'autre demandes, plus petites et triviales mais rien n'y fait, c'est toujours le silence.

C'est assez difficile de rester motivé quand les contributions tombent ainsi dans l'oubli.

J'ai eu la même réaction sur le prix, 800 € c'est vraiment peu cher payé.

Encore plus étonnant, tel que le journal présente le concours j'ai l'impression qu'il y a 10 « gagnants » mais qu'un seul récupère les sous.

Tout à fait. Voici une présentation sur ce sujet.

Il y a d'autres vidéos de la CppCon 14 qui ont le même discours. En gros ils nous disent « on voulait que ça aille vite alors on a fait des tableaux de POD et du traitement en lot ».

Pour l'orthographe j'utilise flyspell qui met les mots mal orthographiés en évidence au fur et à mesure de la frappe. Je ne sais pas si on peu lui faire utiliser hunspell pour profiter des déclinaisons ; quelqu'un a-t-il déjà essayé ?

Alors ça ne fonctionne toujours pas, par contre si dans la la configuration du serveur DHCP je met des IP fixes associées à certaines machines, alors ces machines ont le bon DNS et arrivent à résoudre le domaine. J'aimerais bien avoir ce comportement sans IP fixe.