Posté par Pierre Tramo (page perso, ) le 21/09/2004 à 09:46. (lien). Évalué à 6.

Sur le fond je pense perso qu'il a raison, acheter cette encyclopédie c'est financer la guerre partout dans le monde.
Tout comme consommer des substance illicites c'est financer le terrorisme ? Tu utilises les mêmes raisonnements bancals et infondés que certains ministres de droite.

Pourquoi ne pas dire au moins qu'il existe un équivalent libre, de qualité supérieur et qui fait de vous des acteurs et pas seulement des spectateurs ?
Et bien voilà, tu l'as dit.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 21/09/2004 à 09:33. (lien). Évalué à 10.

on fait de la pub pour les marchands d'armes qui éditent des logiciels propriétaires
On passera sur les rapports entre Hachette et EADS qui sont très loin de ce que tu décris, pour préciser que Hachette n'est pas un éditeur de logiciels mais un éditeur et un distributeur de contenu. L'interface n'est là que pour servir le contenu (après, évidemment on peut critiquer le contenu, mais c'est une autre histoire).

logiciels propriétaires basés sans scrupule sur les logiciels libres, sans aucune contre-partie
Ah tu ne vois aucune contre-partie ? Moi j'en vois deux :
- la crédibilité de la plateforme Mozilla pour développer des produits multimedia multiplateforme
- la reconnaissance de GNU/Linux comme cible pour ces produits, c'est-à-dire comme OS grand public, par les éditeurs de contenus
Certes, mettre l'interface sous une licence libre serait appréciable, mais la contribution de cette encyclopédie n'en est pas moins très positive.
Je préfère voir ça que le même Hachette qui choisit la solution ultra-fermée Windows Media pour son site Virginmega...

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 20/09/2004 à 01:37. (lien). Évalué à 5.

Coches la case pour que la session soit permanente...
(leçon 5 au passage :p )
Justement, pourquoi ne pas avoir mis "connexion/session permanente" ? Le terme "automatique" laisse supposer qu'une nouvelle session est créée à chaque fois qu'on vient sur le site. Et les forums ne doivent pas pallier le choix de termes incorrects.

Et au passage, pourquoi avoir supprimer toutes les sessions se week end (en particulier toutes celles qui avaient une activité récente) ? Surtout que certains (c-à-d ceux qui l'ont utilisée ?) ont eu des problèmes avec la page de récupération des mots de passe.

Pour finir, quand un journal/forum est déplacé, ne serait-il pas possible d'être redirigé automatiquement, ou d'avoir un lien vers la nouvelle localisation ? Avec la page d'erreur qui nous indique (en anglais, pour une audience francophone) que the requested URL /forums/13/3717.html was not found on this server, on ne sait pas si la page a été supprimée, déplacée, ou s'il s'agit d'une erreur de frappe. Et vu que la page ne contient aucun lien (page de l'auteur, page des journaux, page des forums, ...) susceptible d'aiguiller le lecteur dans sa recherche de la nouvelle URL, il doit déjà bien connaître le site pour avoir une chance de s'y retrouver.
Et d'ailleurs, pourquoi les URL des journaux contiennent-elles le numéro de la section, puisque le numéro du journal n'en dépend pas ? Supprimer cette partie inutile permettrait déjà d'avoir des URL résistantes au changement de section.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 17:43. (lien). Évalué à 2.

J'ai pas trouvé de guide, mais en survolant la javadoc du package java.io on peut déjà se faire une idée.
L'important à savoir pour commencer, c'est qu'il y a quatre classes (abstraites) de base, selon qu'on manipule des flux d'octets (InputStream, OutputStream) ou des flux de caractères (Reader, Writer). Ensuite on choisit une implémentation selon le support du flux (fichier, String/StringBuffer, tableau d'octets) ou on obtient le flux en retour d'une méthode (sockets), il existe aussi des passerelles de flux d'octets vers flux de caractères. Enfin, il y a les classes (toujours abstraites) Filter* (et quelques autres) qui ajoutent des facilités pour la manipulation d'un flux (quel qu'en soit le support), selon l'implémentation qui correspond au besoin (Buffered*, Print*, ...).
Voilà, c'est un bref résumé. Après il y a aussi java.nio et ses Channels mais c'est une autre histoire ;)

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 13:37. (lien). Évalué à 2.

Bon, ben les 40 secondes devaient venir d'autre part que de la recherche sur tout le contenu. J'ai utilisé ce code :

			Reader reader = new InputStreamReader(doc1.openStream());

			int nbChars;

			char[] chars = new char[1024];

			StringBuffer content = new StringBuffer();

			

			while ((nbChars = reader.read(chars)) != -1) {

				content.append(chars, 0, nbChars);

			}

			reader.close();

			

			m = p.matcher(content);

			

			while (m.find()) {

				buffy.append("Mediabarre : ").append(m.group(4)).append(" pour ").append(m.group(5)).append('\n');

			}

Et c'est quasi instantanné (et je n'ai pas une machine de guerre), du même ordre que la recherche ligne par ligne (modulo le temps consommé par le réseau et l'interface graphique).

PS : tu as lu http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html#en(...) ?

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 12:29. (lien). Évalué à 2.

Bon, on va prendre dans l'ordre :o

import java.util.*;

Moi j'évite d'importer des packages entiers. D'une part ça doit ralentir un chouille la résolution de noms au chargement de la classe (j'avais remarqué en désassemblant des .class que le compilo ne remplaçait pas les * par la bonne liste de packages), mais surtout ça rend la maintenance du code plus difficile : si tu reprends ton code quelques mois/années plus tard et que t'as pas un bon IDE sous la main, tu risque de passer du temps à retrouver dans quel package était telle ou telle classe.

v = new Vector();

Vector, c'était dans l'ancienne API des collections. Dans l'actuelle, il y a la classe ArrayList qui est équivalente et qu'il vaut mieux utiliser : si plusieurs threads ne risquent pas d'accéder simultanément à une liste, les accès seront plus rapides en utilisant un ArrayList qu'un Vector ; et surtout, la nouvelle API des collections est plus complète, plus souple,... donc autant oublier l'ancienne. Et pour faire propre, on peut découpler le type de structure et son implémentation : List i = new ArrayList();

jLabel1.setText("Bienvenue sur RLFind, votre meta-moteur de recherche pr\u00e9f\u00e9r\u00e9 !");

Hmmm pourquoi encoder les caractères accentués ?

String mediabarre = new String("...");

Alors je reviens là dessus : on ne fait jamais String s = new String("plop"); (ça crée un fait deux objets String, inutilement), mais String s = "plop" (un seul objet String créé, implicitement).

StringBuffer buffy=new StringBuffer("");

Pas besoin de créer une chaîne vide pour initialiser le StringBuffer, new StringBuffer() donnera le même résultat.

            Pattern p;

            Matcher m;

            p = Pattern.compile("...");

Vu que le pattern est immuable, il est préférable de le compiler une fois pour toute et non à chaque appel de la méthode jButton1ActionPerformed, en le déclarant comme attribut de classe contstant (static final). Pour les chaînes constantes, c'est aussi plus propre de faire comme ça.

p = Pattern.compile("dvd");

C'est une coquille, non ? Ça ne devrait pas être là ?

Bon, maintenant on va pouvoir commencer à regarder en détail :o

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 11:54. (lien). Évalué à 2.

Enfin, j'ai mis un peu de temps à te répondre à cause du déplacement de ton journal dans les forums (ce qui est quand même plus sa place).
Oui, c'est peut-être plus la place, mais ça serait bien que les modéros n'utilisent pas la fonction de déplacement avant de l'avoir débuggée : y a pas longtemps, le nombre de commentaires affiché ne prenait pas en compte les commentaires postés quand c'était encore un journal, et maintenant le changement efface les informations sur les commentaires lus/non lus, et du coup, la navigation avec la barre ne sert plus à grand chose :/

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 11:46. (lien). Évalué à 3.

C'est <pre> qui est utilisé, mais comme chaque retour chariot est doublé d'un <br/> (enfin j'ai pas vérifié mais ça y ressemble), bah y a une ligne sautée inutilement à chaque fois.
On peut les désactiver, mais ça devient pas pratique pour le texte qui entoure le code...
Faudrait ptet désactiver les retours chariot spécifiquement dans les <pre></pre> (ou utiliser une mise en syntaxe style wiki), mais je tiens trop à ce qu'il me reste de santé mentale pour me plonger dans le code templite et faire un patch :°)

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 17/09/2004 à 06:10. (lien). Évalué à 2.

Ah oui, 40 secondes, quand même ! Tu peux poster ton code final ?

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 16/09/2004 à 21:44. (lien). Évalué à 2.

Là ça vient clairement de ton code, y a pas photo :p
Et si tu veux faire un bench, fais bien attention de ne pas inclure le coût de la récupération du document par réseau, et aussi celui de l'interface graphique.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 16/09/2004 à 21:37. (lien). Évalué à 4.

Moi aussi, le passage

    BufferedReader plop = new BufferedReader(new InputStreamReader(doc1.openStream()));

    while((tmp=plop.readLine())!=null)

    {

        html = html + tmp;                

    }

    plop.close();   

me parait très sous-optimal, une boucle de lecture sur le InputStreamReader avec écriture vers un StringWriter, ça serait déjà moins violent. Bon, après , l'expression matchée tiens sur une ligne (ce qui a l'air d'être le cas), tester sur chaque ligne du BufferedReader, c'est effectivement encore mieux, ça évite de stocker tout le doc.

            String mediabarre = new String("http://mediabarre.2xmoinscher.com/DVD/liste.asp?strRech=(...(...))");

            String keywords=new String("robin des bois");

            keywords=URLEncoder.encode(jTextField1.getText());

            mediabarre = mediabarre + keywords;

Déjà, ça faut pas le laisser passer [:totoz]. Un String mediabarre = "http://mediabarre.2xmoinscher.com/DVD/liste.asp?strRech=(...(...))" + URLEncoder.encode(jTextField1.getText()); sera bien plus efficace. En particulier, les String truc = new String("bidule") sont à proscrire, String truc = "bidule" marchera aussi bien.

           while (m.find())

           {

               txt_resultat.setText(txt_resultat.getText().concat("Mediabarre : " + m.group(4) + " pour " + m.group(5) + "\n"));

           }

Ça aussi, il faut le revoir. La concaténation de chaînes était très coûteuse, les concaténations en boucle sont catastrophiques pour les perf :

           StringBuffer buffy = new StringBuffer();

           // ou StringBuffer buffy = new StringBuffer(txt_resultat.getText());

           while (m.find())

           {

               buffy.append("Mediabarre : ").append(m.group(4)).append(" pour ").append(m.group(5)).append('\n'));

           }

           txt_resultat.setText(buffy.toString());

devrait légèrement accélérer les choses (le compilo remplace String s = a + b par String s = new StringBuffer(a).append(b).toString();, il faut toujours l'avoir en tête), d'autant plus que l'interface n'aura pas à être raffraichie à chaque fois.

Voilà, c'est ce qui me saute aux yeux en première lecture.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 16/09/2004 à 17:03. (lien). Évalué à 2.

Non, je ne retrouve plus mes sources :(
Il audrait voir dans les articles de quand Intel a dévoilé le jeu d'instructions.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 15/09/2004 à 17:01. (lien). Évalué à 4.

Les DVD, le succes des DVD c'est le p0rn aussi :p

Et aussi du Minitel, de Canal+, ...
C'est le cul qui mène le monde.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 13/09/2004 à 13:07. (lien). Évalué à 8.

EMT64
Ceci est la réponse d'Intel à son concurrent direct puisqu'il s’agit de faire cohabiter 32 et 64 bits dans un même processeur (il me semble même que cette technologie a été rachetée à AMD, mais cette information est à prendre avec des pincettes).

Intel et AMD ont passé il y a quelques années un accord de licences croisées sur leurs technologies de l'époque et à venir. Ceci mettait fin à la tentative d'Intel d'empêcher AMD d'être compatible avec ses extensions multimédia SSE, contrée par AMD avec une plainte pour violation de brevets, si ma mémoire est bonne.
Donc Intel n'a rien à reverser à AMD pour cette techno (et d'ailleurs lors de sa présentation, il n'a même pas mis en avant la compatibilité (à une instruction près, qui ressemble à un oubli d'AMD) de sa techno avec celle d'AMD).

Intel annonce la virtualisation comme une avancée majeur dans le monde informatique.
Pour la microinformatique, peut-être :o

Outre ces avancées technologiques certaines, le site hardware.fr s’interroge sur les problèmes que peuvent engendrer ces évolutions
Ouais, on va les laisser avec leurs interrogations sans grand fondement.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 12/09/2004 à 19:52. (lien). Évalué à 4.

C'est vrai qu'il se donne du mal :o
Moi j'arriverai jamais à avoir autant de mauvaise foi, même en mettant beaucoup de c½ur à l'ouvrage. Il trolle sans répit, c'est qu'il en faut de l'endurance.
Par contre, il fait pas trop dans la dentelle, il trolle toujours comme un goray, on le voit venir à des kilomètres. Toujours le même style, reconnaissable entre mille, même quand il change de multi.
Donc à moins qu'il ne fasse de sérieux efforts pour troller plus subtilement (vu que c'est la rentrée, y a pas une école qui propose des cours ? l'Epita, peut-être ? :°), alors non, définitivement non, il ne sera jamais trolleur du mois ni de quoi que ce soit.

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 04/09/2004 à 16:33. (lien). Évalué à 2.

- rien ne les obligent, la freebox est toujours à eux, même si tu paie 400 euros
Certes, mais dans l'hypothèse (qui reste à vérifier) selon laquelle ils auraient modifié du code GPL sans partager leurs modifs, je ne suis pas sûr que ce code ne soit considéré comme diffusé vis-à-vis de la GPL

- divulger les sources, c'est anéantir tout leur travaille face à la concurrence
Bof, il doit y avoir beaucoup de choses liées au matériel, donc difficiles à réutiliser, et aussi beaucoup de choses qu'on trouve facilement ailleurs.

- divulger les sources, c'est rendre possible la diffusion du flux MPEG2 vidéo vers le PC, c'est permettre la copie numérique
Alors là rien n'est moins sûr que ce soit techniquement faisable, vu que le décodage est matériel. Et quand bien même quelqu'un modifierait le code pour balancer un flux MPEG vers un PC, il faudrait encore réussir à installer ce code sur la Freebox, et matériellement, ça me semble délicat.

c'est trahir la confiance que les fournisseurs de flux ont mis en eux (bah oui c'est pas pour rien si le flux vidéo ne sort qu'en péritel)
Euh oui, enfin il faut regarder aussi la liste des chaînes qui acceptent d'être diffusées (par rapport à celles accessibles sur le cable, le sat et les tv/adsl concurrents), et se demander pourquoi les équipements VOD que Free a achetés ne sont pas utilisés, pour avoir une idée de la confiance des producteurs de contenu envers Free ^^

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 04/09/2004 à 15:50. (lien). Évalué à 2.

Ça c'est des équipements en amont du DSLAM, pas dans la Freebox.
La liste des produits Anevia en atteste : http://www.anevia.com/products.en.php(...)

[ Répondre ]

Posté par Pierre Tramo (page perso, ) le 03/09/2004 à 21:14. (lien). Évalué à 2.

En même temps, c'est un macounet, rien d'étonnant à ce qu'il fasse preuve d'un goût plus que douteux.
Bon d'accord, là ça dépasse les limites du soutenable...

[ Répondre ]