rewind a écrit 3412 commentaires

Du coup, j'ai trouvé. La version de zlib utilisée par OpenBSD est un peu trop vieille (version 1.2.3). La fonctionnalité avec le const a été introduite dans la 1.2.5 (en 2011).

Si tu veux patcher proprement, tu peux remplacer la ligne par:

stream.next_in = const_cast<Bytef*>(input.data());

Merci pour ce retour !

Pour la première erreur, je vais la corriger, c'est bien une vraie erreur.

Pour la seconde, c'est un truc bizarre de zlib. Normalement, l'erreur ne devrait pas arriver. En fait, les fonctions et les structures de zlib sont définies sans const. Mais on peut ajouter des const partout où on veut simplement en définissant ZLIB_CONST à la compilation (via -D), ce que je fais dans mon CMakeLists.txt. Ici, j'ai l'impression que cette constante n'est pas définie, ce qui provoque une erreur. Est-ce que ça vient d'OpenBSD qui force à ce que la constante ne soit pas définie ? Je vais essayer d'investiguer.

Ouais enfin, je suis un habitué du genre (voir les précédents journaux dans le même genre). Ceci dit, je te remercie beaucoup pour ton commentaire d'encouragement.

le karma d’un contributeur est un indice positivement corrélé à sa connerie.

Non. Si c'était le cas, tu aurais un karma au top.

Pour la première fois depuis… depuis toujours en fait, nous avons un président français qui ne se ridiculise pas quand il dit 3 mots d'anglais. L'interview a été réalisée intégralement en anglais.

Et on ne pourrait pas imaginer qu'un journaliste étranger interroge le président français en français ? Que dirait-on si un journaliste français interrogeait Trump en français ? Répondre en anglais, c'est d'une certaine manière faire allégeance au modèle anglo-saxon. C'est abaisser le rang de la France. Ça a du sens politique, ce n'est pas juste une commodité. On va bientôt arriver à un paradoxe où la langue de travail de l'UE restera l'anglais alors que le principal pays anglophone n'y sera plus (il restera l'Irlande qui a comme langue officielle l'anglais, soit moins de 1% de la population).

Il y a une sorte de fascination des élites pour l'anglais. À l'université, ça se traduit par des demandes incessantes d'avoir des cours en anglais pour soit-disant avoir de l'attractivité au niveau international. N'importe quoi ! L'attractivité internationale, on en a sans anglais et avec du français. Parce que quand un étudiant chinois choisi de venir en France, ce n'est pas pour parler anglais, mais français (sinon, il serait allé dans un pays anglophone, c'est pas ce qui manque). De même que les étudiants d'Afrique francophone viennent étudier en France en partie parce que les cours sont dans une langue qu'ils maîtrisent. Faire des cours en anglais, c'est juste une lubie de technocrate illuminé.

C'est un poil mieux mais ça pourrait encore être condensé. Idéalement, je pense qu'il faudrait que toutes les informations tiennent sur deux lignes. Déjà, je mettrais le lien dans le titre (le public de linuxfr est capable de pointer le lien pour voir son URL). Ensuite, je mettrais «pertinent ou inutile» sur la même ligne que le titre, et le lien pour la discussion à la fin de la seconde ligne. Sur le côté, j'enlèverai la date vu qu'elle est déjà présente sous le titre (ou alors il faut l'enlever sous le titre). Avec ces modifications, on aura quelque chose d'assez compacte (pas au niveau d'un Reddit mais pas mal quand même).

Personnellement, j'ai vite arrêté de lire les liens. Parce que quand on regarde la page liens, le rapport information utile (c'est-à-dire les liens) sur surface de la page est extrêmement faible. Ça vient en partie du choix d'avoir basé les liens sur les journaux plutôt que d'avoir fait un truc complètement à part (et beaucoup plus épuré).

Oui je suis assez d'accord. Surtout si on active les liens dans la page de personnalisation, ça prend beaucoup de place par rapport aux autres contenus (journaux et news en particulier). L'idéal serait d'avoir les liens à part, dans la partie droite peut-être en élargissant.

Le code n'est pas C++11 mais au moins C++14, puisque std::make_index_sequence a été introduit uniquement en C++14 !

D'ailleurs, avec GCC, la compilation foire (même avec C++14).

J'ai vraiment du mal à justifier le bashing continuel envers PHP.

Je pense que ça vient de l'antislash pour séparer les namespaces…

Ce blog post donne des exemples de race conditions en Go.

Oui, mais ça n'invalide en rien ce que j'ai dit. Je remets ici le morceau important : «Si tu ne fais qu'utiliser ce modèle (avec les channel et les goroutines)». Or, dans le premier cas de bug, ils n'ont pas utilisé les channels et paf le chien. Et la solution utilise un channel. Dans le deuxième cas, ils font des trucs sales (variable globale) et ils s'étonnent que ça ne marche pas en concurrence.

De manière globale, je préfère utiliser et même forcer l'utilisation d'un modèle de programmation sûr plutôt que de demander à un compilateur de garantir quoi que ce soit. Surtout que les garanties qu'offre Rust s'arrêtent aux frontière du unsafe.

Mais Rust a un avantage sans prix : La thread safety garantie à la compilation, ce que Go ne pourra jamais offrir.

Heu, tu m'expliqueras comment tu lances un thread en Go ? En fait, tu ne peux pas, parce que Go offre bien plus que les threads, il offre un l'implémentation d'un vieux modèle de programmation concurrente qui te garantie que ça va bien se passer. Si tu ne fais qu'utiliser ce modèle (avec les channel et les goroutines), tu n'as même pas besoin de garantir quoi que ce soit à la compilation, c'est juste garanti par design. C'est ça la force de Go.

À noter, pour accomplir ce fait Clang dépendrais de MSVC, et la compilation est plus lente (à peu près 15%), mais tout ça est expliqué quand le lien quivabien.

En fait, non. C'est bien Clang tout seul qui est utilisé, et sa version clang-cl.exe qui peut remplacer cl.exe présent dans MSVC (avec les mêmes options). Pour l'édition de lien, là encore, on peut utiliser link.exe fourni avec MSVC ou ldd.exe fournit par le projet LLVM.

En fait, tous les nombres sont des réels en Wren. J'ai fait une différence mais au final toutes ces variables ont le type Num.

1. C'est un journal, tu n'es pas obligé de lire
2. Ça permet de (re)découvrir des langages de programmation
3. Ce n'est pas si souvent qu'il y a des journaux techniques sur LinuxFr

J'y ai pensé mais j'ai vite abandonné. Celui qui réussira aura toute ma considération.

Je ne suis même pas sûr que ça soit si populaire que ça. En effet, ça se place sur la même niche que Lua, mais c'est plus orienté objet que Lua. C'est une alternative intéressante, à mon avis, pour ceux qui cherchent un langage à embarquer facilement et avec une syntaxe simple. Et le code est suffisamment clair pour pouvoir être adapté s'il le faut. Maintenant, en dehors de ça, je dirais que c'est une question de goût et de couleur.

L'auteur est très prolifique, c'est déjà son deuxième langage (son premier était à base de prototype), et il en a un troisième pour faire des expérimentations. Il a aussi écrit le livre Game programming patterns qui est plutôt bien fait. Et il est en train d'écrire un autre bouquin Crafting interpreters qui donne envie.

Donc, voilà, ça permet de faire un peu de pub pour ce langage et cet auteur.

Je ne peux qu'être d'accord avec toi. Ces normes comptables m'exaspèrent au quotidien et au CNU. Ça biaise tout le jugement qu'on devrait avoir sur des travaux scientifiques dans toutes leurs dimensions. Mais, parce qu'il y a un mais de taille, c'est la moins pire des solutions.

En fait, le CNU n'évalue pas les activités de recherche, il se contente de chercher et compiler les indicateurs d'une activité de recherche pour produire un jugement ou un classement. C'est très différent ! Si on devait évaluer réellement une activité de recherche, on y passerait beaucoup plus de temps (puisqu'il faudrait comprendre l'objet des recherches, évaluer leur pertinence, évaluer les résultats obtenus, etc) et ce temps, nous ne l'avons pas. Sans compter que nous n'avons sans doute pas les compétences pour le faire pour tous les collègues. Un article publié, en revanche, donne une indication : ce chercheur a été évalué par des pairs et son travail a été validé pour être publié. Doit-on refaire le travail du comité de lecture ? Ça dépend de ce qu'on cherche à faire. Si on voulait réellement évaluer, alors il faudrait (mais il faudrait également d'autres méthodes et d'autres moyens pour le faire correctement). Mais ce n'est pas la tâche qui a été assignée au CNU, donc on ne le fait pas, on se contente de l'indicateur.

Dans ce cadre, un logiciel, c'est compliqué à intégrer dans la fiche de notes. Parce qu'il y a assez peu d'indicateurs pertinents du point de vue de la recherche. Je les ai donné auparavant : nombre d'utilisateurs, nombre de téléchargements, etc. Mais ça n'indique pas la qualité de la recherche, juste sa diffusion. Là encore, si on faisait réellement un travail d'évaluation, on pourrait décortiquer le logiciel et se rendre compte qu'il contient des algorithmes originaux non-triviaux (qui peuvent avoir fait l'objet d'une publication ou non) et que c'est bien une production scientifique à part entière. Et comme tu le dis, vu le temps qu'on peut y passer, ça vaudrait largement des publications en plus du côté utilisabilité (parce qu'une publication vient rarement avec le bout de code qui va bien, et même pire, il est souvent difficile de refaire le bout de code en lisant la publication, ce qui est un comble).

Bref, on ne trouvera pas la solution ici mais je ne désespère pas de convaincre des collègues au fur et à mesure (beaucoup le sont déjà même s'ils continuent de «jouer le jeu»).

Par ailleurs, on a la forte impression que l'activité de développement de logiciels (libres en particulier) n'est que très peu valorisé lors de l'évaluation de notre activité de recherche par nos pairs. Si encore le logiciel générait des revenus (vente de licence d'exploitation à une entreprise par ex), alors ça serait surement mieux perçu. Mais pour du logiciel libre… J'entends souvent dire qu' "un logiciel compte comme une publication", ce qui fait un peu mal au coeur, car si on compare le temps passé à écrire une publi, et à développer/s'occuper d'un logiciel (comprenant la maintenance et toute l'activité autour)…

Étant élu au CNU en section 27, je peux te répondre là dessus. Un logiciel ne compte comme une publication que pour les jeunes docteurs qui demandent la qualif (ça vient de l'ambiguïté du terme «travaux» utilisés dans les textes officiels qui peut se comprendre comme publication mais aussi comme tout autre résultat de la recherche, y compris les logiciels).

Pour les permanents, un logiciel est valorisé indépendamment des publications (comprendre que ce n'est pas la même case dans les fiches de prise de notes). Les logiciels peuvent compter comme du rayonnement quand le candidat donne des chiffres de téléchargements et d'utilisateurs (ça indique que les résultats de sa recherche sont utilisés par d'autres). Ils peuvent compter comme de la production scientifique au même titre qu'un brevet (déposer son logiciel à l'APP peut être une bonne idée dans ce cas), mais pas tout à fait au même niveau qu'une publication. Dans le cas particulier de G'MIC, on peut aussi argumenter de son âge vénérable qu'atteignent assez peu les logiciels produits dans la recherche. Pour moi, c'est valorisable, ça indique une continuité et une évolution dans la thématique de recherche. En plus, il est utilisé dans des logiciels grand public, ce qui indique de la vulgarisation à grande échelle.

Tu as un collègue dans l'équipe MAD qui est également au CNU (et que j'apprécie beaucoup au passage), tu peux aller lui poser la question mais je pense qu'il te dira la même chose que moi.

Edit: je m'aperçois maintenant que tu es CR, et je ne connais pas les critères dans ce cas, mais bon je laisse le commentaire quand même, ça peut aider ;)

Globalement, je suis d'accord avec tout ce que tu dis ici, et je suis souvent confronté à ce même problème. J'ai parfois fait des choix sur lesquels je suis revenu ensuite : par exemple, l'UI en mode immédiat, au départ j'ai utilisé un truc simple que j'avais pioché dans un projet quasi-mort mais qui marchait, mais il manquait des fonctionnalités et au final, ça me semblait être une tâche trop ardue d'implémenter ça correctement et rapidement. Au final, j'ai intégré Nuklear qui avait bien plus de fonctionnalités et qui correspondait mieux à ce que je voulais. Mais la question se pose à chaque fois. Je me suis aussi retrouvé à devoir implémenter des petits trucs qui vont venir dans la bibliothèque standard, comme std::string_view.

De toute façon, si je grossis le trait, j'ai fait une implémentation de SFML en prenant SDL comme base, mais j'ai repris beaucoup de code de SFML. Ce qui veut dire qu'il faut suivre les évolutions de SFML (et/ou les corrections de bugs) tout en ajoutant ce dont j'ai besoin. Et je ne parle même pas des morceaux de SFML que j'ai modifiés à ma sauce parce que je trouvais l'implémentation originale moyenne.

Pour répondre à ta question sur la gestion des dépendances, j'essaie d'en avoir le moins possible. Mais ce n'est pas toujours gagné. J'ai deux sortes de dépendances. Premièrement, des dépendances que j'importe directement (via git submodule). Ça concerne en particulier des bibliothèques qui ne sont que des en-têtes et qu'il est plus facile d'utiliser de cette manière (on peut planquer l'implémentation dans un fichier source sans la mettre dans une interface). J'ai stb et Nuklear qui sont comme ça. Ensuite, j'ai des parsers de formats particuliers que je préfère intégrer directement de cette manière plutôt que de passer par une dépendance affichée, je cherche alors des bibliothèques simples (un seul fichier source). J'ai TinyXML et RapidJson dans cette catégorie. Et j'envisage sérieusement de supprimer ces deux dépendances bientôt et de ne passer que par un seul format d'entrée (j'en parlerai peut-être dans un journal bientôt). Et enfin, j'ai GameControllerDB qui contient des données uniquement et Google Test où c'est la manière recommandée de procéder.

Deuxièmement, j'ai des dépendances externes affichées. Là, j'essaie d'en avoir le minimum. J'ai SDL2, Freetype, Boost (seulement certaines parties) et récemment j'ai ajouté Zlib. Pour celles là, j'utilise mon gestionnaire de paquet préféré quand je suis sur Linux et j'utilise l'excellent vcpkg quand je suis sur Windows (j'inclus les plateformes de CI dans ces descriptions). Et ça marche plutôt bien. Je trouve vcpkg très bien foutu, en une seule ligne, on a tout ce qu'il faut prêt à l'emploi. On a une impression d'être à la maison (Linux) tellement c'est simple. En revanche, je déteste Conan cordialement. Je trouve le concept fumeux de base.

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.

De nos jours, les grands compilateurs sont compatibles avec C++14, qui est une petite évolution par rapport à C++11. Mais bon, je peux comprendre. En revanche, pourquoi ne pas avoir utilisé des morceaux de libc++ par exemple (qui a une licence permissive) plutôt que de réimplémenter ?

Je trouve que dans beaucoup d'endroits, il y a plein de choses qui sont en doublon par rapport à la bibliothèque standard ou qui sont réimplémentées un peu différemment et du coup, on perd de l'intérêt ou des fonctionnalités.

Dans le module meta, je prend l'exemple de remove_const_reference qui aurait pu être implémenté plus simplement:

template<typename T>
struct remove_const_reference {
  using type = typename std::remove_const<std::remove_reference<T>::type>::type;
};

Et en plus, vous aviez la gestion des rvalue references (celles avec un &&) alors que l'implémentation proposée n'enlève pas la référence dans ce cas.

Il y a aussi indices et make_indices dont on voit mal la différence avec std::integer_sequence et std::make_integer_sequence.

Et dans le module memory, c'est un peu pareil. make_unique est réimplémenté mais sans prendre en compte les tableaux. Et donc, si je fais iscool::memory::make_unique<int[]>(4), ça ne compile même pas (alors que la version dans la bibliothèque standard compile et fait bien ce qu'on attend d'elle).

Et dans le module random, random_generator fait quasiment la même chose que std::discrete_distribution sauf qu'en plus, ça ne peut pas prendre n'importe quelle source de hasard (alors que la bibliothèque standard est plutôt bien conçue à ce niveau).

Je pourrais continuer mais je vais m'arrêter là. Tout ça me laisse une impression plus que mitigée à la lecture du code. Ça laisse penser que le syndrôme NIH n'est pas loin et donc, qu'il n'y a que peu d'intérêt à utiliser cette bibliothèque.

Quand on est l'État, on n'est pas censé avoir besoin d'un monopole sur des fréquences pour imposer son point de vue!

Oui, on peut demander gentiment, ça marche… ou pas. On devrait essayer de demander gentiment à tous les évadés fiscaux de revenir, ou alors on devrait essayer de demander gentiment aux automobilistes de rouler à 80 au lieu de 90.

Mince, l'ARCEP n'existe pas ! Les opérateurs font vraiment tout ce qu'ils veulent, sans plan.

L'ARCEP ne peut rien faire au plan mondial, elle peut s'occuper des opérateurs français et encore. Quand on voit l'état du déploiement de la fibre, on se dit que l'ARCEP se fait marcher sur les pieds. L'IPv6, c'est pas uniquement au niveau français que ça doit se décider.

C'est fou, Orange a obtenu ses fréquences mobiles unilatéralement, sans contraintes, et il n'y absolument aucun plan national (et même européen) pour avoir la THD partout.

En quoi est-ce contradictoire avec ce que j'ai dit ? J'ai bien dit que les fréquences appartenaient à l'État. Mais on parle d'IPv6 là, pas du mobile. Mais après, on peut parler du déploiement de l'ADSL ou de la 4G et aller dans des coins très sympathiques, mais dépourvus de la moindre antenne ou du moindre DSLAM. Donc, le «partout» est sans doute un peu trop fort.

l'auto-hébergement existe aussi chez un hébergeur

Du coup, ça ne s'appelle plus un auto-hébergement, mais un hébergement tout court…