pulkomandy a écrit 2019 commentaires

ça ne sera pas un TPM mais par exemple une carte à puces (accessible avec PC/SC) ou une Yubikey. Les outils et bibliothèques à utiliser ne sont pas les mêmes, ça serait trop facile :(

La commission ne se réunit que tous les 6 mois normalement. De là, 2 options possibles par exemple :

• La pétition atteint le nombre de signatures nécessaires et doit être examinée cette fois-ci,
• Le gouvernement organise une réunion spéciale de la commission pour classer la pétition à nouveau (mais ça va se voir qu'ils y mettent de la mauvaise volonté, non?)

Ça marche aussi pour les associations "d'intérêt général", qui doivent juste respecter quelques critères sans avoir besoin de démarches particulières. En cas de doute on peut demander à la préfecture de vérifier si une association est vraiment d'intérêt général, mais cette vérification n'est pas obligatoire.

On peut utiliser autre chose qu'UML, par exemple le langage SDL: https://en.wikipedia.org/wiki/Specification_and_Description_Language est plus adapté pour des processus qui s'échangent et réagissent à des messages.

On commence à avoir des retours un peu critiques sur Rust de gens qui l'ont suffisament utilisé pour voir où sont ses limites, et dans quels cas il vaut mieux choisir un autre langage. C'est plutôt bon signe pour la maturité du langage.

Je n'ai pas trouvé ça exagéré, l'auteur s'est volontairement placé dans une situation où il savait que Rust allait poser problème, pour voir comment un autre langage pouvait s'y prendre dans ce cas précis. ÇA ne remet pas en cause l'utilisation de Rust dans plein d'autres cas (tous ceux où il n'y a pas besoin d'écrire de code "unsafe", c'est à dire probablement une très grande partie du code, tout le monde n'écrit pas des allocateurs ramasse-miettes, des machines virtuelles ou des systèmes d'exploitation).

Il faut voir ce qu'on entend par "à proximité". À Toulouse il existe un réseau de chaleur alimenté entre autres par un incinérateur de déchets (et aussi des datacenters et d'autres choses). Il a été mis en place en 1965 et étendu plusieurs fois depuis.

La carte présentée ici: https://eneriance.fr/qui-sommes-nous/histoire-et-chiffres-cles/ montre qu'il dessert une grande partie de la ville. Donc il semblerait que "à proximité" ça se compte en kilomètres et que ça permet de couvrir une ville de taille respectable.

Et il y a une extension pour desservir d'autres quartiers de l'autre côté de la Garonne: https://www.toulouseenergiedurable.fr/plan-du-reseau-toulouse-energie-durable/

Mettre les incinérateurs de déchets parmi les énergies décarbonées me semble quand même un peu… exagéré? Brûler des déchets ça émet du CO2.

Oui, par défaut ce sont les cycles CPU, mais dans l'article je n'ai pas vu de précision sur ce qui est fait avec perf (et c'est un outil qui peut faire beaucoup d'autres choses).

Justement, ma question est de savoir précisément ce qui est mesuré avec perf. Dans la commande "time" on a droit à 3 mesures:

• Le temps "user": temps passé à exécuter du code utilisateur
• Le temps "system": temps passé à exécuter du code du noyau (appels système)
• Le temps "real": temps total de l'exécution

On peut soustraire les deux premiers au troisième pour avoir le temps passé à ne pas exécuter de code du processus concerné (autres tâches en cours d'exécution, attente sur les entrées-sorties, etc).

Avec le compteur "cycles" de perf, on mesure au mieux les deux premiers, mais pas le troisième. Et donc le temps passé à ne pas exécuter de code n'est pas identifié. Je n'ai pas trouvé dans l'article ni dans le dépôt git du benchmark si tu as regardé la commande "time" pour voir si le code passe surtout du temps à s'exécuter ou surtout du temps à attendre les entrées-sorties. Ça peut être pas mal de vérifier ça pour s'assurer qu'on optimise au bon endroit. Si le programme est limité par les entrées-sorties, les gains en utilisation CPU ne seront pas visibles sur le throughput ou le temps d'exécution total pour un test donné (mais ils seront visibles sur la charge CPU et la consommation électrique).

Pour mesurer le temps passé ailleurs que dans le code avec perf: par exemple, en utilisant les évènements "syscalls:sys_enter_" on peut profiler tous les endroits qui font des appels systèmes (ce qui est en général assez coûteux, ça se place quelque part entre un appel de fonction et un switch de contexte pour exécuter un autre processus). Les évènements "block:" peuvent aussi être utiles pour regarder les entrées-sorties sur disque. On s'éloigne vite du C++ pour entrer dans les détails de la programmation système UNIX, mais ça peut être intéressant.

Pour les claviers, c'est pour réduire les coûts. Jusqu'à il y a pas longtemps, les claviers de PC portables étaient encore avec le protocole PS/2. Ça gère mal la mise en veille, ça demande des broches d'entrée/sortie dédiées, etc. Ça a été remplacé par de l'i2c qui est relié sur le même bus que les capteurs de température (entre autres) et le protocole haut niveau utilisé est proche de celui de l'USB et donc beaucoup plus flexible (pour avoiredes commandes standardisées pour des LEDs RGB par exemple)

Pour les touchpads, l'utilisation du PS/2 était vraiment tordue pour gérer la rétrocompatibilité avec une souris classique et contourner les bugs des interfaces ps/2 des différents chipsets. Et en plus de ça, utiliser de l'i2c permet plus de liberté sur les infos retournées et un plus haut débit. Donc on peut faire du "vrai" multipoints, ou le touchpad remonte au driver la position de tous les doigts et laisse le système traiter ces infos directement. Au lieu de les convertir en évènements de défilement, etc pas du tout configurables dans le firmware du touchpad.

Alors oui, c'est pénible de devoir refaire un driver. Mais moins que de maintenir le driver pour les vieux trucs ps/2, à long terme.

Est-ce que les mesures faites avec perf prennent en compte uniquement le temps cpu utilisé? Il y a peut-être pas mal de performances à gagner sur les entrées/sorties, en particulier en utilisant de façon intelligente les buffers proposés par fstream. Mais pour ça il faut mesurer le temps "réel" et pas le temps "user". Il me semble que c'est faisable avec perf en changeant quelques options.

J'ai eu des gains très importants en creusant de ce côté sur un de mes projets, mais c'était sur un système embarqué avec du stockage eMMC et un système de fichier f2fs. Peut-être sur un PC portable, les IO sont beaucoup plus rapides?

(note: le lien est indiqué en français, mais il est en anglais)

Parce que, pour que cette image puisse s’afficher correctement, le nom du fichier doit être en caractère ASCII (latin 1), pas d’accents ou de fioritures dans ce genre.

Soit c'est en ASCII et on ne peut pas mettre d'accents. Soit c'est en Latin-1 (de son vrai nom ISO-8859-1) et on peut mettre les accents nécessaires pour les principales langues Européennes écrites avec l'alphabet latin.

Encore une étude qui fait des statistiques uniquement sur GitHub, mais qui présente ses résultats comme si c'était fait sur tout l'écosystème opensource?

J'en profite pour re-partager cette image extraite d'un livre sur la programmation Forth qui ne se privait pas de taper sur les développeurs BASIC et leur code spaghetti:

Oui, ça devenait trop compliqué sinon. Peut être en retournant un std::wstring_view?

Et ma version fait n'importe quoi si on demande un progress supérieur à 1 ou négatif ou…

Comme quoi l'implémentation proposée n'est probablement pas la plus bête.

Au passage j'ai découvert quelques trucs sur la gestion des chaînes de wchar_t que je ne manipule pas souvent:

• On ne peut pas faire un printf avec un %ls pour afficher un wchar_t, ou en tout cas ça fait des trucs bizarres avec le modificateur de longueur, un %.10ls n'affiche pas 10 caractères. Avec wprintf ça semble fonctionner.
• Il faut faire un setlocale, sinon le printf ou wprintf refuse d'afficher la chaîne. Je ne savais pas que printf pouvait retourner une erreur (en y réfléchissant ça semble logique, mais je m'étais pas posé la question).

Allez je tente une version sans conditions et sans boucles:

#include <locale.h>
#include <math.h>
#include <stdio.h>
#include <wchar.h>

static const wchar_t* const progressBar = L"🔵🔵🔵🔵🔵🔵🔵🔵🔵🔵⚪⚪⚪⚪⚪⚪⚪⚪⚪⚪";

void GetPercentageRounds(double progress)
{
    int intProgress = round(progress * 10);
    wprintf(L"%-.10ls (%lf)\n", &progressBar[10 - intProgress], progress);
}

int main () {
    setlocale(LC_ALL, "");

    for (double progress = 0; progress < 1; progress += 0.1)
        GetPercentageRounds(progress);
}

En théorie oui, mais en pratique pas vraiment.

Le préprocesseur C (cpp) est de plus en plus intégré avec la suite de la compilation. Par exemple in insère des directives permettant au compilateur de savoir à quelle ligne de quel fichier le code se trouvait avant le pré-processing, ce qui permet d'afficher des messages d'erreurs avec les bons noms de fichiers et numéros de lignes.

La plupart des langages de programmation n'apprécient pas trop de se retrouver avec des #file et des #line un peu partout dans le code.

Avec m4, ça fonctionne, mais la syntaxe de m4 fait que l'intégration avec autre chose peut vite être compliquée. On a vite fait de se retrouver avec une macro qui est remplacée à un endroit où on ne voulait pas. Et puis la syntaxe ne fait pas vraiment rêver de toutes façons.

Et Sim City 2000

Pour moi le code avec des goto pour gérer les erreurs est beaucoup plus simple à comprendre et à maintenir.

C'est peut-être juste une question d'habitude.

On ne fait bien sur pas n'importe cuoi avec des goto dans tous les sens. Seulement des goto qui vont vers la fin de la fonction, pour faire les libérations de ressources nécessaires avant d'en sortir. C'est bien sûr avantageusement remplacé par la RAII en C++, mais en C, on a pas ce luxe.

Si on utilise pas de goto, on a deux choix:

• tout le code se retrouve imbriqué dans un tas de if() qui ne servent qu'à gérer les erreurs, on a du mal à suivre le flot du code au milieu
• le nettoyage est fait à plein d'endroits dans la fonction (partout où une erreur peut se produire) avec beaucoup de code dupliqué

Ça permet de savoir qui a cliqué sur ce lien. Que ça soit de la publicité payante ou pas, c'est intéressant pour savoir s'il faut faire plus de communication ici où si ça sert à rien.

Est-ce que c'est indispensable? probablement pas, mais c'est dans les habitudes des gens qui font de la publicité. Sans toujours savoir quoi faire des résultats collectés, d'ailleurs.

En 2013, 60% des échanges sur Internet étaient en fait des robots et pas des humains.

Enfin on trouve des chiffres aasez variables selon à qui on demande et ce qu'on mesure, mais c'est entre 30 et 70%. Donc c'est déjà bien commencé. Il y a des gens qui font de faux sites, puis de faux visiteurs pour ces sites via des fermes à publicités. Il n'y a que les publicités qui sont vraies.

Et maintenant il y a des influenceurs qui font des fausses publicités, pour attirer des vrais annonceurs qui pourraient leur donner des sous.

Bon après moi, je trouve que rien ne battra le duff's device en terme de code spaghetti et il n'a pas besoin de goto.

Ah si on peut faire pire, il y a les coroutines en C de Simon Tatham

Of course, this trick violates every coding standard in the book. Try doing this in your company's code and you will probably be subject to a stern telling off if not disciplinary action! You have embedded unmatched braces in macros, used case within sub-blocks, and as for the crReturn macro with its terrifyingly disruptive contents . . . It's a wonder you haven't been fired on the spot for such irresponsible coding practice. You should be ashamed of yourself.
Any coding standard which insists on syntactic clarity at the expense of algorithmic clarity should be rewritten. If your employer fires you for using this trick, tell them that repeatedly as the security staff drag you out of the building.

Si vous avez d'autres idées pour créer sh*tcode,

Si vous avez d'autres idées pour créer du code de m*rde,

Il suffit de demander aux arnaqueurs de respecter la RFC 3514 et de s'annoncer via le bit prévu à cet effet dans les en-têtes IP. Ainsi il sera facile de les identifier et de les bloquer.

Pour le son, cette combinaison a tellement bien marché que Yamaha a proposé des puces combinant un synthétiseur FM et un générateur de signaux carrés dans le même composant.

Pour ce mélange en particulier, il me semble que Scream Tracker 3 permettait déjà de composer à la fois avec des samples et des sons FM OPL3 sur une carte son Sound Blaster 16. Mais la partie FM de ce tracker a été relativement peu utilisée