Guillaum a écrit 474 commentaires

Et l'on a le droit de répondre aux questions même si l'on n'est pas Victor ni Antoine ?

Avec vim, mais oui ;)

Globalement je pense que l'informatique décroissante passe par trois choses :

- Attendre que le matériel meurt avant de changer
- Récupérer du vieux (sur ebay ou dans des poubelles)
- Mutualiser le matériel.

J'ai personnellement deux ordinateurs,

- un athlon xp 2000+ avec une GeForce 3. J'ai celui-ci depuis plus de 9 ans, il tourne parfaitement bien. Je peux même jouer à World of warcraft avec (et sûrement a diablo III qui devrait sortir bientôt). Je peux faire de la 3D avec blender.

- J'ai aussi un ibook g3 600 mhz. Avec celui-ci je ne peux pas faire de 3D ni jouer à wow, mais je fais tous le reste (coder, web, gestion de photos, lecture de vidéos, ...).

Actuellement, si j'avais un seul besoin ce serait un tout petit peu plus de puissance de calcul (pour mes rendus avec blender), mais je regle facilement ce souci en utilisant les ressources informatiques inutilisée de la fac/entreprise/... par ssh.

En pratique j’attends donc que tout ce beau monde meurt gentiment (en espérant qu'ils me fassent encore plusieurs années) avant de changer. Ou j’attends d'en trouver des meilleurs en je donnerais à ce moment les anciens à une association ou autre. En fait, aucun de mes ordinateurs n'a été acheté neuf. Les deux proviennent de récupération de vielles machines (de proches, d'entreprises, d'achat sur ebay, ...)

La seule question que je me pose dans tout cela, est-ce-que le fait de récupérer du vieux matériel n'encourage pas certaines personnes à changer celui-ci plus vite ?

Le dernier point, ici je pense que les os libres sont vraiment un très bon point pour l'informatique décroissante. Leur modularité permet de très facilement choisir les briques nécessaires et d’être parfaitement à jour sur certaines et d'ainsi de profiter de la sécurité et des performances associés, mais aussi de conserver certaines briques plus anciennes pour les performances

True

Tu m'as grillé.

J'ajouterais tout de même :

Dans le flan, mettez au choix :

- un peu d'essence de fleur d'oranger (Pourquoi ce mot s'écrit er, c'est pas un verbe... bref, je ne comprendrais jamais rien à la langue française). Attention, trop et vous gâchez la tarte. Généralement celle-ci est vendue en pot avec un tout petit bouchon, mettez moins d'un bouchon. Pour que cela soit bon, il faut que le gout ne soit pas détectable tout de suite. C'est réussi si les invités disent à la deuxième bouché "Il y a un gout que je connais, mais je ne serais pas dire ce que c'est". Si cela sent la fleur d'orangé en sortant du four, vous pouvez la donner au chien ;) (Ou la manger, moi j'adore ;)
- un peu de vanille.

Personnellement, je fais de très gros morceaux de pommes (de l'ordre du quart de pommes si elles sont petites), donc le soucis c'est qu'ils sont rarement cuits avant que le flan ne brule si l'on met le flan au début. Alors je laisse cuir la tarte un bon moment, et quand les pommes commencent à fondre, je met le flan et j'attends que celui-ci cuise.

Pour ajouter un coté "joli" à la tarte, répartir un peu de flan sur les bords de la pâte, cela la fait dorer ;)

Dernière astuce, faites des morceaux de pommes de taille différente (sauf si vous voulez que cela soit beau ;) Hormis l'effet chaos (qui fait très "c'est moi qui l'ai fait"), vous aurez des pommes plus ou moins cuites, et cela change le gout ;)

J'obtient:

Mon code:

cpython (2.6) 98s
pypy (1.4) 13s
psyco (Pas/plus disponible sur ubuntu maverick)

Ton code:

cpython: 69s
pypy: 88s

Au passage, j'utilise le pypy 64 bits...

C'est en effet marrant ;) Autant qu'il y ai une telle différence entre les deux pypy c'es marrants, mais que dans le cas de ton code pypy mette plus de temps que cython alros que dans le cas de monde code c'est l'inverse...

J'ai un peu joué avec ton code. Perso j'obtiens un gain de l'ordre de 6 entre python et pypy1.4 (et en *nettoyant* un peu, j'obtiens un gain de l'ordre de 6 entre ta version et la mienne ;)

http://hg.insecable.net/hgwebdir.cgi/guibou/hg/cheval/file/4(...)

Sur cette solution je suis à 13s alors qu'avant c'était 50s

Il y a encore moyen de bien gagné en faisant une table des jumps possibles, je passe à 9 secondes.

Il y a aussi une autre solution qui doit être encore plus rentable en C, c'est de faire une grille circuit un peu plus grande (de 2 de plus sur chaque bords) et de mettre les valeurs de ces bords à != 0, comme cela tu peux virer tous les tests dans la boucle principale ;)

Gtk et cairo (enfin, toute la pile G) est disponible pour python 3 avec gobject-introspection, et cela d'une façon bien plus propre que ce qui était fait avant pour python2. En bref, le binding python python se génère automatiquement à partir des données d'introspection fournies par les librairies, ainsi tu met à jour cairo et hop, tu a la nouvelle API dans python-cairo automatiquement. (Sans mettre à jour python-cairo qui en fait n'existe plus ;)

Pour OpenGL, je m'en sert tous les jours avec python3, aucun soucis.

Pour Soya, tu sais ce qu'il te reste à faire ? ;)

Sinon, pour le u'' et le print, tu peux faciliter ta transition en utilisant (python2.6), from __future__ import print_function, unicode_literals.

Personnellement, ce qui me pose le plus de problème actuellement avec python3 c'est le manque de packaging correcte de la plupart des distributions. Hormis ce détail, et bien... Python3 c'est bon, mangez en ;)

(Et globalement, pypy c'est pire que python3 d'un point de vu extensions portées, il faut compiler toutes les extensions soit même)

A noter que l'article dis une grosse connerie, ou peut être mal interprété.

Il permettra d’exécuter du code Python adapté (basé sur un sous-ensemble du langage, RPython) plus rapidement qu’avec l’interpréteur officiel (CPython)

En pratique pypy est écrit en RPython, sous ensemble de python, mais pypy exécute n'importe quelle code python (2.5) sans modifications.

De mon coté j'ai testé sur de nombreux algorithmes (recherche de chemin, coupure de graph, ray tracing) et généralement j'ai des perfs bien meilleurs (de l'ordre de 2-3x, plus certaines fois). Je suis tombé sur quelques cas pathologiques (bien plus lent) et quelques minutes après sur le chan IRC de pypy en discutant avec les dev, j'ai eu le droit à une explication du pourquoi c'était lent, et generalement un patch (de pypy) reglait le problème dans les minutes à venir.

Bref, globalement c'est vraiment positif pour les performances sur des algos "crunching numbers". Pour la stabilité en production et l'occupation mémoire, je ne peux pas me prononcer.

Le truc c'est que c'est un sujet HYPER complexe et que les gens qui y sont arrivés sont soit des chercheurs (mais ils n'ont pas publiés de code), soit des boite privées qui se gardent bien de publier.

Un jour, j'achèterais "antidote" qui est, il semblerait, vraiment pas mal.

Je suis curieux de connaitre le nom d'un outil qui fait cela (même si c'est pas intégré). Parce que si cela existe (que cela marche, ...), je peux te dire que ma prochaine motivation sera de l'intégrer partout dans mon environnement !

Rien ne t'empêches en python de livrer le fichier de bytecode. C'est portable entre les plateforme si l'interpréteur reste le même.

Super bonne idée tient !

Oui, cela doit être techniquement possible.

Cependant, j'avoue que je ne voie aucun moyen de ne pas exposer le code python déchiffré après (il est forcement en mémoire à un moment donné).

D'ailleurs j'en viens à me demander comment ils "sécurisent" ce type d'outil, les proprios ;)

Sinon, il faudra penser à désactiver la génération du bytecode .pyc, parce que celui-ci est en "clair".

Qu'entends tu par "de script"

Attend, là tu bouleverses toutes mes convictions.

Le COD c'est découverte, donc c'est avant, donc il faut accorder, or c'est féminin ?

Donc avec ce raisonnement (que j'ai eu en écrivant cet article, et j'étais tout fier de ne pas avoir, pour une fois, oublié d'accorder avec le COD), et bien l'accord est juste non ?

Bon, ok, après réflexion, le COD c'est pas "découverte", mais "m", toutes mes confuses !

N'empêche...

Question de point de vu ;)

En fait c'est mon éditeur qui coupe les phrases et après pour linuxfr j'oublie de remettre le bon formatage.

En fait c'est tordu, parce que si l'on coche la case "ajouter des retours a la ligne", cela prend en compte mes retours a la ligne inutiles, et si l'on ne la coche pas, cela font le bronx.

Bref toutes mes excuses pour cela.

Sinon, simple remarque, mais sur un viewport de plus de 800 px de large, si tu laisse le texte couler normalement, cela ne fait pas des lignes de 400 caractères ? Personnellement mon cerveau décroche sur les lignes de plus de 80 caracteres (je crois que des études prouvent que la longueur moyenne de confort c'est 40em)

Gre, j'ai pas vérifié l'indentation.

Tient, je n'arrive pas a savoir deux choses :

1) il a trouvé la scene de l'horloge ?
2) comment il à refait la bande son ?

En fait, si tu veux vraiment faire du bépo, n'achète pas la skin bépo. En pratique cela va te ralentir l'apprentissage et si tu sais déjà taper au clavier en bépo, cela ne va servir à rien !

Par contre, cela rendra l'utilisation de ton clavier impossible pour les occasionnels qui voudraient taper en azerty ;) Pire encore, si tu perd ton layout bepô pour pleins de raisons possibles, tu va galérer pour retrouver comment remettre la disposition clavier.

Ma pire erreur fut d'acheter le TM avec une skin dvorak (oui, ici le bépo ne passera pas ;)) Si un jour j'en rachète un, je le prendrais avec une skin azerty.

Sinon, heureux utilisateur du TM depuis maintenant presque deux ans, et ma vie à changée, ma femme est revenu, j'ai passé mon permis de conduire, j'ai gagné au loto, les gens me respectent dans la rue et mon chien ne fait plus ses crottes sur le canapé.

Plus sérieusement, le TM c'est bien, je n'ai plus mal aux mains !

135 ?

j'ajoutne que dans le diff j'ai changé le sheebang, mais tu peux (et doit) le remettre sans le 3 ;)

Rendre autojump compatible python 2 et 3 ?

Pour autojump en lui même, c'est trivial ! J'ai un diff de 10 lignes qui le rend compatible python 2.6 et 3.
http://gobpower.free.fr/diff/autojump_python3.diff

Pour avoir la compatibilité python 2.5 et 3 cela sera un peu moins drôle, mais c'est toujours faisable.

Sinon pour l'applet GTK, c'est un peu moins drôle puisque pygtk ne sera jamais porté pour python3 et qu'il faudrait porter le code sur python-gobject.

Ce que je ne comprend pas dans toute cette histoire, c'est si des entités se font des millions (milliards ?) de $, qui sont ceux qui en perdent autant ?

Typiquement, dans ce truc de haute fréquence, si le prix de la ressource passe de X à Y avec X > Y, tu en achètes et tu les revend à ceux qui ne savent pas que le prix à changé. Donc eux ils se font banané, mais pourquoi ils achètent à la base ? Le prix n'a pas encore changé pour eux.

Bref, cela reste une science obscure pour moi.

Bon, cela a fait ma soirée...

Je me demande maintenant si il est simplement sénile ou génial ;)

La traduction du Que donne Québec ;)