Tom Lord, mainteneur de GNU Arch, un programme de gestion de sources, a décidé d'abandonner le poste de mainteneur de GNU Arch.

Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.

Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)

Le post sur la mailing list:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)

Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)

Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.

Enfin, bonne chance à Tom Lord pour ces futurs projets.

> Lire le journal (29 commentaires, moyenne: 2,1).

Le fait d'exporter xvidcore vers un dépôt de source Mercurial (voir mon précédent journal) m'a permis de sortir des stats sur l'âge moyen d'une ligne de code du projet.

Le projet est a 25% constitué de code provenant du premier patchset de la branche devapi4 (branche forké a partir de la version 0.9.0). Je me suis un peu senti vexé par cette statistique qui semble signifier qu'on s'est un peu branlé la nouille sur le projet depuis, car on a touché qu'a 75% du code source depuis la patchset 0.

J'ai un peu modifié Mercurial pour me sortir des temps Unix dans la sortie de la commande log, et j'ai donc calculé l'âge moyen d'une ligne de code (c|asm|h) d'xvid. Le résultat est sans appel:
Thu Jun 3 21:13:20 2004

XviD a drôlement peu évolué depuis le cycle de versions 1.0.x. J'en suis d'autant plus touché que j'ai quitté ce projet en Janvier il me semble, et que depuis, c'est un peu le néant coté commit. Il semblerait que les développeurs restant ne font plus rien. Plutôt dommage étant donné que le projet est intéressant et que le travail ne manque pas.

Addendum: les scripts me permettant de déduire l'âge moyen d'une ligne de code.


# Annoter toutes les lignes.
$ (for i in `hg manifest |grep -E "\.(c|h|asm)$" | awk '{print $3 }'` ; do hg annotate $i |cut -d ':' -f 1 ; done ) > annotations.txt

# Chopper la date de chaque commit (j'ai patché mercurial/commands.py pour me donner un temps unix au lieu de time.asctime)
$ hg log | grep ^date: | awk 'BEGIN{i=0;} { printf("date[%3s] = %s;\n", i, $2); i++;}' |less > patches-date.dat

# Ecrire le script awk qui va faire le calcul
$ cat > losc-age.awk << EOF
BEGIN {
EOF

$ cat patches-date.dat >> losc-age.awk
$ cat >>losc-age.awk << EOF
for (i=0; i<444; i++) {
patch[i] = 0;
}
average = 0;
lines=0
}

{
patch[$1]++;
lines++;
}

END {
for (i=0; i<444; i++) {
average += patch[i]*date[i]/lines;
}
printf("%s\n", average);
}
EOF

# Et on trouve l'age moyen
$ awk -f losc-age.awk annotations.txt


La date obtenue n'est pas super précise (erreur d'arrondi flottant), mais ça permet de donner au moins le triplet année/mois/jour moyen sans trop d'incertitude.


Biensûr tout ceci aurait pu être fait en Python, mais je ne connais pas Python :-)


Mon dépôt xvid converti utilisé pour ce test est disponible sur http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...)

> Lire le journal (23 commentaires, moyenne: 3,8).

Hello journal,

Même si j'ai été obligé de me vendre dans les forums pour gagner des XP et pouvoir poster ce journal... je t'en veux pas trop de m'avoir bouder en m'empêchant de te parler.

Bref tout cela pour dire que j'ai continué à tester des SCM depuis mon dernier journal. La victime suivante a été Mercurial (http://www.selenic.com/mercurial).(...)

C'est un sympathique projet en Python qui basé sur les mêmes idées que GIT (de linus torvalds) tente de réparer des erreurs de design fondamentales
- c'est pas un modèle de portabilité (il y auraient de flagrant linuxismes)
- les objets du backend nommés par le sha1 de leur contenu tend à pourrir les perfs lors des tree traversing de source. Cette baisse de perfs est due au fait que le backend en deux niveaux (un niveau de répertoire qui donne le début du hash sha1 et le nom complet de l'objet sha1 ensuite) tend à éloigner physiquement sur le disque des fichiers proches par leur localité dans l'arborescence logique.
- n'est pas un SCM en soi, pour espérer pouvoir s'en sortir, il faut cogito, un sur-ensemble à GIT qui permet de s'en servir de façon conviviale.
- consomme trop d'espace disque pour la taille d'un projet comme linux (3.6GB pour l'historique de linux depuis le 2.4.0). Ceci rend impossible l'import de l'historique global par tout le monde sans plomber kernel.org. Linus a décidé de ne publier l'historique que depuis le 2.6.12-rc2 pour remédier à ça. Mais même comme ça kernel.org a du mal à supporter la charge imposée par des synchros rsync.
- et d'autres dont je suis moins sûr, donc autant éviter l'impression de linchage qui n'est absolument pas mon but.

Donc mercurial a corrigé tout ça. Certains algos trop coûteux de GIT ont été écartés dans le design, et Mercurial a favorisé deux choses:
- le cross indexing entre les revisions de fichiers et les changesets, ce qui rend extrêmement efficace la navigation dans les versions (pratique pour les opérations d'annotations, de diff entre 2 versions arbitraires, et de recherche d'ancêtre lors de merges)
- backend qui respecte l'arborescence logique et qui enregistre les modifs de façon incrémentale et non pas sous la forme d'objets complets.
- protocole assez efficace pour synchroniser deux repositories (basé sur HTTP).

Avec ça on arrive à:
- historique de linux depuis le 2.4.0: 309MB
- clone d'un repo linux comprenant l'historique complet: ~130MB transférés.
- et pleins d'autres trucs impressionnants comme des diffs super rapides, des imports de patch rapides, des annotations peu coûteuses etc... (pour des chiffres sur l'importation de patchs voir http://www.selenic.com/pipermail/mercurial/2005-June/001498.html(...) )

Pour le coup j'ai amélioré mon script d'export arch vers "autre SCM" maison (sans prétention, y a un projet Python qui ferait beaucoup mieux d'apres ce j'ai cru en lire mais manque de bol, il supporte pas arch. Ca s'appelle tailor). Le repository obtenu est dispo la: http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...) , le script dont je me suis servi est la: http://ed.gomez.free.fr/vrac/convert-xvid-baz-repo-to-mercurial.sh(...) .

Bon je m'arrête là, je vous laisse découvrir l'outil par vous même.

> Lire le journal (8 commentaires, moyenne: 2,1).

Suite a l'episode BK sur la LKML, je me suis dit que je pouvais retenter d'utiliser monotone car ça fait maintenant 3ans que j'utilise arch/tla (baz aujourd'hui), et je m'encroute dans mes habitudes.

J'ai donc pour tester le bignou, pris le projet XviD depuis Janvier 2004 que j'ai maintenu dans mes archives arch (dispos sur mon site)

En gros j'ai fait, deux scripts de porc:

Le premier importe la base head de 2004:

#!/bin/sh

# ---- Initial import ----



baz get ed.gomez@free.fr--2004-1/xvidcore--head--0.0--base-0 xvidcore.baz

monotone --db=xvidcore.monotone db init

monotone --db=xvidcore.monotone genkey ed.gomez@free.fr

cd xvidcore.baz

monotone --db=../xvidcore.monotone setup .

baz inventory -s | xargs monotone --db=../xvidcore.monotone add

monotone --db=../xvidcore.monotone --branch=org.xvid.head commit --message="Initial import in monotone"

Le deuxieme permet de mettre a jour vers la revision suivante:

#!/bin/sh



REVISION=$1



baz replay ed.gomez@free.fr--2004-1/xvidcore--head--0.0--patch-${REVISION} | grep -v '{arch}' | grep -v '.arch-ids' | grep -v "^*" > replay.txt



ADDED_FILES=`grep ^A[^/] replay.txt |awk '{print $2}'`

MODIFIED_FILES=`grep ^M replay.txt |awk '{print $2}'`

DELETED_FILES=`grep ^D[^/] replay.txt |awk '{print $2}'`

RENAMED_FILES=`grep ^R replay.txt |awk '{print $2 ":" $4;}'`



for i in ${ADDED_FILES} ; do

        monotone --db=../xvidcore.monotone add ${i}

        echo "A ${i}"

done

for i in ${DELETED_FILES} ; do

        monotone --db=../xvidcore.monotone drop ${i}

        echo "D ${i}"

done

for i in ${RENAMED_FILES} ; do

        ORG_FILE=`echo $i | cut -d ':' -f 1`

        DST_FILE=`echo $i | cut -d ':' -f 2`

        echo "R ${ORG_FILE} => ${DST_FILE}"

        monotone --db=../xvidcore.monotone rename ${ORG_FILE} ${DST_FILE}

done

for i in ${MODIFIED_FILES} ; do

        echo "M ${i}"

done



COMMIT_SUMMARY=` baz log -f -r patch-${REVISION}:patch-${REVISION} |grep ^Summary: | sed s,'^Summary:[[:space:]]*\(.*\)$','\1',`

COMMIT_LOG=`baz log -f -r patch-${REVISION}:patch-${REVISION} | awk 'BEGIN{start=0} /^$/ {start=1;} // { if (start != 0) print;}' | grep -v '==========='`

echo "Summary: ${COMMIT_SUMMARY}" > MT/log

echo >> MT/log

echo "${COMMIT_LOG}" >> MT/log

Puis je m'en suis servi comme ça:

# cd ~/tmp/

# mkdir monotone.test

# cd monotone.test

# import-base.sh

# cd xvidcore.baz

# for i in `seq 1 121` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done

# (edition de commit-rev.sh pour passer sur mon archive 2005)

# baz replay ed.gomez@free.fr--2005-1/xvidcore--head--0.0--base-0

# for i in `seq 1 8` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done

Avis de la transition:
- J'ai pas encore vérifié la cohérence des révisions, je ne sais pas si elles sont équivalentes à celles de arch. Mais les commits ne m'ont pas semblé longuets, donc pour un projet de la taille d'xvid, monotone est utilisable sans souci sur ce point la.
- En deux cuillères a pot, j'ai pu coder un script de migration arch>monotone qui conserve l'historique linéaire d'une branche avec tous les logs messages ! Pas mal, il faudrait cependant faire gaffe au type de changeset dans arch, s'il s'agit d'un merge, il faudrait idéalement importer la branche dont provient le merge avant de merger le patch, et utiliser monotone dans un contexte de merge histoire que l'arbre des révisions monotone ait la meme topologie que celui d'arch.
- J'ai mal aux doigts a force de taper le password de mon certificat monotone et de faire :wq pour valider le log pourtant ecrit dans MT/log...

En gros la 0.18 semble aussi sympa a utiliser que arch/baz, la prise en main est plus simple que celle d'un baz 1.3. Le seul point que je trouve dommage c'est le fait de ne pas pouvoir faire un mirror de sa DB locale sur un serveur tout bête HTTP ou FTP ou SFTP comme le fait arch, la on est obligé de lancer un serveur maison qui permet de synchroniser.

Ah bonne surprise, monotone est plutôt bon à représenter les révisions sous forme compacte, les 130 révisions pèsent 1.5MB pour monotone alors que pour arch sur une partoche ext3, ca pèse 3MB, avec certes une révision en cache pour la continuation 2004->2005.

Enfin voila, ma petite expérience avec monotone... au lieu de troller sur le thread BK, on pourrait donner ici ses expériences dans l'utilisation d'outils SCM décentralisés.

PS: j'ai utilisé bazaar 1.3.1 et monotone 0.18 pour effectuer tout ça

> Lire le journal (6 commentaires, moyenne: 2).

Houpla boum, une nouvelle release d'XviD.

Pour ceux qui ne connaissent pas, il s'agit d'un codec MPEG4 libre (GPL) qui donne d'excellents résultats pour des taux de compression importants (<1.5MBit/s)

Cette nouvelle version apporte un certain gain en qualité pour les vidéos à petit débit, et corrige certains bugs de la dernière beta. Le ChangeLog est disponible sur http://www.xvid.org/(...) ainsi que les sources.

Cette release est aussi la dernière que je prépare au nom de la "XviD team", car après plus de 3 années de loyaux services, je ne ressens plus aucun plaisir à travailler sur ce projet qui demande beaucoup d'investissement personnel en temps pour le suivi et son amélioration.

Voilà j'espère que les linuxfriens qui utilisent xvid et lisent ce journal ont apprécié mon travail. Je souhaite bonne chance au reste des developpeurs XviD pour les prochaines releases.

> Lire le journal (11 commentaires, moyenne: 3,7).

Et hop, le cru 2004 de comparaison de codec de Mr Doom9 vient de paraître.

XviD a perdu la première place en faveur de codecs basés sur le standard mpeg4 avc, qui n'a de rapport avec le mpeg4 d'aujourd'hui (xvid, divx, ffmpeg-mpeg4) que le nom.

Ce journal n'ayant pour objectif que de donner un peu de lecture à ceux que le codage vidéo intéresse, je ne m'étendrai pas sur les détails et vous laisse lire tout çà aidés vos petits "oeils" attentifs.

Ca se passe par la:
http://www.doom9.org/codecs-104-1.htm(...)

PS: je trouve dommage que ffmpeg ait été laissé de coté, il n'est même pas fait mention de lui une seule fois. Codec apparemment boudé par les utilisateurs de windows. Même remarque pour x264, codec libre basé sur le standard mpeg4 avc, standard qui a montré son fort potentiel dans ce comparatif.

> Lire le journal (6 commentaires, moyenne: 4,2).

Faisant suite à un de mes précédents journaux, j'ai déniché ces tutoriaux d'un fort beau gabarit. Ils ne correspondent pas à mes besoins, mais je me disais que çà pourrait rendre service à certains d'entre vous pour découvrir GIMP2.

Les adresses:
http://jimmac.musichall.cz/gimp2demos.php(...)
http://jimmac.musichall.cz/gimp2demos2.php(...)

Bon apprentissage.

> Lire le journal (4 commentaires, moyenne: 2).

Petit journal bien léger et totalement crétin, et inutile...

J'ai trouvé une voiture qui porte la moitié de mon nickname en bannière latérale... si c'est pas la classe çà ! En plus garée juste devant chez moi. J'ai pas pu résister et j'ai l'ai prise en photo.

http://ed.gomez.free.fr/vrac/pictures/gomgom-car.jpg(...)

D'ailleurs je serais soit disant un "nettoyeur"...

:-) Bonne journée à tous

> Lire le journal (1 commentaire, moyenne: 0).

Bonjour journal,

Heureux possesseur d'un APN depuis quelques mois, je commence a bien connaître mon appareil et donc ses défauts. C'est pourquoi je tente de retoucher mes photos pour qu'elles collent plus à ce que je ressentais au moment de la prise en terme d'ambiance/lumière/contraste/grain.

Sous GNU/Linux, mon sauveur s'appelle The Gimp, et j'ai trouvé d'excellents tutoriaux sur http://www.gimpguru.org/(...) et je voudrais aller encore un poil plus loin.

Journal aurais tu d'autres adresses avec des tutoriaux orientés photo aussi intéressants car mon ami google me ramène toujours les mêmes tutoriaux de base :-( ?

> Lire le journal (14 commentaires, moyenne: 2,4).

Comment ça, mes journaux se ressemblent ?!... non pas possible ;-)

L'équipe xvid a le plaisir d'annoncer une release mineure corrigeant quelques bugs (dont un majeur pour le décodeur *uniquement*, le codeur est conforme depuis la 1.0.0)

* xvidcore
- Correction d'un bug d'arrondi lors du décodage des bvops, ce bug rendait le décodeur non conforme au standard, bien que visuellement ce bug n'ait jamais aucun impact (les erreurs d'arrondis sont d'une amplitude de +1 sur la valeur des pixels, dur pour l'oeil de voir la différence).
- Meilleur code de clipping des vecteurs dans le cas de flux codés cassés (erreur de transmission), le code ne devrait plus permettre de crashs.
- Meilleur gestion des cas ou le flux codé "dit" ne pas contenir de bvops, mais en contient bien.
- Les valeurs de fincr/fbase sont remises à echelle pour qu'elles ne dépassent jamais une longueur dépassant les 16bit autorisés par le standard.
- Correction d'un petit problème de "thread safety" dans la version C de la fonction iDCT.

* frontend vfw
- correction d'une fuite memoire

* répertoire debian:
- rajouté au packaging de la release puisque xvidcore ne semble pas être accepté dans le pool debian :-( (sûrement à cause des brevets)

En résumé, cette version n'apporte aucune fonctionnalité, juste des correctifs plus ou moins importants.

Pour les gens désireux de tester du code frais et qui sens bon la fin d'été, il reste toujours l'option CVS HEAD, ou sur mon site, des snapshots plus ou moins réguliers (quand je trouve que c'est opportun). Qu'apporte la version HEAD:
- nouveau port PPC (activé, bien que partiel)
- des tonnes d'optims coté décodeur (25% de perfs en mieux, ffmpeg est toujours plus rapide mais j'y arriverai(tm))
- des retouches coté codeur, et meilleure qualité pour les bvops (option bvhq=1, voir ma section 'modules mplayer')

A noter que si vous jouez avec la version HEAD, c'est pour tester et donner des retours (merci bcp), pas pour se plaindre :-)

Pour vos archivages sérieux, veuillez utiliser la version stable 1.0.2.

Les liens qui vont bien:
L'annonce: http://list.xvid.org/pipermail/xvid-devel/2004-August/004539.html(...)
Pour la version stable http://www.xvid.org/(...) ou http://ed.gomez.free.fr/projects/xvid-1.0.2/(...)
Pour les snapshots: le cvs sur http://www.xvid.org/(...) (developer->cvs) ou http://ed.gomez.free.fr/projects/xvid-snapshot/(...)
Pour le module mplayer mis à jour: http://ed.gomez.free.fr/#mencoder_modules(...)
Pour les chèques et les rendez vous coquins, s'adresser directement à mon agent.

Merci pour votre attention.

PS: vu que les journaux se voient amputés de tous les posts "comment je fais pour...?" (merci les forums), je me permets de passer tranquillement cette news en journal "Première Page".

> Lire le journal (11 commentaires, moyenne: 3,2).

Heureux possesseur d'un APN depuis un ou deux mois, j'ai donc eu moi aussi envie de faire des panoramiques a moindre frais :-)

Mais bon je sais pas trop pourquoi, j'm'y suis pas mis. Et pourtant cykl (http://linuxfr.org/~cykl/(...)) m'avais pointé vers hugin (http://hugin.sourceforge.net/(...)), site me pointant a son tour vers enblend (http://www-cad.eecs.berkeley.edu/~mihal/enblend/(...))... mais non, j'ai pas fait de panos, donc je me suis pas penché sur ces programmes prometteurs.

J'ai même vu traîner deux journaux linuxfr sur le sujet.

Puis aujourd'hui (enfin hier pour être précis), je me suis dis, allez prend ton courage a deux mains, et installes le bouzin pour voir le resultat. Comme annoncé sur le site, c'est un cauchemar de dépendances, mais la je trouve "LA" adresse sympa pour les debianeux (http://people.debian.org/~jordens/debs/(...)) et j'installe le tout avec un simple apt-get hugin enblend.

J'ouvres ma fenêtre, prend trois photos vite fait, et lance hugin pour "stitcher" tout ca. Et la horreur ! enblend supporte pas les TIFF multilayer de hugin+stitcher nona... sur ce j'abandonne et je pleure sur ce resultat: http://ed.gomez.free.fr/vrac/plop-nonblended.jpg.(...)

Mais je me réveille ce matin archi motivé, et je me décide à patcher enblend, car extraire les layers à la mimine dans GIMP, c'est long fastidieux et ca devrait être le travail d'un programme informatique, pas de l'Homme :-)

Alors du coup, je pond çà:
http://ed.gomez.free.fr/vrac/multi-layered-tiff.diff(...)

Et je pleure de joie sur:
http://ed.gomez.free.fr/vrac/plop-blended.jpg(...)

Et je poste ca:
http://www.email-lists.org/pipermail/ptx/2004-June/001791.html(...)

Donc tout retour est le bienvenu de la part des linuxfr'iens.

PS: il semble d'apres une reponse a mon post sur [ptx] que hugin possede un output multi TIFF que je n'ai pas vu... bon bé tant pis, quelqu'un pour confirmer ? sinon le patch c'est du benef :-)

PPS: oui pas besoin de commenter sur la mocheté des banlieues parisiennes :P

> Lire le journal (22 commentaires, moyenne: 2,5).

Une nouvelle version de XviD est disponible. Il s'agit "juste" d'une version bugfix.

Elle corrige quelques bugs mineurs qui rendaient le codage un poil sous optimal. Donc cette version peut apporter un gain en qualité.

Coté décodeur, les vidéos de 1 image/seconde ne devraient plus poser de problèmes. (On y pense pas souvent à coder des vidéos en 1fps ;-)

La news détaillée, les sources, l'argent, la gloire et la beauté sont dispos sur (pour les deux premiers c'est sûr et certain, les 3 autres, ça dépend du visiteur :-):
http://www.xvid.org/(...)

> Lire le journal (8 commentaires, moyenne: 2,4).

Bonjour,

Voici XviD 1.0.0

L'équipe de développement est heureuse de vous annoncer la disponibilité immédiate d'XviD 1.0.0. Et bien que ce numéro de version ne soit au final que symbolique, il s'agit tout de même d'une étape importante. La "xvid-team" espère que vous apprécierez les efforts placés dans cette version 1.0. Merci à tous les utilisateurs qui ont rapporté des bugs, envoyés des patchs et donc au final contribuer à ce que XviD atteigne une qualité suffisante pour être estampillée 1.0.

Nous vous souhaitons d'heureux codages de vidéo et restez attentifs aux améliorations prévues pour les prochaines versions.

Changements depuis la RC4 (Hola):

• Bug mineur dans l'optimisation de quantification par Trellis
• Optimisation des modes VHQ>1 (le code exécutait deux types de recherches, là ou une seule était utile)
• Meilleur clipping des vecteurs de mouvements
• Correction de la fonction C de sortie RGB 16bit
• Correction d'une possible corruption de l'entête VOL dans le cas ou le framerate est de 1 image par seconde
• Correction de la prédiction du coefficient DC (ce bug a aussi été rapporté/corrigé au/par le projet FFMPEG)

Dispo dans cette crèmerie uniquement, mais à savourer entre amis:
http://www.xvid.org/(...)

-- XviD Team

Puis ma valeur ajoutée à cette traduction de l'annonce... XviD 1.0 c'est quand même:

• un projet vieux de 3ans (enfin en Novembre 2004), dont presque 1an et demi consacré à cette version
• un projet mené tant bien que mal par à peu près seulement 6 personnes de coins différents (Allemagne, France, Australie, USA et d'autres)
• quelques 242 patchs depuis la version 0.9.2, soit un patchset arch/tla pesant 5.2MB (logs tla compris), soit 93 fichiers modifiés, 525 fichiers ajoutés (logs tla compris), 50 fichiers supprimés, 18 fichiers renommés.
• des heures et des heures de chauffage de pièce par les CPUs des devs pour les tests, et pas de pause pendant la canicule 2003
• de belles tensions dans l'équipe de dev pour savoir ce qui a le droit de citer dans la version finale comme fonctionnalité ou encore license GPL ou license GPL plus clause d'exclusion géographique à cause des brevets logiciels

Bah vala, il est temps de lacher son bébé dans la nature, mon oeuvre ne m'appartient plus :-)

PS: pensant que linuxfr n'est pas freshmeat, je n'ai pas proposé cette info comme une news, si vous pensez le contraire, soumettez la donc, ca ne me deranges pas.

> Lire le journal (22 commentaires, moyenne: 2).

Y'a un projet GNU qui m'intrigue depuis un moment.

Il s'agit de GDB. A ce que j'ai compris, il est en developpement actif, maintenu par Red Hat principalement. Red Hat ayant surtout contribué l'ajout de bindings TCL:TK qui vont bien pour avoir une GUI utilisable. Le truc s'appelle Insight.

http://sources.redhat.com/insight/(...)
ftp://sources.redhat.com/pub/gdb/releases/(...)

Bon alors la question qui me turlupine l'esprit, c'est pourquoi un projet aussi important pour les developpeurs est si mal géré coté relations publiques ("marketing") ? y'a qu'a matter la gueule du site qui a pas bougé depuis plus d'un an. Zapper une version majeure 6.0, faut le faire quand meme, ne pas s'en rendre compte pour la version suivante ca devient gravissime. A croire qu'ils veulent pas que leur GDB soit utilisé apres la version 5.x.

Sinon vous utilisez quoi comme debugger vous (pour du C principalement) ?

- ddd, j'ai tourvé nul.
- gvd (le prog codé en gtkada) est completement mort (mais il etait interessant en terme d'interface GTK :-)
- xgdb, aussi inutilisable que ddd

J'ai beau chercher, j'ai rien trouvé d'aussi intégré a gdb que insight. Mais j'ai pas trouvé un seul projet de debugger récent/vivant qui utilise gtk. (tcl:tk, saibien, mais y'a franchement mieux niveau widget et gestion des polices)

> Lire le journal (14 commentaires, moyenne: 1,4).

Voila comme promis suite au poisson d'avril, xvid 1.0.0-rc4 est dispo sur xvid.org.

La news:
http://www.xvid.org/modules.php?op=modload&name=News&file=a(...)

Le bz2:
http://files.xvid.org/downloads/xvidcore-1.0.0-rc4.tar.bz2(...)

Pour les plus paranos (ces fichiers sont pas dispos sur le site officiel, faudrait que j'en touche deux mots au webmaster):
http://ed.gomez.free.fr/projects/xvid-1.0.0-rc4/md5sum.txt(...)
http://ed.gomez.free.fr/projects/xvid-1.0.0-rc4/key-fingerprint.txt(...)
http://ed.gomez.free.fr/gpg-key.txt(...)

> Lire le journal (1 commentaire, moyenne: 1).

Et voila tout est dans le titre, a vos compilos, chauffez vos mencoder/transcode et zou encodez moi vos meilleures vidéos avec un des meilleurs codec MPEG4 !

Ca se passe la:
http://ed.gomez.free.fr/projects/xvid-1.0.0/(...)

L'annonce officielle sur la ML:
http://edu.bnhof.de/pipermail/xvid-devel/2004-April/004095.html(...)

> Lire le journal (8 commentaires, moyenne: 0,4).

Rien si ce n'est pour dire que j'ai participé au dépouillement des votes de mon canton. Bref j'ai été un citoyen(tm) et je trouve ca bien(tm) d'user de droits chèrement acquis au fil des siècles.

> Lire le journal (11 commentaires, moyenne: 0,9).

Cher journal, j'abuse de toi mais c'est pour le bien d'autrui, pas pour moi ;-)

Voila, un ami s'en va en New Zealand (la grosse ile a coté de l'australie, bref c'est loin tres loin). Et on pensait lui offrir un petit cadeau de départ, mais on est 3 a secher depuis une semaine sur la question... on a aucune idee de cadeau sympa.

Et toi journal tu offrirais quoi ?

PS: mon ami n'est pas un geek, les cadeaux techies ne lui vont pas trop.
PPS: je mets ce journal en deuxieme page en esperant qu'il tienne plus longtemps qu'en premiere afin de *vous* permettre de donner plein d'idees ;-)

> Lire le journal (9 commentaires, moyenne: 1,6).

Recemment Thomson a sorti une nouvelle version de leur modem Speedtouch 330. Bien que d'autres modeles gris soient sortis avant, ceux ci sont devenus incompatibles (la rai manta est une revision 0000, les violets et les premiers gris sont des revisions 0200, mais les 3 modeles restaient compatibles)

Donc avec un peu de retard sur le planning prévu, j'ai rajouté le support du nouveau modele à modem_run. A savoir qu'il faut maintenant specifier le firmware principal *et* le boot block sur la ligne de commande (-f et -a). Sinon vous pouvez concatener les deux fichiers ensembles (cat boot.bin firmware.bin > firmware_complet.bin), et n'utiliser que -f.

Un boot block libre est fourni pour les premiers modeles (0000 et 0200, dans src/boot.v123.bin, installé par le "make install" dans ${prefix}/share/speedtouch), mais pas pour les 0400. Leur license ne me permet pas d'inclure leur binaire dans nos sources. Cherchez donc un fichier de 935 octet dont le nom ressemble a celui du firmware principal.

Vala le tout se trouve dans le CVS, retours d'experience le bienvenu de la part des utilisateurs de ces nouveaux speedtouch.

PS: attendre demain afin que sourceforge replique les chgts sur le CVS anonyme.

> Lire le journal (2 commentaires, moyenne: 1).

Ca y est, je bosse, et ce message vous est offert par mon employeur ;-) Fini d'etre etudiant et glandeur !

> Lire le journal (8 commentaires, moyenne: 1,5).