L'exemple de Hello World est base sur une programmation par evenement. Il me semble que wxWidget supporte aussi une programmation par signaux, comme sous Qt ou Gtk mais cela n'est pas mis en evidence : la totalite de la documentation semble basee sur le concept d'evenement.
La programmation par evenement est beaucoup moins souple que les signaux/slot facon Qt, car un evenement ne peut contenir que tres peu d'information: "il se passe qqch". Du coup, pour transporter des informations complexes, on est obliger de rajouter du code qui va chercher l'information la ou elle est. Les exemples simples comme le hello world ne mettent pas en evidence ce probleme, mais quand on rentre dans des cas reels, le flux de communication de donnees a l'interieur de l'application devient complexe. Avec une programmation purement evenementielle comme wxWidgets (ou MFC), ce flux est penible a gerer.
La communication par signaux permet de completement separer la preparation des donnees de leur traitement, et d'offrir plus d'independance entre les differents objets d'une application. Pour ceux qui sont familiers avec les Design Pattern, c'est un probleme recurrent resolu par le Mediateur. Pour faire communiquer un objet A avec un objet B, soit B doit connaitre A, soit A doit connaitre B, soit il y a un objet C entre A et B qui connait A et B. On peut dans ce cas faire evoluer A separement de B a condition de faire suivre C, qui devient le mediateur.
Ce qui est fort avec Qt, c'est que pour les cas simples, le mediateur, c'est la connection signal/slot et qu'il n'y a donc pas besoin de pondre une classe pour ca.
Je donne un exemple simpliste mais concret: une interface graphique doit generer des rectangles dont l'utiisateur controle la hauteur et la largeur. Il entre deux nombres de facon diverses, clique sur un bouton et un rectangle doit etre genere.
Cote interface, il y a donc du code qui doit lire deux nombre. On imagine deux spinbox et un bouton pour generer le tout. De l'autre cote, il y a une partie du programme qui recoit le "signal" de generer un nouveau rectangle.
En Qt, ca donnerait qqch dans le style:
class MyRectangleInput : public QVBox {
Q_OBJECT
public:
MyRectangleInput( QWidget * parent ) {
spin1 = new QSpinBox( this );
spin2 = new QSpinBox( this );
QPushButton * button = new QPushButton("Generate Rectangle");
connect( button, SIGNAL(clicked), this, SLOT(slotGenerate) );
}
slots:
void slotGenerate() {
emit generateRectangle( spin1->value(), spin2->value() );
}
signals:
void generateRectangle( int width, int height );
protected:
QSpinBox *spin1, *spin2;
};
De l'autre cote, on a la classe reception :
class RectangleGenerator : public QWidget
{
// [...]
public slots:
slotGenerateRectangle( int width, int height ) {
// create new rectangle
}
};
Pour faire marcher le tout, il doit y avoir un moment donne une connection entre une instance de MyRectangleInput et RectangleGenerator:
connect( myRectangleInstance, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstance, SLOT(slotGenerateRectangle(int,int)) );
On voit bien que les deux classes sont completement independantes, et ce qui les lie, c'est la connection signal / slot.
[ A noter que le MyRectangleInput peut etre librement redimensionner et que les widget adapteront la bonne taille ]
Si on revient a un toolkit base sur des evenements, on aurait une problematique differente. Je ne connais pas bien wxWidget, mais en reprenant le concept general de la haut, la classe A, c'est le MyRectangleInput, et la classe B, c'est le RectangleGenerator. Dans le cas ou on appuie sur le bouton, un evenment GENERATE_RECTANGLE est envoye. De la, il y a le choix:
- B connait A : la classe RectangleGenerator dispose d'un pointeur vers la classe MyRectangleInput et va lire elle-meme le contenu des spinbox. Le probleme, c'est que si on remplace les spinbox par autre chose, il faut faire evoluer aussi la classe RectangleGenerator. Un autre probleme qui est beauoup plus contraignant, c'est que RectangleGenerator doit disposer d'un pointeur sur MyRectangleInput. Que se passe-t-il si il y a plusieurs MyRectangleInput ? Il faut gerer la vie du pointeur. Que se passe-t-il si une autre partie de l'application veut effacer un pointeur sur MyRectangleInput ? Elle doit en informer toutes les classes qui possedent un pointeur sur MyRectangleInput. Plutot lourd.
- A connait B : cette fois, c'est MyRectangleInput qui connait bien RectangleGenerator, qui appelle directement l'instance avec les bons parametres qu'il va chercher en interne. On peut donc faire evoluer MyRectangleInput facilement. Mais on retombe vite dans une problematique similaire : imaginons qu'on aie plusieurs destinataires du message GENERATE_RECTANGLE. Ils doivent tous s'enregistrer aupres de MyRectangleInput et tous avoir une interface commune. Si en plus on a plusieurs generateurs, on arrive vite a une situation ou il y a n generateurs, n recepteurs et on doit maintenir n x n liens tout en sachant a tout moment que faire si des pointeurs sont effaces.
- C connait A et B : c'est pour ca qu'on a besoin d'une classe supplementaire C. Elle va recevoir l'evenement GENERATE_RECTANGLE, aller cherche l'info dans A parce qu'elle connait bien l'implementation de A, puis dispatcher cette information dans B. Si il y a plusieurs RectangleGenerator et plusieurs MyRectangleInput, la class C maintient la liste des associations et est la seule classe qui doit etre au courant quand un nouveau pointeur est cree ou supprime.
L'avantage dans le modele signaux/slot, c'est qu'on a pas besoin de classe C. Elle est deja dans le toolkit. Dans les problematiques que j'ai cite, on peut imaginer en QT :
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
si on efface un pointeur myRectangleInstanceX, il n'y a rien de special a faire, la connection disparait toute seule. Idem si on efface un rectangleGeneratorX.
Ce probleme peut paraitre simpliste, mais dans une application graphique (et meme non graphique), on a beaucoup de morceaux d'applications a faire communiquer ensemble (typiquement, le frontend et le backend) et les facilites fournies par Qt permettent de gerer cela avec beaucoup de legerete et d'elegance.
Avec une programmation par evenement, le code devient vite abominable et on est tout de suite obliger de faire appel a moultes Design Pattern pour garder un truc maintenable.
<< wxGridBagSizer qui permet de décrire l'organisation d'une fenêtre comme un tableau dont les cases peuvent fusionner >>
Si j'ai bien compris, c'est ce qui permet de faire facilement des fenetres redimensionnables. Impressionnant, c'etait une fonctionnalite de base dans Qt 1.0 (les qlayout) et dans Gtk 1.0 aussi (gtk_pack il me semble).
J'ai du mal a imaginer qu'on puisse sortir un toolkit graphique au 3 millenaire sans ce type de fonctionnalite !
C'est bien, on progresse ! Plus que 10 ans a wxWidget pour rattrapper le retard sur les autres toolkits.
> L'utilisation d'un logiciel proprio a forcement ralenti le developpement d'un CMS "special kernel" libre puisque le besoin n'existait pas.
D'un autre cote, elle a surement permis a Linus de se fixer les idees sur ce qu'il voulait dans un SCM (et pas un CMS, vive les acronymes). Avant bitkeeper, il n'en avait pas trouve qui lui convienne et il n'aurait probablement pu en pondre un aussi vite.
Linus a aussi eu l'habitude de travailler pendant tres longtemps avec des outils tres simples: patch, diff, et le mail pour stocker les patches en cours. Je soupconne que s'il n'avait pas eu un outil tres sophistique pendant quelques temps, il aurait continue avec sa methode a lui qui marchait tres bien, c'est a dire a la mano. Evidemment, on peut tout supposer mais de mon point de vue, l'utilisation de bitkeeper a engendre git et ce dernier n'aurait pas vu le jour sans cette periode de transition.
Maintenant, ramene ca a la realite du desktop, ou il n'y a qu'un seul utilisateur, ou bien ou alors plusieurs utilisateurs partagent en general le meme compte (maman, papa) et tu peux mettre ton raisonnement a la poubelle.
Cela dit, c'est chiant de devoir re-installer une machine.
> lorsque je suis à vélo et que je décide d'aller sur le trottoir, je descends de mon vélo et le pousse à pieds.
Ce serait genial si tu n'etait pas une malheureuse exception.
> Je vais bien rire lorsque ce sera le cas parce qu'en tant que roller ce sera toi qui deviendra le "piéton" par rapport aux bus, taxis, motos
Ca va etre une revolution pour nous. On est tellement con, on etait jamais alle sur la route et on savait pas comment c'etait, on ne s'est jamais fait colle par un taxi, frole par un bus. Pour dire, on a meme jamais fait de velo!
> et bien j'aimerai beaucoup savoir quelles rues tu empruntes en roller.
Il y a un parametre qui joue beaucoup : on fait du roller pour le plaisir. Tu vas probablement a ton travail en velo. Ce n'est pas les memes horaires, la meme circulation et pas les memes choix d'itineraires. A la meilleure heure pour faire du roller (21h00), il y a de la place sur le trottoirs et sur la route. Et il y a moins de moto qui remontent le boulevard St Michel par la voie de bus que le reste du temps.
Si on prend l'exemple de rue de Rivoli, il y a une voie reservee velos qui est bien pratique et qu'on emprunte avec joie. Sauf qu'il y a des pietons qui campent tous les 20 metres. Sur la gauche, on est coince par les voitures garees donc on ne peut pas aller sur la route. Du coup, on monte sur le troittoirs. Sinon, on peut s'arreter poliment tous les 20m et demander poliment aux pietons de laisser une place pour qu'on puisse passer poliment et recommencer 3s plus loin.
> Oui en ville y'a des grands mères, des mômes sortant de l'école qui courent partout, des chiens qui font n'imp...
Alors, je vais pas defendre la pratique de tous les rollers car il y a des comportements que je desapprouve.
Typiquement, je ne fais jamais de roller entre 8h et 10h00 du matin en semaine parce que d'une part les troittoirs sont satures (c'est ingerable) et d'autre part, les conducteurs de voitures sont tres stresses et vraiment agressifs et dangereux. En plus, la circulation est tres intense. Idem entre 18h00 et 19h00.
Donc je croise peu de grand-meres, de gamins qui courent dans tous les sens, de clebards excites. Je roule a partir de 20h00 ou 21h00, lorsque les rues sont calmes, ou bien le samedi et le dimanche.
Les seuls endroits ou je croise des pietons alors que je suis a fond sont des endroits ou il y a largement la place : boulevard St Germain, boulevard St Michel, Champs Elysees, quais de Seine, etc. Dans les autres rues, s'il y a des pietons, on va en general directement descendre sur le troittoir.
Cependant, il est vrai que ca ne me gene pas de m'integrer dans la circulation des voitures qui roulent a 15-20 km/h en respectant leur vitesse. Et je n'hesite pas a alterner les chemins en fonctions des "obstacles" : pietons qui campent sur la voie reservee aux velos, pietons qui marchent sur la voie reservee aux velos, taxi arretes qui obligeraient a passer au milieu de la route, trottoir bouche pour une raison quelconque (enfants, clebards, groupe de gens, elephant rose, ...)
Quand on roule, on est dans un mode ou on surveille tout: l'etat du sol, la couleur des feux, la direction des gens, leur vitesse, les velos, les voitures, les scooters, ... . Si il y a des gamins devant moi, soit je passe a plus de 3m, soit je m'arrete parce que les enfants ont tendance a se mettre a courrir soudainement. S'il y a des clebards, j'essaie d'eviter. Malheureusement, on a invente les laisses de 10 metres qui barrent completement la route, ou meme un pieton ne pourrait pas passer (mais c'est probablement normal, le troittoir a ete invente pour les pietons et les clebards !).
Maintenant, il y a des gens qui se sentent agresses rien que par le fait qu'on existe. Ils se sont pris une fois un gros con de roller debutant sur la gueule, et ensuite considerent que tous les rollers sont des dangers publics.
Tu veux que je pleure sur un conducteur de voiture qui a fauche un roller qui prenait des risques sur la route et qui fait une depression a cause de ca ?
Je veux bien que tu critiques le roller, mais faut pas exagerer. Qui plus est, pour tuer un roller, je pense qu'il faut avoir une conduite en voiture vraiment dangereuse.
Pour relativiser, et en ce qui me concerne, c'est exceptionnel que je trace dans des endroits encombres de pietons.
Pour le pieton qui reste petrifie sur place, le mieux est de ne rien faire, comme si on n'existait pas, et de profiter du courant d'air.
<< Le problème des rollers c'est qu'ils tiennent absolument à évoluer sur des environements ou ils sont minoritaires et sans faire l'effort de s'adapter aux autres, qui sont forcement des cons marchant n'importe comment. >>
Bon, va falloir que je m'habitue a ta haine alors. Cela dit, tout les rollers ne prennent pas les pietons pour des "cons qui marchent n'importe comment".
Au fait, dis-moi, t'as deja traverse une rue alors que le feu etait rouge pour les pietons ? Expliques-moi comment tu justifies cette action et cette derogation aux lois, cette invasion d'un territoire reserve aux voitures, aux taxis, au scooters, aux velos et aux motos ?
<< Note : j'ai fait 4 ans de street histoire de couper court à la réponse tu peux pas comprendre toussa :-)
>>
Typiquement, j'aime pas le concept de street (ou en tout cas de certaines de ses formes) parce que ca degrade le mobilier urbain. En plus, t'es vachement dependant de ton environnement. Il faut une rampe, des tremplins, des protections, une salle, etc etc.
D'un point de vue personnel, je trouve que ca manque vraiment de style. Pas de detente, pas de souplesse, pas beaucoup de technique de detail (comparee au slalom). Un bon slide m'impressionne bien plus que 50% des trick de streeters.
Avec le slalom, les sauts a notre dame ou au trocadero, on a jamais rien abime. On s'adapte a notre environnement qui est Paris et on le respecte.
Sinon, je pense que les rollers ne sont plus du tout minoritaire. Donc qu'est-ce qu'on fait, on interdit ce moyen de transport ecolo et sain ? On construit des voies rollers a cote de voies velo (le top, il n'y aurait plus de place pour les voitures).
<< de manière à ce que vous vous rendiez compte de l'effet que ça fait de se faire bouler par un gros con sur roues lancé à pleine vitesse.
>>
Tu te trompes de cible. Ceux qui te boulent en roller, c'est ceux qui ne savent pas en faire mais qui sortent quand meme le samedi apres-midi sans prendre le temps d'apprendre, sans savoir freiner ou meme ralentir, mais qui vont quand meme aller dans des endroits ou ils prennent de la vitesse et ou il ne controlent rien du tout.
Les rollers que tu as vu sur les video et les vrais rollers parisiens, je doute qu'ils aient jamais touche un pieton de leur vie. En ce qui me concerne, sans avoir le niveau d'Hakim ou de Walid, en 10 ans de roller dans Paris, j'ai touche une fois un pieton, et c'etait parce qu'un gros con de roller debutant arrivait super vite sur moi et m'a telescope vers un pieton.
J'comprends que tu ne nous comprenne pas. Mais le plaisir de la glisse, le frisson de la vitesse et du risque, c'est unique ! On peut pas imaginer le plaisir qu'il y a a faire le boul'mich en croise arriere sur la voie de bus.
Je comprends pas trop ta reaction. La personne mise en danger, c'est lui. Quand il passe entre les voitures a fond, c'est la ou il risque sa vie.
Les pietons risquent 10 fois moins leur vie quand il leur passe a cote qu'en traversant une rue dans Paris. Et il passe plutot loin.
A te lire, je pensais qu'on allait voir un type descendant le boulevard st michel sur le trottoire un samedi apres-midi avec les pietons qui se jettent sur le cote pour le laisser passer. On est loin de ca, il y a de la place, il est total maitrise, personne n'a eu a se pousser pour le laisser passer.
Non, sincerement, il n'y a pas de danger pour les pietons. Ceux qui sont dangereux, c'est pas les mecs comme lui, c'est les abrutis de rollers qui tiennent a peine debout et se jettent sur tout ce qui depasse (y compris les gens) pour ne pas tomber. Ou bien qui font des randos qui depassent leur niveau et qui s'accrochent aux gens qui passent quand il tombent.
Desole, mais je ne vais pas pleurer sur l'entreprise coincee par cet aspect (et je suis chef d'entreprise).
Si tu veux absolument recuperer du code GPL dans ton projet close source, tu contactes les developpeurs et tu leurs demandes leur avis. En general, tu as 3 types de reponse possibles:
1. RMS mode: JAMAIS !!!!
2. pragmatic mode : ok, je veux 100 ke brut et vous avez mon code plus un mec competent
3. cool mode : je veux bien le relicencier pour vous, pour que dans le cadre de votre projet, vous puissiez l'utiliser.
Dans le cas 2, il faut que l'entreprise passe par le portefeuille. C'est la que tu t'apercois que les gens qui sont "super interesses par ce que tu as fait" sont tout d'un coup beaucoup moins chaleureux.
Je peux citer le cas du moteur JavaScript de Qt (QSA) qui a ete developpe par le mec ayant ecrit le moteur javascript de konqueror, re-embauche par Trolltech.
Warwick allison aussi avait developpe des QCanvas et deux trois autres trucs en Qt avant de rentrer chez Trolltech. Ils font partie de Qt maintenant.
Donc on voit que pour une boite comme Trolltech qui joue le jeu de la GPL, ca se passe bien.
> Or aujourd'hui bizarrement, GIT ca va lui convenir
Bizarre en effet qu'un logiciel qu'il developpe lui-meme lui convienne. C'est encore plus bizarre, que pendant 3 ans il critique les divers SCM et que au bout de 3 ans, tout d'un coup, il ne se mettent pas a convenir par un coup de baguette magique. Dans tes bizzareries, j'y verrai juste une opinion technique persistante.
> GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Il faut voir que Linus n'utilise pas un SCM de facon traditionelle. D'habitude, les SCM servent a partager du code et a garder une tracabilite. Dans le cas de Linux, le gestionnaire doit permettre a Linus de lire et d'integrer rapidement les patchs qu'on lui soumet avec une contrainte majeur de vitesse.
Les divers SCM dont tu parles n'ont pas ete developpe dans ce contexte et il n'est pas surprenant qu'ils ne conviennent pas parfaitement.
> Par contre, qu'il chippe les forces de dév en attirant des gens
Il ne vole personne, les gens sont libres de travailler sur ce que bon leur semble. Est-ce qu'on se plaint que KDE vole des forces de dev Gnome ?
> sur un projet à la durée de vie contestable
Dans la mesure ou c'est un projet central du noyau, sa duree de vie sera incontestablement liee a la duree de vie du noyau. Autant dire que pour l'instant, c'est partie pour longtemp.
> dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
La communaute des developpeurs du noyau profite. En fait, tu lui reproches de bosser trop sur Linux ? Pourquoi ne pas lui demander de bosser pour KDE aussi ?
A lire le resume sur kerneltrap, la contrainte no 1 est le temps qu'il faut pour appliquer un jeu de changement. Il a evalue tous les SCM et a chaque fois, il semble que cela ait ete le point bloquant.
Dans un mail, il disait qu'il avait facilement chaque jour 200 patchs a integrer pour une personne. Si integrer un patch prend 30 secondes, 200 patch, ca fait 1h20, ce qui ne semble pas le temps dont Linus a a sa disposition. Partant de la, on comprends qu'il developpe son truc, qu'a l'air pas mal et qui resoud aussi un autre probleme, le probleme de la confiance.
Linux est developpe avec une dictature bienveillante. Si tu veux une democratie, tu peux faire un fork du noyau qui sera developpe democratiquement avec un gestionnaire de source choisi democratiquement, auxquels les developpeurs du noyau contribueront pour qu'il arrive a gerer les 60 000 fichiers du noyau. Bonne chance !
Bitkeeper et git n'ont pas du tout le meme objectif, ni le meme jeu de fonctionnalite.
Si tu regardes git, ca ne resemble a aucun gestionnaire de source existant (peut-etre arch ?), donc visiblement, on n'aurait pas pu le faire en faisant evoluer CVS.
Linus se concentre probablement sur les fonctionnalites qui lui paraissent les plus essentielles dans un gestionnaire de conf pour gerer les sources du noyau.
Il a aussi l'experience de bitkeeper pour savoir ce qu'on peut faire, ce qui l'interesse lui, ce dont le kernel a besoin maintenant, etc etc.
Son truc pour l'instant n'a pas l'air d'avoir beaucoup de points communs avec bitkeeper.
J'ai pas le niveau pour comprendre l'interet de toutes les exigences, qui il est vrai sont la pour respecter le standard C++.
Mais si c'est pour que les // ne soient pas supportes en C parce que le standard l'interdit, est-ce que ca vaut le coup. Je me demande si les exigences de compatbilites ne sont pas de ce niveau la.
Le C++ reste un langage incroyablement complexe. Il reste cependant possible de coder en l'utilisant simplement. J'espere que ces 'mises au standard" ne vont pas retirer cette possiblite.
Je suis d'accord avec toi, mais il ne faut pas tomber dans l'exces inverse: des gens qui n'ont que survole les langages et qui les connaissent mal.
Si tu n'as fait que survoler du C++, j'espere que quand tu as commence ton stage, tu t'es achete un bon bouquin et tu as comble tes lacunes.
Pour citer un exemple, j'ai fait passer des entretiens a des stagiaires qui avaient fait du C++ mais pas de C, ou bien du C++ mais pas de pointeurs. Ca me parait tres tres limite et je ne comprends pas trop le raisonnement de leur prof. Si ils veulent leur eviter les pointeurs, qu'il leur fassent faire du Java.
Le fait d'avoir fait une incursion dans un autre paradigme de programmation te permettra d'avoir plus de solutions dans ta boite a outils du programmeur. Tu verras qu'un jour, ca fera la difference chez un client.
Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
C'est pour ca que c'est important d'avoir touche a OCaml.
Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
Comme d'habitude, a chaque fois que je lis des docs sur le Hurd, je reste sur une impression tres mitigee.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
Oui, unsermake est deja utilise mais ton commentaire est tout a fait pertinent. unsermake ne fait que simplifier une des 12 etapes qui genere les makefile de KDE.
Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
La fonctionnalite qui me plait le plus avec subversion, c'est qu'on peut faire un diff de facon instantanee, sans avoir une connexion avec le serveur.
Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.
A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.
[^] # Re: Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 10.
La programmation par evenement est beaucoup moins souple que les signaux/slot facon Qt, car un evenement ne peut contenir que tres peu d'information: "il se passe qqch". Du coup, pour transporter des informations complexes, on est obliger de rajouter du code qui va chercher l'information la ou elle est. Les exemples simples comme le hello world ne mettent pas en evidence ce probleme, mais quand on rentre dans des cas reels, le flux de communication de donnees a l'interieur de l'application devient complexe. Avec une programmation purement evenementielle comme wxWidgets (ou MFC), ce flux est penible a gerer.
La communication par signaux permet de completement separer la preparation des donnees de leur traitement, et d'offrir plus d'independance entre les differents objets d'une application. Pour ceux qui sont familiers avec les Design Pattern, c'est un probleme recurrent resolu par le Mediateur. Pour faire communiquer un objet A avec un objet B, soit B doit connaitre A, soit A doit connaitre B, soit il y a un objet C entre A et B qui connait A et B. On peut dans ce cas faire evoluer A separement de B a condition de faire suivre C, qui devient le mediateur.
Ce qui est fort avec Qt, c'est que pour les cas simples, le mediateur, c'est la connection signal/slot et qu'il n'y a donc pas besoin de pondre une classe pour ca.
Je donne un exemple simpliste mais concret: une interface graphique doit generer des rectangles dont l'utiisateur controle la hauteur et la largeur. Il entre deux nombres de facon diverses, clique sur un bouton et un rectangle doit etre genere.
Cote interface, il y a donc du code qui doit lire deux nombre. On imagine deux spinbox et un bouton pour generer le tout. De l'autre cote, il y a une partie du programme qui recoit le "signal" de generer un nouveau rectangle.
En Qt, ca donnerait qqch dans le style:
class MyRectangleInput : public QVBox {
Q_OBJECT
public:
MyRectangleInput( QWidget * parent ) {
spin1 = new QSpinBox( this );
spin2 = new QSpinBox( this );
QPushButton * button = new QPushButton("Generate Rectangle");
connect( button, SIGNAL(clicked), this, SLOT(slotGenerate) );
}
slots:
void slotGenerate() {
emit generateRectangle( spin1->value(), spin2->value() );
}
signals:
void generateRectangle( int width, int height );
protected:
QSpinBox *spin1, *spin2;
};
De l'autre cote, on a la classe reception :
class RectangleGenerator : public QWidget
{
// [...]
public slots:
slotGenerateRectangle( int width, int height ) {
// create new rectangle
}
};
Pour faire marcher le tout, il doit y avoir un moment donne une connection entre une instance de MyRectangleInput et RectangleGenerator:
connect( myRectangleInstance, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstance, SLOT(slotGenerateRectangle(int,int)) );
On voit bien que les deux classes sont completement independantes, et ce qui les lie, c'est la connection signal / slot.
[ A noter que le MyRectangleInput peut etre librement redimensionner et que les widget adapteront la bonne taille ]
Si on revient a un toolkit base sur des evenements, on aurait une problematique differente. Je ne connais pas bien wxWidget, mais en reprenant le concept general de la haut, la classe A, c'est le MyRectangleInput, et la classe B, c'est le RectangleGenerator. Dans le cas ou on appuie sur le bouton, un evenment GENERATE_RECTANGLE est envoye. De la, il y a le choix:
- B connait A : la classe RectangleGenerator dispose d'un pointeur vers la classe MyRectangleInput et va lire elle-meme le contenu des spinbox. Le probleme, c'est que si on remplace les spinbox par autre chose, il faut faire evoluer aussi la classe RectangleGenerator. Un autre probleme qui est beauoup plus contraignant, c'est que RectangleGenerator doit disposer d'un pointeur sur MyRectangleInput. Que se passe-t-il si il y a plusieurs MyRectangleInput ? Il faut gerer la vie du pointeur. Que se passe-t-il si une autre partie de l'application veut effacer un pointeur sur MyRectangleInput ? Elle doit en informer toutes les classes qui possedent un pointeur sur MyRectangleInput. Plutot lourd.
- A connait B : cette fois, c'est MyRectangleInput qui connait bien RectangleGenerator, qui appelle directement l'instance avec les bons parametres qu'il va chercher en interne. On peut donc faire evoluer MyRectangleInput facilement. Mais on retombe vite dans une problematique similaire : imaginons qu'on aie plusieurs destinataires du message GENERATE_RECTANGLE. Ils doivent tous s'enregistrer aupres de MyRectangleInput et tous avoir une interface commune. Si en plus on a plusieurs generateurs, on arrive vite a une situation ou il y a n generateurs, n recepteurs et on doit maintenir n x n liens tout en sachant a tout moment que faire si des pointeurs sont effaces.
- C connait A et B : c'est pour ca qu'on a besoin d'une classe supplementaire C. Elle va recevoir l'evenement GENERATE_RECTANGLE, aller cherche l'info dans A parce qu'elle connait bien l'implementation de A, puis dispatcher cette information dans B. Si il y a plusieurs RectangleGenerator et plusieurs MyRectangleInput, la class C maintient la liste des associations et est la seule classe qui doit etre au courant quand un nouveau pointeur est cree ou supprime.
L'avantage dans le modele signaux/slot, c'est qu'on a pas besoin de classe C. Elle est deja dans le toolkit. Dans les problematiques que j'ai cite, on peut imaginer en QT :
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance1, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceA, SLOT(slotGenerateRectangle(int,int)) );
connect( myRectangleInstance2, SIGNAL(generateRectangle(int,int)), rectangleGeneratorInstanceB, SLOT(slotGenerateRectangle(int,int)) );
si on efface un pointeur myRectangleInstanceX, il n'y a rien de special a faire, la connection disparait toute seule. Idem si on efface un rectangleGeneratorX.
Ce probleme peut paraitre simpliste, mais dans une application graphique (et meme non graphique), on a beaucoup de morceaux d'applications a faire communiquer ensemble (typiquement, le frontend et le backend) et les facilites fournies par Qt permettent de gerer cela avec beaucoup de legerete et d'elegance.
Avec une programmation par evenement, le code devient vite abominable et on est tout de suite obliger de faire appel a moultes Design Pattern pour garder un truc maintenable.
# Je me marre
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 2.6 est sorti. Évalué à 1.
Si j'ai bien compris, c'est ce qui permet de faire facilement des fenetres redimensionnables. Impressionnant, c'etait une fonctionnalite de base dans Qt 1.0 (les qlayout) et dans Gtk 1.0 aussi (gtk_pack il me semble).
J'ai du mal a imaginer qu'on puisse sortir un toolkit graphique au 3 millenaire sans ce type de fonctionnalite !
C'est bien, on progresse ! Plus que 10 ans a wxWidget pour rattrapper le retard sur les autres toolkits.
ok, je sors ----> []
[^] # Re: BK vs git.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 6.
D'un autre cote, elle a surement permis a Linus de se fixer les idees sur ce qu'il voulait dans un SCM (et pas un CMS, vive les acronymes). Avant bitkeeper, il n'en avait pas trouve qui lui convienne et il n'aurait probablement pu en pondre un aussi vite.
Linus a aussi eu l'habitude de travailler pendant tres longtemps avec des outils tres simples: patch, diff, et le mail pour stocker les patches en cours. Je soupconne que s'il n'avait pas eu un outil tres sophistique pendant quelques temps, il aurait continue avec sa methode a lui qui marchait tres bien, c'est a dire a la mano. Evidemment, on peut tout supposer mais de mon point de vue, l'utilisation de bitkeeper a engendre git et ce dernier n'aurait pas vu le jour sans cette periode de transition.
[^] # Re: Tracabilité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le développement du noyau continue autour de Git. Évalué à 2.
En attendant, ca reste un peu stressant comme situation, ce ne pas avoir l'historique.
[^] # Re: Il a pas tord
Posté par Philippe F (site web personnel) . En réponse au journal du troll de compete. Évalué à 1.
Maintenant, ramene ca a la realite du desktop, ou il n'y a qu'un seul utilisateur, ou bien ou alors plusieurs utilisateurs partagent en general le meme compte (maman, papa) et tu peux mettre ton raisonnement a la poubelle.
Cela dit, c'est chiant de devoir re-installer une machine.
[^] # Re: Pfff....
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 2.
Ce serait genial si tu n'etait pas une malheureuse exception.
> Je vais bien rire lorsque ce sera le cas parce qu'en tant que roller ce sera toi qui deviendra le "piéton" par rapport aux bus, taxis, motos
Ca va etre une revolution pour nous. On est tellement con, on etait jamais alle sur la route et on savait pas comment c'etait, on ne s'est jamais fait colle par un taxi, frole par un bus. Pour dire, on a meme jamais fait de velo!
> et bien j'aimerai beaucoup savoir quelles rues tu empruntes en roller.
Il y a un parametre qui joue beaucoup : on fait du roller pour le plaisir. Tu vas probablement a ton travail en velo. Ce n'est pas les memes horaires, la meme circulation et pas les memes choix d'itineraires. A la meilleure heure pour faire du roller (21h00), il y a de la place sur le trottoirs et sur la route. Et il y a moins de moto qui remontent le boulevard St Michel par la voie de bus que le reste du temps.
Si on prend l'exemple de rue de Rivoli, il y a une voie reservee velos qui est bien pratique et qu'on emprunte avec joie. Sauf qu'il y a des pietons qui campent tous les 20 metres. Sur la gauche, on est coince par les voitures garees donc on ne peut pas aller sur la route. Du coup, on monte sur le troittoirs. Sinon, on peut s'arreter poliment tous les 20m et demander poliment aux pietons de laisser une place pour qu'on puisse passer poliment et recommencer 3s plus loin.
[^] # Re: Pfff....
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 2.
Alors, je vais pas defendre la pratique de tous les rollers car il y a des comportements que je desapprouve.
Typiquement, je ne fais jamais de roller entre 8h et 10h00 du matin en semaine parce que d'une part les troittoirs sont satures (c'est ingerable) et d'autre part, les conducteurs de voitures sont tres stresses et vraiment agressifs et dangereux. En plus, la circulation est tres intense. Idem entre 18h00 et 19h00.
Donc je croise peu de grand-meres, de gamins qui courent dans tous les sens, de clebards excites. Je roule a partir de 20h00 ou 21h00, lorsque les rues sont calmes, ou bien le samedi et le dimanche.
Les seuls endroits ou je croise des pietons alors que je suis a fond sont des endroits ou il y a largement la place : boulevard St Germain, boulevard St Michel, Champs Elysees, quais de Seine, etc. Dans les autres rues, s'il y a des pietons, on va en general directement descendre sur le troittoir.
Cependant, il est vrai que ca ne me gene pas de m'integrer dans la circulation des voitures qui roulent a 15-20 km/h en respectant leur vitesse. Et je n'hesite pas a alterner les chemins en fonctions des "obstacles" : pietons qui campent sur la voie reservee aux velos, pietons qui marchent sur la voie reservee aux velos, taxi arretes qui obligeraient a passer au milieu de la route, trottoir bouche pour une raison quelconque (enfants, clebards, groupe de gens, elephant rose, ...)
Quand on roule, on est dans un mode ou on surveille tout: l'etat du sol, la couleur des feux, la direction des gens, leur vitesse, les velos, les voitures, les scooters, ... . Si il y a des gamins devant moi, soit je passe a plus de 3m, soit je m'arrete parce que les enfants ont tendance a se mettre a courrir soudainement. S'il y a des clebards, j'essaie d'eviter. Malheureusement, on a invente les laisses de 10 metres qui barrent completement la route, ou meme un pieton ne pourrait pas passer (mais c'est probablement normal, le troittoir a ete invente pour les pietons et les clebards !).
Maintenant, il y a des gens qui se sentent agresses rien que par le fait qu'on existe. Ils se sont pris une fois un gros con de roller debutant sur la gueule, et ensuite considerent que tous les rollers sont des dangers publics.
[^] # Re: Planquez vous
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 1.
Je veux bien que tu critiques le roller, mais faut pas exagerer. Qui plus est, pour tuer un roller, je pense qu'il faut avoir une conduite en voiture vraiment dangereuse.
# Meme question pour ordinateur usage
Posté par Philippe F (site web personnel) . En réponse au journal Jeter une batterie d'ordinateur portable ?. Évalué à 6.
[^] # Re: Pfff....
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 1.
Pour le pieton qui reste petrifie sur place, le mieux est de ne rien faire, comme si on n'existait pas, et de profiter du courant d'air.
<< Le problème des rollers c'est qu'ils tiennent absolument à évoluer sur des environements ou ils sont minoritaires et sans faire l'effort de s'adapter aux autres, qui sont forcement des cons marchant n'importe comment. >>
Bon, va falloir que je m'habitue a ta haine alors. Cela dit, tout les rollers ne prennent pas les pietons pour des "cons qui marchent n'importe comment".
Au fait, dis-moi, t'as deja traverse une rue alors que le feu etait rouge pour les pietons ? Expliques-moi comment tu justifies cette action et cette derogation aux lois, cette invasion d'un territoire reserve aux voitures, aux taxis, au scooters, aux velos et aux motos ?
<< Note : j'ai fait 4 ans de street histoire de couper court à la réponse tu peux pas comprendre toussa :-)
>>
Typiquement, j'aime pas le concept de street (ou en tout cas de certaines de ses formes) parce que ca degrade le mobilier urbain. En plus, t'es vachement dependant de ton environnement. Il faut une rampe, des tremplins, des protections, une salle, etc etc.
D'un point de vue personnel, je trouve que ca manque vraiment de style. Pas de detente, pas de souplesse, pas beaucoup de technique de detail (comparee au slalom). Un bon slide m'impressionne bien plus que 50% des trick de streeters.
Avec le slalom, les sauts a notre dame ou au trocadero, on a jamais rien abime. On s'adapte a notre environnement qui est Paris et on le respecte.
Sinon, je pense que les rollers ne sont plus du tout minoritaire. Donc qu'est-ce qu'on fait, on interdit ce moyen de transport ecolo et sain ? On construit des voies rollers a cote de voies velo (le top, il n'y aurait plus de place pour les voitures).
[^] # Re: Planquez vous
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 0.
C'est probablement le meme que tu admireras un jour sur un slalom, qui s'integrera a la circulation a 30 km/h rue de Rivoli ou rue Claude Bernard.
Et toi, avec ton logiciel libre, fout pas le bordel chez les gens normaux non plus (ceux qui utilisent microsoft).
[^] # Re: Pfff....
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 1.
>>
Tu te trompes de cible. Ceux qui te boulent en roller, c'est ceux qui ne savent pas en faire mais qui sortent quand meme le samedi apres-midi sans prendre le temps d'apprendre, sans savoir freiner ou meme ralentir, mais qui vont quand meme aller dans des endroits ou ils prennent de la vitesse et ou il ne controlent rien du tout.
Les rollers que tu as vu sur les video et les vrais rollers parisiens, je doute qu'ils aient jamais touche un pieton de leur vie. En ce qui me concerne, sans avoir le niveau d'Hakim ou de Walid, en 10 ans de roller dans Paris, j'ai touche une fois un pieton, et c'etait parce qu'un gros con de roller debutant arrivait super vite sur moi et m'a telescope vers un pieton.
J'comprends que tu ne nous comprenne pas. Mais le plaisir de la glisse, le frisson de la vitesse et du risque, c'est unique ! On peut pas imaginer le plaisir qu'il y a a faire le boul'mich en croise arriere sur la voie de bus.
[^] # Re: Planquez vous
Posté par Philippe F (site web personnel) . En réponse au journal RollerFr.net : un site libre sur roller acrobatique et le freeride. Évalué à 0.
Les pietons risquent 10 fois moins leur vie quand il leur passe a cote qu'en traversant une rue dans Paris. Et il passe plutot loin.
A te lire, je pensais qu'on allait voir un type descendant le boulevard st michel sur le trottoire un samedi apres-midi avec les pietons qui se jettent sur le cote pour le laisser passer. On est loin de ca, il y a de la place, il est total maitrise, personne n'a eu a se pousser pour le laisser passer.
Non, sincerement, il n'y a pas de danger pour les pietons. Ceux qui sont dangereux, c'est pas les mecs comme lui, c'est les abrutis de rollers qui tiennent a peine debout et se jettent sur tout ce qui depasse (y compris les gens) pour ne pas tomber. Ou bien qui font des randos qui depassent leur niveau et qui s'accrochent aux gens qui passent quand il tombent.
[^] # Re: Rien de mal à être contaminé !
Posté par Philippe F (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 10.
Si tu veux absolument recuperer du code GPL dans ton projet close source, tu contactes les developpeurs et tu leurs demandes leur avis. En general, tu as 3 types de reponse possibles:
1. RMS mode: JAMAIS !!!!
2. pragmatic mode : ok, je veux 100 ke brut et vous avez mon code plus un mec competent
3. cool mode : je veux bien le relicencier pour vous, pour que dans le cadre de votre projet, vous puissiez l'utiliser.
Dans le cas 2, il faut que l'entreprise passe par le portefeuille. C'est la que tu t'apercois que les gens qui sont "super interesses par ce que tu as fait" sont tout d'un coup beaucoup moins chaleureux.
Je peux citer le cas du moteur JavaScript de Qt (QSA) qui a ete developpe par le mec ayant ecrit le moteur javascript de konqueror, re-embauche par Trolltech.
Warwick allison aussi avait developpe des QCanvas et deux trois autres trucs en Qt avant de rentrer chez Trolltech. Ils font partie de Qt maintenant.
Donc on voit que pour une boite comme Trolltech qui joue le jeu de la GPL, ca se passe bien.
[^] # Re: L'info sur kerneltrap
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 5.
Bizarre en effet qu'un logiciel qu'il developpe lui-meme lui convienne. C'est encore plus bizarre, que pendant 3 ans il critique les divers SCM et que au bout de 3 ans, tout d'un coup, il ne se mettent pas a convenir par un coup de baguette magique. Dans tes bizzareries, j'y verrai juste une opinion technique persistante.
> GIT c'est un embryon de SCM, bien loin de couvrir ce que fait BK, et Monotone/Darcs/Arch....
Il faut voir que Linus n'utilise pas un SCM de facon traditionelle. D'habitude, les SCM servent a partager du code et a garder une tracabilite. Dans le cas de Linux, le gestionnaire doit permettre a Linus de lire et d'integrer rapidement les patchs qu'on lui soumet avec une contrainte majeur de vitesse.
Les divers SCM dont tu parles n'ont pas ete developpe dans ce contexte et il n'est pas surprenant qu'ils ne conviennent pas parfaitement.
> Par contre, qu'il chippe les forces de dév en attirant des gens
Il ne vole personne, les gens sont libres de travailler sur ce que bon leur semble. Est-ce qu'on se plaint que KDE vole des forces de dev Gnome ?
> sur un projet à la durée de vie contestable
Dans la mesure ou c'est un projet central du noyau, sa duree de vie sera incontestablement liee a la duree de vie du noyau. Autant dire que pour l'instant, c'est partie pour longtemp.
> dont la communauté de l'OSS ne pourrait pas profiter car trop Linux-centré, je trouve ça un peu dommage.
La communaute des developpeurs du noyau profite. En fait, tu lui reproches de bosser trop sur Linux ? Pourquoi ne pas lui demander de bosser pour KDE aussi ?
[^] # Re: L'info sur kerneltrap
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 4.
Dans un mail, il disait qu'il avait facilement chaque jour 200 patchs a integrer pour une personne. Si integrer un patch prend 30 secondes, 200 patch, ca fait 1h20, ce qui ne semble pas le temps dont Linus a a sa disposition. Partant de la, on comprends qu'il developpe son truc, qu'a l'air pas mal et qui resoud aussi un autre probleme, le probleme de la confiance.
Linux est developpe avec une dictature bienveillante. Si tu veux une democratie, tu peux faire un fork du noyau qui sera developpe democratiquement avec un gestionnaire de source choisi democratiquement, auxquels les developpeurs du noyau contribueront pour qu'il arrive a gerer les 60 000 fichiers du noyau. Bonne chance !
[^] # Re: Licence de BitKeeper
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 3.
[^] # Re: Rapidité étonnante
Posté par Philippe F (site web personnel) . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 10.
Si tu regardes git, ca ne resemble a aucun gestionnaire de source existant (peut-etre arch ?), donc visiblement, on n'aurait pas pu le faire en faisant evoluer CVS.
Linus se concentre probablement sur les fonctionnalites qui lui paraissent les plus essentielles dans un gestionnaire de conf pour gerer les sources du noyau.
Il a aussi l'experience de bitkeeper pour savoir ce qu'on peut faire, ce qui l'interesse lui, ce dont le kernel a besoin maintenant, etc etc.
Son truc pour l'instant n'a pas l'air d'avoir beaucoup de points communs avec bitkeeper.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Philippe F (site web personnel) . En réponse au journal De gcc3 à gcc4 : Un code plus propre ?. Évalué à 1.
J'ai pas le niveau pour comprendre l'interet de toutes les exigences, qui il est vrai sont la pour respecter le standard C++.
Mais si c'est pour que les // ne soient pas supportes en C parce que le standard l'interdit, est-ce que ca vaut le coup. Je me demande si les exigences de compatbilites ne sont pas de ce niveau la.
Le C++ reste un langage incroyablement complexe. Il reste cependant possible de coder en l'utilisant simplement. J'espere que ces 'mises au standard" ne vont pas retirer cette possiblite.
[^] # Re: Pérénité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 1.
Si tu n'as fait que survoler du C++, j'espere que quand tu as commence ton stage, tu t'es achete un bon bouquin et tu as comble tes lacunes.
Pour citer un exemple, j'ai fait passer des entretiens a des stagiaires qui avaient fait du C++ mais pas de C, ou bien du C++ mais pas de pointeurs. Ca me parait tres tres limite et je ne comprends pas trop le raisonnement de leur prof. Si ils veulent leur eviter les pointeurs, qu'il leur fassent faire du Java.
[^] # Re: Pérénité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Présentation d'OCaml à Rennes le jeudi 7 avril, 20h, MCE, 48 bd Magenta. Évalué à 2.
Genre un jour, tu vas tomber sur un projet. Tu vas commencer a te prendre la tete avec des objets et de l'heritage et tout d'un coup, l'illumation te viendra: c'est un probleme qui doit se resoudre avec une approche beaucoup plus fonctionelle. Meme si tu codes au final la solution en C++, tu utiliseras des techniques de programmation fonctionelle qui te donneront une solution plus elegante qu'une solution en style objet.
C'est pour ca que c'est important d'avoir touche a OCaml.
Si tu vas voir la page du "Great Language Shootout", tu verras que OCaml a le meilleur score dans de nombreuses configurations.
Meme si je n'en ai pas fait beaucoup, ce que j'ai aime dans ce langage, c'est l'inference de type. Alors que python introduit des bugs subtils et indectables par sa resolution dynamique des attributs, OCaml a une approche hyper clean qui te permet de trouver des problemes subtils tres tot dans le cycle de dev. Et surtout, il ne te force pas la main sur les types (contrairement au C++ ou a Ada ou tu dois vraiment _tout_ dire) mais se debrouille lui-meme pour deduire des infos que tu lui as fourni, les types qui sont utilises.
[^] # Re: Bravo
Posté par Philippe F (site web personnel) . En réponse à la dépêche talweg, solution de portail captif. Évalué à 2.
C'est monte comment leur systeme ?
# Mouai
Posté par Philippe F (site web personnel) . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 4.
Ce truc a tres peu d'applications pratiques. Un des avantages de Linux, et ce qui l'a tres vite distingue de minix, c'est qu'il est utile concretement. A cote de ca, Hurd reste un exercice de style.
Le fait est qu'un noyau reste un truc pour gerer du materiel. Mon impression est que Hurd veut reussir a abstraire completement cette partie, et que ca donne des resultats sous-optimaux, comme les problemes qu'il decrit avec la gestion de la memoire. Autant je pense qu'on peut faire abstraction de beaucoup de choses au niveau langage de programmation, autant je ne suis pas persuade que ca s'applique aussi bien a un OS (meme si PDP11 faisait des merveilles avec sa macine lisp, il parait).
Deporter la gestion de la memoire du cote des applications. Super! J'essaie de reflechir a quelle application de nos jours aurait besoin de sa propre gestion memoire. Ce serait soi des applications avec des besoins de tres grosses quantites, soit des applications avec des besoins de beaucoup de petites quantite (ce qui pousse parfois a re-ecrire son gestionnaire de memoire, le modele classique etant plutot adapte a des allocations de gros blocs de facon non repetees). Je suis curieux de savoir si dans la pratique, c'est super lourd a gerer ou s'il suffit juste de linker avec libmemory et ca marche tout seul.
Je pense aussi aux remarque d'Alan Cox, sur l'obsolescence du modele Hurd en tant que station de travail. Hurd est oriente serveur avec plusieurs utilisateurs, ce qui etait l'environnement classique de travail de l'epoque ou il a ete concu. Aujourd'hui, avec des postes PC mono-utilisateurs tout puissants, qui a besoin de monter son systeme de fichier en mode utilisateur ?
Ca n'enleve rien a la qualite du travail effectue, c'est juste que un peu comme quake en ascii-art, ca reste un exercice de style.
[^] # Re: pourquoi virer autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 2.
Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.
Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
[^] # Re: svn vs cvs
Posté par Philippe F (site web personnel) . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 6.
Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.
A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.