GuieA_7 a écrit 675 commentaires

Ce genre de demake est vraiment très intéressant à voir.
Merci du partage !

Si je comprends bien il y aurait un orateur, et les participants peuvent uniquement l'entendre lors du déroulement de la séance, mais pas le voir ?

Du coup est-ce qu'une solution telle que suivant est acceptable :

1. L'orateur uploade sa présentation sur la plateforme de broadcasting pour sozi, il obtient alors une interface sommaire de pilotage, et un lien unique à donner aux participants (ainsi personne n'a besoin de créer de compte ; mais c'est juste une contrainte de plus qui me paraissait intéressante ici).
2. L'orateur créé un salon Jitsi (par exemple) dans lequel on peut désactiver les caméras et avoir uniquement le son, et partage le lien unique généré en 1 dans le tchat Jitsi.
3. Quand la séance est finie, l'orateur clos la séance sur son interface de broadcasting, le fichier Sozi est alors supprimé (sinon il l'est dans les jours suivants).

Auquel cas la plateforme de broadcasting n'a pas besoin de beaucoup de ressources (le plus gros est fait par Jitsi), c'est typiquement quelque chose qui se ferait à coup de WebSocket (comme indiqué au dessus). Sozi est déjà fait en JS du coup le choix le plus évident serait peut-être NodeJS (mais c'est faisable avec n'importe quel langage). Ça me semble assez petit vu comme ça, mais bon c'est facile à dire quand ce n'est pas vous qui investissez votre temps libre, évidemment.

Le résultat intéressait peut-être Framasoft ; sinon est-ce que vos utilisateurs sont du genre à déployer leur instance ?

Difficile de répondre à ton problème, car il est complexe de manière général, et qu'on ne te connaît pas personnellement ; en revanche le fait de vouloir progresser est une très bonne chose (il n'y a pas pire que les gens qui pensent être bon et ne se remettent pas en question).

• Il faudra (si tu veux être compétent) toute ta vie continuer à étudier (ne serait-ce que des articles de blog sur des problématiques pointues, de nouveaux langages…) mais aussi pratiquer (sinon tu as tendance à te rouiller) ; donc pas de panique c'est une bonne chose de s'y mettre dès maintenant.
• Il est tout à fait normal que les premières solutions qui te viennent à l'esprit soient tordues ; on a tendance à envisager le cas nominal, puis à rustiner pour gérer les cas à la marge. On abouti alors à du code de piètre qualité. Donc premièrement n'hésite pas à attendre avant d'implémenter ta première idée et de réfléchir un peu plus (prendre 1 heure quand tu te lances dans un développement de plusieurs jour ça vaut le coup); deuxièmement ne t'attends pas à ce que ton code soit bon du premier coup, il est normal d'améliorer itérativement un code (tu es ton 1er relecteur en soit).
• Si tu as des collègues compétants qui te font des retours c'est là où tu vas apprendre le plus (car tu vas apprendre de tes erreurs, pas de celles des autres, ce qui est bien plus difficile). Si tes collègues te parlent de concepts que tu ne connais/maîtrises pas, c'est clairement qu'il faut un peu bosser ta théorie (ex: les design patterns, le couplage faible, la complexité algorithmique…).
• Concentre toi sur la qualité pas la quantité ; tu progresseras plus en perfectionnant du code, même si la tâche qu'il effectue te semble relativement simple, qu'en pissant des milliers de lignes. Si tu n'y arrives pas sur des petites choses, tu n'y arriveras pas sur des grosses.
• Avec le temps tu vas réussir à détecter les motifs qui se répètent dans ton code ; pas de problèmes de faire du copier-coller en première intention, mais ensuite ré-usine ton code en essayant de factoriser, de trouver des abstractions suffisamment génériques pour être utiles dans différents cas de figures et qui sont le plus faiblement couplée avec le reste du code. Je te conseillerai le développement piloté par les tests pour un ré-usinage moins stressant, mais aussi car en te forçant à faire du code testable il est souvent bien meilleur (limiter les états globaux par exemple).
• Balade toi dans le code des autres c'est intéressant de voir d'autres approches ; l'apprentissage d'autres langages (de préférence pas dans ta zone de confort) aussi.

J'espère que quelques uns de mes conseils te seront utile !

Le JIT a beaucoup plus d'info que la compilation AOT

Du côté de l'AOT, les techniques de Profile-guided optimization et autre AutoFDO permettent de réduire cet avantage du JIT ; il reste au JIT la possibilité de générer du code natif différent si 2 exécutions ont des profiles très différents.

Mais je serai curieux de savoir si en pratique cet avantage mène souvent à des différences de performances significatives.

(préambule: je ne suis pas un codeur Rust expérimenté, et serai donc bien incapable de tenir un débat trop technique là-dessus—mais l'avis d'un spécialiste m'intéresse aussi)

• Si j'ai bien compris, beaucoup de grosses applications finissent par mettre en place ce genre de design quand le fait d'avoir des pointeurs un peu partout devient ingérable.
• C'est un problème de gestion de ressource complexe par nature. Il n'y a pas de solution miracle j'imagine. Peut-être qu'une application qui consiste à 99% à manipuler un graphe sera moins pénible dans un autre langage, mais qu'une application qui ne fait ça que 10% du temps aura globalement à y gagner (ces 10% sont plus pénible mais les autres 90% bénéficient des vertus de sécurité/performances…). La question sera sûrement plus facile à répondre quand plus d'applications auront été écrites et qu'on aura plus de recul sur les avantages & inconvénients.

Rust ne permet pas de faire des cycles de références […] il n'est donc pas possible d'avoir des fuites de mémoire

Tu te trompes :
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

(première ligne: "Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak").

sauf à utiliser des pointeurs faibles

Comme le dit le lien que j'ai indiqué, les pointeurs faibles servent à casser les cycles ; ils sont donc la (une) solution, pas le problème.

Une façon idiomatique en Rust de gérer les structures de données complexes consiste à utiliser des index plutôt que des pointeurs (les objet étant stockés dans une collection classique). J'ai cru comprendre que Rust fonctionne bien avec les systèmes à entités (ECS) du coup.

Mais oui dans certains cas on va avoir recours à des smart pointers ; un truc cool c'est que le compilateur va nous obliger à utiliser un compteur atomique (ARC) si on partage des objets entre plusieurs threads (on peut donc utiliser un comptage de référence classique plus performant dès que possible, sans peur de ne pas être thread-safe).

Mais via les cycles de référence il est tout à fait possible d'avoir des fuites de mémoires ; et donc un GC optionnel aurait du sens en effet.

Je te conseille de relire l'histoire du langage D (qui continue de bouger un peu).

Tu as quelques pépites sous le coude ? C'est sûrement parce que je m'intéresse beaucoup à Rust (et pas spécialement à D), mais j'ai l'impression que je vais avoir pas mal de briques en Rust dans ma distro Linux d'ici quelques temps (en plus de celles qu'il y a déjà), mais pour D, à part un shoot'em libre que j'avais testé y a quelques années ça n'a pas l'air d'être trop ça.

Alors je le répète, l'utilisation des langages de programmation, ce n'est pas un marché à se partager.

J'aimerai bien que tu développes, parce que pour le coup je ne suis pas entièrement d'accord. Je peux boire plusieurs types de soda, et même plusieurs types de cola, Koka et Paipsi sont quand même concurrents et se partagent un marché. Si on considère les nouveaux projet démarrés, j'imagine qu'on peut envisager l'ensemble des langages, dans lequel on va choisir, comme un marché ; et ce même sans tout percevoir de manière consumériste de manière générale.

Il y a aussi, par exemple, le fait que OpendBSD ait gardé un Big Kernel Lock (là où Linux & FreeBSD s'en sont débarrassé depuis pas mal d'années) afin de garder un code plus simple et sécurisé (mais empêchant d'avoir du parallélisme au niveau noyau).

Merci à Hybird de nous mettre à disposition un très bon CRM.

Je ne cacherai pas que ça fait plaisir de lire ce genre de choses.

J'ai conservé sqlite car il correspond à mon usage peu concurrentiel, moins de dix utilisateurs.

En matière de performances le nombre d'utilisateurs (et surtout le nombre de gens qui sont actifs en même temps, on s'en doute) n'est qu'un paramètre parmi d'autres. Le nombre de fiches en est un autre, et le genre de filtre qu'on va effectuer encore un autre (certains filtres bien poilus peuvent provoquer des jointures qui font exploser la combinatoire, et sont donc plutôt lourds pour le SGBD).

C'est un peu toute la difficulté (et donc l’intérêt évidemment) que d'essayer de répondre à des cas d'usage assez variés.

Mais des retours de performances sur une instance de Creme en production avec de vraies données, et basée sur sqlite, seraient intéressants (justement parce que c'est un cas que nous n'avons pas trop exploré ; c'est cool de voir des gens "s'approprier" le logiciel à leur guise).

Sur ce je retourne à mes vacances !

Oui c'est un truc piégeux de python que la façon dont le contexte est capturé ; on pense que chaque for va créer un nouveaux contexte, mais non, et du coup tes lambda utilisent la dernière valeur pour cat.

Il y a plusieurs façon de s'en sortir. Tu peux instancier ton instance de Button dans une fonction (chaque appel de fonction a bien son propre contexte—que va capturer ta lambda). Sinon il y a une astuce:

Ça c'est ce que tu fais :

functions = []
for i in range(3):
     functions.append(lambda: print(i))

for func in functions: 
   func()

et qui va afficher :
2
2
2

Mais si tu écris "functions.append(lambda x=i: print(x))" (note le paramètre nommé "x"—il pourrait s'appeler "i" aussi) alors ça écrira bien:
0
1
2

Y a-t-il des trucs pour "traduire" une interface tkinter en GTK ou Qt?

Je doute, c'est vraiment des façons de faire différentes (conseil: bien séparer la logique purement métier de l'interface graphique, pour n'avoir à réécrire "que" l'interface en cas de changement, ou pour gérer plusieurs toolkits).

Sur Debian et Ubuntu (désolé je ne suis pas sous Mint, mais c'est un dérivé) tkinter n'est pas installé de base (même si ça fait partie de la bibliothèque standard Python), j'imagine pour avoir Python sur des installations sans interface graphique propres. Mint l'installe vraiment de base (ça m'étonne car il ne doit pas y avoir beaucoup de logiciels l'utilisant, contrairement aux bindings GTK et Qt) ?

J'ai testé et j'ai effectivement du installer via Synaptic sur ma 18.04 le paquet "python3-tk" qui n'avait jamais été installé depuis 2 ans, afin que import tkinter fonctionne.

ce langage a eu une hype immédiate

Je ne sais pas ce que tu appelle "immédiate", mais j'avais écrit un journal sur la version 0.7 en 2013 ; le langage était en développement depuis des années, et a encore mis des années à atteindre la 1.0. Justement parce que ses créateurs se sont concentrés à faire un bon langage, pas juste un langage jetable mais avec plein de trucs dans la bibliothèque standard (donc pas dans l'optique "vite vite utilisez notre langage pour faire votre web app"). Il a mis longtemps à être utilisé en production par des grosses entreprises ; je ne vois pas ce côté "hype immédiate" dont tu parles (qu'à pu avoir nodeJS par exemple).

sans même avoir à le prouver, sans applications

Servo, moteur de rendu HTML moderne (multi-thread, GPU etc…) écrit en Rust a justement été développé en parallèle, les problèmes trouvés servant de retour pour améliorer le langage. C'est une application grosse et complexe, qui prouve sûrement bien plus que le langage est utilisable/efficace que développer 300 bots IRC triviaux. Je ne pense pas que beaucoup de langages aient depuis le début un aussi belle preuve en fait—je pense au C avec Unix, mais il doit quand même y en avoir d'autres.

Impressionnant pour le travail de quasiment une seule personne. Il faudra que je teste ça.

Je crois qu'il faut un peu démystifié cette image de complexité du Rust.

Du coup tu n'a pas démystifié sa complexité ; tu as expliqué qu'elle se justifiait à moyen et long termes. Ce avec quoi je suis tout à fait d'accord (c'était l'essence même de mon commentaire précédant).

Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable

J'avoue que quand j'ai commencé à m'intéresser à Rust il y a pas mal d'années, le fait que Mozilla ait abandonné pas mal de technos me faisait assez peur. J'ai l'impression qu'aujourd'hui le projet est nettement plus porté pas la communauté, ce qui est une bonne chose.

J'imagine que pour des programmes relativement petits comme ceux présentés, même si Rust va rendre l'écriture plus difficile, cela reste de bons terrains de jeux pour essayer d'écrire une implémentation (quasi) optimale (un peu comme on s'amuserait à coder la partie critique d'un code en ASM).

C'est cocasse de dire aux gens de ne pas prendre la mouche, tout en la prenant toi-même. Si tu sors tes idées cash, ne te plaints pas qu'on te réponde cash.

Je serai ravi de lire un journal où tu viens présenter un de tes projets libres en Rust. En revanche lire tes commentaires anti-Python (alors que ça fait longtemps que tu en as fait le tour) me parait nettement moins réjouissant.

Le seul truc écœurant ici c'est ton commentaire. Venir cracher à la gueule de quelqu'un alors que tu n'as ni pris pris 5 minutes pour comprendre à quoi ça pourrait servir (tu n'as jamais entendu parlé de Blender j'imagine), ni pensé que commencer par poser la question serait intelligent…

Ah mais je suis entièrement d'accord.

Personnellement je ne vais pas dire aux gens que leur projet me semble inutile car il y en déjà plein d'autres qui ont l'air de faire la même chose ; je passe juste mon chemin. C'est mon approche, mais peut-être qu'au final elle n'est pas si bienveillante que ça, je ne sais pas (l'enfer est pavé de bonnes intentions, toussa). Peut-être qu'aller interroger les créateurs sur l'utilité de leur projet serait mieux ; ils pourraient alors expliquer ce qu'il apporte selon eux, ou bien expliquer qu'il est fait juste à titre éducatif, etc… Je n'ai pas la réponse.

Moi aussi, j'adore faire mon propre pain. Sans pour autant prétendre rivaliser avec mon (excellent) boulanger de quartier ;)

Si tu te lançais dans la 5ème boulangerie de ta rue, j'imagine que des gens viendraient te demander pourquoi tu fais ça ; d'autres t'ignoreraient. Quelle est la meilleure approche, je ne sais pas.

Ou dis autrement pourquoi est-ce que le fait que ça ne soit pas utile à une ou plusieurs personnes ici devrait remettre en cause ce projet/code/partage ?

Je n'ai personnellement rien remis en cause (cf la 2ème partie de mon commentaire).

Ah, et sur quel critère on se base pour dire que c'est utile ou pas ?

Je ne sais pas ; d'ailleurs je n'ai rien dit de l'utilité de quoi que ce soit, j'ai parlé de "penser". La seconde partie de mon message étant assez claire sur le fait que, bien souvent, garder son avis pour soi est une bonne chose…

Imaginez le monde avec 1 seul fromage, 1 seul vin, 1 seule biere, 1 seule recette de cuisine […]

Ça c'est parce que tu fais un procès d'intention. Tu peux penser qu'une 2ème distribution Linux c'est utile, mais qu'une 2563254ème ne l'est peut être pas autant.

Après j'évite d'aller dire aux gens comment ils auraient du utiliser leur temps libre, mais c'est un autre problème.

… sur le fait que tu doives utiliser un if sur un range (qu'on utilise 99% du temps avec un for).

Avec quelques print dans ton code tu pourrais voir ce qui se passe et trouver tes bugs seul (ce qui est 90% du travail d'un codeur haha).

Bonne chance !