GuieA_7 a écrit 704 commentaires

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).

C'est rarement utile, mais ça arrive que la sémantique des arguments change avec leur nombre et ordre. Par exemple la classique fonction range() ne prend pas d'arguments par mot-clé ; ça va pouvoir être formalisé plus proprement dans sa signature avec Python 3.8.

C'est pratique aussi pour les IDE qui extraient un fichier .py représentant l'interface d'un module écrit en C dans lequel les fonctions utilisent uniquement l'ordre des arguments.

de quel(s) support(s) disposes-tu ?

J'allais poser cette question aussi. Ainsi que "Faut que ça soit libre ?" & "Quel budget ?".

Avec reportlab c'est la sanction immédiate, en Go l'erreur est pardonnée.

En l'occurrence c'est plus un biais de confirmation ici.

Bien sûr que Go est plus performant (code natif, typage statique, parallélisme…), mais dans ce cas :

• soit c'est une limite de conception (le PDF est entièrement en RAM) et le code en Go explosera lui aussi, mais plus tard (au sens 'PDF avec plus de pages') ; "l'erreur est pardonnée" n'est vrai que parce que la limite, plus lointaine, te suffit (tant mieux).
• soit c'est une différence de conception (ex: en Python le PDF est entièrement en RAM, en Go il est écrit au fur et à mesure dans un fichier/socket), et dans ce cas comparer les langages est injuste (rien n'empêche—dans l'absolu—de faire la même chose en Python).

D'un autre côté il faut quand même vérifier, à un moment donné, que la contrainte arbitraire 160×205px est respectée  ; si on met une PNG de la taille qu'on veut on a une cartouche avec la capacité qu'on veut.
Après j'imagine qu'il y a sûrement une bonne raison (au moins à la base) pour avoir opté pour cette technique (genre ne faire qu'une seule vérification et pas deux).

Tu t'es déjà fait jeter par terre par des flics pour un splif ?

Plot twist: le flic c'était Zenitram.

Ok merci d'avoir précisé ta pensée et d'avoir regardé pour Gimp.
Pour Blender en revanche je pense que c'est bien embarqué comme tu le décris.

À moins que je n'ai pas compris ce que tu appelles "embarquer", tu es es passé à côté de pleins de logiciels (typiquement écrits en C/C++) et qui embarquent Python. On pensera par exemple à Gimp et à Blender.

aux dépens de la robustesse du langage (ce qui est indéfendable).

Ça n'est pas indéfendable de manière absolue, c'est un compromis tout à fait subjectif (que tu peux tout à fait refuser hein). Par exemple si ça provoque 0.001% (chiffre sorti de mon chapeau pour l'exemple) de bug mineurs en plus mais que ça permet d'améliorer sensiblement la beauté de l'ensemble du code (ne pas avoir à "beautifier" le code d'une bibliothèque externe que tu lis, tu te sens de base à peu près chez toi), on peut tout à fait comprendre que certains acceptent le compromis sans souci.

Après je suis aussi le premier à dire que pour du code hyper critique il vaut mieux éviter le Python (et le C)…

Tu affirmes que l'indentation en Python est une cause monumentale de bugs, mais tu ne nous dis toujours pas comment tu le sais. Si je comprends bien tu ne codes globalement qu'en C toute la journée donc ce n'est pas ton expérience personnelle ; et toujours aucun lien vers des gens qui font du Python et qui parlent de ce (soit-disant) gros problème (alors que des blogs qui se plaignent de l'absence de typage statique ou du GIL ce n'est pas ce qui manque)…

Chose amusante, Jython (implémentation de Python en environnement Java) permet le vrai parallélisme (même si évidemment il y a un "stop the world" lors du travail du GC) ; après comme ce n'est pas compatible avec les modules écrits en C pour l'implémentation la plus utilisée (CPython), je ne pense pas que grand monde s'en serve.

ayant mené à des tétra-chiées de bugs sans doute fort coûteux.

Sans doute… ou pas. S'il y en a des "tétra-chiées" tu ne devrais pas avoir de problème à nous en indiquer quelques uns.

Après cela, on a beau jeu de dire que le C est dangereux…

Parce que des vulnérabilités dans du code C ayant mené à des soucis énormes de sécurité (entre autres) ce n'est pas difficile, il y en a beaucoup. Par exemple les différentes failles dans OpenSSL de ces dernières années (Heartbleed et compagnie) ; évidemment C est très utilisé (et pas au mêmes endroits que Python, donc difficile de comparer), et aucun langage n'empêchera jamais de coder salement etc… donc je ne vais pas tout mettre sur le dos du C. Mais l'existence de "tétra-chiées de bugs fort coûteux" est sans appel.

Reste que dire que C est plus fiable que Python pour une raison de re-formatage du code source c'est assez ridicule. J'écris du python depuis 2004 (et à temps plein de puis 2009) et j'ai du être piégé une poignée de fois par un problème d'indentation foireuse, et j'ai au pire perdu quelques minutes à trouver pourquoi mon code ne marchait pas ; ça n'a jamais donné lieu à un bug qui explose chez un utilisateur. Peut-être parce que je teste mon code, j'évite de le committer directement avoir l'avoir écrit (un buffer-overflow il faut passer à un niveau supérieur niveau test, genre fuzzing, pour les trouver efficacement, c'est très loin d'être trivial). Il y a des tas de vrais problèmes dans python, mais "ohalala j'ai copié-collé 3000 lignes de codes trouvées sur le Web, j'ai pas testé et ça me faire du caca" n'en est pas un.

Hum j'ai souvenir d'une série d'articles dans LinuxMag (il y a plusieurs années) sur l'écriture d'un noyau en Ada (et notamment un passage corsé sur la gestion de la mémoire virtuelle). Tu me mets le doute du coup sur comment ça se passe avec le runtime de Ada ; il y a peut être moyen de le désactiver (comme pour la gestion des exceptions en C++).

Si tu veux étudier le langage assembleur pour un programme C dont tu as les sources, tu peux utiliser la sortie assembleur de ton compilateur plutôt que de désassembler un binaire (option -S de gcc il me semble).

je constate que la taille des instructions (dans la fonction start) vaut parfois 2 octets, puis 3, puis 1, puis plus loin 7… comment le processeur peut savoir que l'instruction vaut parfois des tailles différentes, sachant que la taille de mon bus est de 64 bits soit 8 octets, donc on pourrait penser que toutes les intructions vallent 8 octets ?

Ça dépend de ton processeur ; sur MIPS 32 bits, toutes les instructions font 32bits par exemple (du coup pour stocker certaines constantes dans le code il faut parfois 2 instructions). Sur x86, la taille des instructions varie ; ça rend leur décodage plus complexe, mais en pratique le code binaire est souvent plus compact. De plus, il ne faut pas oublier que les x86 ont toujours gardé la compatibilité binaire ascendante, et donc ton x86 64bits comprend les instructions 8086/286/386/… et on comprend bien que les instructions du 386 ne sont pas en 64bits. L'ensemble des instructions d'un processeur est appelé ISA, et tu dois pouvoir trouver cette spec' pour le processeur qui t'intéresse.

Comment le processeur s'y retrouve-t'il ? Comme d'habitude, il lit l'OpCode en début d'instruction, il sait alors ce qu'est l'instruction, et donc sa taille. Les instructions sont chargées dans le processeur depuis le cache mémoire (qui est bien rempli depuis la RAM avec plusieurs instructions et en utilisant efficacement ton bus de 64bits).

Si tu regarde attentivement, la réponse 2 a habilement tronqué cette partie : Mais c'est un détail.

Je n'ai pas tronqué "habilement" cette partie afin d'en changer le sens ; cette partie ne change absolument pas le sous-entendu de ta phrase.

Exemple:

"Par ailleurs, XXX n'est pas performant, c'est écrit en Python. Mais c'est un détail."

Bon et ben ça sous-entend clairement que le logiciel XXX est lent, et que c'est la faute (au moins en partie) de Python. Le "Mais c'est un détail" s'applique à l'ensemble le la première phrase, et n'enlève pas le sous-entendu de la première phrase.

En gros tes 2 phrases se comprennent (pour plein de gens) telle que:

"Par ailleurs, PGP n'est pas libre car c'est commercial. Mais c'est un détail."

(et donc commercial implique non-libre/propriétaire, ce qui est faux)

Et pas:

"Par ailleurs, PGP n'est pas libre, et en plus, et ceci n'a rien à voir avec le début de la phrase, c'est commercial. Mais c'est un détail."

C'est plus clair ?

Par ailleurs, PGP n'est pas libre, c'est commercial.

Attention à ne pas laisser sous-entendre que libre et commercial sont incompatibles ; le contraire de "libre" c'est "propriétaire".

Vous devriez mettre à jour les captures qui sont ici […]

Vous avez raison ; l'interface a pas mal évolué (notamment avec la 1.7 sortie l'année dernière) et mon collègue qui s'occupe du site est assez débordé.

[…] je suis toujours content quand je vois arriver une de vos dépêches : c'est sympa les logiciels qui mûrissent sur le long terme.

Merci beaucoup ! C'est évidemment une fierté pour nous d'arriver à développer un logiciel libre avec nos petits moyens ; ça fait plaisir de voir que des gens aiment mes dépêches (je sais qu'il est plus facile de prendre la plume quand on est mécontent).