Julien Jorge a écrit 526 commentaires

Je fais aussi mes sauvegardes sur aws, avec le même débit. De mon côté ça tourne la nuit.

J'avais regardé les tarifs de glacier et de souvenir il y avait un coût non négligeable lié aux nombre de requêtes. Comme je fais un rclone chaque nuit sur un gros dossier je craignais que le nombre de requêtes soit trop élevé, du coup j'envoie tout sur S3. Ça me coûte environ un dollar par mois.

Par rapport à ton script, que se passe-t-il quand tu reprends la main, la copie est en pause ? Interrompue ? Chiffres-tu tes données avant de les envoyer ?

Merci pour cette excellente dépêche, merci en particulier à Jehan car c'est toujours un plaisir d'avoir des nouvelles aussi détaillées de GIMP.

À titre personnel j'apprécie en particulier le côté « juste libre » de ce que vous faite avec LILA. On parle régulièrement ici de licences NC et ND, et que « oui c'est de l'art c'est pas pareil que du code ». De votre côté vous faite de l'art et du code, tout est en BY-SA, c'est juste simple. Bravo à vous.

Une petite question technique pour finir : maintenant que la migration vers GTK 3 est terminée, entamez vous la migration vers GTK 4 qui vient de sortir ?

J'aime bien l'idée mais j'y vois pas mal d'inconvénients :)

• Je plussois sur l'intérêt de documenter le site d'appel, mais en l'état on n'a plus les noms ni les types des paramètres dans la signature de l'appelé.
• Second problème, l'appelé est forcément template. Ais-je envie d'augmenter mes temps de compilation pour pouvoir nommer les paramètres côté appelant ? Probablement non.
• Comment passer des paramètres par adresse ? Combien de copies des paramètres sont faites entre l'appelant et l'appelé ? Sur cet exemple j'ai déjà une copie superflue :

#include "../include/params14.hpp"

#include <cstdio>

using namespace params14::literals;

int copy_count = 0;
int assign_count = 0;

struct copy_counter
{
  int value;

  copy_counter(int v) : value(v) {}
  copy_counter(const copy_counter& that)
    : value(that.value)
  {
    ++copy_count;
  }

  copy_counter& operator=(const copy_counter& that)
  {
    value = that.value;
    ++assign_count;
    return *this;
  }
};

template<typename... KWArgs>
void foo(KWArgs&&... kwargs)
{
  auto args = params14::parse(std::forward<KWArgs>(kwargs)...);
  printf("value=%d\n", args.get("p"_kw).value);
}

void bar(const copy_counter& p)
{
  printf("value=%d\n", p.value);
}

int main(int argc, char** argv)
{
  copy_counter p(argc);
  foo("p"_kw=p);
  printf("named:\ncopies=%d\nassignments=%d\n", copy_count, assign_count);

  copy_count = 0;
  assign_count = 0;
  bar(p);
  printf(
         "good old syntax:\ncopies=%d\nassignments=%d\n",
         copy_count, assign_count);

  return 0;
}

Perso je trouve la difficulté dans le kn, à savoir si ça se prononce comme dans knife ou Knuth par exemple.

Au final je prononce le K à la française.

[…] ta question était purement théorique pour faire chier le peuple […]
[…] comme un bon facebookien, tu pollues les commentaires pour déverser ta rage extrémisante sans même avoir pris le temps de lire de quoi on parle.

Comme tu y vas !

Ça m'amuse parce qu'en lisant ton journal et en voyant « Creative Commons » sans précision j'ai tiqué aussi. Pas sur le sens des mots, c'est plutôt que j'ai trouvé cela très étonnant de ta part car je ne doute pas que tu connais très bien LinuxFr.org et que tu sais très bien que sans précision ça va dégénérer dans les commentaires.

Du coup je pense que tu as volontairement omis la précision pour générer ces commentaires, auxquels tu peux réagir pour faire encore plus de bruit et asseoir ta présence. Mais bon, peut-être que j'extrapole :D

C'est pas mal comme solution, merci. J'ai mis une IP fixe, pas de passerelle et pas de DNS, maintenant ça imprime bien.

Merci, grâce à cette commande (en root) l'imprimante apparaît bien. Elle est partagée deux fois : une fois par avahi et une fois par cups. Pas de chance, l'impression ne se lance sur aucune… Mais ça me fait déjà un peu avancer !

C'est obligatoire en effet, je préfère que l'imprimante n'ai pas accès à Internet et je n'ai pas envie de gérer des routes pour elle :)

Pour la procédure j'ai suivi cette page. En gros :

1. activer le débogage USB sur le téléphone
2. connecter l'appareil en USB
3. adb reboot bootloader, pour accéder au menu de boot
4. fastboot devices, pour vérifier que l'ordi voit bien l'appareil
5. fastboot oem unlock, pour débloquer le bootloader
6. redémarrer le téléphone s'il ne le fait pas tout seul
7. récupérer un TRWP récent
8. refaire 1 à 4 pour revenir au bootloader si nécessaire
9. fastboot flash recovery trwp*-mako.img
10. fastboot boot trwp*-mako.img
11. rebooter en recovery (i.e. lancer TRWP sur le téléphone)
12. cliquer sur Wipe puis Format data
13. récupérer une image de LineageOS, par exemple https://androidfilehost.com/?fid=8889791610682908446
14. dans TRWP cliquer sur Advanced puis ADB Sideload puis swiper
15. sur l'ordi, adb sideload lineage-15-1-20200807-UNOFFICIAL-mako.zip

Si jamais le téléphone se met à redémarrer en boucle, maintenir le bouton volume bas pour qu'il s'arrête au bootloader au redémmarrage.

C'est pas de leur faute, il faut dire qu'avec la crise qu'on traverse… Heureusement qu'ils étaient là sinon ça aurait été pire.

Je pense l'avoir déjà dis, mais peut-être que le problème de vitesse de compilation de C++, c'est juste que les gens font de la merde, à tout inclure comme des porcs sans réfléchir?

Qu'est-ce qui te fait croire ça ? ;)

Oui, il suffit de ne pas exporter les symboles. Cet article en anglais décrit bien les cas d'usage.

Le problème des headers est qu'ils sont interprétés des tonnes de fois. Même avec des gardes, c'est lu et relu pour chaque unité de compilation les utilisant. Sur des gros projets ou de grosses dépendances ça se sent.

De plus le résultat de l'interprétation peut varier d'une unité de compilation à l'autre selon les paramètres du préprocesseur.

// header.hpp
#pragma once

#ifdef FOO
  using bar = int;
#else
  using bar = char;
#endif

// 1.cpp
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)

// 2.cpp
#define FOO // ou -DFOO sur la ligne de commande
#include "header.hpp"

static_assert(std::is_same_v<bar, char>)
// Perdu, bar est int.

Les modules sont une réponse à ces problèmes.

J'ai testé un petit peu, ça m'a l'air d'être exactement ce que je veux, merci :)

Je me retrouve dans ces 4 sources mais je ne mets pas le même poids à chaque.

En ce qui me concerne, ce qui m'intéresse c'est sans doute de devenir meilleur à ce que je fais. Je ne saurais expliquer pourquoi et je n'ai pas envie de chercher, je sais juste que ça me stimule.

Au travail ce sera ma première motivation : atteindre un objectif en apprenant des choses au passage. Construire un logiciel, un outil, du mieux que je peux, en le découpant en petites tâches que je résoudrai une à une pour construire quelque chose de plus grand et d'utile à quelqu'un. J'apprends en pratiquant et l'aboutissement du projet, la confrontation au public, sert à confirmer que je m'en suis bien sorti.

Ensuite les technos jouent beaucoup. De tous les langages que j'ai essayé, je préfère faire du C++. J'ai trouvé insupportable d'utiliser Unity. Les langages du web et tout l'écosystème qui va avec m'ennuient. J'aime aussi bosser avec un tooling léger, moins il y en a, mieux je me porte. En gros tu me files Linux + CMake + Bash + GCC et je suis heureux.

Je dirais donc énormément pour « maîtrise » (il faut que ce soit un peu plus compliqué que ce que je sais faire), beaucoup pour « autonomie » (je choisis mes outils et contribue à la méthode de résolution) et pas mal de « sens » (il faut que ce que je fais serve à quelqu'un).

Pour ce qui est de l'effet tribu, il y a de ça aussi. Effectivement c'est mieux si je suis en phase avec les collègues et que nous marchons en rythme vers un objectif commun, en accord sur les méthodes. Je ne suis pas sûr cependant qu'on puisse trouver ça dans de grandes équipes ; à un moment il y a forcément des profils disons moins stimulants. Et puis il faut voir ce que chacun apporte. J'ai eu un collègue qui était très bon sur un domaine où j'étais nul, mais à côté de ça son code était plutôt médiocre et il n'avait aucune intention de faire des efforts sur ce point. Au final il n'y a pas grand chose à faire, chacun apporte sa contribution au projet.

Tu passes sur le salaire mais ça a sa pertinence aussi, pas tant pour la somme que pour le symbole de reconnaissance. Avoir une renégociation genre une fois par an avec une petite augmentation, c'est rassurant. A contrario, voir le coût de la vie augmenter et son revenu stagner, ça donne l'impression d'être coincé dans une impasse, c'est démotivant. Pareil pour les primes, recevoir une prime quand on dépasse les attentes, c'est encourageant. Sans ça on fait vite le ratio revenu sur effort et on arrête les efforts.

Alors j'ai lu ce livre et effectivement c'est un de ceux que je pointe. Je fais aussi référence à Code Complete.

C'est plein de bons conseils et lire ça me semble être un bon moyen d'acquérir une sorte d'expérience de plusieurs décades de développement avant nous. Mais que faire quand les autres ne l'ont pas lu ? Pire, que faire quand ils ne sont même pas intéressés par la notion de code clean ?

Il y a aussi des principes qui ont un peu vieillit dans ces livres. Dans le lien de blog que tu donnes plus bas il y a un lien vers un autre article qui explique que le DRY se fait avec modération. Oui, factoriser à tout va pose aussi des problèmes. Oui je m'y suis aussi brûlé.

Pareil pour le fait de favoriser le polymorphisme à la place d'if/else ou switch/case. Ça se discute. Des fois c'est plus clair d'avoir tous les cas à plat dans un switch plutôt que d'avoir plein de classes qui éparpillent la logique.

Il y a des trucs sur lesquels j'ai du mal à faire des retours en revue. Quand il y a un problème du genre « ça ne fonctionne pas », c'est facile, mais quand c'est un problème de façon de faire, c'est dur à justifier.

Par exemple quand je vois passer des acronymes, des abréviations, des fonctions de cinq kilomètres, des dépendances inutiles dans les headers, de l'objet pour que dalle… C'est sûr ça fonctionne, mais niveau hygiène c'est pas génial. Quelle galère de lire du code comme ça. Quelle galère de revenir là dedans après quelques mois, et quelle tristesse de se traîner ça sur toute la vie du projet.

Et du coup à part faire une remarque personnelle disant que mon expérience et mes lectures m'amènent à penser que c'est médiocre, éventuellement en pointant un paragraphe d'un bouquin ou un article en guise de source externe (et bonjour l'effort pour retrouver mes sources), je ne vois pas trop comment faire pour encourager à faire du code propre.

Comment faites vous pour faire des retours sur ce genre de soucis ?

J'ai déjà entendu cette histoire et… bof. Elle sous entend que la réponse à un problème est d'augmenter les ressources sans chercher, mais je ne vois pas en quoi c'est plus malin ou plus économique que de trouver la cause du problème.

C'est sûr qu'on a l'impression d'avoir perdu de l'argent avec ce fameux expert, mais bon il faut bien quelqu'un pour trouver la cause du problème. Après que la solution soit d'ajouter de la RAM ou de réduire la conso mémoire, ça se discute. Le problème c'est que si ce gars n'était pas là quelqu'un d'autre aurait augmenté les ressources au hasard en espérant contourner le problème. Plus de CPU ! plus de RAM ! plus de serveurs ! Ça va bien finir par passer… Cette augmentation de ressources ça se paye aussi sur la durée, et ça ajoute de l'incompréhension pour ceux qui entrent dans le projet par la suite.

Enfin je dis ça, à la base je ne suis déjà pas fan de l'idée d'ajouter toujours plus de puissance. Déjà parce qu'en terme de satisfaction personnelle je préfère chercher la cause du problème, et ensuite parce que, d'une manière générale, je crois que la surconsommation de ressources cause des problèmes plus grands sur le long terme. La survie c'est principalement de l'endurance, pas que du sprint, même en informatique. T'imagine un peu si on appliquait la même méthode en dehors de l'informatique, à mettre toujours plus de puissance au lieu d'économiser ? On cramerait toute nos ressources.

Attend une minute…

Je suis peu familier de Qt mais si je me souviens bien leurs signaux font partie des extensions au langage, du coup je doute que l'auteur du benchmark puisse l'intégrer facilement et par conséquent je ne le mets pas non plus dans les tests.

Au niveaux des outils chez nous c'est aussi Slack & Hangout pour la communication. Hangout ne fonctionne malheureusement plus avec Firefox mais il y a moyen de faire du partage d'écran avec (sous Chrome, donc).

Après 6 ans en télétravail et différentes équipes je peux te dire les trucs qui ont bien fonctionné pour moi :

• Dire bonjour à l'équipe sur Slack quand on commence à bosser. J'avais au début l'impression de spammer mais ça permet aux uns et aux autres de savoir que l'on est dispo.
• Faire un point en visio le matin. Ça fait un point de synchro et ça permet de planifier sa journée. En général toutes les questions en suspend sont traitées à ce moment puis ensuite on est tranquille pour le reste de la journée.
• Avoir un bon micro-casque.
• Faire le chiffrage en visio et le répartir sur plusieurs jours. J'ai eu des sessions de trois heures de chiffrage et ça chauffe bien les oreilles. C'est mieux de faire quelques stories par jour.
• Ne pas hésiter à s'appeler en visio sans prévenir.

Pour les réunions à plusieurs en visio, c'est pratique d'avoir un « chef d'orchestre » qui se charge de donner la parole aux un et aux autres. Sans ça on se retrouve à parler en même temps à cause des latences, sans savoir si on a été entendu. S'il y a en plus dans l'équipe des gens qui ont tendance à couper la parole, ça devient vite cacophonique.

Il y a souvent un flottement en fin de visio, où personne n'ose raccrocher en premier. Il ne faut pas hésiter. À+ et on raccroche. C'est pratique quand le « chef d'orchestre » clôt clairement la réunion.

Pour référence : https://linuxfr.org/news/experience-s-de-teletravail

C'est corrigé.

Ta solution est sans doute très efficace, malheureusement elle ne répond pas à la question ! Le but est d'ignorer les valeurs pour lesquelles il existe un zéro plus haut dans la même colonne. Là ton algo ignore le reste de la ligne quand il rencontre un zéro.

Ça fonctionnerait si la matrice était en column-major, ce qui est d'ailleurs pris en considération dans le journal, mais ça demande de changer la structure de donnée. C'est un peu tricher par rapport à l'exercice. J'aurais bien voulu croire que tu considères que la matrice est en column-major mais comme tu as nommé ta variable row je ne doute pas que tu la considères en row-major.

En tout cas merci pour les insultes et le mépris, c'est top ! <3

Tiens, dis-moi, j'essaye le même genre de truc sur la version indices, qui maintient une liste les indices des colonnes pertinentes :

int matrix_elements_sum_indices_branchless
(const std::vector<std::vector<int>>& matrix)
{
  const int row_size(matrix[0].size());
  std::vector<int> usable_columns(row_size);

  const auto usable_columns_begin(usable_columns.begin());
  auto usable_columns_end(usable_columns.end());

  std::iota(usable_columns_begin, usable_columns_end, 0);

  int remaining_count(row_size);
  int result(0);

  for (const std::vector<int>& row : matrix)
    for (auto it(usable_columns_begin); it != usable_columns_end; )
      {
        const int i(*it);
        const int v(row[i]);
        result += v;

        const int keep_mask((v == 0) ? 0 : -1);
        usable_columns_end += ~keep_mask;

        // discussion ci-dessous sur le code d'ici…
        const int distance_to_last(usable_columns_end - it);
        const auto new_i_it(it + (distance_to_last & ~keep_mask));
        *it = *new_i_it;
        // …à là.

        it += -keep_mask;
      }

  return result;
}

Ça ne fonctionne pas très bien et je pense que c'est à cause de l'écriture dans le bloc d'ici à là. Si je mets à la place de ce bloc la condition suivante :

        if (~keep_mask)
          *it = *usable_columns_end;

Alors ça fonctionne très bien.

Ma compréhension est grosso-modo que dans la première version on réécrit inconditionnellement dans la mémoire pointée par it, et bien qu'elle est probablement en cache (on vient juste d'y accéder) et que sa valeur ne change pas toujours, la ligne de cache devient toujours dirty et il faut la renvoyer en RAM. Du coup on paye une écriture à chaque itération, qui coûte bien plus cher qu'une misprediction occasionnelle. Qu'en penses tu ?

L'interface et l'API de ublas sont super mais malheureusement les perfs ne suivent pas :(

Ce n'est pas évident que ce branchement soit inliné, il aurait été bien d'avoir un extrait du code assembleur, et de comparer avec une version sans multiplication.

Bien vu ! Voici une version sur Compiler Explorer où on peu voir le corps de la version branchless :

.L31:
        mov     rdx, QWORD PTR [r8]
        movsx   ecx, BYTE PTR [rdi+rax]
        mov     edx, DWORD PTR [rdx+rax*4]
        mov     esi, ecx
        imul    ecx, edx
        add     r12d, ecx
        test    edx, edx
        setne   dl
        and     edx, esi
        mov     BYTE PTR [rdi+rax], dl
        mov     rdx, rax ; à partir de là on gère le compteur de la boucle et
        add     rax, 1   ; la condition de sortie.
        cmp     r9, rdx
        jne     .L31     ; on a un seul jump par itération.

et celui avec les branches :

.L70:
        mov     BYTE PTR [rdi+rax], 0 ; usable_column[i] = 0
.L53:
        lea     rdx, [rax+1] ; gestion du compteur de la boucle, sans intéret
        cmp     rcx, rax     ; pour la comparaison de la sortie asm
        je      .L52         ; saut pour sortir de la boucle
.L59:
        mov     rax, rdx     ; fin de la gestion du compteur de la boucle
.L55:
        cmp     BYTE PTR [rdi+rax], 0
        je      .L53 ; un premier jump hors gestion du compteur de la boucle
        mov     rdx, QWORD PTR [rsi]
        mov     edx, DWORD PTR [rdx+rax*4]
        test    edx, edx
        je      .L70 ; là on a un jump qui va nous permettre de faire
                     ; l'affectation usable_column[i] = 0 puis d'enchaîner avec
                     ; la gestion du compteur de la boucle.
                     ; Ça fusionne les deux sauts du code initial (le test
                     ; if (v==0) puis le saut pour reboucler.
        add     r12d, edx ; result += v
        lea     rdx, [rax+1] ; à nouveau de la gestion du compteur de boucle
        cmp     rcx, rax
        jne     .L59