Ca sert aussi à gérer la compilation : lancer make comme il faut pour qu'il passe le moins de temps possible, gérer les options de compilation, faire la génération de lien correctement, faire des lib statiques ou dynamiques.
Quand on survole, ça a l'air très simple mais quand on rentre dans les détails, c'est pas du tout du tout simple. Il y a des différences entre chaque compilateur, entre chaque plateforme. Il y a pleins de subtilités sur la façon de faire des libs dynamiques (installable, qui trouvent automatiquement leurs différences, ...).
Au départ KDE avait choisi scons mais la lenteur et l'absence de flexibilité et la quantité de travail à faire pour faire compiler KDE avec on fait qu'il a été rejeté.
A côté, CMake s'est imposé tranquillement mais surement. En tant que fan de python, ça me fait bizarre que ce soit un langage de compilation à base de Macros en majuscule qui marche mieux qu'un truc développé en python mais les faits sont là. Et les mecs de KDE font rarement des erreurs techniques.
D'après Thomas Nagy qui a bossé sur scons pour KDE, les problèmes de scons tenaient vraiment à son architecture. Il a d'ailleurs écrit waf à la suite de ça: http://code.google.com/p/waf/
KDE est vraiment très content avec CMake, il y a régulièrement des améliorations en terme de vitesse de compilation de rigueur, ou de correction de problèmes extrèmement subtils.
Pour ma part, je l'utilise en j'en suis très content. Aussi simple à utiliser que qmake, mais mieux supporté et plus souple.
La documentation pèche un peu parfois mais rien d'insurmontable. Je l'utilise principalement sous windows, avec mingw, pour faire des nightly builds de certains projets.
Ca a toujours toujours été comme ça. KDE a toujours sorti des versions très régulièrement, tous les neuf mois avec au plus un mois de décalage. Les seuls versions qui ont vraiment dérapé, c'est KDE 2.0 et KDE 4.0, parce que elles demandaient une réécriture importantes des bibliothèques de bases et des applications.
Il y a toujours eu un processus très carré, feature freeze trois mois avant la sortie de la release, string freeze un mois avant, ouverture des branches de dev en parallèle.
La seule chose qui change pour la série KDE 4, c'est que les intervalles de release sont passés de 9 mois à 6 mois, ce qui les rends apparamment plus lisible pour le grand public.
Tu fais quand même un raccourci sévère. On aurait presque l'impression que Novell peut faire des choses sans ton accord. Le cheminement, c'est : tu travailles sur cette partie-là de Mono, tu fais le choix de donner ton copyright à Novell en sachant que tu perds le contrôle de l'utilisation de ton code, Novell peut faire ce qu'ils veulent de ton code.
La forme des ombres est d'ailleurs caractéristique d'une projection sur une surface plane, preuve une fois de plus s'il en était, que la terre est bien plate et non ronde comme nos dirigeant voudraient nous le faire avaler.
Ben il manque la touche windows et la touche menu windows.
Apple a bien essayé de ré-inventer le concept avec la touche pomme mais on sent que c'est du réchauffé et ça n'arrive pas à la hauteur d'un vrai clavier windows :
Malgré le nom un peu effrayant, ce sont des cartes faciles à programmer. Il doit être possible d'en faire une carte PKCS#11. Après, elles doivent pouvoir être intégrées avec un simple lecteur PC/SC à coup de MUSCLE dans du Linux.
Tout ça, c'est de la théorie, mais pour une âme motivée, il n'y a pas d'obstacle majeur à la mise en pratique.
Ne jamais se fier à ses sens, toujours [...] garder à l'esprit que notre vision du monde est en permanence faussée par une grille de lecture qui nous est propre, faite de préjugés, de souvenirs, de ressentis, de peurs, fantasmes, etc.
Je suis un peu étonné par ton encouragement à rejeter nos sens. Pourquoi ne pas accepter au contraire, que nos expériences teintent nos ressentis. Qu'y a-t-il de mal à trouver qu'une pomme offerte par une jolie fille aura un goût différent que la même pomme, offerte par un clochard ?
Est-ce vraiment un objectif ultime de devenir une machine débarrassée de tout sentiment, de tout a priori, de tout souvenir, de tout biais, de toute expérience passée ? En ce qui me concerne, la machine objective n'est pas un idéal de vie. Et je suis heureux que mes décisions ne soient pas toutes rationnelles.
Je transformerai plutôt ton appel en :
Fiez vous à vos ressentis, vos intuitions ! Gardez à l'esprit et profitez du fait que notre vision du monde est colorée et enrichie par une grille de lecture qui nous est propre, faite de souvenirs, d'émotions, de ressentis.
Les tests sont intéressants, même si il faut les prendre avec des pincettes. Ca donne un aperçu du potentiel.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.
Même si nous sommes d'accord sur le fond, il faudrait pas sauter tout de suite à une conclusion erronée. Que beaucoup de projets libres naissent et meurent, c'est un fait. Que le choix de la licence GPL en soit une des cause, je reste sceptique.
La menace de non-contribution en retour est brandie en permanence dès qu'on parle de BSD. D'une part, ce risque existe aussi avec les autres licences libres. D'autre part, parce que ce risque existe ne veut pas dire qu'il est réalisé. Il y a des projets BSD qui reçoivent des retours sous forme de patch, de la part d'entreprises qui les utilisent.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.
Oui. Et même que finalement, ils ont dit que ça ne servait pas à grand chose et qu'ils allaient ré-intégrer leur travail dans leur équipe de base de donnée ou ailleurs mais peut-être pas dans Windows Longhorn...
J'ai toujours du mal à comprendre pourquoi ce gestionnaire de version ne reçoit pas plus de publicité.
Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.
En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS
Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...
Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.
> - fournit des containers dont l'interface est plus que largement inspirée de la STL
Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.
Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.
Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.
Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).
Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.
Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).
> Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"
Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.
Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.
Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.
Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.
> J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.
Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.
C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.
Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.
> les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.
Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.
Mouai. Le standard du C++ propose à la fois une syntaxe et une bibliothèque. Ok pour se conformer au langage (bien que quand une spec fait 1200 pages, on peut se poser la question de la logique qui préside à ce langage).
La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.
La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?
Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]
Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).
Quelques exemples en vrac :
- trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.
- les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.
Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]
Voilà, je pense que ca répond à la question initiale.
[1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.
Euh, Eliza, c'est plus un psychanalyste qu'un psychothérapeute.
La distinction est pas forcément claire pour les non-initiés mais en gros le psychanalyste, c'est le cliché que tout le monde connait - "allongez-vous sur le divan, parlez moi de votre enfance" - où l'intervention du thérapeute est réduite et consiste à relancer doucement le client dans ses souvenirs. Ça se prête bien à Eliza puisque c'est surtout le client qui parle.
Dans la plupart des techniques de psychothérapie (et pour ma part, je ne considère pas que la psychanalyse en soi une), il y a une implication plus profonde et marquée du psychothérapeute : partage d'émotion, discussion, proposition d'un exercice mettant en jeu le corps. Bref, plein de trucs qu'on ne peut pas faire faire à Eliza et qu'on ne peut pas vraiment faire avec juste du chat.
Je vois toujours des références à du « code propre » et j'avoue que ça m'agace un peu.
On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».
J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.
Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).
Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.
Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.
Après lecture détaillée du bug, on voit qu'aucun développeur Thunderbird n'a participé à la discussion. Ils ont pas l'air de considérer cette requête comme intéressante. Le bug n'est d'ailleurs pas assigné.
Pourtant, il y a des arguments vraiment importants présentés dans les commentaires : instabilité sur les gros mbox, gain en vitesse, meilleure stabilité, backup plus facile, meilleure interopérabilité avec d'autres clients mail, ...
Passage aux autotools pour faciliter l'installation ;
Ca fait des années que je n'ai pas vu les mots "autotools" et "facile" dans la même phrase, sans avoir une négation entre les deux.
On pourrait détailler, parce que autotools est quand même connu pour être un truc super compliqué et lourd, remplacé allègrement de nos jours par CMake, qmake, scons, waf, ...
[^] # Re: Génial
Posté par Philippe F (site web personnel) . En réponse au journal scons 1.0. Évalué à 4.
Quand on survole, ça a l'air très simple mais quand on rentre dans les détails, c'est pas du tout du tout simple. Il y a des différences entre chaque compilateur, entre chaque plateforme. Il y a pleins de subtilités sur la façon de faire des libs dynamiques (installable, qui trouvent automatiquement leurs différences, ...).
Au départ KDE avait choisi scons mais la lenteur et l'absence de flexibilité et la quantité de travail à faire pour faire compiler KDE avec on fait qu'il a été rejeté.
A côté, CMake s'est imposé tranquillement mais surement. En tant que fan de python, ça me fait bizarre que ce soit un langage de compilation à base de Macros en majuscule qui marche mieux qu'un truc développé en python mais les faits sont là. Et les mecs de KDE font rarement des erreurs techniques.
D'après Thomas Nagy qui a bossé sur scons pour KDE, les problèmes de scons tenaient vraiment à son architecture. Il a d'ailleurs écrit waf à la suite de ça: http://code.google.com/p/waf/
KDE est vraiment très content avec CMake, il y a régulièrement des améliorations en terme de vitesse de compilation de rigueur, ou de correction de problèmes extrèmement subtils.
Pour ma part, je l'utilise en j'en suis très content. Aussi simple à utiliser que qmake, mais mieux supporté et plus souple.
La documentation pèche un peu parfois mais rien d'insurmontable. Je l'utilise principalement sous windows, avec mingw, pour faire des nightly builds de certains projets.
# Export ODF
Posté par Philippe F (site web personnel) . En réponse à la dépêche Bon anniversaire txt2tags !. Évalué à 2.
[^] # Re: Mises à jour mineures de prévues
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 4.1 : Don't Look Back. Évalué à 7.
Il y a toujours eu un processus très carré, feature freeze trois mois avant la sortie de la release, string freeze un mois avant, ouverture des branches de dev en parallèle.
La seule chose qui change pour la série KDE 4, c'est que les intervalles de release sont passés de 9 mois à 6 mois, ce qui les rends apparamment plus lisible pour le grand public.
[^] # Re: novell n'est pas rose... non plus
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 7.
[^] # Re: RE : La libération de L. Bettancourt , du gros pipo ?
Posté par Philippe F (site web personnel) . En réponse au journal La libération de L. Bettancourt , du gros pipo ?. Évalué à 10.
[^] # Re: Cool
Posté par Philippe F (site web personnel) . En réponse à la dépêche Luc Chatel veut la fin de la vente liée. Évalué à 8.
Apple a bien essayé de ré-inventer le concept avec la touche pomme mais on sent que c'est du réchauffé et ça n'arrive pas à la hauteur d'un vrai clavier windows :
http://obligement.free.fr/images/clavier_windows.jpg
# Basiccard
Posté par Philippe F (site web personnel) . En réponse au journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?. Évalué à 2.
http://www.basiccard.de/
Malgré le nom un peu effrayant, ce sont des cartes faciles à programmer. Il doit être possible d'en faire une carte PKCS#11. Après, elles doivent pouvoir être intégrées avec un simple lecteur PC/SC à coup de MUSCLE dans du Linux.
Tout ça, c'est de la théorie, mais pour une âme motivée, il n'y a pas d'obstacle majeur à la mise en pratique.
[^] # Re: Est-ce que quelqu'un saurait pourquoi
Posté par Philippe F (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
Tu as raison d'avoir peur, toutes les distrib debian depuis 2006 utilisent une version d'OpenSSL qui n'utilise presque pas d'entropie.
Maintenant OpenSSL lui-même fonctionne correctement.
[^] # Re: euh...
Posté par Philippe F (site web personnel) . En réponse au journal [HS] Dan Ariely, professeur de déraison. Évalué à 6.
Ne jamais se fier à ses sens, toujours [...] garder à l'esprit que notre vision du monde est en permanence faussée par une grille de lecture qui nous est propre, faite de préjugés, de souvenirs, de ressentis, de peurs, fantasmes, etc.
Je suis un peu étonné par ton encouragement à rejeter nos sens. Pourquoi ne pas accepter au contraire, que nos expériences teintent nos ressentis. Qu'y a-t-il de mal à trouver qu'une pomme offerte par une jolie fille aura un goût différent que la même pomme, offerte par un clochard ?
Est-ce vraiment un objectif ultime de devenir une machine débarrassée de tout sentiment, de tout a priori, de tout souvenir, de tout biais, de toute expérience passée ? En ce qui me concerne, la machine objective n'est pas un idéal de vie. Et je suis heureux que mes décisions ne soient pas toutes rationnelles.
Je transformerai plutôt ton appel en :
Fiez vous à vos ressentis, vos intuitions ! Gardez à l'esprit et profitez du fait que notre vision du monde est colorée et enrichie par une grille de lecture qui nous est propre, faite de souvenirs, d'émotions, de ressentis.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 9.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 8.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.
[^] # Re: Bon article
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 4.
http://www.news.com/New-file-system-has-long-road-to-Windows(...)
# Mercurial, c'est bon, mangez-en
Posté par Philippe F (site web personnel) . En réponse à la dépêche Mercurial 1.0. Évalué à 5.
Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.
En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS
Par exemple :
http://sources.freehackers.org/hg.cgi
Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...
Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.
La video côté google présentant mercurial :
http://video.google.com/videoplay?docid=-7724296011317502612(...)
Elle génère moins de buzz que celle de Linus, mais tel est le sort de Mercurial : moins de buzz mais des trucs qui marchent !
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 8.
Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.
Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.
Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.
Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).
Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.
Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).
> Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"
Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.
Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.
Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.
Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.
> J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Dans Qt 2, tu ne pouvais pas choisir ton algo de tri :
http://doc.trolltech.com/2.3/qarray.html
Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.
Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.
C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.
Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.
> les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.
Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 3.
La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.
La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 6.
Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]
Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).
Quelques exemples en vrac :
- trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.
- les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.
Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]
Voilà, je pense que ca répond à la question initiale.
[1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.
# Psychothérapeute ou psychanalyste ?
Posté par Philippe F (site web personnel) . En réponse au journal Pouvez-vous m'en dire plus sur votre mort Joseph ?. Évalué à 1.
La distinction est pas forcément claire pour les non-initiés mais en gros le psychanalyste, c'est le cliché que tout le monde connait - "allongez-vous sur le divan, parlez moi de votre enfance" - où l'intervention du thérapeute est réduite et consiste à relancer doucement le client dans ses souvenirs. Ça se prête bien à Eliza puisque c'est surtout le client qui parle.
Dans la plupart des techniques de psychothérapie (et pour ma part, je ne considère pas que la psychanalyse en soi une), il y a une implication plus profonde et marquée du psychothérapeute : partage d'émotion, discussion, proposition d'un exercice mettant en jeu le corps. Bref, plein de trucs qu'on ne peut pas faire faire à Eliza et qu'on ne peut pas vraiment faire avec juste du chat.
# gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 8.
On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».
J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.
Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).
Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.
Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.
[^] # Re: Tests sur mac
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 6.
http://ivan.fomentgroup.org/blog/2008/03/04/acid3-and-konque(...)
[^] # Re: Eudora ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 3.
[^] # Re: autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche VHFFS l'hébergement libre pour tous en 4.1. Évalué à 4.
[^] # Re: \o\ \o/ /o/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 7.
Pourtant, il y a des arguments vraiment importants présentés dans les commentaires : instabilité sur les gros mbox, gain en vitesse, meilleure stabilité, backup plus facile, meilleure interopérabilité avec d'autres clients mail, ...
[^] # Re: \o\ \o/ /o/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 10.
# autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche VHFFS l'hébergement libre pour tous en 4.1. Évalué à 9.
Ca fait des années que je n'ai pas vu les mots "autotools" et "facile" dans la même phrase, sans avoir une négation entre les deux.
On pourrait détailler, parce que autotools est quand même connu pour être un truc super compliqué et lourd, remplacé allègrement de nos jours par CMake, qmake, scons, waf, ...