Victor STINNER a écrit 1632 commentaires

http://www.eyrolles.com/Accueil/Livre/9782212116779/livre-pr(...)
écrit par Tarek Ziadé qu'on peut croiser sur IRC (#python-fr sur Freenode) :-)

Le livre est très complet et bien écrit. Il s'adresse aux débutants et programmeurs confirmés... un peu à tout le monde, mais personnellement je l'ai lu en diagonale, elles servent surtout aux gens qui débutent.

J'ai quand même appris beaucoup de chose sur la programmation agile, les tests unitaires, les modèles de conception (design pattern) appliqués en Python, etc.

Bref, un bouquin a avoir sur son étagère.
--
Truc bête : si ce journal se complète, ça serait bien d'en faire une actualité LinuxFR... Pour rappel, on peut justement gagner des livres grâce à ça ! Je me régale encore du « Fontes et codes » (O'Reilly) qu'on m'a offert ;-) C'est une bible pour tous les gens qui s'intéressent de près ou de loin au stockage et au rendu du texte sur un ordinateur (Windows, Mac et Linux).

Haypo

Excellent livre... mais il faut s'attacher pour le lire, c'est plutôt du haut vol :-) Enfin, il ne faut pas confondre roman et livre de programmation non plus ;-) (je vous conseillerai la trilogie des fourmis sinon, mais je m'égare)

Haypo

http://www.openclipart.org/ a ce genre de gallerie. Demande leur leur code.

Haypo

Ce qui est intéressant, c'est la vitesse de réaction, pas le bug. Un bug, ça peut arriver n'importe quand et surtout quand on s'y attend pas.
https://launchpad.net/distros/ubuntu/+source/xorg-server/+bu(...)

Bug rapporté le "2006-08-21 21:37:15 UTC"

* 1ere réaction de Rodrigo à "2006-08-22 07:39:26 UTC" (I'm working on an update to xorg-server as we speak.)

* 2e réaction de Rodrigo à "2006-08-22 09:08:58 UTC" (Unfortunately I am not able to reproduce this locally)

* À "2006-08-22 09:24:04 UTC", João Pinto teste les patchs indépendement et détecte le patch mis en cause (patch "005") (trouve l'origine exacte du bug)

* Rodrigo poste alors une nouvelle version à "2006-08-22 09:36:42 UTC".

* À "2006-08-22 09:37:21 UTC" le bogue est fermé étant donné qu'une nouvelle version est dispo sur le serveur central (et bientôt dans le "monde entier" le temps que les miroirs répliquent le paquet)

21h => 9h, ça fait euh ... 12h pour corriger le bug. C'est raisonnable non ? Et puis, ce bug semblait assez particulier car il ne touchait pas tout le monde (c'est une histoire de truc PCI).

Haypo, qui a attendu 20h (heure Française) pour faire la mise à jour vers le paquet 1.0.2-0ubuntu10-4

Après de très nombreux tests dans des configurations différentes (avant/sans setuptools, avec/sans urwid) et un patch sur setup.py, j'ai réussi à installer Hachoir sans mon $HOME : sans être root (IT va être heureux) et sans extension Python (sans setuptools).

Comme julien n'était pas trop chaud pour sortir 3 versions en 2 jours, voici une version "0.5.2-batarde" :
http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2-batarde.t(...)

Et l'½uf batard :
http://www.haypocalc.com/tmp/hachoir/hachoir-0.5.2_batarde-p(...)

$ md5sum *
d30c4cbce43cd75c5150ccf7e38b6aaf hachoir-0.5.2_batarde-py2.4.egg
77af3c33c67417102c5a22c35a882549 hachoir-0.5.2-batarde.tar.gz

Le principal changement est un tout nouveau setup.py qui fonctionne sans setuptools (et qui peut être lancé de n'importe où : mais attention, il crée des dossiers dist et build).

Haypo

Nouvelle réponse après respiré bien profondément.

J'ai rédigé une documentation qui explique comment installer Hachoir. Il y a 5 manières différentes : easy_install, quick_install.sh, tarball, Gentoo & Arch ... bon disons 3 manières différente si on exclut les paquets.
http://hachoir.org/wiki/Install

Aucune des 3 méthodes ne demande les droits root. Par contre, mieux vaut avoir le bon module (setuptools).

Hum, il y a encore une méthode qui n'est pas détaillée... (je le ferai plus tard) et c'est pourtant celle que j'utilise quotidiennement. Enfin, ce n'est pas une « installation », mais une bidouille pour éviter l'installation.

=> Modifier PYTHONPATH, il faut le faire pointer sur le dossier hachoir (celui qui contient le sous-dossier hachoir, et non pas le sous-dossier directement). Genre : « export PYTHONPATH=$HOME/hachoir ».
--
Au sujet des centres informatiques pas très ouverts, genre « on utilise des versions stables et point barre », je dirai que sous Unix/BSD on peut se *débrouiller* tant qu'on a de l'espace disque. Il faut jouer avec LD_LIBRARY_PATH, les "--prefix" & ci. C'est très contraignant, mais ça dépanne. Pendant longtemps j'ai du utiliser des "dpkg -x ~/pouet/ paquet.deb" avec des paquets venus de (Debian) backports.org pour pouvoir utiliser autre chose que le strict minimum installé de base.

L'idéal étant d'arriver à faire comprendre le besoin de tel bibliothèque ou tel programme pour éviter quelques dpkg -x quotidient :-)

Haypo

http://aur.archlinux.org/packages.php?do_Details=1&ID=64(...)

GnunuX a préparé un paquet Arch. Si arno et GnunuX ne sont pas la même personne, ça serait bien que vous travailliez ensemble :-)

Des paquets Arch et Gentoo : vous nous gattez :-) Merci. J'attend les paquets Debian et Ubuntu avec impatience.

Haypo

Pour corriger ce bug et le bug du parseur FAT, voici la version 0.5.1 :
http://cheeseshop.python.org/pypi/hachoir

Haypo

Raaah, ça m'énerve de lire ça.

Il te faut absolument un .tar.gz avec autotools!

Il n'y a pas pire invention que autotools pour torturer les développeurs. Aussi bien les fichiers ".ac" et ".am" que le résultat (script configure et Makefile) sont imbitables ! De la grosse saloperie.

Heureusement, en Python on n'a pas cette chose HORRIBLE : chaque programme/bibliothèque (bien foutue) a son script "setup.py" qui fait en quelques lignes tout ce qu'on peut attendre d'un script ayant ce nom, et bien plus encore (ex: générer un installateur Windows, si le bon paquet est installé).

svn n'est pas aussi courant que cvs (trop jeune pour IT ...)

Je sais pas qui est IT, mais euh c'est pas pour dire mais cvs est VRAIMENT vieux et dépassé. La majorité des projets majeurs utilisent SubVersion. D'ailleurs, svn n'est absolument pas nécessaire pour installer Hachoir : un .tar.gz existe (cherche un peu ...) et un .egg existe.

j'aime pas les "rm -rf $hachoir" dans ton script ...

C'est pour ça que je cherche des packageurs. Et d'ailleurs, tu as ma copié/collé la commande.

* Debian/Ubuntu: apt-get install python2.4-setuptools
* Other distrib: download ez_setup.py and execute it as root (another copy if needed: ez_setup.py)

setup.py peut installer Hachoir dans $HOME/<où tu veux>

it needs svn and wget (and python2.4) programs

Ceci concerne le 2e mode d'installation (quick_install.sh).

On peut installer Hachoir :
* à partir du .tar.gz avec setup.py (pas besoin d'être root)
* à partir du .egg (pas besoin d'être root, mais il faut easy_install)
* avec quick_install.sh (il faut svn, càd ne pas vivre en 1990)

IT n'est pas geek ...

Hum ?

"#!/usr/bin/env python2.4" n'est pas "portable", configure doit insérer la bonne commande.

Cela fonction sur UNIX et *BSD. Au pire il faut taper "python2.4 script" (hou là là, c'est dur !).

"from hachoir.error", idem, tu dois insérer le chemin, export PYTHONPATH= c'est pas automatique.

Non, Hachoir doit être installé pour être utilisé... ou alors les gens qui ne veulent pas l'installer peuvent modifier eux-même leur PYTHONPATH.

Si tu veux je peux t'envoyer un exemple avec essentiellement du Perl,

QUOI ?
--
La prochaine fois, renseigne _un peu mieux_ avant de critiquer stp. Par contre, les contributions nous font toujours plaisir.

Haypo

J'ai ajouté cette assertion 48h avant la sortie de la version 0.5... et je pensais aux archi' 64 bits en l'écrivant :-) C'était une sortie de "TODO" :-) Cela confirme mon doute : un "long" n'a pas forcément 32 bits avec l'outil struct de Python.

Si "make test" passe, alors tu peux dire que tout marche :-) La documentation est testée, quelques tests unitaires, un jeu de fichier de tests et le packaging (setuptools).

Haypo

Un ami m'a fait remarqué, à juste titre, qu'on parle peu des applications pratiques. Et bien, Hachoir peut déjà replacer la commande file (file --mime <=> hachoir-metadata --mime) et est une très bonne alternative au programme extract (extract <=> hachoir-metadata) : hachoir arrive souvent à extraire plus d'informations.

hachoir-grep est assez proche du programme strings sauf qu'il ne donne aucun "faux positif" et extrait les chaînes dans différents charsets (UTF-16LE, UTF-16BE, UTF-8, latin-1, etc.), là où strings a besoin de plusieurs appels. Mais la qualité de hachoir-grep dépend de la qualité des parseurs, et certains sont encore incomplets (il n'y a pas de faux-positif, mais on zappe beaucoup de chaînes si ça se trouve).

hachoir-urwid permet de vérifier ce que contient un fichier. On y découvre des fois des surprises. J'ai appris par exemple d'une image JPEG embarque une miniature (et des fois, la miniature n'est pas mise à jour, on découvre des choses......), qu'une vidéo Matroska peut contenir d'autres fichiers (ex: fichier texte, image, etc.), qu'un document Word est basé sur un système de fichier proche de FAT, qu'un document Word contient des secteurs (512 ou 64 octets) inutilisés (là où on trouve des paragraphes soit-disant supprimés...), etc. J'ai aussi que dans une vidéo : le titre du film, un lien vers le site d'où provient la vidéo, une partie des acteurs, etc. La majorité des fichiers AVI contiennent le nom du logiciel utilisé pour générer la vidéo : et quel logiciel affiche ces informations ? Perso, je n'en connais aucun (même pas extract :-)).
--
Autre idée : écrire un programme qui va valider un fichier à la manière d'une DTD ou XML Schema pour un document XML. Un tel programme mis en amont d'un serveur (web) éviterait certaines attaques (cf. faille JPEG, faille gzip, etc.).

Une fois que Hachoir permettra l'édition d'un document. Les possibilités seront encore augmentées.

Ex: éditer/ajouter des commentaires à n'importe quel document.

Ex: pouvoir supprimer tous les "mouchards" d'un document (auteur, date de création, logiciel utilisé pour la création, coordonnées GPS (si si, ça existe dans Exif), etc.).

Ex: pouvoir injecter un document dans un autre document ("stéganographie du pauvre").

Ex: supprimer une partie inutile d'un fichier pour réduire sa taille (ex: commentaires du logiciel de création, commentaires inutiles, "padding" inutile, etc.).

Ceux ne sont que quelques idées. Avec un peu d'imagination, on peut en trouver d'autres. Après "yapluka".

Haypo

Tiens, ça me fait plaisir de voir que mon logiciel est cité sur le forum :-) Par contre, je crains que le parseur actuel du format bzip2 dans Hachoir soit insuffisant. Justement, il faudrait que je le complète un jour ou l'autre, enfin moi ou quelqu'un d'autre. Avis aux amateurs.

Je me suis aussi posé la question : est-ce que le format bzip2 indique ou non la taille décompressée ? Apparement oui, il faut voir dans les 95% des non-reconnues par Hachoir :-)

Haypo

Aaaaaaaah, les joies des pilotes propriétaires. OpenBSD a eu des soucis avec le RAID pour ces raisons (manque de documentation, pilotes tous pourris, etc.).

« OpenBSD: RAID Management in 3.8 » :
http://kerneltrap.org/node/5649

« 3.8: "Hackers of the Lost RAID" », la chanson :-) :
http://openbsd.org/lyrics.html#38

Haypo

Tiens, ça me fait penser au film Final Cut (dont je n'ai vu qu'une partie).
http://www.imdb.com/title/tt0364343/

Il est terrible cte film. Une société propose d'implémenter une puce dans le tête qui enregistre tout ce que les yeux voyent. Après le décès, Robin Williams le poète disparu... ah non, je confond là... bref Alan va composer le film de la vie de cette personne.

Le lien avec Neven Vision est qu'on voit un programme qui est capable de rechercher un visage dans le milliard d'heure de vidéos enregistrées.

--

Bon, sinon il existe des trucs sympas (et flippant) en vidéo : inpainting (supprimer un objet d'une vidéo), incrustation de texte ou image, modification d'un visage (ben oué :-p), etc. Bon, je sais pas si tous ces opérations peuvent être faites en temps réel.
http://www-mount.ee.umn.edu/~guille/inpainting.htm

Haypo

Si je me trompe pas, MultideskOS version 1.4 était sous licence GNU GPL.

Haypo

Moi j'ai une plainte à déposer : Kopete est plus joli qu'avant :-D Maintenant, il affiche la photo de l'interlocuteur à chaque message, et regrouper les messages par interlocuteur pour gagner de la place. C'est joli, mais pas très compact. Enfin, je n'ai pas encore trouvé de thème de remplacement, les autres utilisent des couleurs vives affreuses :-p

Haypo

« Quels sont les solutions ? » : une solution est de mettre par écrit les choses à savoir. Utiliser Mediawiki (ou autre wiki) pour que chacun puisse travailler sur ce(s) document(s) me semble une bonne idée.

Haypo

Reiser 4 supporte aussi l'association de méta-données aux fichiers. Ceci permettrait (je n'ai pas bien compris comment) de pouvoir faire des recherches très fines sur les fichiers. Un peu comme Beagle le fait, mais au niveau du système de fichier (plus rapide donc ?).

J'ai entendu ça vite fait, j'ai très peu d'informations dessus. Certains disent que Reiser 4 est le WinFS du libre à cause de ce truc de méta-données.

Haypo

Je veux pas faire mon intégriste, mais moi j'espère de tout c½ur que le projet Nouveau aboutisse un jour ! C'est un projet qui vise à développer des pilotes libres complets (support de la 3D potable) pour les cartes Nvidia (depuis GeForce jusqu'aux toutes dernières).
http://nouveau.sourceforge.net/

Haypo

Pour faire des sites web :-) Et pour les boîtes (oué, ceux qui manipulent de l'argent, pas les étudiants atardés qui font du libre), il reste Java et .NET.

Haypo

Pour info, artefacts a fait un gros boulot pour que Wormux soit intégré dans Debian, et voilà le travail :
http://packages.debian.org/unstable/games/wormux

Uniquement dans unstable, mais bientôt dans testing ;-)

Haypo

"~ppc" devrait apparaitre étant donné que PowerPC est supporté.

Haypo

Le concours IOCCC (The International Obfuscated C Code Contest) ?
http://www.ioccc.org/

Ça m'intéresserait de connaître le même genre de site mais pour Python ! Perl, c'est de la triche, il intègre un obscursificateur de base :-p
http://en.wikipedia.org/wiki/Just_another_Perl_hacker

Haypo

Pour faire avancer la discussions sans fin, la question « découper CImg en plusieurs fichiers » est relative, à mon avis, à la facilité de développement de CImg : il est plus agréable de travailler sur des fichiers de 200 à 400 lignes que sur un fichier de 20.0000 lignes.

Sinon, plutôt que d'utiliser des flags de compilation pour choisir les options de CImg à activer, il serait intéressant de découper la bibliothèque en module. Un programme pour X11 qui voudra permettre l'enregistrement en JPEG utilisera :

#include <CImg.h>
#include <CImg-X11.h>
#include <CImg-jpeg.h>

En tout cas, je pense qu'au niveau de la compilation, c'est kif-kif. Le précompilateur, cc je crois bien, fait bien son boulot.

C'est vraiment pour rendre le code de CImg (mais pas des programmes qui l'utilisent) plus lisible (plus facile à relire, à maintenir, à faire évoluer, etc.).

Haypo

En quoi le fait que le style de code d'une bibliothèque te plaise ou non soit un critère pour l'utiliser, si elle remplit les fonctions pour lesquelles tu l'utilises ?

Elle ne me satisfait pas, elle est trop lente :-) Je voulais l'optimiser (ex: en utilisant de l'assembleur SIMD, MMX, SSE, Altivec & co).

De plus, l'essentiel du code de GREYCstoration est dans CImg (tous les traitements sur l'image).

Ne serait-ce pas un peu une sorte de snobisme de programmation ?

Oui, il me semble.

Je suis pas contre que quelqu'un reprenne le peu de code que j'ai écrit. De tout façon il est sous GPL, je ne peux même pas m'y opposer :-)

Haypo