Pour retomber sur ses pattes il y a la programmation par monades qui permet de recomposer les traitements “dans le bon sens” – que l'on retrouve sous plusieurs formes de façon parfois un peu cachée comme les promises.
C'est une autre façon de présenter les promesses, les futures et les observables oui :)
Je suis d'accord que c'est totalement infernal de travailler à base de callback. Ça rend très complexe le moindre refactoring aussi et ça empêche de voir certain partern dans le code.
Désolé, je ne comprends toujours pas. Ça veut dire quoi « être réactif » ?
C'est le mot à la mode pour dire qu'on utilise un pattern reactor (AM*H*A).
Qu'est-ce qui est du domaine de la programmation événementielle si ce n'est l'utilisation du patern reactor ? Si la programmation événementielle, c'est réagir à des événements, j'ai l'impression que la définition englobe toutes les implémentations côté serveur, je ne vois pas comment un serveur pourrait ne pas « réagir » à des requêtes réseau.
Pour moi une distinction importante consiste dans le fait de recevoir un évènement et que cet évènement contient toute l'information utile à mettre en rapport avec le fait de tout envoyer dans le contexte d'un fil d'exécution. Quand tu spaw un thread par requête et que ton framework te positionne dans le contexte de ton thread toute l'information utile (la requête, l'authentification, etc), tu peux difficilement dire que tu es évènementiel. C'est typiquement ce que fais Spring par exemple. Il utilise intensivement le thread local storage.
Merci pour le lien. De ce que j'ai l'impression il remplace les appels asynchrones par des appels synchrones, mais qui indique qu'il faut les préempter et c'est la différence avec CFS. Par contre je ne vois pas comment ça pourrait bien se passer en terme de cache. Le context switch est drastiquement plus léger, mais il est toujours là, on invalide forcément tous les caches, etc.
Merci pour les exemples. J'ai l'impression que les green threads sont là pour être plus simple qu'un monde juste asynchrone. Mais je n'arrive pas à voir cela comme véritablement plus efficace que d'autres solutions pour pallier aux callback hell.
En fait, mon usage n'est pas le même que le tiens.
Je n'ai pas de problème de portabilité. Il est très rare que j'écrive un script qui sort de ma machine. L'énorme majorité du temps c'est pour mon usage personnel. Quand j'en écris un pour un serveur au boulot j'utilise le bourn shell ou python parce que c'est ce qui est le plus maitrisé par mes collègues. Quand c'est sur ma machine j'utilise zsh la majorité du temps.
J'utilise du coup le même langage en interactif (zsh est mon login shell) et pour mes scripts. La genèse de mes scripts est souvent intéractif.
De mon point de vue, il y a d'un côté la programmation événementielle, avec un seul thread, une boucle événementielle et des callbacks (potentiellement abstraits via des promises, futures, observables).
Là tu décris le paterne reactor. C'est une façon de faire de l'évènementiel. On doit pouvoir dire qu'il s'agit de tout ce qui est réactif.
Et de l'autre côté, on a des modèles qui s'exécutent sur plusieurs threads et du parallélisme.
Il y a un tas de façons de gérer ça donc à part dire que c'est de la programmation parallèle, je ne vois pas bien quoi en dire de plus.
Pour les serveurs où les performances (et notamment la latence) sont importantes, j'ai l'impression que le premier modèle est nettement en déclin (la hype, c'était plutôt vers 2010-2013), avec notamment beaucoup de Go.
Je n'ai pas réussi à trouver l'architecture interne de haproxy ou de sozu […] je viens de trouver une conférence d'un développeur de sozu. Je te l'ai mis au timecode qui parle de ça, ils font de l'eventloop monothread. Pour ceux qui ne connaissent pas sozu est un reverse proxy sorti l'an dernier (et open source) dont l'objectif est la performance et la capacité à n'avoir aucune downtime y compris lors de ses mises à jour et des changements de configuration. Ils l'ont écris en rust et sont d'abord aller voir ce qu'il y avait sur le marché. Je pense qu'on peut dire qu'ils ont une bonne vision de l'état de l'art du domaine (et au passage il explique que haproxy (comme nginx) est aussi une eventloop monothread).
Je connais mal les green threads comment ils se comportent par rapport aux contexte switch ? Je veux dire :
comment le runtime d'un langage est plus à même de faire des choix que CFS ?
comment se comporte le contexte swicth ? c'est juste qu'on reste dans l'espace utilisateur ?
comment cela se passe par rapport aux caches CPU ?
Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ? J'aimerais bien regarder le modèle de threading utilisé.
Nodejs a plutôt l'air de survivre auprès des développeurs Front (que ce soit pour des outils à la webpack, browserify, babel, etc. ou pour avoir le même code Angular/React/Vue qui tourne côté client et côté serveur).
J'ai volontairement pas parlé du front parce que le sujet est très différent.
Non, il dit que JavaScript a fait des progrès, notamment avec le mot clef async, mais que le modèle du JavaScript reste inférieur pour les serveurs à celui de Go.
Je n'ai probablement pas lu avec assez d'attention je n'ai pas trouvé ce passage.
Je suis parfaitement d'accord avec toi ! C'est uniquement parce que je veux pousser mes outils dans leur limite avant de passer à l'artillerie au dessus que je ne remplace pas mon awk par perl. J'avais découvert toutes ces possibilités avec l'article : http://articles.mongueurs.net/magazines/perles/perles-38.html qui permet de se rendre compte de comment il fonctionne de manière assez ludique :)
L'objectif était justement de faire le lien entre tout ce qu'on peut lire aujourd'hui sur le réactif et le fait que ça prend ses racines dans des choses qui ne sont pas particulièrement récent (j'ai bien décris à quel moment chacun de ses appels est apparu justement).
Aucun de ces deux exemples n'utilisent de la programmation événementielle.
Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.
Pour MigratoryData, c'est basé sur du publish-subscribe qui est classé dans l'event driven programming sur wikipedia.
Après je n'ai pas caché qu'il y a d'autres solutions, j'ai dis explicitement que je m'intéressais à l'une d'entre elles.
Je me rappelle qu'il y a quelques années, vers 2010-2012, je m'intéressais à la programmation événementielle, d'abord avec EventMachine en Ruby, puis avec Node.js. Mais, ça donnait du code compliqué[…]
Ça peut devenir plus compliqué, je suis d'accord, mais les API comme Rx sont très populaires aujourd'hui et je trouve que les Functional Reactive Programming sont plutôt lisible (voir elm par exemple, même si ça n'est pas pour du serveur).
D'ailleurs, je trouve intéressant l'entretien avec Ryan Dahl, créateur de Node.js, où il explique que Go a un meilleur modèle d'IO que nodejs pour les serveurs. Voici une citation rapide, mais il y a plus de détails dans l'entretien complet :
That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
Tout ce que je vois dans l'article c'est de dire que les coroutines c'est mieux que les callback-hell, mais il y a bien d'autres API sur de l'asynchrones (les futures, les promesses, les observables,…). Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.
Je n'ai pas était assez clair, mais l'idée général n'est pas de dire que c'est particulièrement nouveau. Le développement de POE par exemple a commencé il y a 20 ans.
Par contre si je comprends bien l'interrupt coalescing. Il s'agit de remplacer les interruptions hardware pour les envoyer des une file. Pour réduire les interruptions et avoir un meilleur débit en augmentant la latence, là où la programmation réactive a pour objectif de réduire la latence quitte à limiter le débit.
Hum… Je ne sais pas ce que tu entends par sobriété. awk s'inscrit dans la veine des grep/cut/sed. Lui donner des centaines de Mio de données ne lui fais pas particulièrement peur.
D'un point de vue performance, selon les cas grep+cut peuvent être plus performance grâce pipelining (mais si ton pipeline as plus d'étapes que tu n'a de cœurs tu ne gagne rien). Sur des exécutions rapide mais fréquentes le fait d'utiliser un seul processus va par contre te faire gagner du temps. Enfin awk permet d'exprimer des choses autrement.
Exprimer ce que j'ai fais en awk avec grep+cut ça donne :
et ça ne gère pas un time dont la taille serait variable (il faudrait faire un cut par field puis retirer les dernier caractère).
Avec grep+sed ça marche mieux :
xev | sed -n '/KeyPress event/{n;s/ root.* time \([0-9]*\), .*/\1/p}'
Mais bon on perds en lisibilité. La majeur partie du temps je me sert d'awk pour extraire des données depuis un ps, lsof, etc et je trouve awk beaucoup plus pratique pour ça.
Je n'ai personnellement jamais mis en défaut gred, sed, cut ou awk (et pourtant j'aimerais bien pour avoir l'occasion de jouer avec perl).
Bah oui, mais pas pour C++, pour qui static signifie une existance en dehors d'une classe instantiée. Le seul usage qui pourrait correspondre, c'est "static const", mais là, c'est plus le "const" qui est important.
Pas forcément. Il y a pleins de choses qui vivent en dehors des classes et qui ne sont pas dis « static » (les fonctions libres, les templates,…). De plus des mots-clef comme static_cast() ne correspond pas à ta définition (et il est antérieur à l'introduction de constexpr).
Du coup, utiliser static avec une signification différente de ce qu'il a ailleurs en C++, ça ne va pas simplifier le système.
Redéfinir un mot utilisé dans le reste de l'industrie à tel point que l'on en réécris une partie du langage (on renomme des mots-clefs) ne va probablement pas aider. Renommer des mots clefs en gardant la compatibilité (donc avoir 2 mots clefs qui feraient aujourd'hui la même chose) c'est ce qui amène des class/struct…
Pour l’anecdote, cette fonctionnalité aurait bien pu s'appeler constexpr_assert() car constexpr exprime qui est évalué lors de la compilation. Donc constexpr est plus précis que static dans le nom constexpr_assert(). La fonctionnalité static_if s'est bien fait renommée constexpr_if (voir l'historique de P0292).
Pour moi static c'est tout ce qui se passe avant l’exécution du programme. Par exemple : l'analyse statique de code consiste à analyser une base de code sans l'exécuter. Quelle est la subtilité avec consexpr ? constexpr représente le temps de la compilation, alors que le static peut être au chargement du programme en mémoire ?
Ce que tu met en place me semble être un système de cache. Une solution ne pourrait pas être d'utiliser une partition spécifique et de paramétrer le iosched de ce dernier ?
Rooh le troll !!!
Autant le dire tout de suite, IntelliJ, et tout les IDE qui tournent autour m'insupportent. Et traiter Eclipse d'UAG en comparaison faut vraiment pas avoir peur.
Un IDE qui me demande 10000 trucs à chaque fois lors de l'install incapable de gèrer du multiprojet et … moche … et qu'il faut payer en plus, no mé Allooo
Ca s'apparente à du Cargo Cult.
Je ne connais plus vraiment eclipse (je suis entrain de réessayer pour voir), mais tu ne parle pas d'Intellij là… Il gère des "multiprojet" sans problème. les boites de dialogues sont plutôt simples, la beauté c'est une question de goût, mais pour être entrain de réessayer eclipse je préfère l'organisation intellij. Eclipse a une barre de boutons qui regroupe pleins de trucs là où intellij les places au plus prêt des outils dans leurs panneaux spécifiques. C'est peut être une question d'habitude ou j'ai peut être une customisation d'intellij que j'ai oublié. Par contre de mon bref essaie pour le moment a eclipse, j'ai toujours du mal avec le démarrage du projet : je ne sais pas choisir entre prendre un projet de source existante sans en faire un projet maven ou faire un checkout d'un projet maven depuis un dépôt. Je n'ai jamais compris l'intérêt du workspace non plus d'ailleurs.
Intelij m'avait séduit par des micro fonctionnalité qui sont facile d'accès (il ne faut pas avoir fouillé les profondeurs de l'IDE pour les trouver) et qui sont bien sympathiques :
sélection > clique-droit > « compare with clipboard » juste génial pour faire des refacto ;
shift-shift pour chercher partout (tous les identifiants de ton projets, toutes les fonctions de l'IDE, tous les noms de fichiers, etc) ;
clique-droit sur un dossier > « Mark directory as » > source root/test root/resources root/test resources root : quand j'utilisais encore eclipse il y avait des fois où eclipse ne se décidait pas à comprendre qu'un dossier était des sources ou des tests et c'était très compliqué de lui faire comprendre ;
pour faire du remote debuging : je choisi de lancer le debugger, j'indique les informations qui m'intéressent (genre le nom d'hote et le port) et il me génère les paramètres à ajouter à la jvm pour que ça corresponde (ne plus avoir besoin d'un moteur de recherche c'est très pratique).
ton système de type n'est pas forcément suffisant pour rendre le chose compréhensible notamment pour avoir une idée clair des pré/post-conditions et des invariants. Mettre tout ça dans tes identifiants n'est pas forcément plus intéressant que ça (il peut y avoir une décorrélation entre le nom et son utilisation) et augmenter la taille des noms ne rend pas forcément le code plus lisible ;
ton code travaille interagis avec d'autres éléments qui peuvent t'imposer certaines choses ou condition (notamment pour de l'IoT ou hardware) expliquer pourquoi tu fais certaines actions ou pourquoi l'ordre dans le quel tu les fais est important n'est pas forcément trivial et peut donc mériter d'être commenté ;
les structures qui te permette d'être hyper expressif peuvent au contraire poser des problèmes de performance par exemple et tu peux donc ne pas pouvoir t'en servir.
Avoir comme objectif de réduire au minimum la quantité de commentaire (comme de réduire la quantité de code non testé) c'est bien, mais il ne faut pas en conclure qu'il faut se l'interdire ou imaginer que c'est une mauvaise pratique.
Pour le coup les sources des paquets debian sont dispo et tu y trouve le dossier des sources upstream sans le moindre changement. Les patchs appliqués sont dans un dossier spécifiques).
De tête reconstruire un paquet sans les patch ça doit être à peu près :
Tu es loin d'être le seul à avoir rencontré ce genre de problème. La communauté Debian essaie d'arrêter d'avoir un mainteneur pour un paquet donné, mais de faire ça en équipe. Ça n'apporte que des bonnes choses :
une meilleure réactivité, tu as plus facilement quelqu'un dispo
de meilleurs échanges : ce n'est pas garanti, mais tu évite les biais du gars qui s'est levé du pied gauche ce matin
c'est plus facile de s'intégrer : le travail de l'empaqueteur est revu avec une boucle de feedback plus courte que lors de l'intégration aux dépôts
il y a une meilleure mutualisation : les équipes se forment autour de centre d'intérêt (python, science,…) et maintiennent une série de paquets ce qui est fait pour un paquet peut être fait pour tous
Les remontés de bug directement à l'upstream, Debian tente de les éviter en proposant des outils dans Debian pour simplifier la remonté de bug au sein de Debian. C'est encore loin d'être parfait.
C'est beaucoup moins le cas dans les distributions à base de RPM qui ont tendance à fournir des logiciels plus "vanilla".
Beaucoup de logiciels ne respectent pas très bien les standards du genre HFS ou tout ce qui vient de freedesktop.
C'est un point de vue qui me paraît complètement irréaliste pour un logiciel comme LibreOffice dont les utilisateurs sont vraiment nombreux. L'empaqueteur ne ferait que ça de la journée et passerait son temps à remonter des doublons upstream.
Rien oblige à ce qu'il soit seul, mais surtout, c'est une bonne répartition de charge ! Flooder l'upstream n'est pas plus efficace. C'est le contraire ça pas très bien quand il y a peu d'utilisateurs.
Le meilleur moyen de savoir si un bug vient du packaging de la distribution, c'est justement d'en avoir connaissance upstream et d'essayer de le reproduire sur d'autres distributions et d'autres OS.
Si tu veux plus t'investir et aller plus loin dans la qualification tu trouvera presque souvent des gens bienveillants.
[^] # Re: Sympa ton journal
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2.
C'est une autre façon de présenter les promesses, les futures et les observables oui :)
Je suis d'accord que c'est totalement infernal de travailler à base de callback. Ça rend très complexe le moindre refactoring aussi et ça empêche de voir certain partern dans le code.
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2.
C'est le mot à la mode pour dire qu'on utilise un pattern reactor (AM*H*A).
Pour moi une distinction importante consiste dans le fait de recevoir un évènement et que cet évènement contient toute l'information utile à mettre en rapport avec le fait de tout envoyer dans le contexte d'un fil d'exécution. Quand tu spaw un thread par requête et que ton framework te positionne dans le contexte de ton thread toute l'information utile (la requête, l'authentification, etc), tu peux difficilement dire que tu es évènementiel. C'est typiquement ce que fais Spring par exemple. Il utilise intensivement le thread local storage.
Merci pour le lien. De ce que j'ai l'impression il remplace les appels asynchrones par des appels synchrones, mais qui indique qu'il faut les préempter et c'est la différence avec CFS. Par contre je ne vois pas comment ça pourrait bien se passer en terme de cache. Le context switch est drastiquement plus léger, mais il est toujours là, on invalide forcément tous les caches, etc.
Merci pour les exemples. J'ai l'impression que les green threads sont là pour être plus simple qu'un monde juste asynchrone. Mais je n'arrive pas à voir cela comme véritablement plus efficace que d'autres solutions pour pallier aux callback hell.
[^] # Re: Outils de base et awk vs Perl
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 2.
En fait, mon usage n'est pas le même que le tiens.
Je n'ai pas de problème de portabilité. Il est très rare que j'écrive un script qui sort de ma machine. L'énorme majorité du temps c'est pour mon usage personnel. Quand j'en écris un pour un serveur au boulot j'utilise le bourn shell ou python parce que c'est ce qui est le plus maitrisé par mes collègues. Quand c'est sur ma machine j'utilise zsh la majorité du temps.
J'utilise du coup le même langage en interactif (zsh est mon login shell) et pour mes scripts. La genèse de mes scripts est souvent intéractif.
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 4.
Là tu décris le paterne reactor. C'est une façon de faire de l'évènementiel. On doit pouvoir dire qu'il s'agit de tout ce qui est réactif.
Il y a un tas de façons de gérer ça donc à part dire que c'est de la programmation parallèle, je ne vois pas bien quoi en dire de plus.
Je n'ai pas réussi à trouver l'architecture interne de haproxy ou de sozu […] je viens de trouver une conférence d'un développeur de sozu. Je te l'ai mis au timecode qui parle de ça, ils font de l'eventloop monothread. Pour ceux qui ne connaissent pas sozu est un reverse proxy sorti l'an dernier (et open source) dont l'objectif est la performance et la capacité à n'avoir aucune downtime y compris lors de ses mises à jour et des changements de configuration. Ils l'ont écris en rust et sont d'abord aller voir ce qu'il y avait sur le marché. Je pense qu'on peut dire qu'ils ont une bonne vision de l'état de l'art du domaine (et au passage il explique que haproxy (comme nginx) est aussi une eventloop monothread).
Je connais mal les green threads comment ils se comportent par rapport aux contexte switch ? Je veux dire :
Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ? J'aimerais bien regarder le modèle de threading utilisé.
J'ai volontairement pas parlé du front parce que le sujet est très différent.
Je n'ai probablement pas lu avec assez d'attention je n'ai pas trouvé ce passage.
[^] # Re: Outils de base et awk vs Perl
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 3.
Je suis parfaitement d'accord avec toi ! C'est uniquement parce que je veux pousser mes outils dans leur limite avant de passer à l'artillerie au dessus que je ne remplace pas mon awk par perl. J'avais découvert toutes ces possibilités avec l'article : http://articles.mongueurs.net/magazines/perles/perles-38.html qui permet de se rendre compte de comment il fonctionne de manière assez ludique :)
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 7.
L'objectif était justement de faire le lien entre tout ce qu'on peut lire aujourd'hui sur le réactif et le fait que ça prend ses racines dans des choses qui ne sont pas particulièrement récent (j'ai bien décris à quel moment chacun de ses appels est apparu justement).
Elixir par construction se base sur le système à acteurs d'erlang qui est une manière évènementielle de coder.
Pour MigratoryData, c'est basé sur du publish-subscribe qui est classé dans l'event driven programming sur wikipedia.
Après je n'ai pas caché qu'il y a d'autres solutions, j'ai dis explicitement que je m'intéressais à l'une d'entre elles.
Ça peut devenir plus compliqué, je suis d'accord, mais les API comme Rx sont très populaires aujourd'hui et je trouve que les Functional Reactive Programming sont plutôt lisible (voir elm par exemple, même si ça n'est pas pour du serveur).
Tout ce que je vois dans l'article c'est de dire que les coroutines c'est mieux que les callback-hell, mais il y a bien d'autres API sur de l'asynchrones (les futures, les promesses, les observables,…). Il dit lui même que l'introduction du mot clef "async" doit avoir changer ce problème.
[^] # Re: Typo dans le titre
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 3.
Merci beaucoup !
[^] # Re: Vieille solution
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2.
Je n'ai pas était assez clair, mais l'idée général n'est pas de dire que c'est particulièrement nouveau. Le développement de POE par exemple a commencé il y a 20 ans.
Par contre si je comprends bien l'interrupt coalescing. Il s'agit de remplacer les interruptions hardware pour les envoyer des une file. Pour réduire les interruptions et avoir un meilleur débit en augmentant la latence, là où la programmation réactive a pour objectif de réduire la latence quitte à limiter le débit.
[^] # Re: Typo dans le titre
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2.
Arf désolé -_-'
[^] # Re: awk vs cut
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 3. Dernière modification le 06 mars 2018 à 16:12.
Tu n'a pas compris en ayant 2 espace entre le champ 3 et 4 :
[^] # Re: awk vs cut
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 4.
Hum… Je ne sais pas ce que tu entends par sobriété. awk s'inscrit dans la veine des grep/cut/sed. Lui donner des centaines de Mio de données ne lui fais pas particulièrement peur.
D'un point de vue performance, selon les cas grep+cut peuvent être plus performance grâce pipelining (mais si ton pipeline as plus d'étapes que tu n'a de cœurs tu ne gagne rien). Sur des exécutions rapide mais fréquentes le fait d'utiliser un seul processus va par contre te faire gagner du temps. Enfin awk permet d'exprimer des choses autrement.
Exprimer ce que j'ai fais en awk avec grep+cut ça donne :
et ça ne gère pas un time dont la taille serait variable (il faudrait faire un cut par field puis retirer les dernier caractère).
Avec grep+sed ça marche mieux :
Mais bon on perds en lisibilité. La majeur partie du temps je me sert d'awk pour extraire des données depuis un ps, lsof, etc et je trouve awk beaucoup plus pratique pour ça.
Je n'ai personnellement jamais mis en défaut gred, sed, cut ou awk (et pourtant j'aimerais bien pour avoir l'occasion de jouer avec perl).
[^] # Re: xev
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 2.
Arf c'était une valeur de test pour moi j'ai oublié de le changer avant de publier. Désolé.
[^] # Re: xev
Posté par barmic . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 2.
Tu as bien sélectionné la fenêtre que xev crée d'appuyer sur des touches ?
[^] # Re: Merci pour ce partage - mais la doc fouque
Posté par barmic . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 2.
ans → semaines ;)
[^] # Re: Portage du vendredi
Posté par barmic . En réponse au journal Portage de TapTempo en Wren. Évalué à 3.
C'est plus une version malbolge qui m'amuserait :)
[^] # Re: static / constexpr
Posté par barmic . En réponse à la dépêche C++17 adapte le static_assert() aux usages. Évalué à 2.
Pas forcément. Il y a pleins de choses qui vivent en dehors des classes et qui ne sont pas dis « static » (les fonctions libres, les templates,…). De plus des mots-clef comme
static_cast()ne correspond pas à ta définition (et il est antérieur à l'introduction deconstexpr).Redéfinir un mot utilisé dans le reste de l'industrie à tel point que l'on en réécris une partie du langage (on renomme des mots-clefs) ne va probablement pas aider. Renommer des mots clefs en gardant la compatibilité (donc avoir 2 mots clefs qui feraient aujourd'hui la même chose) c'est ce qui amène des
class/struct…# static / constexpr
Posté par barmic . En réponse à la dépêche C++17 adapte le static_assert() aux usages. Évalué à 3.
Pour moi static c'est tout ce qui se passe avant l’exécution du programme. Par exemple : l'analyse statique de code consiste à analyser une base de code sans l'exécuter. Quelle est la subtilité avec
consexpr?constexprreprésente le temps de la compilation, alors que lestaticpeut être au chargement du programme en mémoire ?# Cache
Posté par barmic . En réponse au journal Recette de cuisine : base whisper (carbon, graphite) avec zram et anything-sync-daemon. Évalué à 1.
Ce que tu met en place me semble être un système de cache. Une solution ne pourrait pas être d'utiliser une partition spécifique et de paramétrer le iosched de ce dernier ?
[^] # Re: IntelliJ non open-source
Posté par barmic . En réponse au journal Quel IDE pour quel langage. Évalué à 1.
Bof je vois mes collègues qui sont contents avec, mais j'en ressent pas le besoin et me sent pas moins efficace qu'eux.
[^] # Re: A peu près pareil que le top
Posté par barmic . En réponse au journal Quel IDE pour quel langage. Évalué à 4.
Je ne connais plus vraiment eclipse (je suis entrain de réessayer pour voir), mais tu ne parle pas d'Intellij là… Il gère des "multiprojet" sans problème. les boites de dialogues sont plutôt simples, la beauté c'est une question de goût, mais pour être entrain de réessayer eclipse je préfère l'organisation intellij. Eclipse a une barre de boutons qui regroupe pleins de trucs là où intellij les places au plus prêt des outils dans leurs panneaux spécifiques. C'est peut être une question d'habitude ou j'ai peut être une customisation d'intellij que j'ai oublié. Par contre de mon bref essaie pour le moment a eclipse, j'ai toujours du mal avec le démarrage du projet : je ne sais pas choisir entre prendre un projet de source existante sans en faire un projet maven ou faire un checkout d'un projet maven depuis un dépôt. Je n'ai jamais compris l'intérêt du workspace non plus d'ailleurs.
Intelij m'avait séduit par des micro fonctionnalité qui sont facile d'accès (il ne faut pas avoir fouillé les profondeurs de l'IDE pour les trouver) et qui sont bien sympathiques :
Je verrais si eclipse a corrigé tout ça.
[^] # Re: Merci pour ce partage - mais la doc fouque
Posté par barmic . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 10.
C'est bien plus compliqué que ça.
Avoir comme objectif de réduire au minimum la quantité de commentaire (comme de réduire la quantité de code non testé) c'est bien, mais il ne faut pas en conclure qu'il faut se l'interdire ou imaginer que c'est une mauvaise pratique.
[^] # Re: Impolitesse ?
Posté par barmic . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 4.
Pour le coup les sources des paquets debian sont dispo et tu y trouve le dossier des sources upstream sans le moindre changement. Les patchs appliqués sont dans un dossier spécifiques).
De tête reconstruire un paquet sans les patch ça doit être à peu près :
[^] # Re: Impolitesse ?
Posté par barmic . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 6.
Dans la version, ce qui n'est pas forcément très visible.
[^] # Re: Impolitesse ?
Posté par barmic . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 5.
Tu es loin d'être le seul à avoir rencontré ce genre de problème. La communauté Debian essaie d'arrêter d'avoir un mainteneur pour un paquet donné, mais de faire ça en équipe. Ça n'apporte que des bonnes choses :
Les remontés de bug directement à l'upstream, Debian tente de les éviter en proposant des outils dans Debian pour simplifier la remonté de bug au sein de Debian. C'est encore loin d'être parfait.
Beaucoup de logiciels ne respectent pas très bien les standards du genre HFS ou tout ce qui vient de freedesktop.
[^] # Re: Impolitesse ?
Posté par barmic . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 3.
Rien oblige à ce qu'il soit seul, mais surtout, c'est une bonne répartition de charge ! Flooder l'upstream n'est pas plus efficace. C'est le contraire ça pas très bien quand il y a peu d'utilisateurs.
Si tu veux plus t'investir et aller plus loin dans la qualification tu trouvera presque souvent des gens bienveillants.