Fusil est une bibliothèque qui factorise beaucoup de besoins courants pour écrire un fuzzer :
- générer des données aléatoires
- analyser finement un processus : CPU, mémoire, recherche de motif dans la sortie standard
- analyser des fichiers de logs
- écrire un scénario, ex : créer une fichier, puis lancer un processus, puis attendre la fin du processus
- etc.
L'idée serait de créer un outil pour avoir le minimum de chose à faire pour écrire un fuzzer de langage (un truc plus simple encore que fusil :)
Chaque langage ayant son lot de spécificités, je ne suis pas sûr que tu arrives à mettre grand chose en commun. De toute façon, les auteurs de fuzzer ne veulent pas apprendre à utiliser une bibliothèque, ils préfèrent écrire leur petit outil autonome. Sûrement que Fusil est trop mal documenté :-) Fusil a des fuzzers pour Python, PHP et la fonction printf() : ils ne partagent pas de code pour ce qui est de la génération du code source (Python, PHP, C).
Il existe déjà plusieurs fuzzers qui testent des parties différentes des langages :
- jsfunfuzz (par exemple) pour Javascript (teste la syntaxe et des fonctions)
- fusil-python : teste la bibliothèque standard Python
- pyfuzz : teste la syntaxe Python
- ...
J'ai entendu que Mozilla utilise énormément le fuzzing pour tester Firefox (Javascript entre autres).
Le but est de protéger des attaques de l'homme du milieu (MITM). Cet homme (ou femme hein :-)) peut se faire passer pour LinuxFR en montant un proxy HTTPS pour capturer le traffic en clair. Il a juste besoin d'un certificat autosigné. Si ta banque ou LinuxFR a un certificat bien propre, tu vas avoir un vilain message d'erreur HTTPS s'il y a un proxy HTTPS sur le route (qui change le certificat HTTPS).
Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Oh, j'ai été un peu trop vague : pack() sert à sérialiser des données (encoder en octets). Jusqu'à Python 2.6, l'encodage de nombres non signés (formats B, H, I, L, ...) tolérait les nombres négatifs en les convertissant en nombres non signés (ex: -1 devient 0xFF avec le format B). unpack(pack(...)) n'est donc plus bijectif : on ne récupère pas exactement ce qu'on a rentré (-1 devient 255). L'ancien comportement peut être surprenant et causer problème. Maintenant, il est aussi possible que des programmes reposent sur ce comportement, et vont donc arrêter de fonctionner avec Python 2.7. La code est plutôt simple à adapter pour garder le même comportement (ex: x & 0xFF pour le format B) et sera encore compatible Python < 2.7. Sur ce cas précis, effectivement Python a cassé la compatibilité ascendante.
D'ailleurs, as-tu essayé de lancer ton projet avec Python 2.7 pour voir si Python a cassé la compatibilité ?
Aussi, il me semble que Moonlight, la version Mono de Silverlight embarque les librairies de Microsoft pour le décodage vidéo. C'est avec l'accord de Micosoft, mais oups! ce n'est pas libre.
Mais euh, Moonlight et Mono sont dans le même dépôt source ? Est-il possible d'utiliser Mono sans installer / utiliser Moonlight ?
Même questions pour les autres trucs "borderline" (comme tu dis) comme Windows.Forms.
Je ne vois pas en quoi c'est un soucis pour Mono que des gens l'utilisent pour coder des trucs non libres. Je pense qu'il y a plein de logiciels libres qui tournent sur des VM non libres... et inversement ;-)
(Il parait même que des gens développent des applications Python non libres alors que Python est libre, rooooh !)
Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?
Si tu parles de Python 2 vers Python 3, il y a des outils et beaucoup de documentations pour migrer vers Python 3.
Mais je pense que tu veux dire version 2.n vers 2.n+1. Or je n'ai jamais eu de soucis dans ce sens. Je joue plutôt à essayer de rendre compatible Python 2.n-1 un code écrit pour 2.n, et il y a pas mal d'effort dans ce sens (ex: multiprocessing existe pour Python 2.4 et 2.5). Je lis souvent que Python casse la compatibilité, or j'ai souvent vu du code Python 2.4 tourner avec Python 2.5, 2.6 et 2.7, mais jamais de code qui ne passe pas.
Parfois, Python fait des blagues : genre le module md5 est marqué comme désuet dans Python 2.6 puis finalement n'est pas supprimé dans 2.7. Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Selon moi, l'API Python est trop stable, ça serait sympa de parfois faire table rase pour nettoyer les erreurs du passé. Ça a été fait en profondeur dans Python 3, mais ça serait pratique de pouvoir le faire petit à petit. En pratique, dans Python 2, quand l'API évolue, l'ancienne est conservée. Exemple : le module threading a plein de fonctions et méthodes avec des noms en double (ancienne / nouvelle convention).
Maintenant, comme l'a écrit Antoine : je serai intéressé d'avoir un exemple d'incompatibilité entre des versions N et N+1.
Je suppose qu'il parle de la problématique des brevets logiciels qui portent sur Mono
C'est des questions théorique, ou ça a déjà posé des problèmes pratiques ? Est-ce que les parties qui sont soumises à des brevets font parti intégrante de Mono ou bien c'est des modules optionnels ?
ainsi que des infractions de licence que Mono aurait fait en implémentant certaines APIs non standardisées de .Net (Windows.Forms par exemple)
Pourquoi tu parles au conditionnel ? Ca a été implémenté ou pas ? Ca pose des problèmes de licence ou pas ?
Effectivement, je n'ai pas du tout suivi Mono et j'en suis déjà, donc je pose des questions qui peuvent paraitre idiotes :-)
J'utilise vim. Pour le code C, ^] (avec ctags) est pratique pour aller à la définition d'une fonction. Pour le code Python, j'aimerai bien savoir comment aller au début/à la fin d'une fonction/classe Python, mais je me débrouille autrement (je cherche "def " et "^class "). Pendant une dizaine d'année, j'ai développé sans la complétion. Maintenant j'en abuse, ça évite les fautes de typo à la con.
La JVM, .NET, ce ne sont pas des projets pilotés par la communauté...
Mono est un logiciel libre non ? Mono gère beaucoup de langages et pas que des langages statiques : http://mono-project.com/Languages
Au vu des problèmes qu'il y a eu dessus depuis leur apparition, je suis bien content que la communauté Perl essaye une autre voie.
À quels problèmes tu fais référence ? (je ne suis pas l'actualité des VMs)
LLVM, ce n'est pas si ancien que cela et en plus, il y a Apple derrière...
Tu veux dire que c'est un défaut que LLVM soit récent ? Parrot est plus ancien que LLVM ?
Pour Apple : tant mieux qu'une société paie des développeurs pour améliorer un logiciel libre. Apple utilise LLVM pour compiler les shaders des GPU sous Mac OS X. Bah Xorg fait maintenant pareil avec Gallium. J'en comprends qu'Apple a indirectement contribué à Xorg (ou dumoins à LLVM).
Par ailleurs, c'est quand même à la base fait pour faire de la compilation de langage statique.
Effectivement, la JVM, .NET et LLVM sont plus à l'aise avec des langages statiques. Mais je ne suis pas sûr qu'écrire une nouvelle VM se voulant générique et adapté à tous les langages (surtout les langages dynamique) est un projet réaliste. Il faut y aller petit à petit. Parrot a été lancé depuis longtemps et il semble que l'implémentation de Perl6 (qui est liée à Parrot) ne soit pas encore terminée, et c'est le seul langage majeur supporté. En plus, j'ai entendu que les performances de Perl6 ne sont pas fameuses, le JIT ne Parrot ne semble donc pas très avancé.
Bien sûr que Parrot est une belle idée. Bien sûr que ça serait génial d'avoir une implémentation de Python pour Parrot. Mais qui va l'implémenter ? Est-ce qu'il y a suffisamment de développeurs motivés pour aller jusqu'au bout ? Quel en est l'intérêt comparé aux autres solutions ? Perso j'attends de voir des résultats intéressants avant de m'y plonger. Pour l'instant, le seul truc que j'ai vu est que l' "assembleur" me semble assez proche du langage Perl.
ce serait bien que ça pousse à sortir quelques outils (notamment pour la recherche de paquets)
À ce que j'en ai compris, distutils2 ("packaging") est livré avec un outil pysetup qui permet de lister les paquets installés (entre autres, ça peut faire plein de trucs). Sinon y'a une API simple pour faire la même chose. Si pysetup répond déjà à tous les besoins, je ne suis pas sûr qu'il soit encore nécessaire d'avoir plusieurs outils (incompatibles ?) pour cette tâche. J'espère d'ailleurs que pip va fusionner avec distutils2 (il me semble que c'est bien parti pour).
wxpython par exemple n'est pas installable via distutils/distribute/pip
distutils2 ne résoud pas tous les problèmes. Un projet comme wxPython est autrement plus compliqué à packager qu'un petit projet ayant juste un fichier Python, notamment car il doit être compilé, a sûrement des dépendances non-Python, et le binaire résultant est spécifique à un OS (voir à une version précise de l'OS). Les distributions Linux ont déjà de super outils pour packager tout et n'importe quoi. Sous Mac OS X et Windows, il faut tout faire soit même.
j'ai du mal à comprendre les critiques de Twisted
Perso, c'est la syntaxe des callbacks qui me dégoûte. C'est difficile à écrire et encore plus difficile à déboguer (surtout les errbacks !).
Je pense pareil que pour Python vs Perl : c'est le même langage, mais avec une syntaxe différente, et comme Perl : Ruby privilégie l'implicite (mais un peu moins que Perl) à l'explicite. On m'a d'ailleurs dit que Ruby On Rails repose essentiellement sur des conventions, je n'en sais pas plus :-)
De mon expérience, un projet est vite écrit, mais devra être maintenu plusieurs années, et parfois le(s) développeur(s) initiaux quittent le projet. La priorité pour moi est la maintenance sur le long terme, et la lisibilité de Python est très importante pour moi.
Je trouve dommage que le langage python (ruby...) mise pas plus sur la machine parrot pour la couche basse
Quand tu écris "le langage", tu veux dire les développeurs Python ? Ou bien la fondation Python (PSF) ? La fondation Python a donné un chèque de 10.000$ à PyPy lors du dernier PyCon US (mars 2011). PyPy est déjà compatible à 100% (ou disons 99,999%) avec CPython et plus rapide que CPython sur de réelles application (dans certains cas). Il me semble plus rentable d'investir du temps et de l'argent dans PyPy que dans Parrot.
Il existe des implémentations de Python sur la JVM (Jython) et .NET (IronPython). Mono a également pour objectif d'être la VM de tous les langages. Pourquoi Perl n'investit pas plus de temps de ressources dans Mono plutôt que de recoder (depuis zéro !) sa propre VM ?
Il y a également eu des expérimentations avec LLVM (Unladen Swallow et une des premières implémentations du JIT de PyPy), mais les résultats étaient décevants.
Python a beaucoup de particularités qui font que c'est un langage difficile à optimiser. PyPy semble avoir trouvé une voie qui donne des résultats concrets.
Vu la complexité des algorithmes cryptographiques actuels, on peut considérer qu'il y aura toujours une faille dans la bibliothèque X ou Y.
C'est plutôt dans les protocoles comme TLS ou dans la gestion des certificats que des failles sont trouvées plutôt dans les implémentations des algorithmes de chiffrement.
Ah oui, c'est Pause ou Verr. num. pour lancer Duke Nukem Forever. Wow, les graphismes sont bluffant ! Ça met un peu minable à Linux avec ses pilotes qui font pas du tout à fait de la 3D de qualité. Par contre, le ventilo du CPU bosse à donf (on peut pas tout avoir). Une version complète est prévue ?
Cet OS est vraiment extrêment rapide à booter (c'est le plus rapide que j'ai jamais vu). Par contre, je ne trouve pas comment lancer Duke Nukem Forever ni comment passer en AZERTY.
# dnk
dnk: Computer bough the farm
# ls
ls: Computer bough the farm
# cd /bin
cd: Computer bough the farm
Perso je préférerai largement le changelog sous forme de diffs plutôt qu'avec tout le paragraphe (difficile de voir les changements). diff -u ou wdiff ?
Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc.
Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², ...
Python 2 a deux types pour les nombres entiers : int et long. Avec Python 3, il n'y a plus qu'un seul type : int (qui est en fait le type long de Python 2). Je ne comprends pas ce que tu appelles "type numériqué" : un nombre entier ou flottant ?
Il existe une branche py3k-jit qui vise à intégrer le travail d'Unladen Swallow dans Python 3. Le dernier commit dans cette branche date de 8 mois, et c'était un merge.
Par contre, certaines optimisations faciles à intégrer font déjà parti de Python 3.2, je pense notamment à l'énorme optimisation de pickle citée dans la dépêche.
[^] # Re: script fuzzer ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Rencontre sur les langages de script à l’IRILL le 1er juin 2011. Évalué à 3.
Oui, ce sont des outils dédiés à chaque fois.
Fusil est une bibliothèque qui factorise beaucoup de besoins courants pour écrire un fuzzer :
- générer des données aléatoires
- analyser finement un processus : CPU, mémoire, recherche de motif dans la sortie standard
- analyser des fichiers de logs
- écrire un scénario, ex : créer une fichier, puis lancer un processus, puis attendre la fin du processus
- etc.
L'idée serait de créer un outil pour avoir le minimum de chose à faire pour écrire un fuzzer de langage (un truc plus simple encore que fusil :)
Chaque langage ayant son lot de spécificités, je ne suis pas sûr que tu arrives à mettre grand chose en commun. De toute façon, les auteurs de fuzzer ne veulent pas apprendre à utiliser une bibliothèque, ils préfèrent écrire leur petit outil autonome. Sûrement que Fusil est trop mal documenté :-) Fusil a des fuzzers pour Python, PHP et la fonction printf() : ils ne partagent pas de code pour ce qui est de la génération du code source (Python, PHP, C).
[^] # Re: script fuzzer ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Rencontre sur les langages de script à l’IRILL le 1er juin 2011. Évalué à 3.
Il existe déjà plusieurs fuzzers qui testent des parties différentes des langages :
- jsfunfuzz (par exemple) pour Javascript (teste la syntaxe et des fonctions)
- fusil-python : teste la bibliothèque standard Python
- pyfuzz : teste la syntaxe Python
- ...
J'ai entendu que Mozilla utilise énormément le fuzzing pour tester Firefox (Javascript entre autres).
[^] # Re: C'est bien joli tout ça, mais...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche HTTP Strict Transport Security. Évalué à 3.
Le but est de protéger des attaques de l'homme du milieu (MITM). Cet homme (ou femme hein :-)) peut se faire passer pour LinuxFR en montant un proxy HTTPS pour capturer le traffic en clair. Il a juste besoin d'un certificat autosigné. Si ta banque ou LinuxFR a un certificat bien propre, tu vas avoir un vilain message d'erreur HTTPS s'il y a un proxy HTTPS sur le route (qui change le certificat HTTPS).
[^] # Re: Pas trop de clichés SVP
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 4.
Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Oh, j'ai été un peu trop vague : pack() sert à sérialiser des données (encoder en octets). Jusqu'à Python 2.6, l'encodage de nombres non signés (formats B, H, I, L, ...) tolérait les nombres négatifs en les convertissant en nombres non signés (ex: -1 devient 0xFF avec le format B). unpack(pack(...)) n'est donc plus bijectif : on ne récupère pas exactement ce qu'on a rentré (-1 devient 255). L'ancien comportement peut être surprenant et causer problème. Maintenant, il est aussi possible que des programmes reposent sur ce comportement, et vont donc arrêter de fonctionner avec Python 2.7. La code est plutôt simple à adapter pour garder le même comportement (ex: x & 0xFF pour le format B) et sera encore compatible Python < 2.7. Sur ce cas précis, effectivement Python a cassé la compatibilité ascendante.
D'ailleurs, as-tu essayé de lancer ton projet avec Python 2.7 pour voir si Python a cassé la compatibilité ?
[^] # Re: parrot
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 2.
Aussi, il me semble que Moonlight, la version Mono de Silverlight embarque les librairies de Microsoft pour le décodage vidéo. C'est avec l'accord de Micosoft, mais oups! ce n'est pas libre.
Mais euh, Moonlight et Mono sont dans le même dépôt source ? Est-il possible d'utiliser Mono sans installer / utiliser Moonlight ?
Même questions pour les autres trucs "borderline" (comme tu dis) comme Windows.Forms.
Je ne vois pas en quoi c'est un soucis pour Mono que des gens l'utilisent pour coder des trucs non libres. Je pense qu'il y a plein de logiciels libres qui tournent sur des VM non libres... et inversement ;-)
(Il parait même que des gens développent des applications Python non libres alors que Python est libre, rooooh !)
[^] # Re: Pas trop de clichés SVP
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Les journées Perl 2011. Évalué à 4.
Python (pourquoi mon code plante à chaque mise à jour majeure de Python ?
Si tu parles de Python 2 vers Python 3, il y a des outils et beaucoup de documentations pour migrer vers Python 3.
Mais je pense que tu veux dire version 2.n vers 2.n+1. Or je n'ai jamais eu de soucis dans ce sens. Je joue plutôt à essayer de rendre compatible Python 2.n-1 un code écrit pour 2.n, et il y a pas mal d'effort dans ce sens (ex: multiprocessing existe pour Python 2.4 et 2.5). Je lis souvent que Python casse la compatibilité, or j'ai souvent vu du code Python 2.4 tourner avec Python 2.5, 2.6 et 2.7, mais jamais de code qui ne passe pas.
Parfois, Python fait des blagues : genre le module md5 est marqué comme désuet dans Python 2.6 puis finalement n'est pas supprimé dans 2.7. Le seul changement incompatible que je connaisse est struct.pack() qui lance une struct.error avec Python 2.7, alors qu'avant ça n'affichait qu'un DeprecationWarning. L'avertissement était déjà affiché dans Python 2.5, alors y'avait quand même le temps de préparer la migration.
Selon moi, l'API Python est trop stable, ça serait sympa de parfois faire table rase pour nettoyer les erreurs du passé. Ça a été fait en profondeur dans Python 3, mais ça serait pratique de pouvoir le faire petit à petit. En pratique, dans Python 2, quand l'API évolue, l'ancienne est conservée. Exemple : le module threading a plein de fonctions et méthodes avec des noms en double (ancienne / nouvelle convention).
Maintenant, comme l'a écrit Antoine : je serai intéressé d'avoir un exemple d'incompatibilité entre des versions N et N+1.
[^] # Re: parrot
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 2.
Je suppose qu'il parle de la problématique des brevets logiciels qui portent sur Mono
C'est des questions théorique, ou ça a déjà posé des problèmes pratiques ? Est-ce que les parties qui sont soumises à des brevets font parti intégrante de Mono ou bien c'est des modules optionnels ?
ainsi que des infractions de licence que Mono aurait fait en implémentant certaines APIs non standardisées de .Net (Windows.Forms par exemple)
Pourquoi tu parles au conditionnel ? Ca a été implémenté ou pas ? Ca pose des problèmes de licence ou pas ?
Effectivement, je n'ai pas du tout suivi Mono et j'en suis déjà, donc je pose des questions qui peuvent paraitre idiotes :-)
[^] # Re: Quel éditeur ?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 3.
J'utilise vim. Pour le code C, ^] (avec ctags) est pratique pour aller à la définition d'une fonction. Pour le code Python, j'aimerai bien savoir comment aller au début/à la fin d'une fonction/classe Python, mais je me débrouille autrement (je cherche "def " et "^class "). Pendant une dizaine d'année, j'ai développé sans la complétion. Maintenant j'en abuse, ça évite les fautes de typo à la con.
[^] # Re: parrot
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 2.
La JVM, .NET, ce ne sont pas des projets pilotés par la communauté...
Mono est un logiciel libre non ? Mono gère beaucoup de langages et pas que des langages statiques : http://mono-project.com/Languages
Au vu des problèmes qu'il y a eu dessus depuis leur apparition, je suis bien content que la communauté Perl essaye une autre voie.
À quels problèmes tu fais référence ? (je ne suis pas l'actualité des VMs)
LLVM, ce n'est pas si ancien que cela et en plus, il y a Apple derrière...
Tu veux dire que c'est un défaut que LLVM soit récent ? Parrot est plus ancien que LLVM ?
Pour Apple : tant mieux qu'une société paie des développeurs pour améliorer un logiciel libre. Apple utilise LLVM pour compiler les shaders des GPU sous Mac OS X. Bah Xorg fait maintenant pareil avec Gallium. J'en comprends qu'Apple a indirectement contribué à Xorg (ou dumoins à LLVM).
Par ailleurs, c'est quand même à la base fait pour faire de la compilation de langage statique.
Effectivement, la JVM, .NET et LLVM sont plus à l'aise avec des langages statiques. Mais je ne suis pas sûr qu'écrire une nouvelle VM se voulant générique et adapté à tous les langages (surtout les langages dynamique) est un projet réaliste. Il faut y aller petit à petit. Parrot a été lancé depuis longtemps et il semble que l'implémentation de Perl6 (qui est liée à Parrot) ne soit pas encore terminée, et c'est le seul langage majeur supporté. En plus, j'ai entendu que les performances de Perl6 ne sont pas fameuses, le JIT ne Parrot ne semble donc pas très avancé.
Bien sûr que Parrot est une belle idée. Bien sûr que ça serait génial d'avoir une implémentation de Python pour Parrot. Mais qui va l'implémenter ? Est-ce qu'il y a suffisamment de développeurs motivés pour aller jusqu'au bout ? Quel en est l'intérêt comparé aux autres solutions ? Perso j'attends de voir des résultats intéressants avant de m'y plonger. Pour l'instant, le seul truc que j'ai vu est que l' "assembleur" me semble assez proche du langage Perl.
[^] # Re: Distutils
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 4.
ce serait bien que ça pousse à sortir quelques outils (notamment pour la recherche de paquets)
À ce que j'en ai compris, distutils2 ("packaging") est livré avec un outil pysetup qui permet de lister les paquets installés (entre autres, ça peut faire plein de trucs). Sinon y'a une API simple pour faire la même chose. Si pysetup répond déjà à tous les besoins, je ne suis pas sûr qu'il soit encore nécessaire d'avoir plusieurs outils (incompatibles ?) pour cette tâche. J'espère d'ailleurs que pip va fusionner avec distutils2 (il me semble que c'est bien parti pour).
wxpython par exemple n'est pas installable via distutils/distribute/pip
distutils2 ne résoud pas tous les problèmes. Un projet comme wxPython est autrement plus compliqué à packager qu'un petit projet ayant juste un fichier Python, notamment car il doit être compilé, a sûrement des dépendances non-Python, et le binaire résultant est spécifique à un OS (voir à une version précise de l'OS). Les distributions Linux ont déjà de super outils pour packager tout et n'importe quoi. Sous Mac OS X et Windows, il faut tout faire soit même.
j'ai du mal à comprendre les critiques de Twisted
Perso, c'est la syntaxe des callbacks qui me dégoûte. C'est difficile à écrire et encore plus difficile à déboguer (surtout les errbacks !).
[^] # Re: Python vs Ruby
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 5.
Python vs Ruby
Je pense pareil que pour Python vs Perl : c'est le même langage, mais avec une syntaxe différente, et comme Perl : Ruby privilégie l'implicite (mais un peu moins que Perl) à l'explicite. On m'a d'ailleurs dit que Ruby On Rails repose essentiellement sur des conventions, je n'en sais pas plus :-)
De mon expérience, un projet est vite écrit, mais devra être maintenu plusieurs années, et parfois le(s) développeur(s) initiaux quittent le projet. La priorité pour moi est la maintenance sur le long terme, et la lisibilité de Python est très importante pour moi.
[^] # Re: parrot
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Entretien avec les développeurs Python francophones. Évalué à 5.
Il existe le projet https://bitbucket.org/allison/pynie
Je trouve dommage que le langage python (ruby...) mise pas plus sur la machine parrot pour la couche basse
Quand tu écris "le langage", tu veux dire les développeurs Python ? Ou bien la fondation Python (PSF) ? La fondation Python a donné un chèque de 10.000$ à PyPy lors du dernier PyCon US (mars 2011). PyPy est déjà compatible à 100% (ou disons 99,999%) avec CPython et plus rapide que CPython sur de réelles application (dans certains cas). Il me semble plus rentable d'investir du temps et de l'argent dans PyPy que dans Parrot.
Il existe des implémentations de Python sur la JVM (Jython) et .NET (IronPython). Mono a également pour objectif d'être la VM de tous les langages. Pourquoi Perl n'investit pas plus de temps de ressources dans Mono plutôt que de recoder (depuis zéro !) sa propre VM ?
Il y a également eu des expérimentations avec LLVM (Unladen Swallow et une des premières implémentations du JIT de PyPy), mais les résultats étaient décevants.
Python a beaucoup de particularités qui font que c'est un langage difficile à optimiser. PyPy semble avoir trouvé une voie qui donne des résultats concrets.
[^] # Re: Petite question de néophite
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche GnuTLS ajoute le support de DTLS. Évalué à 8.
Vu la complexité des algorithmes cryptographiques actuels, on peut considérer qu'il y aura toujours une faille dans la bibliothèque X ou Y.
C'est plutôt dans les protocoles comme TLS ou dans la gestion des certificats que des failles sont trouvées plutôt dans les implémentations des algorithmes de chiffrement.
# pan ! pan ! pan !
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche DuckDuckGo. Évalué à 10.
\_o< coin[^] # Re: not /run
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche /run or not /run. Évalué à 4.
Bah si tu te logues en root, "cd<entrée>" suffit ! (3 touches), plus rapide que "/r<tab><entrée>" (4 touches) :-)
[^] # Re: Test
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche hurd 0.401 est sorti !. Évalué à 6.
Ah oui, c'est Pause ou Verr. num. pour lancer Duke Nukem Forever. Wow, les graphismes sont bluffant ! Ça met un peu minable à Linux avec ses pilotes qui font pas du tout à fait de la 3D de qualité. Par contre, le ventilo du CPU bosse à donf (on peut pas tout avoir). Une version complète est prévue ?
# Test
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche hurd 0.401 est sorti !. Évalué à 5.
Cet OS est vraiment extrêment rapide à booter (c'est le plus rapide que j'ai jamais vu). Par contre, je ne trouve pas comment lancer Duke Nukem Forever ni comment passer en AZERTY.
[^] # Re: c'est moi ou bien...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 3.
Il existe un autre langage monolettre méconnu, le "C".
[^] # Re: Le choix de Warmux
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Atelier jeu vidéo Warmux à Lunel. Évalué à 5.
Pourquoi Hedgewars plutôt que Hurd ? Je crois que Hurd a plus besoin de main d'œuvre que Hedgewars !
# ChangeLog sous forme de diffs
Posté par Victor STINNER (site web personnel) . En réponse à l’entrée du suivi Espace rédaction : séparer le changelog du chat ?. Évalué à 5 (+0/-0).
Perso je préférerai largement le changelog sous forme de diffs plutôt qu'avec tout le paragraphe (difficile de voir les changements). diff -u ou wdiff ?
# Régressions graves !
Posté par Victor STINNER (site web personnel) . En réponse à l’entrée du suivi Seconde partie des dépêches en modération. Évalué à 2 (+0/-0).
Tout à fait d'accord, c'est deux régressions graves par rapport à l'ancienne version de linuxfr.org
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.2. Évalué à 2.
Effectivement, Python 2.7 également. Mais ça n'empêche pas d'avoir l'imprécision lié aux conversions entre les bases 2 et 10 à certains moments.
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.2. Évalué à 2.
Certains processeurs IBM savent faire du calcul sur nombre flottant en base 10, comme les Power6 et Power7 : http://speleotrove.com/decimal/
Pour les pauvres, il y a le calcul en logiciel :
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.2. Évalué à 2.
Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc.
Hum ? PHP distingue clairement 1 (type int) et 1.0 (type float).
Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², ...
Python 2 a deux types pour les nombres entiers : int et long. Avec Python 3, il n'y a plus qu'un seul type : int (qui est en fait le type long de Python 2). Je ne comprends pas ce que tu appelles "type numériqué" : un nombre entier ou flottant ?
[^] # Re: Unladen Swallow
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Python 3.2. Évalué à 4.
Il existe une branche py3k-jit qui vise à intégrer le travail d'Unladen Swallow dans Python 3. Le dernier commit dans cette branche date de 8 mois, et c'était un merge.
Il existe aussi la PEP 3146: Merging Unladen Swallow into CPython.
Ça ne semble pas trop avancer...
Par contre, certaines optimisations faciles à intégrer font déjà parti de Python 3.2, je pense notamment à l'énorme optimisation de pickle citée dans la dépêche.