tgl a écrit 1743 commentaires

Le codec, en général (et ici), c'est "RLE" (aka "Quicktime Animation"). Et en principe il est librement supporté en lecture via FFmpeg.

Yup, pas mieux.

La dernière fois que j'ai joué à Rails, j'étaits justement un peu déçu de ne pas avoir trouvé de solution toute prête pour gérer proprement des users/groups, donc là vraiment tu tombes à pic. Je vais m'y remettre tiens du coup...

À part ça, je ne trouve aucune mention d'une licence... t'as une idée sur la question ?

> D'une certaine façon, plus j'augmente les indices, plus j'affine la
> correspondance?

Mmh, pas tout à fait, enfin ça dépend ce que tu entends par là :)
Disons que, après l'utilisation d'un "=~", le tableau BASH_REMATCH contient :
- à l'indice 0, la chaine qui a matché l'ensemble de la regexp. Ici, c'est le nom de fichier ($f) complet, puisque ma regexp va obligatoirement du début jusqu'à la fin de la chaine ('^' au début et '$' à la fin). Mais si j'avais fait par exemple [[ "123plop.MP3" =~ '([a-ZA-Z]+)\.([mM][pP]3)' ]], on aurait eu BASH_REMATCH[0] qui vaudrait "plop.MP3", puisque le "123" lui n'est pas dans le match.
- aux indices >= 1, le tableau contient les sous-expressions marquées entre parenthèses dans la regexp. Ça permet de récupérer des morceau de chaines. Ici, BASH_REMATCH[1] correspond au groupe "([a-ZA-Z]+)", donc au nom du fichier (note que c'est pas une bonne regexp pour un nom de fichier, vu que tu as en fait probablement des espaces ou des trucs du genre). Et BASH_REMATCH[2] correspond au groupe "([mM][pP]3)", donc à l'extension. Et au delà de 2, il n'y aura rien puisqu'il n'y avait que 2 groupes.

> J'en suis pas encore à un soucis d'optimisation

Ouais, là je me doute un peu que tu n'as pas 10000 fichiers à renommer d'un coup, et que donc tu t'en fiches. Mais c'est clair qu'il est utile de connaitre quelques bashismes pour éviter les forks quand on fait des grosses boucles, sinon on arrive vite à des scripts qui passent de quelques dixièmes de secondes à quelques minutes en temps d'exécution. C'est des bonnes habitudes à prendre.
Par exemple, sans parler même du =~ qui est encore un peu trop récent pour pouvoir être largement utilisé, prends par exemple les substitutions "simples" dans les chaines... Tu vois souvent des crougnes de ce genre là :

find . -type f -name '*.MP3' \
| while read f ; do
mv "${f}" "`echo $f | sed 's/\.MP3$/.mp3/'`"
done

Bon, bah c'est affreusement lent (on crée, pour chaque nom de fichier, un premier sous-shell pour le `...`, puis deux autres processus pour les 2 côtés du pipe). Alors qu'on peut écrire sans fork inutile dans la boucle :

find . -type f -name '*.MP3' \
| while read f ; do
mv "${f}" "${f%.MP3}.mp3"
done

Enfin voilà, ça c'est déjà un exemple plus réaliste d'un truc où un petit bashisme permet de faire bien mieux que du bourne shell de base.

les expr reg bash ne sont pas tres évoluées

Les patterns de base sont assez nazes, mais en bash-3.x y'a aussi le support des vraies regexps, même si elles sont pas forcement toujours très pratiques à utiliser (opérateur de comparaison "=~", et variable $BASH_REMATCH pour récupérer les matchs). En étant un peu tordu, enfin plus pour illustrer leur utilisation en fait, ça peut donnes des trucs dans ce genre là :

for f in * ; do
	if [[ "${f}" =~ '^([a-zA-Z]+)\.([mM][pP]3)$' ]] \
	&& [[ "${BASH_REMATCH[2]}" != "mp3" ]] ; then
		mv "${f}" "${BASH_REMATCH[1]}.mp3"
	fi
done

Comme tu vois, je confronte des noms de fichier à une regexp 'achement compliquée, qui a deux sous expressions qui, quand ça matche, sont récupérables dans le tableau $BASH_REMATCH (et pour info, à l'indice 0 on aurait trouvé le match complet, ici équivalent à $f bien sûr). Heu, bon, on est bien d'accord que mon exemple est débile, mais bref, parfois c'est bien pratique pour éviter de forker des grep ou des sed...

Ça n'est pas le cas non. Par contre on peut facilement imaginer que la clef qu'il faut demander (y compris pour l'éval de 30 jours), elle, contienne cette date de péremption.

Perso j'ai eu une fois des soucis pour charger un module compilé en 3.4 sur un noyau compilé en 3.3. Est-ce normal ou pas, j'en sais rien, mais toujours est-il que depuis, quand j'ai un doute, je vérifie moi aussi quelle branche j'ai utilisé pour le noyau avant de lui rajouter des modules.

Hmm... j'avais zappé la 2ème question, plus générale : à ma connaissance, pas de méthode miracle. Tu trouveras l'info pour certaines libs qui le prévoient (essaye d'exécuter /lib/libc.so.6 par exemple), mais je pense qu'il n'y a rien dans les headers ELF standards pour la stocker.

Tapez ici votre message.

Rsync c'est bien pour un maître et des esclaves, mais si toutes les machines sont à égalité, c'est un peu lourd (enfin, faut faire tourner un serveur sur chacune quoi).

Je te conseillerais plutôt Unison, qui est lui vraiment prévu pour ce cas de figure. Il permet de faire des synchros d'arborescences bidirectionnelles, totales ou partielles, par ligne de commande ou GUI, avec une bonne gestion des conflits, et sans avoir de service spécifique qui tourne (tu peux passer par différent protocoles classiques, dont ssh que je trouve idéal). Et en plus il est cross-platform (Linux, OSX et Windows au moins). Fait juste gaffe à un truc, c'est à utiliser des versions suffisament proches (même X.Y) sur toutes les machines, sinon elles ne vont pas se comprendre.
http://www.cis.upenn.edu/~bcpierce/unison/(...)

Quant à Subversion, bah, ouais si tu as besoin d'une gestion de version en plus, mais sinon ça va juste être plus lourd à utiliser. Et encore, ça serait chaud si tu n'as pas une des machines qui serait toujours accessible par les autres, pour faire repository. Des gestionnaires distribués comme Arch ou Bazaar seraient peut-être un peu plus adaptés (sur chaque machine une branche, qui peut aller pomper directement sur les autres).

> - au Luxembourg : passage oblige pour l'Essence et les cigarettes

Erf, amusant quand on pense au nombre de français qui eux vont en Belgique pour ça...

> Le passage à la version 3 n'est pas si impossible que ça, car un bon
> nombre de fichiers portent la mention "either version 2 of the
> License, or (at your option) any later version.".

Y'a pas l'air d'y en avoir tant que ça :

% find . -name "*.[ch]" | wc -l
16300
% find . -name "*.[ch]" | while read f ; do grep -l "2.*or.*later" "${f}" ; done | wc -l
887

Bon, bien sûr ma recherche peut en rater en cas de saut de ligne, m'enfin quand même, je doute que ça en rajoute les milliers qu'il faudrait.

Ah... ok, donc tu veux à la fois les virer de l'un et les ajouter dans l'autre. Si c'est bien ça, et bah j'avais pas capté.

En sed, ça pourrait se faire avec d'une part l'option '-i', qui permet de modifier un fichier sur place (ici, on va lui faire des 'd' pour effacer les lignes à couper), et d'autre part avec la commande 'w' qui permet d'écrire dans un fichier. Ça donnerait ça (oui oui, sur 2 lignes, pour séparer les 2 commandes entre accolades) :

sed -i -e "${Numdebut},${NumFin}{w$rep/filtre.txt
d}" $rep/$fic

errr... s/ls/Le/

C'est probablement plus simple tout en awk, genre :
awk "NR == ${ligne} { \$2 = plop } ; { print \$0 }" ancien_fichier > nouveau_fichier

ls « NR == ${ligne} { \$2 = plop } » va modifier le 2ème champs de la ligne n°$ligne, et le « print \$0 » va afficher les lignes quelles qu'elles soient, modifiées ou non.

« sed -e "$NumDebut,$NumFind" > $rep/filtre.txt »

Ici, ton shell va faire une substitution de "$NumFind" par rien du tout vu que la variable NumFind n'existe pas. Ce que tu veux, c'est plutôt "${NumDebut},${NumFin}d" : les accolades permettent de bien délimiter ce qui est nom de variable et ce qui ne l'est pas.

Bon et sinon, je vois pas trop sur quel fichier ton sed est censé travailler. Enfin, là il va bosser sur l'entrée standard, donc faut que tu pipes un truc vers ton script shell. Si c'est pas ça que tu voulais faire, faudrait que tu passes le nom du fichier en argument à sed.

Je pense pas qu'il soit indispensable de modifier Bugzilla pour faire ça. On peut imaginer un script complètement séparé, un robot qui traiterait les commandes email et ferait les requêtes/updates correspondantes, genre en utilisant WWW::Bugzilla.
http://search.cpan.org/~mcvella/WWW-Bugzilla-0.5/Bugzilla.pm(...)

Y'a une rediff' les 2ème mardi du mois (donc là le 11 octobre je suppose) à 10H30 aussi.

Elle est arrivée vers 16H, on a fait ce qu'on a pu.

Bande d'ingrâts... :p

Faut décidement croire que je suis pas encore mûr pour une astuce sans boulette...

> Une fois le bookmark créé, il vous suffira de faire :
> % cdargs toto
> pour vous rendre dans le dossier en question

Il faut lire "% cv toto". Quant à la commande "cdargs", elle offre elle une éspèce de navigateur qui permet de se balader dans les répertoires et de créer des bookmarks, mais en fait perso je l'ai pas trouvée super utile. Enfin disons qu'avec "ca" pour faire un bookmark et "cv" pour y aller, et bien je suis content et je n'ai pas cherché beaucoup plus loin...

J'ai joué qlqs parties contre l'ordi tout à l'heure, et franchement je trouve ça super bien vu, genre bien prise de tête malgré des règles simples, ce que je considère comme un gage de qualité en matière de jeu de plateau. Un truc qui manque peut-être à mon avis (j'ai écrit à l'auteur pour lui suggérer d'ailleurs) ça serait une règle pour interdire de revenir dans des configurations déjà jouées, sinon je pense qu'on laisse un peu la porte ouverte à l'anti-jeu (les parties ordi vs. ordi ont tendance à boucler, c'est ce qui m'y a fait penser).
Mais sinon, bah c'est vraiment un nouveau venu bienvenu. Je suis curieux aussi d'essayer un peu à 3 joueurs, je me demande dans quelle mesure la position du joueur central est équitable par rapport à ceux des côté... on verra bien à l'usage.

Merci à l'inventeur donc, et à Colin pour l'implem'.

oui.

Tu n'as qu'à te dire que 1.5 n'est pas la mi-chemin de 2.0, mais celle de 1.10, et ça sonnera tout de suite moins prétentieux.

Bon alors juste une précision, qui ne fera pas avancer le débat mais quand même... : ça n'est pas lezardbreton qui a écrit «CD vif», c'est moi au moment de la relecture parceque je reformulais cette phrase pour d'autres raisons. Très sincèrement, je l'ai fait sans me poser de question ; je me souvenais du sens, et c'est le mot qui m'est venu, probablement parce que je l'avais déjà vu employé dans d'autres dépêches et qu'inconsciemment il m'avait plu.

J'aurai aussi bien pu ne pas traduire, oui... Si LiveCD avait été la première chose à me passer par l'esprit, je ne serais certainement pas revenu le modifier derrière sous prétexte de défense de la francophonie. Je ne suis pas de ce combat là.

Après, pourquoi « CD vif » m'a plu au point de me paraitre naturel ? Bof, c'est sûrement assez subjectif, mais moi ça me parait être une expression élégante et bien adaptée. Les trucs du style « de démonstration » par contre, ça fait vraiment péremptible en 30 jours, ou à moitié utilisable seulement, bref ça ne me parait pas adapté. Quant à « CD vivant », je trouve ça un peu terre à terre, moins joli, moins sympa : il y a déjà le sens « vivant » dans « vif », pas de problème de ce côté là (« Prenez le mort ou vif !», ça veut dire ce que ça veut dire...), et il y a en plus le côté « agile, malin, rapide, etc. », qui correspond bien lui aussi à l'objectif de ces CDs. Bref un qualificatif dont le double sens est adéquat, ça serait dommage de s'en priver. Enfin, « CD autonome », bah ouais, ça ça aurait pu le faire aussi ; au pire je trouve juste ça un peu plus froid, plus bassement technique, donc ça m'aurait probablement moins marqué, mais bon, j'aurais rien eu contre non plus. Voilà, mes 2¢ de subjectivité...

Hmm, j'suis pas sûr de comprendre là... Hésites pas à me la refaire si tu n'en es pas sûr non plus :)

Faire tourner des machins datant de la 2.4 sur la 2.6, c'est jamais un soucis ça, la compatibilité ascendante pour GTK elle est déjà très bonne.

Là ce dont je parlais, c'est plutôt l'inverse : comment s'assurer, quand on développe avec GTK 2.6 d'installé, qu'on ne tape pas dans les quelques nouvelles additions à l'API, mais seulement dans ce qui existait déjà du temps de la version précédente ?

Bah, de toute façon, j'ai pas essayé dans GCompris, mais pour avoir joué un peu avec GNUdoku, je trouve quand même que l'écran ça vaut pas une version crayon/gomme/papier. T'as nulle part pour gribouiller tes réductions de domaine...