GuieA_7 a écrit 695 commentaires

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 !

Rust notamment où l'accès direct hors du tableau est possible et génère une belle erreur de segmentation à l'ancienne.

Je crois que c'est plutôt un panic() (le programme quitte de lui-même) plutôt qu'une erreur de segmentation (l'OS tue éventuellement le programme plus tard, quand il détecte des accès mémoires foireux).

On doit quand même pouvoir éviter les vérifications de bornes dans un bloc unsafe (et donc avec cette fois-ci des erreurs de segmentation possibles).

Le logiciel libre c'est politique (sinon, on parlerait d'Open Source)

Pour moi tout est politique, donc autant l'Open Source que le logiciel libre sont politique. Mais oui, l'Open Source est bien plus soluble dans la politique la plus répandue actuellement (le code propriétaire, les services fermés etc…) que le libre. Pour caricaturer, l'Open Source est plus conservateur, et le libre plus progressiste.

[je suis le développeur principal de CremeCRM]

Bonsoir,

Il s’avère que Django a une particularité. Il optimise les fichiers statiques (JS, CSS, HTML, images?) avec un outil écrit en java. Il faut java pour faire tourner une application Django avec de bonne performances.

Cette dépendance n'est pas intrinsèque à Django, mais à CremeCRM. Pour info, nous utilisions une app externe 'mediagenerator' bien avant que Django ait sa gestion actuelle des assets, mais comme sont développement a été stoppée (elle n'est plus compatible depuis longtemps avec les versions récentes de Django) j'ai intégré cette app à notre code, j'ai enlevé la plupart des trucs inutiles pour nous, et porté vers les versions récentes de Django puis Python 3.

Il est tout à fait possible de se passer de Java avec la bonne configuration, mais le JS et le CSS ne sont alors plus minifiés.

Et oui les images subissent un traitement: les assets finaux sont renommés et contiennent un hash dans leur nom (le nom change donc si ont modifie l'image), ce qui permet de dire au navigateur de garder les images en cache aussi longtemps que possible.

Quand j'aurai le temps (spoileur: pas une priorité du tout) je regarderai si les minifieurs JS/CSS écrits en Python donnent de bons résultats histoire de pouvoir enlever Java des dépendances de base.

Il s’avère que Django a une deuxième particularité. Il dépend de Pillow, une bibliothèque logicielle de manipulation d’images. Et Pillow doit se compiler sur la machine lors de son installation.

Il s'agit là encore d'une dépendance de Creme, pas de Django. On s'en sert de manière très légère certes, mais si on s'en sert (cherche des from PIL).

J'espère que CremeCRM vous satisfera (même si effectivement on ne conseille pas spécialement SQLite pour autre chose que le développement, voire une utilisation locale mono-utilisateur).

Le module socket de la bibliothèque standard de Python permet l'utilisation bas niveau des sockets réseau de ton OS (c'est globalement la même chose que ce qu'il y a dans la lib standard du C). Ça te permettrait dans l'absolu, et avec beaucoup de temps, d'implémenter tous les protocoles dont tu as besoin. Mais ce n'est probablement pas ce que tu veux.

Si tu veux juste pouvoir télécharger des fichiers en 3 lignes de code, c'est ailleurs qu'il faut regarder (en gros des gens qui ont déjà fait le travail décrit ci-dessus). Pour HTTP, tu as dans les modules standard de python urllib.request, mais la très bonne bibliothèque externe requests lui est nettement supérieure. Si tu veux une seule bibliothèque qui s'occupe de tout un tas de protocoles, peut-être que pycurl te conviendra plus.

Je dirais que ce que tu décris est un didacticiel/tutoriel ; le souci c'est qu'en cherchant ça dans un moteur de recherche tu tombes surtout sur des didacticiels de programmation, et pas des bibliothèques permettant d'en coder (en admettant que ça existe).