Il y a d'autres forks relativement reussis :
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore
- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.
Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.
icescream a ete developpe par un gourou KDE (Stephan Kulow) et marche super bien. Pas une seule reuninon KDE ou les developpeurs ne commencent pas par deployer du icescream partout. Je suis surpris de ne pas le voir cite.
Petite copie de la partie interessante :
============================================
I use distcc, why should I change?
If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:
* you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
* you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
* you don't know what machines will be on-line at compile time.
* most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
* you like nice compile monitors :)
============================================
Je ne sais pas pour vous, mais la mise a disposition gratuite d'un service autrefoir payent, ce que ca m'insipre, c'est que le service payant n'a pas marche et qu'ils essaient de relancer la machine.
Ca fait longtemp qu'on entend plus parler du mandrake club, est-ce que ca tourne toujours ?
La news, c'est pour dire que beagle est capable d'analyser les messages et les contacts de thunderbird ?
Baleze, vraiment vraiment. Les messages sont au format mbox, qui est plus que trivial a analyser (je bourre tous les messages en texte dans un fichier), surtout quand on a fait le format maildir auparavant (un message par fichier texte dans un repertoire). Et les contacts sont au format vcard (du texte encore). Donc en fait, beagle est maintenant capable d'analyser des fichiers textes. Moi, ca m'impressionne :-)
Bon, plaisanterie a part, c'est sympa de voir ce projet avancer et j'imagine qu'il y a plus que l'indexation de fichier texte dans l'integration thunderbird. Mais ca ne ressort pas trop dans la news.
En fait, ce serait pas plus simple d'utilier Qt Designer avec une bonne transformation XSLT ? Ou bien carrement de faire un gtk-uic qui transforme la description xml de Qt Designer en implemntaion Gtk ? 99% des widgets Qt sont presents sous Gtk donc ca devrait pas etre si difficile.
Qt Designer est en GPL, ce serait pas difficile de le faire evoluer pour supporter du Gtk. Il fait deja l'import des fichiers glade de la version precedente :-)
Sans oublier la fonctionnalite de base qui manque cruellement a Sunbird: popup 1/4 heure avant le debut de la reunion, ou insertion dans l'agenda quasi automatique depuis le client mail. Ou encore possibilite pour des externes (secretaire, collegue) de te caser une reunion dans ton agenda, etc etc.
Pour ma boite, je cherchais un client windows libre quelconque mais fonctionnel (== pas une interface web) pour fonctionner avec un serveur libre quelconque sous Linux. La conclusion a ete que le plus fonctionnel etait probablement outlook avec un truc genre kolab. Plutot deprimant. Le probleme notamment, c'est que charger oulook + thunderbird en memoire, c'est vraiment du gachis de resources. Vivement kontact sous windows.
En fait, la conclusion de notre analyse a surtout ete qu'on manquait cruellement de standard en matiere de gestion d'agenda. Il y a bien les trucs genre iCal mais c'est pour formatter les inforamations sur un rendez-vous, pas pour definir la facon de se connecter a un serveur.
Tant qu'on aura pas un "Calendaring Transfer Protocol", les developpements auront du mal a se se focaliser sur un client de bonne qualite et on restera avec des solutions dispersees et de qualite moyenne voire pitoyables.
Justement parce que les fonctionnalites sont equivalentes, ce n'est pas possible d'envisager une convergence. Ca voudrait dire que l'un des deux projets doit abandonner son moteur, ce qui est inenvisageable. Je ne vois pas Gtk se mettre a dependre de Qt et je ne vois pas Trolltech adopter une technologie externe alors qu'elle a tant investi sur X et Qt.
A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.
Et pour ceux qui poseraient la question "quand est-ce que KDE va l'utiliser ?" ou "si Qt l'utilisait aussi, ce serait top", je vous informe que Qt possede un moteur de rendu qui fait exactement la meme chose que Cairo, mais qui s'appelle Arthur. Export SVG, rendu sur OpenGl, export PDF via backend d'impression, etc etc.
Je me demande toujours pourquoi les gens font un tel blocage sur l'allemand. La grammaire complete est au final plus simple que la grammaire anglaise, ou que la grammaire francaise. Tous les mots se prononcent comme ils s'ecrivent contrairement au francais qui rajoute des lettre en plus, ou a l'anglais qui a une difficulte de prononciation assez incroyable.
Juste pour rire, prononcez les deux phrases suivantes :
- I read it and I cut it
- I read it and I cut it
L'une est au passe, l'autre au present, meme si ca ne se voit pas. Dans celle qui est au passe, "read" se prononce comme dans "mer" et au present comme dans "riz".
Apres ca, on veut nous faire croire que l'anglais est simple. L'anglais n'a qu'une qualite indeniable, c'est qu'il est concis. Il ne sait battre que par le chinois.
Pour la tele, si tu es abonne au cable, tu as un certain nombre de chaines qui diffusent en anglais ou francais, avec choix des sous-titres en anglais ou en francais. Pour ma part, j'aime bien jimmy et comedie, qui diffusent en plus a l'occasion des series de tres bonne qualite (celles qui m'ont plu : six feet under, queer as folk, the shield, star trek enterprise, six sexy).
<<
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.
<< Sinon, ces optimisations post-génération de code exécutables sont quand même applicables aux machines physiques ? >>
C'est plus ou moins ce qu'a fait transmeta avec son code morphing. Au final, c'etait beaucoup plus lent qu'un processeur pur.
<<
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
>>
Et on en revient a la necessite d'avoir une grammaire du langage de programmation qui soit suffisamment expressive. Sinon, ces optimisations sont tres difficiles a mettre en oeuvre.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
<<
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
>>
C'est tres proche de ce que fait le compilateur OCaml. C'est d'ailleurs ce qui explique malgre un langage "loin de la machine", il arrive a de tres bonne perfs : il y a une analyse de code tres poussee derriere qui va bien chercher les optimisations.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
Et pourtant, je ne crois pas que OCaml soit "proche de la machine".
De meme, IronPython, une version de python ecrite pour le CLR de C# est plus rapide que la version de python en C.
Le C se prete bien a certaine manipulations mais pour des gros programme, je suis persuade qu'un langage qui expose correctement les intentions du programmeur dans sa grammaire pourra a terme etre mieux optimise par un bon compilateur. Le C et le C++ ont ce probleme que leur grammaire est complexe, avec des manipulations qui cachent ce que veut faire le developpeur. Au final, une information est perdue, celle de l'intention du programmeur et les optimisations sont donc limitees dans la mesure de l'expressivite du langage.
Si on regarde Java ou C#, on trouve plein d'outils de refactoring, d'analyseurs de code, de programmation oriente aspect, etc etc. La richesse de ces outils vient du fait que ces langages exposent une grammaire plus facile et que les outils annexes peuvent mieux comprendre et aider le programmeur.
Un tel systeme demandera a priori une gestion relativement specifique au moins pour dire qu'on ouvre les fichiers en mode asynchrone et non synchrone.
Donc au final, c'est l'application qui doit s'adapter et tu perds l'avantage de la transparence du systeme. Sous KDE, toutes les applications sont deja adaptees a ces problemes. Et KDE n'a eu besoin de demander l'autorisation de personne (Linus, ...) pour le mettre en place et le tester.
Un autre probleme de monter des repertoires distants via le kernel, c'est que l'api pour travailler sur les fichiers (open,read,write,close) suppose en permanence que la lecture d'un fichier est tres rapide, qu'en cas de probleme, tu as une erreur immediatement et que tous les appels sont synchrones (je bloque tant que je n'ai pas de reponse).
Utilise une telle API pour des lecteurs qui peuvent etre tres lent, ou la connection peut carrement etre perdue a tout moment donne un tres mauvais resultat. Des que tu as une operation lente, il veut mieux la faire de facon asynchrone et garder la main sur la partie visuelle de l'application, en proposant un dialogue permettant d'arreter immediatement l'operation en cours.
Si tu as deja utilise un disque dur foireux ou tu fais un ls et tu attends deux minutes sans rien pouvoir faire, tu as une idee de ce que peut etre la latence sur un systeme de fichier monte a distance : super penible.
En fait, tu ne peux pas concevoir une application qui travaille sur un systeme de fichier ayant des caracteristiques reseau (latence, perte de connection) sans integrer ce parametre dans ton application.
Donc les fuse-ioslave, ca peut resoudre qqs problemes pratiques mais ce n'est pas la panacee.
Et donc, tu peux utilsier tous les ioslave KDE sous bash.
Dans la pratique, ce n'est pas tres pratique donc pas tres utilise.
Il y a eu une enfilade de deux mois sur un VFS commun entre Gnome et KDE sur la liste freedesktop. Pour resumer, le VFS de Gnome est moins mature a l'heure actuelle que celui de KDE (bien qu'il semble y avoir des trucs plus interessants sous certains aspects) et il y a enormement de problemes techniques pour la realisation.
Ensuite viendrait la question de ce qui pourrait pousser une desktop comme KDE qui a une solution robuste et eprouvee depuis maintenant 5 ans pour passer a un truc inferieur (moins de ioslave que sous KDE) et mal teste. Ca arrivera surement mais ce ne se fera pas simplement.
Bref, je ne critique pas le fait d'unifié les systèmes, je critique le fait que gnome et kde ont par le passé unifié leur système respectif mais par la même un peu exclu le reste.
J'avais tendance a penser comme toi mais en fait, l'experience montre que c'est la voie naturelle. Tu ne peux pas commencer a prevoir l'integration dans un autre environnement que le tien tant que tu n'as pas essaye la solution d'abord chez toi.
Pour le coup des framework VFS, Gnome est arrive tres en retard sur KDE et a fait un truc different, avec des URLs incompatibles avec celle de KDE.
Si on prend l'exemple de DCOP et DBUS, la situation est relativemetn similaire. D'abord on valide une solution qui marche (DCOP) puis on derive qq chose qui va plus loin (DBUS). Si tu essayes de faire DBUS du premier coup, tu n'y arrveras jamais.
Il y a scite qui est assez connu et marche meme sous windows. Il y a plein de mecs dans ma boite qui l'utilisent pour editer et executer du python.
Je pense qu'en fait pour les gens qui editent vraiment _beaucoup_, un gain de productivite meme leger represente un confort important, et que c'est ce qui les conduits a des editeurs comme vim ou emacs, qu'ils defendent avec ardeur.
Tu as raison. Ce qui reste interessant tout de meme, c'est que comme tu le constates, je suis loin d'utiliser toute la puissance de vi. Et pourtant, c'est deja suffisant pour moi pour creer un gain de productivite significatif.
Pour mon cas particulier, aller cherche l'accolade, c'est un shift plus la touche a cote de (je suis en clavier americain), ce qui veut dire deux utilisations du petit doigt droit et gauche. C'est un mouvement plutot difficile et fatiguant, ce qui fait que je ne l'utilise pas souvent.
Pour les jjjjj, pour moi, c'est plus rapide de les taper que de compter le nombre de lignes a l'ecran, de taper le nombre puis de taper j.
Un des gros avantages de vim que j'apprecie personellement (et qui est au passage le truc le plus deroutant pour les debutants), c'est qu'il y a deux modes d'editions :
- un mode ou le texte que tu tapes est insere, comme sur Kate ou les autres editeurs classiques
- un mode ou chaque touche correspond en fait a une action, que tu lancerais sur les autres editeurs via des combinaisons de Control ou ALT.
Ce second mode permet d'effectuer des actions complexes en laissant tes doigts a des emplacements faciles a joindre sur le clavier. D'une part, c'est moins fatiguant pour les mains, d'autre part, c'est beaucoup plus rapide.
Exemple, tu veux faire un copier/ colle :
- Kate version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste
- Kate version clavier : tu selectionnes le texte, tu fais Control-C, tu scrolles ton texte avec Page-Down et Cursor-Down, tu fais Control-V
- Vi version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste (a noter que c'est la meme chose que Kate version souris)
- Vi version clavier : tu demarra ta selection de texte avec V. Tu deplace ton curseur avec la touche kjhl pour contenir toutes les lignes que tu veux selectionner. Tu tapes y pour faire la copie. Tu te deplace a coup de page-up ou page-down (j'ai jamais pu me rappeler le racourci pour les sauts de pages), tu positionnes ton curseur avec les touches khjl et tu tapes P.
Si on compare kate et vi au clavier, on pourrait imaginer la suite de touches suivantes :
[Down]
[Down]
Control-[Right]
Control-[Right]
[Shift appuye]
[Down]
[Down]
Control-C
[Page-Down]
[Page-Down]
[Down]
[Down]
Control-V
et
j
j
w
w
v
j
j
y
[Page-Down]
[Page-Down]
j
j
p
Tu notes que les touches vi sont plus faciles a taper. A noter aussi que vi est relativement compatible avec un mode d'edition a la kate, de sorte qu'on peut envisager un apprentissage plus lent des foncitonnliates specifiques vi (par exemple, se deplacer au curseur plutot qu'avec jkhl).
On n'a pas la meme definition d'alourdir. Si je suis ton raisonnement, tout ce qui n'est pas ecrit en assembleur est lourd.
Je trouve que tu utilises un vocabulaire imprecis et une analyse hyper theorique eloignee des realites pratiques et des problematiques reelles, ce qui conduit a des conclusions qui sont a mon sens plutot denudees de justesse.
Derriere le vocable fourre-tout "ajouter une couche", il y a differentes operations possibles, l'une pouvant ralentir de facon signficatives les performances du programme et meme en affecter le fonctionnement (genre rajouter xine au dessus de alsa) et l'autre a un impact negligeable (ajouter un ou deux appels de fonctions pour acceder a le meme fonctionnalite).
Je ne sais pas ou tu as lu que KDE ne pretend pas a la legerete (peut-etre dans le marketing de Gnome ?) mais ce n'est pas du tout le cas. Toutes les versions de KDE depuis la 2.0 sont plus rapides les unes que les autres et consomment moins en memoire.
La convivialite est en revanche une preoccupation importante de KDE et si cela veut dire "alourdir" le protocole ssh en "rajoutant une couche" avec kio pour que ce soit plus convivial, ca me semble une bonne chose.
Juste pour rire, est-ce que qq'un a deja note que fish: etait plus lent que scp ? Est-ce que qq'un a deja eu un probleme de ce style au point de vouloir supprimer fish ?
[^] # Re: Super !
Posté par Philippe F (site web personnel) . En réponse à la dépêche cdrkit : Debian forke cdrtools. Évalué à 2.
- XEmacs : l'original et le fork cohabitent plus ou moins bien encore
- gcc : la fork a remplace l'original au bout d'un moment. Si je me souviens bien, c'etait sur des histoires de support de l'objet a un moment ou RMS preferait que gcc ne fasse que du C.
Par contre, il y a des millards de forks rates. C'est _difficile_ de faire vivre un projet et nombreux sont les naifs qui pensent y arriver tout seul.
[^] # Re: autre alternative: icecream
Posté par Philippe F (site web personnel) . En réponse à la dépêche Compilation distribuée avec distcc / dmucs. Évalué à 2.
La page web: http://en.opensuse.org/Icecream
(l'url du commentaire plus haut a une parenthese en trop)
Petite copie de la partie interessante :
============================================
I use distcc, why should I change?
If you're sitting alone home and use your partner's computer to speed up your compilation and both these machines run the same Linux version, you're fine with distcc (as 95% of the users reading this chapter will be, I'm sure). But there are several situations, where distcc isn't the best choice:
* you're changing compiler versions often and still want to speed up your compilation (see the ICECC_VERSION support)
* you got some neat PPC laptop and want to use your wife's computer that only runs intel (see the cross compiler section)
* you don't know what machines will be on-line at compile time.
* most important: you're sitting in a office with several co-workers that do not like if you overload their workstations when they play doom (distcc doesn't have a scheduler)
* you like nice compile monitors :)
============================================
# Linspire, un succes ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linspire offre Freespire et son service en ligne. Évalué à 1.
Ca fait longtemp qu'on entend plus parler du mandrake club, est-ce que ca tourne toujours ?
# Hum
Posté par Philippe F (site web personnel) . En réponse à la dépêche Beagle 0.2.8 : prise en charge de Thunderbird. Évalué à 7.
Baleze, vraiment vraiment. Les messages sont au format mbox, qui est plus que trivial a analyser (je bourre tous les messages en texte dans un fichier), surtout quand on a fait le format maildir auparavant (un message par fichier texte dans un repertoire). Et les contacts sont au format vcard (du texte encore). Donc en fait, beagle est maintenant capable d'analyser des fichiers textes. Moi, ca m'impressionne :-)
Bon, plaisanterie a part, c'est sympa de voir ce projet avancer et j'imagine qu'il y a plus que l'indexation de fichier texte dans l'integration thunderbird. Mais ca ne ressort pas trop dans la news.
[^] # Re: Tasks
Posté par Philippe F (site web personnel) . En réponse à la dépêche Trois médailles pour la France aux Olympiades Internationales d'Informatique. Évalué à 2.
http://www.topcoder.com/tc
[^] # Re: à tester
Posté par Philippe F (site web personnel) . En réponse à la dépêche Glade 3 : l'échappée belle. Évalué à 0.
Qt Designer est en GPL, ce serait pas difficile de le faire evoluer pour supporter du Gtk. Il fait deja l'import des fichiers glade de la version precedente :-)
[^] # Re: Toujours le même problème
Posté par Philippe F (site web personnel) . En réponse à la dépêche Agenda partagé : des solutions. Évalué à 5.
Pour ma boite, je cherchais un client windows libre quelconque mais fonctionnel (== pas une interface web) pour fonctionner avec un serveur libre quelconque sous Linux. La conclusion a ete que le plus fonctionnel etait probablement outlook avec un truc genre kolab. Plutot deprimant. Le probleme notamment, c'est que charger oulook + thunderbird en memoire, c'est vraiment du gachis de resources. Vivement kontact sous windows.
En fait, la conclusion de notre analyse a surtout ete qu'on manquait cruellement de standard en matiere de gestion d'agenda. Il y a bien les trucs genre iCal mais c'est pour formatter les inforamations sur un rendez-vous, pas pour definir la facon de se connecter a un serveur.
Tant qu'on aura pas un "Calendaring Transfer Protocol", les developpements auront du mal a se se focaliser sur un client de bonne qualite et on restera avec des solutions dispersees et de qualite moyenne voire pitoyables.
[^] # Re: GNUstep
Posté par Philippe F (site web personnel) . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 2.
A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.
Pour dbus, on note son arrivee dans Qt 4.2 :
http://doc.trolltech.com/4.2/qtdbus.html
[^] # Re: GNUstep
Posté par Philippe F (site web personnel) . En réponse à la dépêche Cairo 1.2 met le feu. Évalué à 3.
[^] # Re: Licence
Posté par Philippe F (site web personnel) . En réponse à la dépêche PyQt v4 et Python 2.5 beta 1. Évalué à 6.
[^] # Re: Bientot sur commodore 64 ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche XMoto 0.1.16 est sorti !. Évalué à 3.
[^] # Re: Bogue...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 5.
Juste pour rire, prononcez les deux phrases suivantes :
- I read it and I cut it
- I read it and I cut it
L'une est au passe, l'autre au present, meme si ca ne se voit pas. Dans celle qui est au passe, "read" se prononce comme dans "mer" et au present comme dans "riz".
Apres ca, on veut nous faire croire que l'anglais est simple. L'anglais n'a qu'une qualite indeniable, c'est qu'il est concis. Il ne sait battre que par le chinois.
[^] # Re: Bogue...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 10.
Pourquoi Ironpython est plus lent en C qu'en C# ? Mal optimisé ?
>>
Une partie du gain vient du fait que le CLR peut detecter des organisations de code qu'il peut optimiser a la volee au moment de l'execution, ce que ne peut pas du tout faire le C.
Guido Van Rossum et tous les gens qui bossent sur python dpeuis 10 ans ne sont pas des machots donc je doute que le code C de python soit "mal optimise".
<<
Le C peut aussi bien faire de gros programmes, faut créer les bibliothèques et bien modulariser et bien savoir coder aussi
>>
Donc en fait, ta defense du C est une attaque des programmeurs. "Vous ne savez pas coder, sinon, ca marcherait mieux". C'est plutot minable comme argumentaire.
Sur des tres gros programmes en C, tu es souvent conduit a utiliser par exemple des pointeurs en (void *) car tu dois stocker plusieurs types de donnees dans un pointeur. L'absence de notion de dictionnaire, d'heritage, les notions de tableaux tres limitees, l'absence de notion d'interface font que beaucoup de paradigmes indispensables de programmation sont fait completement a l'insu du compilateur, qui du coup a un champ tres limite pour comprendre les intentions du programmeur et optimiser le code en fonction.
L'utilisation d'un (void *) est le plus flagrant mais tous les parametres jouent ensemble. Un dictionnaire a 3 elements est plus facile a optimiser avec une recherche lineaire, un dictionnaire avec 500 elements est plus facile a optimser avec une table de hashage. C'est une decision que le compilateur pourait prendre plutot que le programmeur.
L'absence de ramasse-miette fait aussi que les programmes en C demandent plus de travail au programmeur. Le ramassage des miettes (== desalllocation des ressources inutilisees) est aussi quelque chose que le compilateur peut faire mieux que le programmeur si on lui passe les bonnes information.
<<
La grammaire du C est complexe ? :o Pourquoi ?
>>
Au hasard et en survol :
- pas de distinction entre un tableau et un pointeur
- un melange entre la declaration de type et le nom de la variable :
<type de la variable> <nom de la variable> <info supplementaire facultative sur le type de la varible>
int a[30];
- le pre-processeur qui peut rendre la grammaire du texte decrivant le code completement irreguliere.
- l'absence de taille predefinies pour les types de bases.
<<
Des manipulations qui cachent ce que veut faire le developpeur ? C'est quoi ?
>>
Pour les plus simples :
- passage d'arguments par void *
- passage de tableaux par pointeur, on perd toute l'information sur la notion de tableau (de toute facon, le C n'est stocke aucune, mais c'est bien la une de ses limitations)
- bidouilles a coup de struct et de pointeurs de fonctions pour faire des interfaces
- pas de liste, pas de dictionnaire donc plein d'optimisations a la portee du compilateur qui sont perdues
<<
Et les outils ne font pas obligatoirement faire de meilleur code ;).
>>
T'as vraiment des arguments a 3 francs. T'as deja reflechi au sujet avant d'ecrire un truc pareil ?
Bien sur que la qualite des outils permettent d'ecrire du code de meilleur qualite et de le faire evoluer de meilleure facon.
Un outil de refactoring en java te permet de faire facilement evoluer ton code par exemple. La meme operation en C oblige a faire un gros grep dans les sources et a faire de modifs a la main, super penible donc rarement fait dans la pratique, donc code qui devient vite immaintenable.
Des que tu fais du C++, tu t'apercois que gdb n'as acces qu'a une partie limitee des objets, et que donc le debuggage est super penible, tu en reviens au printf, ce qui est long et penible.
Des outils comme la programmation oriente aspect permettent d'explorer des nouveaux concepts de programmation, plus en rapport avec les besoins de certains projets.
En java, il est possible de debugger a distance un programme java qui s'execute. Par exemple, je peux debugger une javacard depuis mon PC, poser des points d'arrets, inspecter les variables, etc. C'est difficile et lourd a faire avec du code embarque en C, tu es souvent oblige de developper un simulateur complet de ta plate-forme cible.
Des outils d'analyses de code peuvent te permettre de mieux comprendre un code existant. Ces outils sont limites dans leur comprehension du code C a cause des limitations de la grammaire du C (je commence a me repeter la).
<<
Les outils n'ont rien à voir avec la simplicité du langage...
>>
Je n'ai pas parle de simplicite mais d'expressivite. Si ton langage transcrit bien ce que tu veux faire, les outils peuvent t'aider beaucoup. Si ce n'est pas le cas, les outils ne peuvent rien pour toi.
Le cas d'erlang est frappant. Je ne connais pas le langage, mais je suis persuade que si tu informes le compilateur des morceaux de code qui doivent s'executer en parallele ou non, tu obtiens un truc bien plus propre que avec des mutex dans tous les sens, des sections critiques et des forks a tout va. Dans un cas, le compilateur peut t'aider et distributer pour toi l'execution du code sur plusieurs threads/processeurs/machines, dans l'autre, c'est toi pauvre programmeur, qui va essayer de le faire. Tu vas passer ton temps a re-inventer la roue.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 6.
C'est plus ou moins ce qu'a fait transmeta avec son code morphing. Au final, c'etait beaucoup plus lent qu'un processeur pur.
<<
- Un compilateur utilisant massivement une analyse de flot
- Un compilateur qui dispose de bonnes informations, à priori sur les statistiques d'utilisation du code (ie. distribution des valeurs les plus courantes en entrée des fonctions).
>>
Et on en revient a la necessite d'avoir une grammaire du langage de programmation qui soit suffisamment expressive. Sinon, ces optimisations sont tres difficiles a mettre en oeuvre.
C'est bien pour cela que le JIT a attendu des langages comme Java ou C# pour devenir populaire.
<<
Dans le compilateur, il faudrait que l'analyse de flot analyse les sous graphes potentiellement très consommateurs en calculant leur complexité ainsi que les possibilités de "distributions" des paramètres dans l'intervalle possible (typiquement , on peut déduire, dans certains cas, par un moteur logique, que le param appliqué à la fonction f, dans le contexte se trouvera dans l'interval [20;100]).
>>
C'est tres proche de ce que fait le compilateur OCaml. C'est d'ailleurs ce qui explique malgre un langage "loin de la machine", il arrive a de tres bonne perfs : il y a une analyse de code tres poussee derriere qui va bien chercher les optimisations.
Cependant, l'analyse statique restera toujours limitee. Le comportement d'un programme depend de son code et de ses parametres en entree. Une optimisation statique a la compilation ne peut optimiser que le code d'un point de vue general. Elle ne peut pas connaitre quelle fonction est appelee plus souvent dans la pratique. C'est la que les optimisations JIT interviennent. Elles regardent le code s'executer et peuvent trouver les fonctions qui sont reellement utilisees en permanence.
Le C etant compile en assembleur avant d'etre execute, toute l'information sur la notion de fonction et de variable est perdue. Meme si cette information perdurait, a terme, la grammaire du C est trop peu expressive a mon sens pour permettre des optimisations de longue haleine (pas de notion d'interface, pas de notion de dictionnaire, utilisation de pointeurs pour gerer des tableaux, utilisation de pointeurs sans types, etc).
Donc plus ca va, plus le C va etre a la rue parce qu'il ne peut guere evoluer. D'un autre cote, cette stabilite est aussi ce qui a fait son succes.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 7.
Mouai. Faudrait commencer a evoluer.
Par exemple, sur le "language shootout", OCaml est extremement proche du C pur en terme de vitesse:
http://shootout.alioth.debian.org/old/benchmark.php?test=all(...)
Et pourtant, je ne crois pas que OCaml soit "proche de la machine".
De meme, IronPython, une version de python ecrite pour le CLR de C# est plus rapide que la version de python en C.
Le C se prete bien a certaine manipulations mais pour des gros programme, je suis persuade qu'un langage qui expose correctement les intentions du programmeur dans sa grammaire pourra a terme etre mieux optimise par un bon compilateur. Le C et le C++ ont ce probleme que leur grammaire est complexe, avec des manipulations qui cachent ce que veut faire le developpeur. Au final, une information est perdue, celle de l'intention du programmeur et les optimisations sont donc limitees dans la mesure de l'expressivite du langage.
Si on regarde Java ou C#, on trouve plein d'outils de refactoring, d'analyseurs de code, de programmation oriente aspect, etc etc. La richesse de ces outils vient du fait que ces langages exposent une grammaire plus facile et que les outils annexes peuvent mieux comprendre et aider le programmeur.
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
Donc au final, c'est l'application qui doit s'adapter et tu perds l'avantage de la transparence du systeme. Sous KDE, toutes les applications sont deja adaptees a ces problemes. Et KDE n'a eu besoin de demander l'autorisation de personne (Linus, ...) pour le mettre en place et le tester.
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 4.
Utilise une telle API pour des lecteurs qui peuvent etre tres lent, ou la connection peut carrement etre perdue a tout moment donne un tres mauvais resultat. Des que tu as une operation lente, il veut mieux la faire de facon asynchrone et garder la main sur la partie visuelle de l'application, en proposant un dialogue permettant d'arreter immediatement l'operation en cours.
Si tu as deja utilise un disque dur foireux ou tu fais un ls et tu attends deux minutes sans rien pouvoir faire, tu as une idee de ce que peut etre la latence sur un systeme de fichier monte a distance : super penible.
En fait, tu ne peux pas concevoir une application qui travaille sur un systeme de fichier ayant des caracteristiques reseau (latence, perte de connection) sans integrer ce parametre dans ton application.
Donc les fuse-ioslave, ca peut resoudre qqs problemes pratiques mais ce n'est pas la panacee.
[^] # Re: Ce qui est dommage
Posté par Philippe F (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 2.
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway
Et donc, tu peux utilsier tous les ioslave KDE sous bash.
Dans la pratique, ce n'est pas tres pratique donc pas tres utilise.
Il y a eu une enfilade de deux mois sur un VFS commun entre Gnome et KDE sur la liste freedesktop. Pour resumer, le VFS de Gnome est moins mature a l'heure actuelle que celui de KDE (bien qu'il semble y avoir des trucs plus interessants sous certains aspects) et il y a enormement de problemes techniques pour la realisation.
Ensuite viendrait la question de ce qui pourrait pousser une desktop comme KDE qui a une solution robuste et eprouvee depuis maintenant 5 ans pour passer a un truc inferieur (moins de ioslave que sous KDE) et mal teste. Ca arrivera surement mais ce ne se fera pas simplement.
J'avais tendance a penser comme toi mais en fait, l'experience montre que c'est la voie naturelle. Tu ne peux pas commencer a prevoir l'integration dans un autre environnement que le tien tant que tu n'as pas essaye la solution d'abord chez toi.
Pour le coup des framework VFS, Gnome est arrive tres en retard sur KDE et a fait un truc different, avec des URLs incompatibles avec celle de KDE.
Si on prend l'exemple de DCOP et DBUS, la situation est relativemetn similaire. D'abord on valide une solution qui marche (DCOP) puis on derive qq chose qui va plus loin (DBUS). Si tu essayes de faire DBUS du premier coup, tu n'y arrveras jamais.
[^] # Re: Nedit ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vim 7. Évalué à 2.
Je pense qu'en fait pour les gens qui editent vraiment _beaucoup_, un gain de productivite meme leger represente un confort important, et que c'est ce qui les conduits a des editeurs comme vim ou emacs, qu'ils defendent avec ardeur.
[^] # Re: ceci n'est pas un troll ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vim 7. Évalué à 3.
Pour mon cas particulier, aller cherche l'accolade, c'est un shift plus la touche a cote de (je suis en clavier americain), ce qui veut dire deux utilisations du petit doigt droit et gauche. C'est un mouvement plutot difficile et fatiguant, ce qui fait que je ne l'utilise pas souvent.
Pour les jjjjj, pour moi, c'est plus rapide de les taper que de compter le nombre de lignes a l'ecran, de taper le nombre puis de taper j.
[^] # Re: ceci n'est pas un troll ...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vim 7. Évalué à 4.
- un mode ou le texte que tu tapes est insere, comme sur Kate ou les autres editeurs classiques
- un mode ou chaque touche correspond en fait a une action, que tu lancerais sur les autres editeurs via des combinaisons de Control ou ALT.
Ce second mode permet d'effectuer des actions complexes en laissant tes doigts a des emplacements faciles a joindre sur le clavier. D'une part, c'est moins fatiguant pour les mains, d'autre part, c'est beaucoup plus rapide.
Exemple, tu veux faire un copier/ colle :
- Kate version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste
- Kate version clavier : tu selectionnes le texte, tu fais Control-C, tu scrolles ton texte avec Page-Down et Cursor-Down, tu fais Control-V
- Vi version souris : tu selectionne le texte, tu fais menu-droit copy, tu scroll ton texte avec la souris, tu positionnes le surceurs, tu fais menu-droit-paste (a noter que c'est la meme chose que Kate version souris)
- Vi version clavier : tu demarra ta selection de texte avec V. Tu deplace ton curseur avec la touche kjhl pour contenir toutes les lignes que tu veux selectionner. Tu tapes y pour faire la copie. Tu te deplace a coup de page-up ou page-down (j'ai jamais pu me rappeler le racourci pour les sauts de pages), tu positionnes ton curseur avec les touches khjl et tu tapes P.
Si on compare kate et vi au clavier, on pourrait imaginer la suite de touches suivantes :
[Down]
[Down]
Control-[Right]
Control-[Right]
[Shift appuye]
[Down]
[Down]
Control-C
[Page-Down]
[Page-Down]
[Down]
[Down]
Control-V
et
j
j
w
w
v
j
j
y
[Page-Down]
[Page-Down]
j
j
p
Tu notes que les touches vi sont plus faciles a taper. A noter aussi que vi est relativement compatible avec un mode d'edition a la kate, de sorte qu'on peut envisager un apprentissage plus lent des foncitonnliates specifiques vi (par exemple, se deplacer au curseur plutot qu'avec jkhl).
[^] # Re: Petit bemol
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vim 7. Évalué à 7.
Ce sont des concepts qu'on est ravi d'utiliser quand on veut juste changer une option de config a la con. :-)
[^] # Re: Et la légéreté ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Annonce du projet Phonon. Évalué à 5.
Je trouve que tu utilises un vocabulaire imprecis et une analyse hyper theorique eloignee des realites pratiques et des problematiques reelles, ce qui conduit a des conclusions qui sont a mon sens plutot denudees de justesse.
Derriere le vocable fourre-tout "ajouter une couche", il y a differentes operations possibles, l'une pouvant ralentir de facon signficatives les performances du programme et meme en affecter le fonctionnement (genre rajouter xine au dessus de alsa) et l'autre a un impact negligeable (ajouter un ou deux appels de fonctions pour acceder a le meme fonctionnalite).
Je ne sais pas ou tu as lu que KDE ne pretend pas a la legerete (peut-etre dans le marketing de Gnome ?) mais ce n'est pas du tout le cas. Toutes les versions de KDE depuis la 2.0 sont plus rapides les unes que les autres et consomment moins en memoire.
La convivialite est en revanche une preoccupation importante de KDE et si cela veut dire "alourdir" le protocole ssh en "rajoutant une couche" avec kio pour que ce soit plus convivial, ca me semble une bonne chose.
Juste pour rire, est-ce que qq'un a deja note que fish: etait plus lent que scp ? Est-ce que qq'un a deja eu un probleme de ce style au point de vouloir supprimer fish ?
[^] # Re: La relance de l'économie passe par l'autarcie?
Posté par Philippe F (site web personnel) . En réponse à la dépêche DADVSI : La pression monte avant le Sénat. Évalué à 5.