S'il n'y a aucune contention à quoi sert le lock ?
Par contre par design, tu as probablement plus de chance, comme tu as plus de thread dans ce design, de te retrouver avec la requete d'acces suivante sur un autre core et donc declenche une perte de cache.
T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de .tar.gz je ne sais pas de quoi tu parle. Les .tar.gz dont on parle classiquement sont des sources qui demandent ./configure.sh && make && make install.
Ces applications de l'utilisateur ont juste besoin d'ĂŞtre trouvable dans le PATH et d'avoir un .desktop quelque part. Il existe une solution hyper simple :
Donc me dire que j'ai tord parce que "Linus Torvald a dit que" il y a 8 ans, le tout pour souligner que "Debian c'est de la chiasse au moins sous Windows et Mac ça marche", c'est pas de l'irrespect ?
Et est-ce que t'a vraiment envie d'avoir une conversions de string par default, a chaque comparaison, quand tu recode un compilateur, qui auras 10M lignes de code à recompiler le plus rapidement possible ?
Je ne comprends pas ce que tu veux dire de quelle conversion tu parle ?
c'est aussi vouloir lui enlever le choix dans la pratique de ses programmes, c'est un peu incompatible avec le libre comme point de vue?
Je n'affabule pas. Je ne change aucun de tes mots. Tu affirme que faire du web c'est vouloir enlever le choix et tu te demande si c'est compatible avec le libre.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  2. Dernière modification le 06 mars 2022 à 09:12.
S'il n'y a aucune contention à quoi sert le lock ?
Je ne sais pas comment marche go pour ça les go routines sont allouées à un thread système et les threads systèmes sont exécuté sur n'importe quel cpu ?
Plusieurs choses. C'est dans la théorie de flux donc je ne voulais pas être complaisant avec mon design et, comme le fais fyne, tu ne veux pas que ceux qui consomment ton état (état au sens flux, bindings au sens fyne) ne mutent celui-ci. La solution idéale c'est l'imutabilité, tu file une référence à tout le monde et c'est parti. Fyne passe par des interfaces pour ça de ce que je lis. Je n'y avais pas pensé mais c'est pas mal. Il faut juste avoir tout ce qu'il faut d'interface. Fyne semble faire de la génération avec flux tu maintient une interface qui décrit tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3. Dernière modification le 06 mars 2022 à 01:21.
Tu t'es senti visé tout seul. Je ne te reproche qu'une complaisance et groomly te disais que si tu te sent visé c'est peut être qu'il y a quelque chose.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  1.
Tu veux vraiment ressortir les bails ? Il y a des faits, c'est établi et plutôt récent. Le fait de vouloir noyer les choses dans un relativisme radical n'est pas de la neutralité mais de la complaisance.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  2.
Je n'ai jamais parlé d'api mais d'implémentation.
Comme je l'ai dit je ne suis pas un développeur go, si les channels ne sont pas là bonne solution il faut prendre une bibliothèque qui gère des files avec les bonnes propriétés. J'ai décrit les grandes lignes des caractéristiques.
Tu te focalise sur l'api ça n'a jamais été mon point. Que tu écrive ou non le lock tu paie son coût, tu as des data race possible, tu prends un lock par binding,…
Pour ce qui est de la copie c'est dommage. Je ne sais pas ce qu'il y a comme possibilité de réflexion et comme rtti pour pouvoir copier simplement. Une autre possibilité serait d'avoir un proxy qui donne une vue en lecture seule de la structure qu'il proxifie. Après ce n'est pas une obligation vuex ne fait pas ça et fais confiance à l'utilisateur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  4.
Alors il me semble que pas du tout. Je vais imaginer comment flux pourrais être implémenter en go. Ça ne vaut pas grand chose. Je ne suis pas un dev go et je fais ça sur un coin de table.
Tu va plutĂ´t t'appuyer sur les channels. Toutes modifications de l'Ă©tat, qu'elle vienne de l'ui ou pas est un envoi dans un channel vers cette goroutine.
Cette goroutine garde toujours le dernier état global de l'application. Quand il reçoit une action, il exécute un à un tout les reducers qui sont de simple fonctions pures (c'est-à -dire qu'elles ne prennent aucune entrée autre que leur paramètre donc elles ne regarde pas l'heure ou ne vont rien chercher sur le réseau). Pour chacune tu leur donne l'état précédent et l'action et il te donne le nouvel état (qui sera du coup donné au reducer suivant). Une fois le nouvel état complètement calculé, on va le dispatch. Il y a des détails d'implémentation qui sont des choix et contraintes du langage (est-ce que l'on peut rendre une structure immuable ? Combien coûte d'en faire une copie profonde ?).
Ceux qui font actuellement un get par binding, vont simplement devoir avoir le nouvel état qu'ils vont récupérer en une fois.
L'épine dorsal en tout ça c'est les channels. Je ne connais pas forcément assez pour savoir si ça peut fonctionner dans le cas contraire je ne doute pas qu'il existe des bibliothèques de queues efficaces (au lieu de faire des synchro tu utilise des entiers atomiques c'est moins lourd et bien plus simple). Et les reducers doivent tous s'exécuter dans le même thread.
Avec une implémentation efficace, le point de contention c'est quand tout le monde cherche à écrire des actions et ça revient simplement à incrémenter un nombre atomique. Le dispatch c'est de la mise à disposition d'une structure immuable (ou d'une structure par consommateurs éventuellement) donc tu ne devrait pas avoir de synchronisation.
La clef c'est que l'envoi de message peut être très efficace entre des threads.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  4.
Avec redux ? C'est redux qui implémente ça et react peut s'utiliser avec ou non. Si oui tu as des devtools qui permettent de voir toutes les actions qui ont étaient jouées et de les manipuler. Donc tu vois quelle action, puis le reducer associé et donc ton composant.
https://github.com/reduxjs/redux-devtools
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  5.
Le 2 way data binding multiplie les entrées de ton programmes qui vont muter ton état de manière asynchrones et parallèle garantir une cohérence là dedans est vraiment complexe. La plupart des frameworks qui l'utilisent peuvent produire des erreurs du genre change after view qui sont plutôt douloureux à debugger.
Ce que tu présente c'est une extension qui tu regarde l'implémentation du moteur tu vois que tous passe par des lock https://github.com/fyne-io/fyne/blob/master/data/binding/binding.go
Tout ça peut aller jusqu'au cycle de digestion où l'ui modifie l'état, l'état réagi et se met à jour, ce qui modifie l'ui, qui modifie l'état,….
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Pour essayer de repartir sur des bases moins toxique je vais prendre ce qui me paraît cœur.
Le problème c'est que d'un côté c'est une potentialité et de l'autre c'est utilisé au quotidien par tout un chacun.
Dans les fait Windows par de très loin avec quelque chose qui permettais facilement d'installer des choses, mais peu sécurisé et difficile à maintenir et ont beaucoup évolués. L'aspect communautaire fait que sur linux, on a créé des potentialités mais pour le moment aucune n'a suffisamment percée pour être disponible partout et avoir la finition qui convient pour vraiment permettre de le laisser dans les mains d'un utilisateur moyen.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  0.
T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de
.tar.gzje ne sais pas de quoi tu parle. Les.tar.gzdont on parle classiquement sont des sources qui demandent./configure.sh && make && make install.Tout le monde à le droit écrire dans ce /apps ? Il n'est pas définir par HFS actuellement, /opt peut mais il n'est pas aussi normalisé. Comment tu met à jour tout ça ?
Mais du coup ta solution pour dire qu'il n'y a pas de problème avec les systèmes de paquets c'est d'en concevoir un nouveau ?
On ne doit pas être d'accord sur les termes, mais du coup je ne comprends pas quel point de vu tu me donne. Ce dont tu parle c'est d'un système de paquet mis en place par les développeurs d'Apple, mais le boulot de packaging est fait par les développeurs d'application. Comme je le disais dans mon commentaire : une solution qui permet aux développeurs d'application de fournir un logiciel sans que ça n'ajoute du travail aux développeurs Apple.
Les gestionnaires de paquets :
Le boulot de créer des package doit revenir au développeurs des applications à packager.
Le boulot de créer les systèmes de paquets doit revenir aux développeurs de distribution.
Le point initial c'est "la difficulté à créer un package qui soit utilisable à peu près partout sans difficulté est un problème".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  5.
Juste pour ceux qui veulent se renseigner, on parle souvent de virtual DOM et c'est pas lié à Flux. Tout framework déclaratif l'utilise (ce n'est pas toi qui dit comment modifié le dom, tu présente ce que tu veux et le framework fait les changements).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
C'est pas parce que tu ne connais pas que tu peux y sortir tous tes poncifs. Le 2 way data bindings consomme énormément de ressource là où flux peut être implémenté de manière triviale. Il en existe des implémentations, mais tu peux très bien suivre cette architecture en js vanilla et ça va être largement plus simple qu'implémenter le 2 way binding.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Pas dans celui que j'ai cité.
Ça ne marche pas et ça ne marchera pas dans l'avenir. Les distributions ont de plus en plus de mal à avoir des contributeurs, le nombre de logiciels est croissants,… Cette découpe cathédralesque « tout le monde reste chez soit et les moutons seront bien gardé » ne fonctionne pas, ce n'est pas ce qui est fait dans tous les systèmes où le packaging n'est pas un problème et où on a un foisonnement de logiciels. On y croyait dans les années 90, mais ça devient compliqué à tenir et ça ne va pas en s’arrangeant. Si c'était réellement le cas on aurait pas vu arriver autant de système de paquets arrivés pour combler un besoin qui n'existerait pas. Les développeurs debian sont satisfait de dpkg.
Ce n'est pas ce qu'il font. Très peu d'utilisateurs de windows et mac ont une véritable toolchaine sur leur machine. Sur windows les gens font pas mal d'installeur et sous mac ça se rapporche (il me semble) d'un appimage mais mieux intégré (le finder les prends automatiquement en compte) et aujourd'hui les 2 poussent vers un store, mais ce n'est pas comme les dépôts debian/redhat, les développeurs poussent eux même leurs paquets.
Quelque soit la manière permettre aux développeurs de fournir un paquet aux utilisateurs linux, qui soit correctement installés (inclus dans le launcher et dans le $PATH à minima) sans devoir attendre le bon vouloir des distribution ou sans que ça représente une charge de travail en plus pour elles. Aujourd'hui on s'en approche à peu prêt (on reste avec au moins 2 solutions très distinctes dans leur utilisation - donc l'utilisateur doit connaître les 2 -), mais ça demande encore du travail.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  2.
Juger les gens plutĂ´t que leurs arguments c'est toujours dommageable.
Ces systèmes de packages n'ont pas fondamentalement changé les problématiques. AppImage par exemple n'est pas intégré en tout cas dans les distributions que j'utilise (il faut que je le mette moi dans un dossier de mon $PATH, il n'a pas de .desktop - moi je n'en ai pas besoin, mais c'est un problème,…). Flatpack ne met pas lui applications dans mon $PATH et pose des contraintes (de build si par exemple tu utilise maven, d'intégration si tu a un système de plugin). Dans les faits aujourd'hui tu as encore énormément de développeurs qui font du dpkg/rpm voir du
curl | sh -.Ça va peut être dans le bon sens et on est peut être dans un moment préliminaire, mais on y est pas encore.
Linus les connaissait en 2014 et comme IPv6, on le voit plus, mais il n'est pas dominant loin de lĂ .
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Et être constructif, ne pas se comporter comme un troll c'est de ne pas se contenter de s’arrêter là dessus pour "vaincre l'adversaire".
Aucun n'a pour le moment changé véritablement la donne. Aujourd'hui le packaging de distribution est toujours extrêmement majoritaire et les distributions qui tentent de s'appuyer quasi exclusivement sur ces packgings sont tout à fait expérimental.
Bon et flatpack existe depuis 2007 et appimage depuis 2004.
Le fait que les développeurs ne sont pas en mesure de produire des packages n'est pas un problème pour les systèmes de packaging ?
Œil pour œil dent pour dent, c'est pas moi qui ai commencé,…
L'amour propre ça se travail tu sais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  6.
Flux est un pattern ça peut s'implémenter un peu partout. J'ai déjà des appli qui font du flux pour gérer et mettre à jour leur état avec des composants MVC. Les composants MVC ne modifient jamais eux même leur état, à la place ils propagent des actions au reducer qui une fois qu'il a généré le nouvel état le donne au modèle du MVC.
Ca permet de faire de toujours se contenter d'un simple binding de données ce qui simplifie la vie du framework mvc que tu utilise.
Par contre le fait que ça ne soit pas natif comme avec elm demande plus de rigueur (on a vite fais de s'ajouter un 2way binding pour gérer un truc dans son coin).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  5.
C'est une disqualification facile. C'est le point présenté par un speaker à la DebConf 2014. Alors tu peux affirmer que la debconf n'est pas pertinente pour parler de packaging sur linux, mais il va falloir un peu plus d'arguments. De plus Linus ne dis pas « je m'appelle Linus et je vous dis que ça c'est mal », mais il explique son point de vu (il est entrain de dire devant un parterre de Debianeux motivés que le packaging debian a des problèmes).
Bref ce n'est pas parce que l'auteur est connu qu'il est possible de botter en touche comme ça. Oui il a était amené un peu à la truelle ("Linus est du même avis que mois" plutôt que "je suis d'accord avec les arguments de Linus"). Les arguments sont pour autant bien là quelque soit ton manque de respect.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  4.
C'est justement contre ça qu'à était pensé le pattern flux (et dérivés). Tu fais du binding de données avec un MVC et dérivés (MVVM et autres). Avec flux tu n'a pas de correspondance direct entre une action utilisateur et une variable qui est modifiée.
La doc de redux est pas mal pour découvrir peut être https://redux.js.org/understanding/history-and-design/prior-art
Grosso modo les 3 implémentation dont j'ai le plus entendu parler c'est elm, redux, vuex.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3.
J'ai déjà eu le problème parce que toutes les implémentations de awk ne sont pas en mesure de gérer l'unicode et ma solution c'est toujours de sortir perl.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  7.
Très caricatural.
grep '^...$'n'est pas un traitement de texte. C'est le travail d'une bibliothèque d'expression régulière ? Alorswc -c ?Rien que pour afficher des données de manière tabulaire comme le fais
ls -l.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3. Dernière modification le 03 mars 2022 à 07:06.
Je ne comprends pas ce que tu veux dire de quelle conversion tu parle ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  5.
Mozilla n'a plus aucun rapport avec rust.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  1.
Si un outil peu t'aider https://linuxfr.org/users/jeanclaude-2/journaux/karma-is-considered-harmful
J'aurais réellement essayé que la discussion soit ouverte et me concentré sur ce que tu as dis plutôt que du personnel. Je trouve sincèrement que les discalifications en sophismes et en liberté à tout va sont violent même quand leur ton sont feutrés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  4.
Tu sors des poncifs.
Quand je parle de difficultés à gérer la mémoire c'est très simple à vérifier tout outillage qui existe il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Quant à la question de l'assembleur elle n'a pas de sens. On parle entre langage turing complet, tu peux compiler les uns vers les autres. Mais si tu as prouvé certaines propriétés dans un, elles seront maintenues à travers ta compilation. Je n'ai pas dit qu'il est impossible de faire un programme C dénué de bug de mémoire, mais sa sémantique ne permet pas de s'en assurer.
Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3.
Pas que loin de là . Il y a pleins de logiciels de bureau écrit en C gimp par exemple. Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.
Ce qui n'a pas était dit plus haut c'est que le C est la lingua franca des langages de programmation et bien des bibliothèques natives même si elles sont implémentées dans d'autres langages offrent une API C. Il n'y a pas d'autres raisons à ça que son statut. C'est très bien parce que ça signifie que la fragmentation une machine vient avec son langage n'a pas tenu, mais c'est aussi un nivellement.
Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  2.
Je n'affabule pas. Je ne change aucun de tes mots. Tu affirme que faire du web c'est vouloir enlever le choix et tu te demande si c'est compatible avec le libre.
On est pas vraiment sur un questionnement ni sur une demande, mais sur une attaque sur la démarche du développeur.
Si tu m'a vu agressif tu m'en vois désolé, je critique ton commentaire et pas toi. Je n'ai aucun doute que tu ne sors pas des choses comme ça dans des issues. J'ai tenté de resté descriptif et c'est ce que je continue de faire dans ce commentaire.
Maintenant pour ton problème avec le web qui serait discriminant…
Il est impossible (hors grosses organisations) de fournir un logiciel accessible à tous. Donc oui des fois ça demande un accès au réseau, des fois ce n'est pas disponible si tu es sur MacOS ou haiku, des fois c'est sur terminaux mobile que c'est compliqué ou l'inverse, des fois c'est si tu as des problèmes de vue ou pour utiliser un dispositif de pointage que ça devient compliqué,… Il faut faire au mieux, mais il faut comprendre que les gens font avec les moyens qu'ils ont. Ce n'est pas en se montrant sévère que les choses changent.
Par exemple si trop peu de gens s'intéressent à l'accessibilité aux handicapes, le web fourni il me semble de base une meilleure accessibilité (augmentation des contrastes d'une page, un zoom universel,…). Bien sur je parle de base et il est facile de casser ça, mais avec Qt tu n'a rien et c'est au développeur d'être actif pour avoir un minimum d'accessibilité (grosso modo chez Qt l'accessibilité se limite à une page de conseils).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll