jigso a écrit 1205 commentaires

Esperons qu'ils ne sortiront pas un OpenBSD vibrant... Ouille !

Pour info, le gain de performance n'est pas évident - ou au moins il ne sera peut-être pas de l'ordre de ce qu'on imagine. Les opérations de bases de traitement des données (par ex les manipulations de chaines) sont déjà écrites et exécutées en langage machine, même si on passe par une VM. Bien sûr on gagne un niveau d'indirection, mais face au traitement proprement dit ça n'est pas significatif. Par contre le gain au développement et au déploiement à ne pas avoir à recompiler est énorme.

Sinon le "must" dont tu rêves proviendra probablement de Parrot ; destiné initialement à Perl6, d'autres langages disposent de leur compilateur pour cette VM. cf http://fr.wikipedia.org/wiki/Parrot_(machine_virtuelle)

Effectivement, vu comme ça, c'est plus propre.

Mais sinon, faire barboter de l'air, c'est pas suffisant comme source de CO2 ? ( Bientôt les écolos vont se plaindre qu'il n'y a pas assez de CO2 dans l'air ! ;-) )

Sans compter que bruler du bois ne dégage pas que du CO2 et de l'eau, ce serait trop beau...

Dan Gnu/Linux Magazine, de Juin, il y a justement une perle sur la sauvegarde de video flash : il suffit d'écrire un proxy HTTP en Perl qui recopie à la volée tous les flv dans un répertoire.

cf les modules HTTP::Proxy et HTTP::Proxy;:BodyFilter::Save

À coupler avec l'extension FoxyProxy sous Firefox qui permet de changer de proxy en fonction du site - pas là peine de faire passer tout le traffic HTTP par ce proxy, il suffit de ne l'utiliser que pour les sites voulus.

Sinon pour faire plus automatique, avec les modules WWW::Mechanize, il doit être possible de scripter la récupération et l'analyse des pages pour reconstruire l'url des flvs...

Exactement. Surtout que faire à la fois lire le flux et écrire sur disque dans le même thread est dangereux : si l'écriture disque prend trop de temps, les buffers de la couche réseau vont se remplir et provoquer des soucis en cascade aux niveaux des clients. Alors qu'en découplant les accés lecture/écriture, il est plus simple d'identifier et d'isoler le goulot d'étranglement.

Le mieux dans ces cas-là c'est du faire du multithread. : 1 thread par client, qui remplissent un buffer, et un thread qui s'occupe de vider le buffer dans le fichier. Ainsi si ponctuellement le disque "ralentit" (vis-à-vis du process), la RAM est mise à contribution, puis se vide quand le débit du disque remonte, si c'est le débit d'entrée qui diminue le buffer sera tout le temps vide - tant mieux. Si tu satures la RAM et que le disque ne suit pas, c'est pas la peine de chercher à optimiser le process (l'OS sait mieux que toi quelle resource est dispo à un moment donné), il faut changer le hard : passer sur plusieurs machines, mettre des disques plus rapides. etc...

Des fois j'ai l'impression qu'on nous fait bouffer de la merde.

Mois c'est tout le temps...

pour l'instant, la moyenne est de -0.6, ça part mal...

Est-il possible de modifier le code et de le télécharger dans la box, et de la laisser brancher sur le réseau du FAI ? Je suppute que ce n'est pas trop le cas... Conclusion : il n'est pas possible de faire évoluer la box, et personne ne peut vérifier du coup que le code qui tourne est bien celui correspondant au source... Autrement dit on n'est pas loin du modèle propriétaire...

Pourquoi de l'ironie ? Parce que finalement, Paris n'est pas en L2 ? (j'en sais rien, j'aime pas le foot).

Il est toujours possible de normaliser les chaines avant, puis de faire un calcul de distance de levenshtein. Ici la question demandait juste une recherche de mots "similaires" : effectivement il faut peut-être affiner la définition de "similaire".
Mais comme en exemple il y a "Beethoven - Concerto n°1.mp3" et "Beethoven - Concerto no.1 en la mineur.mp3", je pense que la définition est encore plus large qu'une simple distinction phonétique.

Et donc pour répondre à la question, je ne connais pas d'outil tout fait. Par contre il existe en Perl des modules pour calculer cette distance.
Il suffit d'enrober tout ça. Par ex pour avoir la liste des noms de fichiers qui ont la distance la plus courte :


/usr/bin/perl
use strict;
use Text::Levenshtein qw/distance/;
use List::Util qw/min/;
my $f = shift or die "missing filename\n";
opendir my $dir , '.';
my @files = readdir $dir;
closedir $dir;
my %d;
push @{$d{distance($f, $_)}}, $_ foreach @files;
print map { "$_\n" } @{$d{min keys %d}};


http://fr.wikipedia.org/wiki/Distance_de_Levenshtein

Par exemple entre Attila.doc et Atila.doc, la distance est de 1
entre "mon projet.pdf" ou "projet.pdf", la distance est 4.

Donc en calculant toutes les distances, et en fixant un seuil il est possible d'avoir un liste de nom probablement proches. Par contre ça ne marche pas à tous les coups :
"Beethoven - Concerto n°1.mp3" et "Beethoven - Concerto no.1 en la mineur.mp3" => ~15 (à la louche).
Essaye peut-être en divisant la distance par la longueur de la chaine, mais bon est-ce que 15/44 = 36% signifie que les chaines sont proches ou pas ? si on augmente le seuil, on risque d'avoir de faux positifs...
Peut-être qu'en pondérant différement les ajouts dans le calcul de la distance, on peut avoir qqe chose de plus efficace pour ces cas.

www.mais.eu
www.adi.eu
www.bl.eu
www.cessez.le.f.eu

firefox != debian

Je confirme. En désactivant la toolbar, le scroll redevient fluide.
À une époque j'avais même des morceaux de la toolbar (en fait la partie supérieure qui dépasse quand elle est minimisée) qui restaient sur la page, et qui me barraient la page tous les 20 pixels environ (le pas du scroll). Il suffisait d'iconifier puis de reagrandir la fenetre pour provoquer un redraw et tout récupérer...

PS : oubliez le commentaire précédent, c'est une connerie, désolé...

Et pour éviter les pbs si la ligne de commande est trop longue :

xargs -a a_supp.lst -d \n rm

xargs -a a_supp.lst rm

Est-ce que le phénomène se produit avec la main devant la sortie de la télécommande ?

si oui => c'est pas par l'infrarouge que ça passe

si non => c'est l'infrarouge qui perturbe le PC => il doit y avoir un récepteur qqe part.

Pour trouver le récepteur, tu peux essayer de filmer ton PC avec un camescope, souvent ils permettent de voir à travers les caches des capteurs IR. Essayer sur un lecteur de DVD, ou une freebox, c'est assez marrant de voir l'interieur à travers l'afficheur.

Oui, désolé pour le lapsus. Et donc comment continuer à vendre des OLPC dans quelques mois alors que l'OS ne sera plus dispo ? ou alors les membres de l'OLPC ont des infos sur la politique future de Microsoft que je ne connais pas (cas le plus probable)

Passer sous XP alors que le fournisseur a annoncé la fin de la maintenance, faut vraiment avoir les neurones qui se touchent... Même si une pétition est en cours, c'est quand même un sacré coup de poker.

t'es sûr que ça vient pas du clavier ?

Avec xkeycaps, est-ce que la touche passe en jaune quand tu appuies dessus ?

ne pas avoir le clavier qui se blo