Go qui est utilise principalement pour developper des services reseaux et les utilitaires en ligne de commande pour les piloter a aussi une communaute grandissante qui developpe les outils necessaire pour developper des application graphiques completement en Go.
Les avantages de Go se retrouvent principalement dans la capacite d'avoir un binaire unique par architecture (compilation statique) et la grande portabilite du code Go, mais aussi dans la simplicite et lisibilite du code. Il existe evidement des bindings pour les bibliotheques classiques Qt et GTK. Mais des bibliotheques native a l'ecosysteme Go sont aujourd'hui pleinement utilisable et permette une meilleure integration avec le language. Deux d'entre elles ont une communaute grandissante et ont un developpement tres actif:
- Fyne sous license BSD 3 clauses qui a une API de style "retained"
- Gio UI sous double license MIT+Unlicense qui a une API de style "immediate"
C'est deux projets cooperent pour ameliorer l'ecosysteme go permettant le developpement d'application graphique native et ont prepare un questionnaire dans le but de mieux connaitre les besoins des developpeurs. Si un jour vous pensez utiliser go pour developper vos applications graphiques, les developpeurs de Fyne et Gio UI apprecieraient beaucoup votre contribution a ce questionnaire: https://fynelabs.com/2022/03/02/announcing-go-gui-developer-survey/ . Les resultats de ce questionnaire seront publie d'ici quelques semaines.
# Go with C
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Est-ce vraiment possible pour des cadriciels IHM? J'ai l'impression qu'ils dépendent tous de bibliothèques en C dynamiquement liées.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go with C
Posté par cedric . Évalué à 4.
Absolument, si les dependences sont disponible statiquement, il n'y a pas de raison. La problematique est probablement une question de license pour les bindings. Mais dans le cadre de l'ecosysteme Go, les projets pure go font attention a prendre des licenses qui ne posent pas ce probleme. C'est le cas pour Gio UI et Fyne, dont les applications sont contenu dans un binaire unique pour toutes les plateformes supportes (BSD, Linux, Mac, Windows, iOS et Android).
[^] # Re: Go with C
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est uniquement un problème de LGPL, licence qui n'est plus si commune.
"La première sécurité est la liberté"
[^] # Re: Go with C
Posté par cedric . Évalué à 5.
Elle est encore tres centrale pour la majorite des toolkits graphiques natif aujourd'hui. Qt et GTK pour ne citer qu'eux en sont un exemple.
[^] # Re: Go with C
Posté par groumly . Évalué à 2.
Ça dépend du contexte.
Sous Windows/macOS, la plupart utilisent les framework systèmes, qui sont compatible binaire dans toutes les directions, et ça just marche.
Ceux qui font du cross plateform avec qt ou quoi ou qu’est-ce vont de toutes façons devoir embarquer leur dépendance et les déposer quelque part a eux sur le système (sous macOS, typiquement dans l’app bundle, donc privé à l’appli, je sais pas trop où en sont les choses sous Windows de nos jours).
Sur ces plateformes, ça va, ça se gère sans trop de migraines. Mais après t’as Linux.
Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions, de différentes options de compilation, compilateur, en veut tu en voila.
Si t’arrives a être intégré upstream, ça aide, mais après tu te tapes des patches qui te plaisent pas forcemment, tu contrôles pas quelle version est distribué, ce genre de choses qui peuvent être un gros problème en fonction du projet.
Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent ».
Et du coup, l’intérêt du link statique de go devient beaucoup plus apparent.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par abriotde (site web personnel, Mastodon) . Évalué à -10.
Tu oublie
- www.macworld.com le portail français du mac et du neonazisme.
Sinon la différence c est que nous, linuxien, n'allons pas sur les forums nazis de windows et mac poluer leurs discutions.
D ailleurs on est pas totalitaire, tu as le choix : Linux, BSD et autres OS open-source. Tu as même le choix de l m'interface graphique.
Alors oui, il y a quelques contraintes qui vont avec la liberté mais c'est le problème de la démocratie. Va vivre en dictature, là tu n'aura pas le choix de ta patte à tartiner, ni d ecouter la radio. Je te propose la Corée du Nord. Là bas on ne se soucis pas de GUI. :D
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Go with C
Posté par groumly . Évalué à 9.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par Frank-N-Furter . Évalué à 4.
Sa signature fait référence aux paumés qui ont bu le Kool-Aid de soral, qui traînent sur linuxfr et qui ne se faisaient pas suffisamment modérer pour leur propos selon groumly (avis que je partage, mais la situation a changée depuis je trouve). Et pas à un extrémisme libriste des personnes qui fréquentent linuxfr.
Depending on the time of day, the French go either way.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4. Dernière modification le 05 mars 2022 à 21:12.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Go with C
Posté par groumly . Évalué à 0.
Qui se sent morveux, se mouche.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par uso (site web personnel) . Évalué à 0.
Vous connaissez Arch Linux ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 05 mars 2022 à 22:49.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Go with C
Posté par barmic 🦦 . É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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4. Dernière modification le 06 mars 2022 à 00:49.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Go with C
Posté par barmic 🦦 . É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
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2. Dernière modification le 06 mars 2022 à 02:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Go with C
Posté par barmic 🦦 . Évalué à 4.
aucuns faits
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 06 mars 2022 à 12:14.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Baltringues :D
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Le dernier paragraphe me fait penser que tu t'est gouré-e de fenêtre avec l'hommage à Jean-Pierre…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Baltringues :D
Posté par devnewton 🍺 (site web personnel) . Évalué à 6. Dernière modification le 07 mars 2022 à 08:20.
Pasolini est mort en 1975, je me demande s'il aurait aussi parlé de phénomène mort et enterré après les succès électoraux de la Ligue du Nord, les élections de Trump, Modi, Duterte, les scores des partis d’extrême droite en France…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 1.
On joue a trouver des proverbes à la con pour se lancer des fions ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 3.
Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.
Juste le classique
-lmalibCompilo différent, même standard. Osef
Upstream d'une distro ? Ça va rien changer à ta chaine de compilation.
T'as des exemples de patch non voulu sur GTK / Qt ? Qui vont impacter négativement ton appli ?
Ah oui, parce que tu peux pas spécifier une version de ta dépendance au niveau du gestionnaire de paquet.
Non, car aucune de ces choses que tu as cité ne font sens.
Tu n'aurais pas pu prendre un pire exemple:
Ah oui, c'est vrai, c'était une discussion sur le static linking, et il a fallu que tu viennes dire des inepties sur le dynamic linking, faisant office de preuve de ton ignorance sur le sujet. Totalement HS.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par groumly . Évalué à 2.
Ok, mais ca aide pas avec les versions majeures. Tout le monde n'a pas forcement envie de se taper des gros changements comme ca. GTK3 n'est pas source compatible avec les version précédentes. GTK4 non plus.
Qt a l'air de se débrouiller un peu mieux sur la compat source. Quelqu'un qui distribue une appli
Je comprends bien la philosophie sous jacente qui pousse a faire des changements qui petent tout.
Devnewton demande pourquoi est ce qu'on pourrait vouloir embarquer un framework en statique, je lui dit pourquoi certains sont intéressés par du tout statique.
J'ai pas d'exemple de patch non voulu sur GTK/Qt que je ne suis pas plus que ca, mais il me semble qu'OpenSSL a trouvé a redire sur un certain patch de Debian.
Iceweasel est né d'une dispute entre Mozilla et Debian au sujet des patches de Debian dans firefox.
Apres, tu me crois, tu me crois pas. C'est toi qui voit. Linus Torvarlds a l'air d'être du meme avis que moi, et tu serais mal venu de lui expliquer qu'il est ignorant a propos des problemes de link statique vs dynamique, les chaines de compilation ou comment les distributions fonctionnent.
https://youtu.be/Pzl1B7nB9Kc
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 9.
C'est pour ça que les distros permettent d'avoir plusieurs versions d'une même lib en parallèle.
libgtk.so.3,libgtk.so.4, …Et Debian fait un travail phénoménal pour backporter les patchs de sécurités.
Sauf que non, c'est pas ça la philosophie d'une distro. La philosophie c'est de fournir un système cohérent ou chaque paquet est bien intégré avec le reste du système.
Sauf que tes arguments à l'encontre du dynamic linking sont erronés. Je ne remets pas en cause les avantages du static linking.
C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance. Ce qui est critique dans le cas spécifique de OpenSSL. Mais pour le reste, osef un peu.
Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla. Debian ayant une philosophie "100% libre", il n'était pas possible d'intégrer ces assets dans les dépôts officiels de Debian. La seule différente donc entre Iceweasel et Firefox, c'est les images.
C'est pas la question. Tu avances des propos incorrects et peint une image erronée de la situation.
Linus Torvalds n'est pas un dieu, il n'a pas la science infuse, ça lui arrive d'avoir tort. Dans l'extrait vidéo que tu cites, il explique qu'il n'y a qu'une distribution Windows, et qu'une distribution Mac OS, mais plein de distributions Linux, ce qui rend le packaging par le développeur compliqué. Il enchaîne en expliquant que Valve a opté pour "embarquer le runtime avec l'application".
Ça veut dire quoi ? Ça veut dire qu'en tant que développeur d'application, je peux fournir un tar.gz qui contient mon binaire et ses libs partagées, extraire ça dans /opt, et basta. Si les mainteneurs d'une distribution veulent intégrer le logiciel au système, c'est à eux de faire le travail de packaging et d'intégration.
De nombreux projets fournissent un .deb/.rpm pour la version la plus récente, mais tu trouvera aussi un .tar.gz contenant la version portable sur toutes les distros.
La solution du .tar.gz avec tes .so dedans, ça réduit les problématiques de déploiement/distribution au même niveau qu'un binaire statique. C'est la solution que Valve a choisit, c'est la solution que Flatpak et Snap ont choisit. C'est la solution que conda (pour Python) a choisi depuis des décénies.
Si je veux m'intégrer au système et distribuer moi même un paquet .deb / .rpm, je le fais en connaissance de cause. Et j'implémente les tests d'intégrations qui vont bien.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par groumly . Évalué à 4.
Potentiellement est utilisé de façon assez créative dans cette phrase. Et ya pas que le process de code review que ce patch a bypassé, après, je dit ça, je dit rien.
Je comprends bien que t’as juste envie me prouver que j’ai tort, mais que ça te plaise ou non, ça illustre parfaitement mon point. Debian à patché un soft (critique ou pas, c’est pas la question) à la truelle en ayant visiblement aucune idée de comment valider que le soft qu’ils livraient faisaient toujours ce qu’il était censé faire.
Ça donne pas forcément envie d’avoir son soft intégré upstream à leur distro, parce que si ça arrive sur un truc aussi gros et central qu’openssl, va savoir ce qu’il se passe sur des paquets moins populaires.
Ben écoutes, c’est pas trop mal documenté.
Mozilla autorise l’utilisation de la marque firefox sous réserve que le source n’est pas modifié de façon non triviale, ou s’ils ont approuvé les patches eux même.
Thunderbird était déjà patché par Debian, et Debian savait très bien qu’ils allaient devoir patcher Firefox pour backporter au moins les patches de sécu. Et visiblement, ils avaient pas prévu de demander à Mozilla leur avis sur les backports.
Ce qui, oh, comme par hasard, me parait plutôt bien correspondre au concept de « patches non voulus ».
https://lwn.net/Articles/118268/, https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian ou encore https://glandium.org/blog/?p=97
Après, comme j’ai dit plus haut, t’es clairement la juste pour me contredire, je suppose que t’as pas supporté que je dise que C est largement cantonné à l’embarqué et bas niveau, donc je vais passer sous silence tes autre remarques qui n’ont pas grand chose à voir avec la choucroute, et je vais me retirer de ce fil, pas grand chose de productif n’en sortira.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 4.
Aucune CVE n'ont été ouvertes pour les patchs de OpenSSL à ce que je sache.
Ce qui impose des conditions sur la distribution du code, ce qui est contraire à l'esprit du libre et la philosophie de Debian.
Sauf que quand tu distribue ton code sous une licence libre, le concept de "patch non voulu" est juste stupide. Et si tu distribue pas ton code sous une licence libre, tu sera jamais intégré dans les dépôts officiels de Debian.
Cela ne t'empêche pas de fournir ton propre dépôt APT, comme ce que fait NodeJS, MongoDB, et bien d'autres.
Pour citer l'article LWN que tu a mis en lien:
C'est bien dit explicitement, si tu veux distribuer un logiciel qui s'appelle "Mozilla Firefox" ou "Mozilla Thunderbird", c'est soumis à conditions. Donc le code n'est pas libre. Donc Debian fork, retire les choses qui sont soumises à la trademark, et boom Iceweasel lui est 100% libre ce qui correspond à la philosophie de Debian.
La réponse est donc là, tu veux pas de "patch non voulu" ? Tu mets pas ton code sous licence libre. AKA: Tu ne donnes pas la liberté de le faire. (Je sens qu'à force de répéter ça, je vais finir par invoquer Zenitram).
J'y peux rien si ça fait 2 threads ou tu rabâche un ramassis de connerie. Mais bon, à la base j'avais même pas fait le rapprochement.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par aiolos . Évalué à 7.
Pour OpenSSL, je ne me souviens plus, mais il me semble que ça a existé. Par contre, pour OpenSSH, c'est certain. Un développeur Debian a patché la génération pseudo-aléatoire servant, entre autre, à la génération de clef car il pensait qu'une ligne ne servait à rien, ce qui a créé un biais dans la génération pseudo-aléatoire. Le résultat c'est qu'il a fallu régénérer toutes les clefs crées sur Debian pendant la période de 5 ans entre l'introduction de la faille et sa découverte… C'est depuis cette histoire que OpenSSH accepte des certificats X.509 (et donc la révocation de clef) en plus de la gestion à la mimine qui était la seule solution à l'époque.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 2.
Ah ok, good to know.
Mais pour le coup, depuis cet incident, ça n'a pas motivé Debian à travailler un peu plus avec upstream sur ce type de composant critique ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par totof2000 . Évalué à 6.
Ben si le code est libre. Sinon Debian n'aurait jamais pu sortir IceWassel. C'était la même chose avec Redhat/centos (et maintenant RockyLinux). Le code est libre, mais la marque ne l'est pas. Et ça ne me choque pas. La Mozilla Foundation n'a peut être pas envie de corriger les bugs qui lui seraient remontés sur une debian, alors que potentiellement ce sont les patch debian en cause.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 2. Dernière modification le 04 mars 2022 à 20:28.
Pardon, j'aurais du dire "le logiciel n'est pas libre". En effet si on considère que "le logiciel" englobe son code et son nom et ses assets.
Vu qu'il y a des conditions sur ce que tu peux distribuer, c'est pas 100% libre.
Pour l'exemple opposé, on a Python ou Debian a continué la branche 2.7 bien plus longtemps que upstream (2.7.18-13 étant la dernière en date). Et ils ont droit de l'appeler Python.
Moi non plus ça ne me choque pas. Ce qui me choque c'est que cela soit utilisé comme argument détracteur de Debian, alors que le principe même de Debian c'est de ne pas accepter un quelconque truc propriétaire (que cela soit un nom, une image, ou un bout de code).
On adhère à cette philosophie, ou on adhère pas, c'est pas le sujet.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par groumly . Évalué à 2.
Va falloir penser a prendre tes pilules, parce que t'es en plein délire la.
J'ai dit qu'avoir son soft intégré upstream dans une distro impliquait que la distro va applique des patches qui ne vont pas forcement plaire a l'auteur, ce qui peut être un problème pour l'auteur.
Si tu lit ca comme un argument detracteur de Debian, faut consulter, parce que ton syndrome de persecution est un peu trop prononcé.
Ca les a pas dérangé d'inclure thunderbird et firefox au debut pourtant. On va peut être arrêter de prendre ses vessies pour des lanternes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Go with C
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Il faut comprendre licence propriétaire et non détenu par une entreprise privée. C'est ce qui a valu l'inclusion de Chrome (enfin en tant que Chromium) et bien d'autres.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Go with C
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 04 mars 2022 à 08:28.
Je ne demande pas pourquoi, je demande si c'est possible :-)
En regardant la doc de Fyne et Gio UI, on voit que sous Linux ils demandent d'installer des libs qui à priori seront dynamiquement liées, non?
Fyne:
sudo apt-get install golang gcc libgl1-mesa-dev xorg-dev
apt install gcc pkg-config libwayland-dev libx11-dev libx11-xcb-dev libxkbcommon-x11-dev libgles2-mesa-dev libegl1-mesa-dev libffi-dev libxcursor-dev libvulkan-dev
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 5.
Ma réponse, ça serait "oui en trichant". Si tu fais un
/opt/monappli, que tu mets les .so dedans et que tu configure proprement le LD_LIBRARY_PATH, comme ce que fait Valve avec les jeux Steam.C'est tout à fait possible d'avoir une appli isolée avec ses propres dépendances. Perdant tout les avantages des shared libs et gagnant tout les avantages des static libs, le tout sans les compiler statiquement pour autant.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par aiolos . Évalué à 3.
Donc, non.
[^] # Re: Go with C
Posté par uso (site web personnel) . Évalué à 4.
sauf que depuis on a eu, Flatpak, appimage, snapy…
Surtout que si faire du Dynamic Static te conviens, c'est pas trop compliquer, suffit de faire ça: https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88. (qui est en soie très similaire a un Appimage)
Vraiment pas sur que Torval est le même avi aujourd'hui.
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . Évalué à 3.
Merci pour le gist, je le mets en favoris !
De toute façon, c'est que l'avis d'une personne de plus. Les arguments fallacieux d'autorité ("mais un tel il a dit que"), je me torche avec :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par barmic 🦦 . É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: Go with C
Posté par David Delassus (site web personnel) . Évalué à 1.
L'argument fallacieux c'est pas Linus qui le commet. Mais bien celui qui le cite.
La DebConf 14 en particulier, d'il y a 8 ans, les choses ont bien évoluées depuis et donc cette vidéo est obsolète. Flatpak, Snap, Appimage, Docker, …
De plus, il est pas en train de dire que le packaging Debian a des problèmes, mais plutôt que du point de vue d'un développeur d'appli (pas un mainteneur de distro), c'est compliqué de faire les choses bien. Ce qui est une grosse différence.
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 ?
Désolé, j'ai pas de respect non plus pour les trolls.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par uso (site web personnel) . Évalué à 0. Dernière modification le 04 mars 2022 à 11:42.
Dalleur, je sais pas t'a eu l’occasion de lancer Steam sous macos récemment,
mais y'a un truck bizarre, la majorité des jeux qui marchais y'a 2 versions de l'OS ne sont plus supporté et ne se lance même plus.
Un truck à propos de 32 "bit", mais moi qui n'y rien en ordinateur, je comprend pas bien le message.
[^] # Re: Go with C
Posté par barmic 🦦 . É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: Go with C
Posté par David Delassus (site web personnel) . Évalué à 5.
Si tu lis mes réponses, tu verras que j'argumente, que j'expose les informations dont je dispose, qui contredisent les "faits" balancé par mon interlocuteur.
Comme je l'ai dit plus haut, le packaging de distribution type APT / RPM ne disparaitra pas, car l'objectif est de fournir un système cohérent et intégré. Ce n'est pas au développeur d'application de faire ce travail, mais au mainteneur de la distribution.
Non car c'est pas leur boulot. Si le développeur d'appli peut filer un .tar.gz avec son appli dedans, c'est suffisant. C'est ce qu'il fait pour Windows, et Mac de toute façon, sauf que ça s'appelle par "tar.gz". Certains iront un peu plus loin et fourniront un .deb/.rpm pour la version la plus récente de la distribution. D'autres iront même jusqu'à fournir un dépôt APT ou RPM.
Mais travailler activement avec l'upstream de la distro pour intégrer le package au reste du système ? Non, définitivement, c'est pas le taf du dev.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par barmic 🦦 . É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 David Delassus (site web personnel) . Évalué à 1.
Bah c'est la ou on est pas d'accord.
Il y a l'OS (linux kernel + GNU userland), il y a la distribution (gestionnaire de paquet, configuration centralisée, firmware/driver commun, …), et enfin il y a les applications de l'utilisateur (navigateur web, client mail, libreoffice, vs code pour les devs, …).
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 :
/apps/*/bindans le PATH qui soit supporté par les shell/apps/*/*.desktopCette solution est à implémenter au niveau de la distribution. Ensuite, il s'agit d'extraire un .tar.gz dans le dossier /apps.
Alors oui, "duplication de shared libs", "bordel à la 'program files' de windows", etc… Mais clairement, l'utilisateur final s'en cotrefiche.
Un installeur dont le job est d'extraire les fichiers de l'appli dans Program Files et d'ajouter le raccourci dans le menu démarrer. Quelle différence avec extraire un .tar.gz ?
Donc une archive extraite quelque part sur le système, avec la solution que j'ai cité ci dessus du
/apps/*/binet/apps/*/*.desktop(sauf que l'archive est pas vraiment "extraite" pour Mac, mais le principe est le même). Et qui a fait ça ? Les mainteneurs de Mac OS, pas les devs de l'appli.Les dépôts communautaires ça existe (les PPA pour Ubuntu, AUR pour Arch, …). Le store de Windows est juste un endroit centralisé ou télécharger/exécuter l'installeur de l'appli. Au lieu d'aller sur le site de l'éditeur.
Mais cet installeur n'a toujours comme seul rôle d'extraire une archive qui contient tout ce dont elle a besoin.
Et ce travail n'est pas a être fait par le développeur de l'application.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par barmic 🦦 . É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: Go with C
Posté par David Delassus (site web personnel) . Évalué à 3.
Tu as dit toi même que c'était l'intégration minimum qu'un dev d'appli attendait : qu'on puisse trouver et exécuter l'application qu'on a installé sur son système.
Alors là, c'est de la mauvaise foi. Depuis le début je fais le rapprochement entre la méthode d'install de Valve, de Windows avec son Program Files, etc…
J'ai même dit dès le début "une archive tar.gz qui contient tout ce dont elle a besoin", à savoir le binaire et ses libs dynamiques, et un script pour configurer proprement le LD_LIBRARY_PATH.
Exemple : https://go.dev/doc/install
Soit : wget + tar xvf + ajout au PATH.
Faire croire que je parle d'une archive de source, c'est tout simplement me faire dire ce que je n'ai pas dit. C'est du troll.
C'est un exemple, stop la mauvaise foi. Regarde Gobolinux et NixOS si tu veux un exemple concret plus industrialisé.
J'ai jamais dit ça. Je dis simplement que les mainteneurs de distro ont tout les outils nécessaire pour permettre à n'importe quel dev d'intégrer son app au système sans en faire un package. Similaire à ce que tu trouve sur Windows et Mac OS.
Merci d'arrêter de déformer mes propos.
Il existe un nombre immense de distribution Linux, c'est vraiment au dev de fournir ça pour tout le monde ? Cela va au delà du format de paquet, il y a le nom des dépendances qui change d'une distro à l'autre. La découpe de ces mêmes paquets (-dev, -doc, -dbg, …). C'est une problématique d'intégration à un système cohérent, une problématique rencontrée par les mainteneurs de la distro.
L'ensemble des paquets disponibles, leur découpe, leur organisation, etc… fait partie de ce que tu appelle "le système de paquet".
Sauf que c'est faux. Regarde le tar.xz de Golang. Tu peux l'installer sur n'importe quelle distro sans aucun problème (tar xf). Tu peux le désinstaller sans problèmes et sans rien oublier (rm -rf). Et tu peux le mettre à jour tout aussi simplement.
Beaucoup de mauvaise foi et de sourde oreille dans les précédents messages…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par barmic 🦦 . É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 David Delassus (site web personnel) . Évalué à 3.
Windows en lui même n'est pas difficile à maintenir. Ce qui a posé problème pendant longtemps, c'était effectivement la mise à jour des applications.
Cependant, avec l'arrivé d'outils tels que chocolatey, winget, et le store, je peux mettre à jour et gérer mes applis super simplement. C'est pas des gestionnaires de paquets à proprement parler, juste un utilitaire pour télécharger et exécuter des installeurs et me filer une commande pour aller chercher une version plus récente.
Quand je
choco install jqje wget le binaire et je le place dans le dossier de bin de chocolatey. Quand jechoco install cmake, je wget l'installer de CMake et ça l'installe dans Program Files. C'est minime, mais ça marche.En tant qu'utilisateur final, je ne vais pas toucher a system32, etc… De la même manière, un utilisateur final sous Linux ne devrait pas aller éditer le /etc ou jouer avec apt/yum.
Il manque pas grand chose je pense.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne sais pas si les choses ont changé sous Fenêtre, mais ton installeur il va juste te présenter une série de fenêtres pour :
Tiens, ça ressemble furieusement à ce que font les Debian-like en plus simple
Mais sérieusement, quand on retire l'enrobage, extraire une archive et lancer un script post-conf après et t'as l'impression qu'ils ont réussi à faire mieux ? Et qu'il n'y a pas de système de packaging ? Et que c'est mieux que dans les années 90 ? Tout en faisant fi des problèmes de dépendance ?
J'ai toujours eu l'impression qu'ils essayent de recréer l'équivalent des dépôts avec leurs store. L'avantage est que les gens ne doivent plus parcourir des centaines de sites pour trouver un truc, et accessoirement ont piqué la becquet des TéléchargerPointCom et compagnie. Par contre zéro gestion de dépendances dans leur système si bien que devait copier le libre.
Petite aventure qui m'est arrivée la fin de semaine dernière. On s'est rendu sur un store pour rechercher un logiciel précis. On l'a installé et il n'y avait que la moitié des fonctionnalités attendue. Je suis allé sur le site de l'éditeur et j'ai eu la surprise de constater que le store avait deux versions de retard. Mais ce n'est pas le plus grave. Une bonne partie des fonctionnalités s'appuie sur un autre logiciel qu'il fallait installer installer aussi (mais sans gestion de dépendances ça se fait pas tout seul…) On recherche l'autre logiciel sur le store, et pour le même nom on a trois trucs qui n'ont rien à voir, mais pas ce qu'on voulait. Heureusement, le site de l'éditeur pointait vers le site officiel de l'autre logiciel dépendant. La personne avec qui on a vécu ces péripéties a conclu qu'elle n'y serait pas arrivée toute seule. Pourtant c'était deux programmes liés statiquement en plus.
Fin de la parenthèse, je retourne à mes occupations et vous laisse expliquer les bienfaits des installeurs pour µ$
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Go with C
Posté par uso (site web personnel) . Évalué à 5.
Steam Deck qui s’appuie sur flathub pour son store te donne raison.
Mais sinon on pourrais parler de RPCS3, Krita et tout plein de packets auquel je pense pas qui sont packagé en Appimage et marche très bien.
Surtout que RPCS3/krita, c'est surement l'enfer en terme de dépendances.
La majeur différence avec 2014, c'est que aujourd'hui seul ceux qui on pas essayer, croie que le packaging reste compliquée soue linux.
wayland/Python3/Rust/IPv6 existe depuis 2008/2010/1995 pourtant ça fait pas depuis si longtemps qu'on en voie vraiment.
[^] # Re: Go with C
Posté par barmic 🦦 . É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 uso (site web personnel) . Évalué à 2.
Sauf que ce que dit torval (vu qu'il me semble que c'est de ça qu'on parle)
c'est "moi ce que je veut, c'est compiler mon programme, et que ça marche, et OSEF de l'intégration à la distro", et il se peint des ABI qui casse.
Et pour ça Appimage marche, glibc est backward compatible, et un Appimage crée sur une distro stable, est généralement portable.
Tu parle d'intégration aux distro, et c'est exactement ce dont torval ne parle pas, et c'est aussi l'une des choses les moins importante pour les dev d'application, le but c'est qu'on puisse DL, et exécuté l’application. (comme le ferais un utilisateur windows avec son exe)
L'intégration distro, c'est aux distro de la faire. (et reste la meilleur manière d'installer une app)
[^] # Re: Go with C
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 04 mars 2022 à 13:55.
Moi j'avais essayé pour Newton Adventure et j'en suis revenu:
Bref on n'y me reprendra plus: je fais maintenant mes jeux sous forme d'appli web html/js/css. C'est lent, c'est pas adapté, mais la distribution d'appli n'est pas un cauchermar.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go with C
Posté par uso (site web personnel) . Évalué à 2.
Effectivement j'ai pas prit en compte l'intégration a la distro du tout, et oui y'a encore du travaille a faire, pour ça je regarderas plutôt du coté Flatpak que Appimage(et encore, y'en a qui essaye).
Et comme tu la dit y'a encore des bizarrerie avec Flatpak, par contre avec steam deck, silverblue qui l'utilise par default, et la majorité des distro qui l'intégre, je trouve que le projet évolue très vite dernièrement.
Par curiosité ça date de quand ton test Flatpak ?
Après pour java il me semble que Minecraft étais pendant packagé en mode "prend le jar et démerde toi", et ça embêtais pas grand monde.
[^] # Re: Go with C
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
2019 : https://linuxfr.org/nodes/118997/comments/1795082
J'avais écrit un journal sur le sujet : https://linuxfr.org/users/devnewton/journaux/write-once-run-anywhere-qu-il-disait
Si je dois à nouveau écrire un jeu "natif", je me tournerais sans doute vers Go pour ne pas me casser la tête avec la cross compilation et la distribution d'appli.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go with C
Posté par Misc (site web personnel) . Évalué à 6.
Je crois que Debian est celle qui a le support le plus court des distros qu'on compte comme "LTS", donc "LTS par excellence", c'est très relatif.
C'est 3 ans pour Buster. Ensuite, c'est 5 ans en LTS (si des gens payent), et 7 ans en ELTS. Mais 3 ans de base, c'est légèrement moins que FreeBSD.
À coté de ça, Ubuntu tape dans les 10 ans, et ça va dans les 13 à 14 ans pour RHEL.
À comparer avec les 10 ans sur Windows Server.
[^] # Re: Go with C
Posté par David Demelier (site web personnel) . Évalué à 9.
Faut vraiment s'abstenir de dire des inepties quand on sait pas de quoi on parle. Le seul moment où ça devient compliqué c'est quand tu veux utiliser une fonctionnalité qui est récente et que tu vises des distributions qui ont des vieux paquets. Pour ma part ça m'arrive jamais et pourtant j'utilise des outils moderne (je demande du CMake 3.20 par exemple, du C11, du C++17, du Qt 6, etc.). Alors à un moment donné tu peux aussi dire « désolé mon application ne supporte pas Debian 7 ». Tout comme tu peux voir des applications stipulant « Windows 10 ou supérieur, macOS Catalina ou supérieur, etc » Mais à ce moment là on jette la pierre au développeur plutôt qu'à la distribution qui fournit une panoplie de paquets sentant le formol.
Pas sûr de comprendre en quoi tu peux en avoir quelque chose à faire que Gtk soit compilé en
-O0ou-O3. Pour Qt et Gtk, les choses sont bien faites, il y a des modules indépendants. Comme QtWayland, QtMultimedia, etc. Ça permet justement de pas faire un Qt monolithique « Oops, mon programme peut pas se compiler car la distribution crux ne compile pas le support de l'audio dans Qt »/.Là c'est la preuve totale que tu ne sais pas de quoi tu parles. Rien ne bizarre se passe du moment que l'ABI est respectée. Hint : il s'agit du petit numéro stocké dans le
SONAMEd'un ELF.git is great because linus did it, mercurial is better because he didn't
[^] # Commentaire inutile
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
J'ai plussé le message pour l'utilisation de l'expression ou quoi ou qu’est-ce trop peu utilisée 🥰
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# corrections…
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Si la modération passe par là, il manque quelques accents…
https://paste.chapril.org/?267f9e915e43422c#7u9kCyPbmZjcHFZYGSxABezEg8iAJAUdAcuRkzWVNMpc
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Fourvoyé
Posté par sebas . Évalué à 3.
Pourquoi, en voyant le titre, ai-je aussitôt pensé
[^] # Re: Fourvoyé
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
T'as lu « pour » au lieu de « en » ?
?
Ou est-ce que tu viens d'essuyer un revers face à
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fourvoyé
Posté par sebas . Évalué à 3.
La question serait plutôt « le go est-il turing-complet ? »
[^] # Re: Fourvoyé
Posté par David Delassus (site web personnel) . Évalué à 4.
Si tu veux un jeu turing complet, je te conseil Magic the gathering.
https://beza1e1.tuxen.de/articles/accidentally_turing_complete.html
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Fourvoyé
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 04 mars 2022 à 07:54.
entre autres, entre autres…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fourvoyé
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
https://www.quora.com/Is-the-game-of-GO-Turing-complete
https://cstheory.stackexchange.com/questions/18885/is-there-a-generalization-of-the-go-game-that-is-known-to-be-turing-complete a trois réponses qui sont un très bon complément.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fourvoyé
Posté par sebas . Évalué à 3.
Ça alors, et moi qui faisais une simple blague (comme quoi on pense que le smiley est superflu, et puis, finalement…), je n'aurais pas imaginé que le thème avait été débattu sérieusement.
Merci pour ces précisions.
# Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
J'ai l'impression qu'il sont parti sur des interfaces "à l'ancienne" avec les call-back back de l'enfer.
Depuis que j'ai développé avec React (mais Vu.js, ELM, angular, sont pareil), c'est difficile de revenir en arrière.
Le principe de ces toolkit est d'avoir des fonctions qui retournent des éléments graphiques selon des entrées (que l'on peut cascader). Des setters sont transmis en profondeur pour modifier l'état global de l'application (ce qui génère un événement pour redessiner la partie concerné automagiquement). C'est beaucoup plus simple à écrire que de savoir quoi modifier selon l'action.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Il y a une couche de databinding avec Fyne: https://developer.fyne.io/binding/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
C'est comme les slot de Qt ? On est loin de redux (https://redux.js.org/) ou de l'architecture d'ELM (https://guide.elm-lang.org/architecture/).
L'idée est vraiment de coder des appels de fonctions avec des entrées, et le framework appel la fonction à la demande, pas en passant par en dessous, avec tous les effets de bord de la terre imaginable.
Redux rajoute un cycle d’événement qui modifie l'état global qui ensuite modifie le rendu complet (le tout optimisé par le framework en dessous).
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 7. Dernière modification le 04 mars 2022 à 22:46.
Les data bindings de Fyne sont plutot insipire du systeme MVVM ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ). L'idee est de connecter les elements de l'interface a un databinding. Celui-ci peut etre "un proxy"/ViewModel est alterer/combiner les valeurs d'un autre data binding.
Un exemple pour en expliquer le principe, c'est d'avoir un data binding StringWebSocket, qui recupere juste une chaine de charactere via WebSocket. Celui ci peut etre connecte a un JSonString data binding. Imaginons qu'on veut recombiner des champs de ce JSON pour en faire une autre chaine de charactere, du coup on utilise un data binding Sprintf qui prend en parametre les fils de ce data binding JSON. Enfin, on peut connecter cette chaine de charactere a un label qui affichera le resultat de toute cette chaine.
Evidement, si tu veux faire du HTTP, MQTT, ou quelques protocoles que ce soit, tu ne changes que le type du data binding en debut de chaine. Il est possible de coder son propre data binding. Un exemple d'une telle chaine de logique: https://github.com/fynelabs/mqttweather/blob/main/weather.go#L72 .
Pour ce qui est de l'optimisation du framework, c'est l'avantage a mon sens principal des framework en mode "retained" (aucune idee de comment traduire) par rapport a ceux "immediate". En mode "retained", tu as en permanence un etat de ce qui a etait envoye a l'ecran (techniquement sous Linux, tu as interet a te souvenir des 2 dernieres frames) et tu ne mets a jour que ce qui a change entre le buffer que le systeme t'a donne et ce que l'application veut afficher a un moment donnee. Cela veut aussi dire qu'il est plus facile de maintenir un cache qui a du sens, car toutes les donnees deja calcule sont attache aux objets present dans l'interface et leur cycle de vie est gere par le framework graphique de maniere transparente. Bien entendu, si on passe dans une bibliotheque avec une logique "immediate", il faut faire tout cela soi meme.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Est-ce que ce genre de lib 2d peut servir de fondation à une structure imitant react ou vue ? en gros, les widgets seraient vue comme le DOM du navigateur web.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Et pendant que l'appli native avec des widgets maintenable par un stagiaire se charge en 0.001s et consomme 30ko de RAM, la SPA React / Redux / Cloud native demande une équipe 42 personnes dev/ops/agile/ux/ui/lifecoach se lance en 8 minutes et demande 2Go de RAM.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
L'appli maintenable par un stagiaire, je n'y crois pas trop. L'avantage est justement de ne pas avoir le bordel de dépendance dans tous les sens. Cela ne se voit que sur des applis un peu grosses et/ou dynamiques.
La lourdeur de react&Co, c'est la techno web derrière, pas le concept de programmation.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par cedric . Évalué à 3.
J'aimerais bien que tu expliques pourquoi tu penses qu'un 2 way data bindings consomme enormement de ressource par rapport a flux? Pour reference, un exemple avec le data binding MQTT de Fyne: https://github.com/fyne-io/fyne-x/blob/master/data/binding/mqttstring.go
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par cedric . Évalué à 3.
Je ne pense pas que tu puisse avec Fyne generer un cycle, car l'ui ne va generer un changement dans le data binding que si celui-ci est le resultat d'une action de l'utilisateur. Donc un changement dans le data binding, va faire une mise a jour de l'ui, mais l'ui ne va pas generer de mise a jour du data binding apres ce changement.
Par contre, effectivement, il y a des possibilites de change after view (si j'en comprend bien ce que tu decris), si il y a une entree utilisateur sur l'ui au meme moment que le data binding decide de faire un changement. Mais dans ce scenario, le data binding propagera tout de meme l'entree utilisateur ce qui laisse la possibilite au data binding de resoudre le conflit. Du coup, dans le cas d'un protocol reseau, on s'attenderait a ce que cela soit gerer dans le backend.
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 4.
J'essaye de reflechir un peu plus au sujet, et je ne suis pas sur qu'il y ait grande difference sur le sujet en fait. Tout d'abord, les locks avec go, c'est obligatoire (Ou une primitive de synchronization). Les developpeurs en go s'attendent a pouvoir appeler une API depuis n'importe quel goroutine a n'importe quel moment. Il faut qu'elle soit thread safe. Tu remarqueras d'ailleur que pour les developpeurs de data binding, ils n'ont en general pas besoin de lock.
Deuxiemement concernant la difference entre databinding et flux. Dans la pratique, le Get est identique au Dispatch, le Set a un Action et les data binding de type simple au Store. Je ne vois aucune difference technique a part le choix des termes.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 cedric . Évalué à 5.
Une des regles principales de l'ecosysteme est de faire des API synchrones avec une gestion des erreurs explicites et laisser la decision de parallelisme a l'appelant. De plus, il est recommender d'eviter autant que possible d'utiliser les channels dans une API, car leur type ne permet pas a la lecture du prototype de savoir comment les utiliser pour synchroniser deux morceaux de code (buffer/unbuffered et blocking function ne sont pas dans le prototype). Du coup, l'utilisation des channels est plutot quelques choses d'interne.
De plus, meme si les channels sont tres optimise en Go, leur cout n'est pas nul. Aussi bien en memoire que CPU. Et comparer a un lock qui quand il n'est pas un point de contention, se comporte comme un atomic, il y a une difference assez importante en terme de performance.
Enfin comme tu peux le voir, il n'y a pas de besoin de synchronisation pour tous les utilisateurs de cette API, seul les developpeurs des data bindings de type simple ont du prendre cela en consideration. Cela rend l'utilisation de l'API simple et efficace avec aucune allocation memoire une fois que le binding est construit.
Pour repondre a tes questions supplementaires concernant la copie profonde, cela n'existe pas dans le language, car cela transformerait une affectation O(1) en une complexite inconnue. Cela veut dire que la copie profonde est a implementer manuellement et explicitement de maniere a bien en voir le cout (et du cout, on evite de faire des copies autant que possible :) ). Il n'y a pas de structure immutable en Go, uniquement des champs publiques ou prives (mais une fois qu'il y a des champs prives, il est impossible de juste copier une structure, il faut fournir une fonction pour pouvoir le faire).
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 cedric . Évalué à 5.
Si on ne parle pas d'API, cela veut dire qu'on parle uniquement de comparer un systeme qui utilise des locks vs un systeme qui utilise une queue. Dans le cas, qui nous concerne, pour l'implementation de fyne, il n'y a pas de data race, pas d'allocation, et les locks ne sont pas sous contention et donc se comporte comme deux appels atomics successif par lecture/ecriture sur le meme CPU. Techniquement, cela veut dire que le premier atomic va, en pire cas, declencher un vidage de cache dans les autre core du CPU pour obtenir la propriete de la memoire pointe par l'acces atomique. Comme il n'y a pas de contention, aucun autre CPU ne declenchera une perte du cache du core et le second acces sera equivalent a un acces memoire directe sans cout particulier. Ce sera cela le cout d'un lock dans ce scenario.
Maintenant, si tu prend une queue ideale, tu peux te retrouver avec une implementation qui a un seul appel a un atomic par ecriture/lecture dans la queue (CAS ou atomic sont equivalent en terme de cout, donc pas tres important). Par contre, tu es oblige d'allouer de la memoire ou de travailler de maniere bloquante. Dans le cas ideal, disons que tu pars du principe qu'il n'y a pas de contention non plus sur les acces a ta queue et que tu peux te permettre d'avoir juste une seule entree, donc pas non plus de probleme d'allocation memoire. Tu te retrouve exactement dans le cas precedent, un atomic pour faire l'ecriture avec une perte de cache dans les autres core. 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.
Au final, un lock vs une queue dans le cas sans contention sont au mieux equivalent au pire au desaventage d'une queue. Maintenant si on n'est plus dans le cas sans contention, mais dans un cas avec contention, ce que je viens de dire n'est plus valable et le profile de performance sera different. Mais dans le cas de Fyne, il n'y a pas de contention du fait de l'API et de son usage.
Pour revenir sur le sujet du deep copie, c'est bien parce que quoi qu'on fasse, c'est une operation couteuse dans tous les languages et qu'il vaut mieux l'eviter autant que possible. De maniere generale, la contrainte, c'est toujours la bande passante memoire, un seul core peut facilement saturer toute ta bande passante memoire et il faut y faire attention. En forcant le developpeur a etre conscient des couts sans cacher les operations, le go renforce cette affirmation. Et reflexion et rtti sont des operations encore plus lente qu'il vaut mieux eviter en generale. Pas uniquement en go, mais dans tous les languages.
Pour ce qui est du proxy, c'est une possibilite. Mais franchement quel est le probleme que tu essaie de resoudre? Le systeme garde deja pour toi une copie des etats graphiques (uniquement ce qui a finit a l'ecran). Pas la peine de garder l'ensemble des widgets et d'en faire une copie si ceux ci ne finissent pas sur l'ecran. La memoire du delta ne sert pas a grand chose pour ca. Je pense qu'il y a un biais dans ta reflexion du a la mechanique utilise par les navigateurs web pour faire leur rendu. Ceux-ci sont bien plus proche des systemes de rendu immediat du fait de la complexite historique de leur tache. Du coup, on a rajoute des framework en JS pour essayer d'aider les navigateurs web a faire leur boulot. Ce n'est pas un probleme pour les toolkits natifs et c'est globalement devenu un standard de faire du "retained" pour la majorite d'entre eux. Il n'y a pas de besoin pour les utilisateurs de se poser se genre de problematique. Les API pour modifier les widgets sont en O(1) et le systeme ne fera un calcul de delta entre frame que lorsqu'une nouvelle frame pourra etre pousse a l'ecran.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par cedric . Évalué à 4. Dernière modification le 06 mars 2022 à 18:56.
J'ai du mal a comprendre la question. Un lock, c'est pour eviter un acces simultane en ecriture/lecture et eviter une race condition. Les contentions, c'est une question de nombre d'acces et de chance eleve d'avoir le lock deja pris quand on accede a la dite valeur. On peut avoir besoin d'un lock parce que on a une donnee qui est lu une fois lorqu'elle change par frame et qui sera ecrite souvent a la vitesse d'une IO. Mais clairement, cela ne causera pas de probleme de contention.
Un pool de thread systeme est cree et matche le nombre de core disponible. Chaque goroutine sera alloue individuellement, aura sa propre stack et sera schedule en fonction des capacites/de la demande sur un thread systeme approprie. Il y a un tres faible controle de la part de l'application sur ou va etre execute une goroutine. Le scheduler essaye de faire de son mieux pour eviter de changer de CPU et enchainer les executions de goroutine pour eviter d'avoir une goroutine bloque sur une autre trop longtemps (L'ecriture dans un channel est souvent le point de logique qui va declencer un changement de goroutine si il y a une goroutine en attente sur le channel en question).
Ca date un peu, mais c'est encore tres vrai un petit tour des limites de go avec pas mal sur le sujet des goroutines : https://tpaschalis.github.io/reaching-the-ceiling-of-single-instance-go/ . Et pour un cas pratique d'optimisation avec go: https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ .
[^] # Re: Trop simple ?
Posté par ff9097 . Évalué à 4.
Il me semble justement que React notamment est declaratif et donc que "tout" est redessiné et ça ne pose pas de soucis
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
C'est l'api qui te fait croire cela et qui simplifie tout.
Par contre, en vrai, il utilise la techno du "shadow DOM", ou il reconstruit un DOM, fait un "diff" et ne met à jour que les parties intéressantes. Je pense aussi qu'il fait une liaison entre l'object graphique généré et ses entrées, si l'entrée bouge, la fonction est relancé.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 ff9097 . Évalué à 3.
Oui bien sûr mais ça rends l'utilisation très simple et on n'a pas à faire de l'impératif
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui, c'est ça qui est génial. Et je trouve dommage de ne pas avoir ce genre de puissance dans un langage compilé.
Je n'ai pas non plus parlé des Hooks que je trouve totalement génial car on remplace des classes et des High Order composant illisible par… des appels de fonctions tout simple !
Vu que tout ça est implémenté en Javascript, cela doit pouvoir se faire en autre chose.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par ff9097 . Évalué à 4.
Le framework Flutter (langage Dart donc compilé) fonctionne de la même façon
[^] # Re: Trop simple ?
Posté par SSHNuke0 . Évalué à 1. Dernière modification le 07 mars 2022 à 17:48.
C'est pas le cas avec le couple QML + Qt C++ ?
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Sauf si cela a fondamentalement changé depuis 10 ans, non pas du tout.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 5.
C'est vrai uniquement dans le cadre de la famille des toolkit graphiques "immediate". Les toolkit graphiques "retained" se souviennent en permanence de ceux qu'ils ont construit pour les frames precedentes. Ils sont alors capable de faire un delta entre le buffer que le systeme leur donne et ce que l'application veut afficher a l'ecran. Cela va plus loin que ceux que les framework web peuvent faire, car on a du recyclage de buffer video (prive a l'application). C'est a dire que lorsque un buffer a ete affiche a l'ecran on peut le reutiliser. Pas la peine d'en effacer le contenu. On peut, donc calculer les zones de l'ecran qui ont change et ne redessiner que ce qui est necessaire. Bien entendu, les framework "retained" vont pouvoir aussi memoriser le contenu des differents trucs couteux a rendre a l'ecran et les stocker dans un cache associer aux objets a afficher. Comme ceux-ci reste en vie aussi longtemps qu'on en a besoin, la gestion des caches est simplifies et optimales. Enfin comme les framework "retained" ont une vision globale de la scene qu'ils ont a rendre, ils peuvent optimiser le "clipping" des objets a peindre/calculer pour limiter la consommation de CPU et bande passante.
Il est bien entendu possible pour une application qui fait du rendu immediat d'implementer tout cela, mais c'est beaucoup de boulot comme tu le fais remarquer qui a mon sens a plus sa place dans le toolkit que dans l'application.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le problème ne situe pas du tout au niveau dont tu parles.
Le problème concerne l'état réel de l'application vs ce que l'on peut afficher.
Avoir un objet "field" en cache ne t'aide en rien. Redessiner est bien plus simple au niveau de l'API, l’intérêt de react ou vue est de détecter les changements au niveau état de l'application, pas au niveau des widgets.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 4.
Quel est l'interet de dupliquer en memoire une information qui ne sera pas utiliser pour realiser le contenu de l'application a l'ecran? Quel est l'interet de calculer le delta de quelques choses qui sera ignore au final?
React et vue existe et on du sens dans le monde du DOM et du web. Car dans cette univers, tu as un document dont il est couteux de faire une modification et la barriere DOM / JS est lente. Le cout de modification d'une entree du DOM en JS n'est pas juste l'assignation d'une valeur et generalement pas en O(1). Dans cette univers, il est necessaire d'eviter de modifier la representation de ce qui doit etre redessiner pour des questions de performance. Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance.
Dans le cas du natif, ce probleme de barriere DOM/JS et de performance de rendu n'est plus. Une API efficace native peut exposer que des operations qui sont relatif au rendu de la fenetre (Il n'est pas necessaire de maintenir l'etat de ce qui n'est pas l'ecran). Les acces a toutes les fonctions qui modifie le rendu peuvent etre en O(1) et negligeable en terme de cout d'utilisation (plusieur millier d'appel par frame, ne doivent declencher que un seul calcul par frame et idealement sans jamais bloquer un seul de ces appel).
Ceux sont des differences fondamentales entre les contraintes web et les contraintes natives.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne vois pas de quoi tu parles.
Oui, c'est la téchnique du shadow DOM. Mais tu veux dire que tu peux recréer complètement tout tes widgets à la volé à chaque modification du modèle applicatif sans perte de performance ? J'ai un gros doute.
Ce n'est même pas la technique de redux, c'est du pure reactjs. Essayes un hello-wold si tu as du mal à comprendre.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 3.
Non, j'expliquais comment fonctionne react et pourquoi il fonctionne comme ca. Tu n'as pas besoin d'avoir un shadow DOM ou equivalent quand tu fais du natif, car tu n'as pas ces barrieres couteuses.
Dans le cadre d'un toolkit natif, tu as deux morceaux, l'API de widget et la logique de rendu de ces widgets a l'ecran. Dans une API de type "immediat", tu vas avoir un evenement de type "paint" a chaque frame qui va te demander de redessiner le contenu de ton widget. La complexite du rendu est donc deporte dans le widget, voir l'application (cela depend de l'API du widget). Dans une API de type "retained", le code du widget modifie des primitives sur le canvas et c'est le canvas qui va alors voir si il y a un changement lors de la prochaine frame. Ca donne plus de possibilite d'optimisation, car le canvas a une vue globale de ce qu'il y a a faire.
Globalement, dans ces deux cas, tu peux faire des optimisations de type shadow DOM, ce qui limitera les appels sur les API des widgets. Dans le cas d'une API de type immediat, cela payera probablement. Par contre dans le cas, d'une API "retained", c'est tres peu probable voir l'inverse, car cela va augmenter la consommation de memoire et donc la consommation de bande passante qui est la principale ressource limitante pour une application native.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'ai très bien compris le concept de retained, ce n'est pas le sujet. Dans une interface, tu n'as pas seulement le champs string qui bouge, tu as possiblement la création/destruction d'un ensemble de widget eux-même.
Si tu fonctionnes par modification de l'existant, cela donne du code touffu et plein de bug. Si tu fais (semblant) de tout recréer à chaque fois, c'est mille fois plus simple.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 4.
Techniquement, tous ces toolkits sont en go. Ca veut dire que tu as un GC et si tu remplace le contenu d'un conteneur par un autre arbre de widget, celui-ci fera exactement la meme chose qu'en react. Maintenant, je ne pense pas que ce soit un bon pattern pour l'usage de ces API, car cela implique de creer/detruire pas mal d'objet.
Meme avec un systeme optimise, cela a un cout qui impact les performances. Dans ton exemple, c'est probablement negliegable voir meme pas mesurable. Mais comme pattern generaliste, cela a clairement un impact sur les performances. La premiere limite d'un systeme aujourd'hui, c'est sa bande passante memoire. Creer/detruire/acceder de la memoire a tout bout de champs pour pas grand chose a un impact sur les performances non negligeable.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button. Je trouve aussi que cela a tendance a mixer code definissant l'interface et logique du programme, cela veut dire que collaborer avec un designer n'est pas forcement trivial. Je pense qu'on peut faire mieux que ca.
[^] # Re: Trop simple ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Non justement. C'est le boulot de React de ne pas le faire.
Oui, cela sera plus efficace, mais 90% du temps, tu veux surtout un code de GUI léger.
"La première sécurité est la liberté"
[^] # Re: Trop simple ?
Posté par cedric . Évalué à 3.
React evite de construire des objets DOM, pas des objets JavaScript. Ceux-ci existent et consomme des ressources. Ils peuvent etre recycle sous certaine condition probablement, mais globalement, ca va passer par des cycles de GC.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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: Trop simple ?
Posté par cedric . Évalué à 4.
Le double buffering, c'est juste sur le contenu du buffer graphique. C'est principalement utilise pour eviter les problemes de synchronisation avec l'ecran. L'idee, c'est que tu peux travailler dans un buffer pendant que le deuxieme buffer est pousse a l'ecran.
Theoriquement on devrait pouvoir se passer completement de ce buffer supplementaire qui impact la latence pour afficher ce qui ce doit au plus pres du moment ou le contenu va arriver a l'ecran. Tu as toujours au moins une latence de 16ms a 60Hz, mais ca peut varier car il n'y a pas de synchronisation explicite dans la chaine de rendu et du cout les applications travaillent souvent avec en fait 3 buffers. Pour une petite introduction sur le sujet: https://github.com/ishitatsuyuki/LatencyFleX . Aucun toolkit a ma connaissance n'en est la pour l'instant.
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. En regardant quel bounding box a visiblement change depuis les 2 ou 3 dernieres frame, tu peux construire un "masque" des zones a redessiner. Mais cela s'applique uniquement a Linux, les autres ecosystemes n'ont pas cette fonctionnalite et ne permettent pas de connaitre l'age d'un buffer. Du cout, peu de toolkit graphique implemente cette optimisation. Cela n'est peut etre plus vrai avec Vulkan, mais je n'en suis pas certain.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 cedric . Évalué à 4.
Cela n'a pas la meme fonction et n'a pas non plus les memes impacts. Tout d'abord, l'objectif d'une telle optimisation base sur le n-buffering est de sauver de la bande passante. Compare au double DOM qui lui tente de sauver des performances lors de la traverse de la barriere JS/DOM (qui est necessaire, car les appels au DOM stop les optimisations de type JIT). Il n'y a pas d'amelioration de bande passante memoire ni de reduction de ce qui va etre rendu a l'ecran. Cela evite juste de faire des appels qui n'auraient du rien coute, mais qui coute dans le monde web. C'est aussi pour ca que l'implementation dans les navigateurs web d'un double DOM n'aurait pas d'impact sur les performances des applications JS.
De plus, les boundings box, c'est des objets tres sympa, ca tiens sur 4 entiers et un booleen. Tu peux les utiliser directement dans le GPU. Et enfin, tu n'as pas besoin de les reallouer entre deux frames, car elles sont tres facilement reutilisable. Tu peux optimiser ta structure memoire pour qu'elle soit bien lineaire et que les cache memoire apprecie. Pour plus de lecture: https://raphlinus.github.io/rust/graphics/gpu/2022/02/24/piet-gpu-clipping.html .
Enfin tu pourras en conclure que un navigateur web, meme si il fait du rendu d'un truc qui utilise react, aura toujours a gagner a implementer des optimisations de type n-bufferring. Et le double DOM serait probablement moins utile si il etait possible de faire des appels DOM directement depuis le code JIT au lieu de repasser en mode interprete.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 Philippe F (site web personnel) . Évalué à 6.
Je suis un peu surpris par ton commentaire. Tu es sûr que tu as fait du Qt récemment ?
Peut-être que j'arrive pas à cerner précisément le problème que tu rencontres mais j'ai jamais eu l'impression d'être noyé par les callback sous Qt. L'aspect slot justement est plus fin qu'un callback puisque tu n'as pas besoin de connaitre précisément l'appelant.
Quant à la propagation des modifications, sur des écrans de fonctionnalité assez simples, évidemment, quelle que soit la méthode, ça reste simple. Sur des écrans assez complexes, je me retrouve souvent à utiliser du modèle/vue, que ce soit celui fourni par Qt pour des widgets types lists, arbres ou tables, ou bien celui fourni indirectement par le flux de circulation des signaux.
Par exemple, pour cacher une entrée dans un menu en haut de la fenêtre + menu du click + bouton de la barre d'outil, j'ai juste à utiliser l'action d'origine actionMachin.setVisible(False).
On est bien dans une logique modèle/vue où le module (le QACtion) propage son changement dans toutes les vues (3 vues ici). Et tu as seulement besoin de toucher au modèle.
Les mises à jour visuelles se font aussi selon une chaîne de réaction qui ressemble à ce que j'ai vu sous React. L'évenement de base est propagé en descendant (par exemple un click) et tu choisis de le gérer au niveau qui t'interesse en mettant à jour les widgets qui te conviennent. Qt fait ensuite l'analyse en remontant pour voir quels parties de l'écran il doit redessiner.
Autant j'ai bien compris l'intérêt de React par rapport à de la programmation web javascript classique à coup de callback qui est vraiment lourd, autant je lui vois aucune supériorité par rapport à de la programmation en Qt. Les principes de fonds sont à peu près les mêmes, avec quelques particularités liées à la technologie d'implémentation.
React ne résout pas tout non plus. J'ai eu à debugger une application un peu complexe récemment, j'ai du m'accrocher pour comprendre la chaîne d'évènements qui mettait à jour ou pas une partie inappropriée de l'interface. Mon inexpérience côté web a certainement joué, mais il m'a pas semblé que j'étais arrivé dans un monde de simplicité et de clarté que tu vantes ici.
[^] # Re: Trop simple ?
Posté par barmic 🦦 . É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 devnewton 🍺 (site web personnel) . Évalué à 7.
Je me demande encore à quel problème que je n'ai jamais eu il est une solution :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Mais ou est l'innovation ???
Posté par fabrices . Évalué à 1.
En regardant le code des exemples et la doc ça donne l'impression qu'ils ont recodé « from scratch » un Qt Widget minimaliste en Go (Hormis l'ajout du data binding en plus verbeux que QML).
Sauf que Qt Widget c'est un concept périmé. C'est mon avis et pas que le mien. Je ne pense pas que les devs de Qt company soit sous l'emprise de champignons hallucinogènes.
De plus je ne trouve pas dans la doc la moindre explication sur l'implémentation du moteur de rendu. Il faut utiliser une Image pour faire de l'OpenGL ?
En lisant la survey, ils manquent des aspects essentiels pour une UI. Je me demande franchement qu'elle ait l'expérience de ces gens en la matière.
Quant au binding Qt. Il n'y a pas eu un commit depuis 2 ans. Et ça n'a aucun sens si le binding n'est pas autogénéré comme PyQt/PySide.
Pour les UI en techno web sur browser, React est à mon avis une des meilleures solutions. Mais Redux me donne des migraines au cerveau. Le seul avantage, c'est quand la puissance du CSS apporte une valeur ajoutée, par exemple si on veut afficher une typographie à la Wikipédia dans une application. cf. Qt Rich Text.
Donc yet another UI…
[^] # Re: Mais ou est l'innovation ???
Posté par David Delassus (site web personnel) . Évalué à 6.
Source ?
Ce n'est pas un argument.
Source ?
Dans la doc de Gio UI, on trouve la ligne suivante :
J'ai pas regardé pour Fyne, mais c'est pas déconnant pour une appli native soit d'utiliser OpenGL (portable) soit un moyen de détecter l'api native comme Gio UI.
Quels aspects essentiels ? Qui es-tu pour juger l'expérience des gens, toi qui ne sait pas ouvrir un Bescherelle.
Ou alors l'ABI a pas changé depuis, hmm?
Encore une fois, ce n'est que ton avis. Il y a Flutter, Angular, VueJS, Knockout, du SSR rendering avec Django/Flask, ou Elixir/Phoenix LiveView, … Il y a le bon vieux site statique, les Web Components, etc… Toute une myriade de solutions pour une myriade de besoins différents, et personne ne peut objectivement dire que l'une est la meilleure.
Ok. Je vois pas ce que ça apporte à l'argumentation.
Tu passes du Coq à l'Ane, et aucun n'est à la bière. La possibilité de personnaliser une interface est quelque chose de très demandé par les designers depuis très longtemps. GTK 3 a introduit le CSS pour ses widgets pour remplacer les GtkStyle de GTK 2, et on a la même chose côté Qt. Ca fait quoi, 15-20 ans ?
Être aussi réducteur sur une technologie, je comprends pas l'intérêt.
Donc yet another commentaire trollesque qui donne son avis sans aucun argument.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Mais ou est l'innovation ???
Posté par Philippe F (site web personnel) . Évalué à 4.
Je reste aussi sur ma faim côté UI. Les applications que j'ai développées en PyQt ces dernières années se basaient sur affichages en arbres, en liste ou en table. Trois widget/contrôles que je n'ai pas retrouvé dans les lib citées plus haut.
Le choix de widget m'a semblé vraiment pauvre. C'est peut être le côté portabilité universel sur un smartphone qui fait qu'on limite les contrôles à des trucs vraiment très basiques.
Mais parfois, on fait du pur desktop. Par exemple, si je prends un screenshot wireshark, j'ai pas l'impression qu'il soit possible de coder facilement une telle interface avec les deux lib go.
Pourtant, on est bien dans le domaine de prédilection du go: du réseau et du système.
[^] # Re: Mais ou est l'innovation ???
Posté par cedric . Évalué à 4.
Je n'ai pas regarde pour Gio, mais pour fyne la liste des widgets et completement documente:
https://pkg.go.dev/fyne.io/fyne/v2/widget#List
https://pkg.go.dev/fyne.io/fyne/v2/widget#Table
https://pkg.go.dev/fyne.io/fyne/v2/widget#Tree
[^] # Re: Mais ou est l'innovation ???
Posté par cedric . Évalué à 5.
Cet phrase n'a que tres peu de sens. Les data binding sont un mecanisme qui permet de connecter un element graphique a une source de donnees. Le QML est quand a lui un user interface markup language destine a decrire le design et les interactions graphiques de l'application, idealement on ne met pas le code de l'application dans le QML. Ce n'est pas le seul et c'est un concept qui a plusieurs decennie maintenant: https://en.wikipedia.org/wiki/User_interface_markup_language .
L'inconvenient des UIML, c'est qu'il reflete l'intersection entre le canvas graphique utilise et le language auxquel il se connecte, avec des fois une contrainte supplementaire quand ils sont utilise pour definir le theme des widgets, de correspondre a la logique interne des dits widgets. Cela veut dire globalement que chaque UIML est unique et que meme l'introduction de CSS a la GTK, reste un CSS a la GTK qui a peu a voir avec le CSS du web vu que chacun utilise un canvas graphique different. Introduire un nouveau language est tres risque et il faut en avoir le besoin. Les UIML sont principalement utilise quand des interfaces tres customise sont developpe, mais une tres large partie des applications n'en utilisent pas.
L'approche de Fyne et Gio pour est de se baser sur Material Design ( https://material.io/ ). Cela veut dire que la capacite de changer le theme est defini par ce que la specification de material design autorise. Evidement, il y a moins de flexibilite et il n'y a pas besoin de developper un UIML pour ces toolkits. En contre partie, une application aura rapidement un look correct meme quand on n'a pas une grosse equipe pour faire le design.
J'avoue ne pas comprendre le sens de cette phrase, mais pour faire simple un framework moderne se doit de faire une abstraction total du driver utilise. C'est une necessite pour la portabilite, mais cela permet aussi de changer completement la logique interne pour s'adapter a de nouvel API graphique.
J'avoue que cette phrase aussi, je n'arrive pas a la comprendre. Le CSS et la typograhie sont des problemes assez orthogonaux. Wikipedia est en plus l'exemple ideal de quand utilise les technos web, car c'est de la pur documentation avec des hyper liens.
[^] # Re: Mais ou est l'innovation ???
Posté par Guillaume Denry (site web personnel) . Évalué à 3. Dernière modification le 06 mars 2022 à 22:57.
J'aimerais bien comprendre
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.