Ou alors c'est que c'est pas si bien que ça. Perso j'en sais rien (et j'm'en fou en soit), c'est juste que tes remarques se valident entre elles dans un cycle que je voulais faire remarquer.
Maintenant, pour Wayland et dans certain cas sous X11, tu peux te retrouver a travailler dans le buffer que tu avais presente a l'ecran il y a 2 frames. Du coup, tu peux, si tu as une idee des changements qui ont eu lieu, faire un delta et uniquement toucher les morceaux du buffer qui ont change. Pour faire ce delta, tu ne travaille pas au niveau des pixels, cela serait trop couteux, mais au niveau des boundings box des primitives graphiques qui composent la scene que tu dois rendre.
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 ?
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à  3. Dernière modification le 19 mars 2022 à 00:19.
Je n'aime pas le copyleft, mais le copyleft partagé est, il me semble, le moyen le plus fiable de garantir que le développement ne deviendra pas fermé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à  5.
Moi je m'en fou, mais certains se sentent concernés et j'en ai vu s'en plaindre entre autre pour vs code.
Ainsi que de prédater leurs alternatives en te demandant de pas mixer du alma/rocky avec du RHEL.
Mais il ne s'agit plus de « commercialiser du logiciel libre ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et bah dis donc !
Posté par barmic 🦦 . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à  4.
Donc ils vendent du non libre au final et du support, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas natif
Posté par barmic 🦦 . En réponse au journal Slint: Un toolkit pour interface graphiques natives. Évalué à  3.
Avec ce genre d'état d'esprit on va pas très loin, non ?
De mon expérience, les plateformes habituent ou pas à avoir des interfaces hétéroclites. Moi j'utilise awesome chez moi, i3 au boulot, je lance des applications en Qt, Gtk (différentes version), java swing ou tk j'm'en fou. Utilisateur qui a l'habitude (comme ça semble être le cas sur mac) d'avoir une cohérence bien plus forte, des détails vont être vu comme très désagréables. Ce n'est pas de la faute de l'utilisateur et le lui reprocher ne fait avancer personne.
Après à voir comment vous vous positionnez par rapport à ça. Est-ce que votre valeur est avant tout dans le multiplateforme ou un niveau d'intégration solide ? Etc Ça dépend de ce que vous voulais faire et de ce qui est demandé par votre cible d'utilisateurs.
Ou alors c'est que c'est pas si bien que ça. Perso j'en sais rien (et j'm'en fou en soit), c'est juste que tes remarques se valident entre elles dans un cycle que je voulais faire remarquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Conteneurs
Posté par barmic 🦦 . En réponse au journal Golang, oops you did it again. Évalué à  4.
C'est pas un boilerplate c'est in cas d'erreur supprimé car vérifié par le compilateur. Ce n'est pas une question de verbosité mais de fiabilité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Sur Tinder USA uniquement
Posté par barmic 🦦 . En réponse au lien Bientôt il faudra avoir un casier judiciaire vierge pour draguer . Évalué à  4.
Les arguments qui consistent uniquement à dire "non mais je suis sûr que dans l'avenir ça va exister parce que j'aime pas les décideurs", c'est tout aussi pété pour dire que l'on va avoir un score social que pour tous les cas où on l'a entendu ces derniers temps dans des logiques complotistes, hein ? Je trouve ça vraiment bête comme argument.
On peut se poser la question, s'en inquiéter, rester vigilent, s'en émouvoir, mais si ça pouvait se baser sur autre chose que des procès d'intention qui tiennent sur rien d'autres qu'un a priori personnel, ce serait plus intelligent.
Je sais qu'à chaque fois que je challenge ce genre d'arguments ça a tendance à énerver (c'est populiste donc ça plaît, des gens ne distingue pas la qualité argumentative de la thèses qu'ils tentent de porter, pour d'autres la faim justifie les moyens,…).
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 exactement le même principe mais fait à un niveau d'abstraction différent. Au lieu des boundings box c'est des éléments du dom.
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.
Non c'est le virtual dom. Le shadow dom, c'est ce qui permet de cacher le contenu d'un web component.
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.
C'est pourtant ce qui est fait avec le double buffering, non ?
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é à  4.
aucuns faits
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. 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