Si mozilla et par extensions tous les navigateurs pouvaient commencer par s'adapter a l'environnement dans lequel il tourne, ca serait pas mal.
Est-ce que mozilla gere encore sa base de donnee mime de facon independante de Gnome et KDE ? Est-ce que leur theme s'integre dans Gnome et KDE ? Est-ce que leur structure de menu respecte le HIG de KDE et celui de Gnome ? J'ai l'impression qu'un gros travail d'integration reste encore a faire.
En fait, mozilla, c'est un peu emacs. C'est super bien mais ca s'utilise independamment de quoi que ce soit. Promouvoir ca professionnellement sans penser a s'integrer a l'environnement de bureau, c'est vraiment dommage.
Le pire, c'est pas les spams, c'est meme pas les virus que je recois, c'est le messages des anti-virus qui m'indiquent que j'ai envoye un virus a qq'un et qu'il a ete bloque.
C'est une horreur ce truc, ca veut dire que mon adresse email est utilisee comme faux envoyeur par des virus et donc je me prends un message d'erreur.
Comment mon addresse a-t-elle atteri dans un virus ?
Le probleme des spams, c'est pas tant de les recevoir la premiere fois, mais le fait de les recevoir en permanence. A mon avis, si je ne recevais chaque spam qu'une seule fois, le niveau de bruit serait largement acceptable.
la viagra -> viogra ne tient pas longtemp.
J'entraine mon filtre pour que tout spam passe une fois soit toujours reconnu en tant que spam la fois suivante. viogra passera la premiere fois mais ensuite aura la meme probabilite que viagra.
Cela dit, une correspondance approximative pourrait etre un ajout interessant a un logiciel anti-spam. Le probleme avec celui que j'utilise (bogofilter), c'est que les mots sont stockes dans une base de donnee et sont rapatries avec une correspondance exacte.
Pour foncitonner correctement, un algorithme approximatif devrait tester chaque mot recu avec une grande partie de tous les mots deja recus et donner un pourcentage de correspondance, et multiplier ca par le pourcentage de spamicite. Ca pourrait etre marrant en effet
Dans ce cas, tu peux taper dans les commandes ebuild. C'est un tout petit peu plus manuel mais ca marche aussi.
Typiquement, ca m'est arrive une ou deux fois de terminer des installations avec des build compile install qmerge. Ce que je ne comprends pas, c'est que ca a marche alors que c'est exactement les memes etapes qui sont effectuees quand on tape emerge toto.
Ca m'est aussi arrive de terminer la compilation a la main (cd /var/tmp/portage/work/my-app; make) alors qu'elle avait echoue en automatique et de finir avec un emerge qmerge.
Sinon, le vrai probleme de gentoo, c'est la gestion de la responsabilite des package un peu trop legere ou trop lourde. Il faudrait clairement un systeme a la debian avec des mainteneurs nombreux et identifies, des guides de qualite pour faire un ebuild, des responsables reactifs et des inclusions plus rapides des paquets qui sont stables.
Je rage de voir que KDE 3.2.2 n'est toujours pas dans gentoo stable alors que toutes les autres distrib l'ont deja. M'est avis que le pauvre Caleb est depasse.
Le langage presentes des aspects interessants mais l'histoire nous montre que les foncitonnalites d'un langage ne definissent pas son succes.
Moi ce qui m'epate ici, c'est la tenacite de l'auteur. Mine de rien, il s'est developpe a lui tout seul un compilateur C, un compilateur C++ et maintenant, un compilateur D et le langage complet avec des constructions qui sont loin d'etre triviales. Il en faut de l'investissement pour arriver a un tel resultat.
Son compilateur C++ etait tres bien classe dans une comparaison des compilateurs les plus conformants au standard C++ (d'apres une etude du DDJ) et pas mal au niveau perf.
Moi je dis: Messieurs, chapeau bas! [comme dans "La Peste"]
Je ne me plains pas, je ne l'ai jamais utilise ni mesure. En revanche, je sais que KDE a gagne du temps en optimisant la lecture de ses fichiers de conf et je ne vois pas de raisons pourquoi gnome n'aurait pas le me me probleme.
Si tu tapes dans une appli moyenne, tu atteinds vite la centaine de cle de configuration donc autant de xml a lire.
5 a 10 ms, je crois que c'est le temps pour lire toutes les config de tout KDE sur un ordinateur et disque dur lent. Ca inclut pas mal de fichiers differents. Si t'es vraiment inferieur a la ms sur ton temps de parsing, ca ne genera pas. Attention quand meme car l'utilisateur percoit un temps a partir de 50 ms a peu pres.
j'ai verifie, mes flags de compile sont ok, mes sources sont en phase avec mes binaires, je vois pas d'ou ca vient.
en fait, les limitations des logiciels dependant vachement de la facon dont tu les utilises. La facon dont j'utilise le debugger de visual ne m'a pas montre de limitations, alors que la facon dont j'utilise gdb oui.
Sous gdb, break my_class::my_method() ne marche toujours pas pour moi. J'en suis encore a mettre des no de lignes.
> Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
Parfois tu as des compilateurs vraiment pourri. Prenons au hasard Visual C++ (le meme qui est super rapide):
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.
Mais oui. Et chaque changement de compilateur est un nouvel exploit pour chaque distrib, surtout quand ces messieurs de gcc s'amusent (si on peut dire) a retirer des trucs qui marchaient avant.
Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4 . Voila comment l'exploit se realise. Mais c'est pour la bonne cause, c'est pour le standard.
Je ne suis pas alle voir mais je suis sur que sur kde-core-devel, ils discutent deja des nouvelles perfs et du code qu'il faut corriger pour passer sur gcc 3.4 . Ce temps aurait pu etre investi a corriger des bugs mais rien n'est plus important que de respecter le standard du C++.
J'espere pour Soustroup qu'il verra avant sa mort un compilateur qui respecte le standard qu'il a ecrit. Sinon, ca serait triste pour lui quand meme.
Tout ca est vrai. Notamment avec boost, visual souffre pas mal.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.
Le probleme des standards ne se limite pas a l'axiome "tu dois respecter les standards". Je bosse par exemple dans un milieu (la carte a puce sans-contact) ou les mecs qui ecrivent les standards sont malheureusement un peu trop chercheurs. Ils ont plein de bonnes idees qui sont irrealisables techniquement, mais qui passent dans les standards. Resultat, le standard est impossible a implementer avec la techno d'aujourd'hui.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).
> Mouais... Comparé au temps d'accés à ton fichier de conf, le parsing xml
> est probablement pas très couteux.
Chaque microseconde compte parce que beaucoup de fichiers sont lu avant qu'une application puisse se lancer. Typiquement, tu lances KDE:
- dcop lit son fichier de conf
- sycoca lit son fichier de conf
- kwin lit son fichier de conf
Ensuite, tu lances konqueror:
- il lit tout son fichier de conf et l'interpret
- il charge khtml qui va faire de meme
En faisant des optimisations simples sur les fichiers de conf (le charger tout d'un coup, ne faire la conversion unicode qu'au dernier moment, n'interpreter que la cle qu'on recherche, ...), KDE avait divise par 5 le temps subjectif de chargement d'une application (temps subjectif au sens ou c'est le temps ou l'utilisateur a l'impression qu'il se passe qqch). Pourtant, c'etait avec un format hyper-simple style .ini
Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
Il pense probablement a la DLL de windows gerant les styles sous windows XP. La dependance est configurable donc ca n'est pas un obstacle pour livrer Qt4 sous windows.
kconfig permet en effet de verouiller des cles pour non-modification.
Il fait la fusion entre un fichier de conf global et un fichier de conf local
Lors d'une modif, il ne va enregistrer la modif que si elle differe de la config par defaut.
Il s'appuie sur le filesystem pour stocker les fichiers de config. Le demon ksycoca utilise libfam (file access monitoring) pour noter les changements et les notifie via dcop.
Comme il s'appuie sur le systeme de fichier, c'est relativement simple de centraliser une config sur un serveur: tu montes un repertoire KDE par nfs.
Apres, pour les autres possibilites de gconf, je pense pas que kconfig fasse. Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.
faut voir que la versoin KDE n'est qu'un frontend. Le langage de script est integre au backend (libyzis) qui lui ne depend pas de KDE. On verra au moment ou on fait ca mais il est hors de question que libyzis depende de KDE. Si on peut extraire kjsembed, ca peut valoir le coup.
L'avantage de lui, c'est qu'il est vraiment developpe pour etre embarque facilement. Je sais pas si c'est le cas de kjsembed.
quand tu dis une ou deux touches, tu comptes les alt/meta/esc/ctrl/shift ? Parce que c'est justement le genre de touche difficile d'acces sur un clavier, qui vont augmenter les symptomes: tu es oblige de te tordre legerement la main pour y acceder.
Si on y reflechit, les touches de controle devraient etre au milieu du clavier.
Aller, quelques exemples:
- avancer d'un mot: vi=w, emacs=C-F soit 1 vs 2
- sauver le buffer courant: vi=:w, emacs=C-X C-S soit 2 vs 4
- debut de phrase: vi=0, emacs=C-A soit 1 vs 2
- quitter sans sauver: vi=:q!, emacs=C-X C-C n soit 3 vs 5
etc etc
La ou emacs assure, c'est sur la richesse des fontionnalites. Le chercher/remplacer gere aussi mieux les majuscules et le yanking ring est vraiment un paradis (M-Y pour ceux qui voient pas ce que c'est).
Euh, l'editeur parfait suscite, est-ce que les developpeurs ont enfin realise que vouloir modifier une option de config et coder en lisp sont deux choses differentes et que la premiere ne devrait pas implique la seconde ?
Sinon, pour faire dans le troll vi/emacs, un des trucs que j'apprecie dans vi, c'est que beaucoup de fonctions sont accessibles avec simplement une touche du clavier. C'est difficile de s'y faire quand on debute, mais un des avantages, c'est qu'on bouge tres peu les doigts pour executer une action. Sous un editeur classique (et emacs ne fait pas exception), les actions complexes doivent etre activees par une combinaison de touches. Donc d'une part ca prend plus de temps, d'autre part (j'eviterai le troll Esc-Meta-Alt-Ctrl-Shift), cela fatigue plus les doigts. Ce dernier point est significatif pour des gens tapant beaucoup au clavier et souffrant de RSI (repetitive strain injury, blessure liee a des gestes reptitifs) ou de carpal tunnel (traduction wanted).
Reflechissez-y les jeunes quand se posera la question la plus importante de votre vie: "est-ce que j'apprend vi ou emacs ?"
[^] # Re: Mozilla et Gnome, main dans la main ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Mozilla et Gnome, main dans la main ?. Évalué à 2.
Est-ce que mozilla gere encore sa base de donnee mime de facon independante de Gnome et KDE ? Est-ce que leur theme s'integre dans Gnome et KDE ? Est-ce que leur structure de menu respecte le HIG de KDE et celui de Gnome ? J'ai l'impression qu'un gros travail d'integration reste encore a faire.
En fait, mozilla, c'est un peu emacs. C'est super bien mais ca s'utilise independamment de quoi que ce soit. Promouvoir ca professionnellement sans penser a s'integrer a l'environnement de bureau, c'est vraiment dommage.
[^] # Re: Mozilla et Gnome, main dans la main ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Mozilla et Gnome, main dans la main ?. Évalué à 5.
Oh, ca existe deja!
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/kaxul/README?re(...)
Ils sont vraiment trop forts chez KDE
[^] # Re: Je filtre mes mails avec
Posté par Philippe F (site web personnel) . En réponse au sondage Je filtre mes mails avec. Évalué à 1.
C'est une horreur ce truc, ca veut dire que mon adresse email est utilisee comme faux envoyeur par des virus et donc je me prends un message d'erreur.
Comment mon addresse a-t-elle atteri dans un virus ?
[^] # Re: Je filtre mes mails avec
Posté par Philippe F (site web personnel) . En réponse au sondage Je filtre mes mails avec. Évalué à 1.
la viagra -> viogra ne tient pas longtemp.
J'entraine mon filtre pour que tout spam passe une fois soit toujours reconnu en tant que spam la fois suivante. viogra passera la premiere fois mais ensuite aura la meme probabilite que viagra.
Cela dit, une correspondance approximative pourrait etre un ajout interessant a un logiciel anti-spam. Le probleme avec celui que j'utilise (bogofilter), c'est que les mots sont stockes dans une base de donnee et sont rapatries avec une correspondance exacte.
Pour foncitonner correctement, un algorithme approximatif devrait tester chaque mot recu avec une grande partie de tous les mots deja recus et donner un pourcentage de correspondance, et multiplier ca par le pourcentage de spamicite. Ca pourrait etre marrant en effet
[^] # Re: "not for profit"
Posté par Philippe F (site web personnel) . En réponse à la dépêche Distribution Gentoo : des nouvelles du front. Évalué à 2.
Typiquement, ca m'est arrive une ou deux fois de terminer des installations avec des build compile install qmerge. Ce que je ne comprends pas, c'est que ca a marche alors que c'est exactement les memes etapes qui sont effectuees quand on tape emerge toto.
Ca m'est aussi arrive de terminer la compilation a la main (cd /var/tmp/portage/work/my-app; make) alors qu'elle avait echoue en automatique et de finir avec un emerge qmerge.
Sinon, le vrai probleme de gentoo, c'est la gestion de la responsabilite des package un peu trop legere ou trop lourde. Il faudrait clairement un systeme a la debian avec des mainteneurs nombreux et identifies, des guides de qualite pour faire un ebuild, des responsables reactifs et des inclusions plus rapides des paquets qui sont stables.
Je rage de voir que KDE 3.2.2 n'est toujours pas dans gentoo stable alors que toutes les autres distrib l'ont deja. M'est avis que le pauvre Caleb est depasse.
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 1.
Moi ce qui m'epate ici, c'est la tenacite de l'auteur. Mine de rien, il s'est developpe a lui tout seul un compilateur C, un compilateur C++ et maintenant, un compilateur D et le langage complet avec des constructions qui sont loin d'etre triviales. Il en faut de l'investissement pour arriver a un tel resultat.
Son compilateur C++ etait tres bien classe dans une comparaison des compilateurs les plus conformants au standard C++ (d'apres une etude du DDJ) et pas mal au niveau perf.
Moi je dis: Messieurs, chapeau bas! [comme dans "La Peste"]
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
Je ne me plains pas, je ne l'ai jamais utilise ni mesure. En revanche, je sais que KDE a gagne du temps en optimisant la lecture de ses fichiers de conf et je ne vois pas de raisons pourquoi gnome n'aurait pas le me me probleme.
Si tu tapes dans une appli moyenne, tu atteinds vite la centaine de cle de configuration donc autant de xml a lire.
5 a 10 ms, je crois que c'est le temps pour lire toutes les config de tout KDE sur un ordinateur et disque dur lent. Ca inclut pas mal de fichiers differents. Si t'es vraiment inferieur a la ms sur ton temps de parsing, ca ne genera pas. Attention quand meme car l'utilisateur percoit un temps a partir de 50 ms a peu pres.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
en fait, les limitations des logiciels dependant vachement de la facon dont tu les utilises. La facon dont j'utilise le debugger de visual ne m'a pas montre de limitations, alors que la facon dont j'utilise gdb oui.
Sous gdb, break my_class::my_method() ne marche toujours pas pour moi. J'en suis encore a mettre des no de lignes.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.
[^] # Re: Sortie de GCC 3.4.0
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
Le resultat, c'est que des tas de projet vont passer du temps a corriger les problemes de compilation lie a gcc 3.4 . Voila comment l'exploit se realise. Mais c'est pour la bonne cause, c'est pour le standard.
Je ne suis pas alle voir mais je suis sur que sur kde-core-devel, ils discutent deja des nouvelles perfs et du code qu'il faut corriger pour passer sur gcc 3.4 . Ce temps aurait pu etre investi a corriger des bugs mais rien n'est plus important que de respecter le standard du C++.
J'espere pour Soustroup qu'il verra avant sa mort un compilateur qui respecte le standard qu'il a ecrit. Sinon, ca serait triste pour lui quand meme.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 1.
ddd a des trucs un peu chiant (l'idee de sauver toutes les sessions avec un no a 25 chiffres) mais est quand meme bien pratique.
Sinon, quelqu'un sait ou trouver le plugin python pour ddd ? J'ai trouve des liens qui en parlent sur internet mais impossible de trouver ou il est.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
> est probablement pas très couteux.
Chaque microseconde compte parce que beaucoup de fichiers sont lu avant qu'une application puisse se lancer. Typiquement, tu lances KDE:
- dcop lit son fichier de conf
- sycoca lit son fichier de conf
- kwin lit son fichier de conf
Ensuite, tu lances konqueror:
- il lit tout son fichier de conf et l'interpret
- il charge khtml qui va faire de meme
En faisant des optimisations simples sur les fichiers de conf (le charger tout d'un coup, ne faire la conversion unicode qu'au dernier moment, n'interpreter que la cle qu'on recherche, ...), KDE avait divise par 5 le temps subjectif de chargement d'une application (temps subjectif au sens ou c'est le temps ou l'utilisateur a l'impression qu'il se passe qqch). Pourtant, c'etait avec un format hyper-simple style .ini
Avec un fichier xml, le temps de chargement est necessairement plus long et les applications en patissent.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 6.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 2.
[^] # Re: Qt 4 à l'horizon !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Qt 4 à l'horizon !. Évalué à 1.
Il fait la fusion entre un fichier de conf global et un fichier de conf local
Lors d'une modif, il ne va enregistrer la modif que si elle differe de la config par defaut.
Il s'appuie sur le filesystem pour stocker les fichiers de config. Le demon ksycoca utilise libfam (file access monitoring) pour noter les changements et les notifie via dcop.
Comme il s'appuie sur le systeme de fichier, c'est relativement simple de centraliser une config sur un serveur: tu montes un repertoire KDE par nfs.
Apres, pour les autres possibilites de gconf, je pense pas que kconfig fasse. Le xml est une tres mauvaise idee car les fichiers de conf doivent etre lus tres tres vite, ce qui est incompatible avec le parsage de xml.
[^] # Re: Une release importante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 3.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.
[^] # Re: Yzis, un nouveau clone de vi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
L'avantage de lui, c'est qu'il est vraiment developpe pour etre embarque facilement. Je sais pas si c'est le cas de kjsembed.
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 1.
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
Si on y reflechit, les touches de controle devraient etre au milieu du clavier.
Aller, quelques exemples:
- avancer d'un mot: vi=w, emacs=C-F soit 1 vs 2
- sauver le buffer courant: vi=:w, emacs=C-X C-S soit 2 vs 4
- debut de phrase: vi=0, emacs=C-A soit 1 vs 2
- quitter sans sauver: vi=:q!, emacs=C-X C-C n soit 3 vs 5
etc etc
La ou emacs assure, c'est sur la richesse des fontionnalites. Le chercher/remplacer gere aussi mieux les majuscules et le yanking ring est vraiment un paradis (M-Y pour ceux qui voient pas ce que c'est).
[^] # Re: Et pendant ce temps dans le petit monde de Emacs...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Yzis, un nouveau clone de vi. Évalué à 2.
Sinon, pour faire dans le troll vi/emacs, un des trucs que j'apprecie dans vi, c'est que beaucoup de fonctions sont accessibles avec simplement une touche du clavier. C'est difficile de s'y faire quand on debute, mais un des avantages, c'est qu'on bouge tres peu les doigts pour executer une action. Sous un editeur classique (et emacs ne fait pas exception), les actions complexes doivent etre activees par une combinaison de touches. Donc d'une part ca prend plus de temps, d'autre part (j'eviterai le troll Esc-Meta-Alt-Ctrl-Shift), cela fatigue plus les doigts. Ce dernier point est significatif pour des gens tapant beaucoup au clavier et souffrant de RSI (repetitive strain injury, blessure liee a des gestes reptitifs) ou de carpal tunnel (traduction wanted).
Reflechissez-y les jeunes quand se posera la question la plus importante de votre vie: "est-ce que j'apprend vi ou emacs ?"