Chez nous on l'utilise pour les pimpls (Pointer to IMPLementation) une techique très simple pour séparer l'interface de l'implémentation d'un classe.
Ca évite de se soucier de faire le ménage. Un delete est si vite oublié...
Pas besoin de locker, ca utilise les operation d'incrémentation atomiques.
Ca a un coût, certes, mais c'est quand même efficace.
Ca vient de la lib boost, qui a servi de reference pour l'implémentation dans le standard.
Ce n'est pas dans les fonctionnalités de base de la console.
Le bootloader mentionné est un hack basé sur le bricolage d'une sauvegarde de partie du jeu Zelda Twilight Princess.
Il permet d'executer du code maison, dont un bootloader.
Cette faille a aussi été exploitée pour créer des applications (homebrew channel) qui facilite l'installation d'autres applications.
Je parle de systeme de révision *par fichier*, du type de celui présent dans CVS (il y a peut être un terme plus consacré), que nous utilisons également pour notre systeme qualité (ou chaque document est indépendant et dispose de son propre numéro de version, indépendament des autres, parfait pour la doc reglementaire).
Je conviens que ma dernière phrase pourrait être équivoque, ce n'était pas mon intention. J'essayais juste de fournir une explication qui m'aurait été utile quand je suis passé de CVS à un aute systeme.
Je ne comprends toujours pas pour quoi ca prête à rire.
Nous sommes d'accord. Je tente juste une explication sur la difference entre les changesets et le systeme de revisions par fichiers.
C'est quelque chose qui peut dérouter au début et c'est une notion fondamentale.
Je n'affirme a aucun moment que seuls les systemes distribuée en sont dotés. Je ne mentionne meme pas SVN.
Je ne saisis pas pourquoi je devrais rire de mon explication.
Le suivi par changeset nous facilite grandement la vie. Par exemple, en ce moment, nous finalisons une version de l'un de nos softs dans une branche. L'equipe QA nous envoie des bug reports. Nous corrigeons chacun de ces bugs et donc nous 'commitons' :) un patch, ou 'changeset' de quelques fichiers.
Par exemple dans la branche beta, le patch 7300 corrige le bug 120 et le changeset concerne 5 fichiers.
Il est tres simple dans la branche pricipale, de demander a bzr d'appliquer juste ce patch, sans tous les précédents, ou d'appliquer une liste de patch qui modifie des fichiers qui n'ont pas trop divergés , ce qui représente la majorité des cas sur une appli de la taille de la notre (sinon, de toute façon, il faut résoudre les conflits).
Cette operation se nomme 'cherrypicking' dans le vocabulaire des systemes de gestion de version distribués et représente un progrès dans notre façon de gérer nos sources et nos versions.
Chez nous le passage de CVS s'est fait sans douleur. Nous étions habituée a avoir un serveur central, une branche de dev, des branches pour les releases avec des tags (beta, rc et stables).
Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
C'est le meme fonctionnement que CVS, tres simple.
Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).
Nous l'utilisons aussi dans ma boite.
Nous en sommes satisfaits et les dernières versions sont bien plus rapides.
Pour la taille de notre projet, en tout cas, (+ 400K lignes, et bientôt 8000 revisions) ca fonctionne très bien.
Les versions se suivent assez rapidement, les développeurs sont très actifs. Il manque encore peut être quelques utilitaires (aussi évolués que CVSweb, par exemple) mais ça devrait arriver vite.
Les plateformes de dev sont sous Linux et Mac, mais les electroniciens l'utilisent également sous windows.
Concernant bazaar-ng, noun l'utilisons dans ma boite depuis 1 an. Les perfs s'améliorent de version en version et les plugins s'étoffent.
Pour le moment notre code ne contient que environ 80K lignes de code, mais ca grossit relativement vite ( la précédente version de notre soft toujours géré sous CVS a à peu pres 380K lignes ). Nous prévoyons que la nouvelle version sera plus conséquente que la précédente et pour le moment, nous n'envisageons pas de passer à autre chose que bazaar-ng.
Les perfs au commit/update ne sont pas vraiment un problème (pour nous, en tout cas), je ne pense pas que ca soit la meilleur façon de juger ce type d'outil. (a moins de faire un unpdate toute les 20 minutes :)
La fonctionnalité que j'appécie le plus sont les bound branches. Elles permettent d'émuler un fonctionnement centralisé ou chaque commit se fait simultanément sur le repository central et localement, on utilise que les commande commit/update. C'est tres pratique. Quand on le souhaite,on peu passer en mode décentralisé et se synchroniser avec la source que l'on veut ou bosser uniquement en local puis repasser en bound sur le serveur central avec une commande tres simple.
Les explications de James Blackwell sur le sujet (un des gars qui fait du support et aide les débutants) m'on vraiment bien aidé.
Je viens de jeter un oeil sur la doc de Gtk et il y a le passage suivant:
Cairo is a graphics library that supports vector graphics and image compositing that can be used with GDK. Since 2.8, GTK+ does most of its drawing using Cairo.
En gros Gtk utilise cairo pour la majorité de son rendu.
Cairo permet de dessiner entre autre en utilisant XCB ( et Xlib, opengl...). Donc si j'ai bien tout compris, Gtk+ pourrais déja bénéficier d'XCB...
Les distributions ne disposent peut être pas encore du cairo avec XCB, mais si ca peut marcher et que c'est vraiment plus efficace, ca ne devrait pas tarder à se généraliser.
Il y a une gamme de brother qui fonctionnent tres bien entre 100 et 250 euros.
J'ai une 2070N payée environ 200 euros, elle est économique et fonctionne tres bien avec CUPS et a un port ethernet.
Le premier prix de cette gamme, la HL 2030, est a 95 euro et ca doit fontionner également (elle est listée comme compatible).
Parmi les compromis, pourquoi pas développer un proto en python avec un affichage avec SDL, c'est tres simple pour afficher des graphismes. Puis optimiser uniquement les boucles critiques en c/c++ ?
Une autre solution pourrait consister à utiliser C++ et la bibliotheque boost. Les smart pointers, containers, et autre outils permetent d'éviter beaucoup de problèmes de gestion de la mémoire. Il y a des outils de gestion de graphes dans boost qui doivent être intéréssants en IA : www.boost.org.
En revanche, boost représente un investicement en terme d'apprentissage...
Est-il possible d'écouter un extrait des morceaux avant d'acheter ?
Il y a symbole avec un casque après le titre mais en cliquant dessus, c'est juste un lien vers la page courante (en tout cas, chez moi avec FireFox 1.5.0.3).
J'aimerais bien écouter deux ou trois trucs,il y a de styles musicaux dont j'avais jamais entendu parler...
Une petite précision sur mon message précédent:
Ca vas offrir des possibilités fantastiques pour le développement des applis mais ca complique pas mal l'écriture des drivers (qui doivent intégrer a présent un compilateur et un linker, rien que ca...). Mais heureusement, 3DLabs a mis a la disposition du plublic une implémentation de référence des ces deux outils pour simplifier les choses et surtout pour que les compilateur interpretent bien tous le code de la meme façon.
Certainement, en tout cas, les derniers drivers nvidia (proprios, ok, ok,...) permettent de programmer les shaders. Ils sont compatibles OpenGL 1.5 mais ca le fait deja. J'ai testé, ca fonctionne, le driver integre le compilateur et le linker.
Je crois que les drivers ATI faisant la meme chose ne devraient pas tarder (si ils ne sont pas deja sortis).
La version du driver que j'ai installé: 1.0.6111
Pour verifier si vos drivers (et votre carte supporte) le langage de shader:
glxinfo |grep GL_ARB_shading_language_100
Il me semble que les cartes nvidia qui le supportent sont les gammes FX (a partir de la FX5200) et les cartes ultérieures. Chez ATI, je crois aque c'est a partir de la Radeon 9500, mais c'est de mémoire, a verifier...
Les modeles précédents peuvent également etres programmée (fragment & vertex) mais en assembleur ou en utilisant un SDK comme le Cg de NVidia. Je ne parle ici que du langage de haut niveau intégé dans la lib OpenGL (GLSL).
Ouaip, c'est vrais que Scons a l'air pas mal.
Je l'ai essayé pour un tout petit projet fait a la maison parce que j'avais la flemme de me refaire toute la choucroute automake/autoconf pour gérer les dépendences proprement et ca marche super bien.
Il faut quelques minutes pour comprendre comment ecrire l'équivalent du makefile et hop ca roule!
Je suis en train de réflechir a la façon dont je pourrais migrer le projet de l'équipe au boulot (pas une mince affaire).
En tout cas, meme pour un tout petit projet d'une dizaine de fichiers, le bénéfice est immédiat!
Pour accelerer les compilation essayez ccache (ou distcc, si vous avez plusieurs machines dispo).
Comme son nom l'indique presque ccache stocke les resultats de compilation précédents et les ressorts si les sources sont identiques.
Sur notre projet, nous sommes passes de 12 minutes a 1 minute trente (et comme on utilise qmake/Qt et qu'il gere pas super bien les dépendences, on etait obligé de tout recompiler tres frequemment).
Bref, ca marche pas mal et on a pas encore eu de problemes avec.
Est-ce un troll ou une interrogation sincere ?
Je répond quand meme.
Il y a un gouffre entre la niaiserie disneyenne et Myasaki. Le public qu'il vise, par exemple, pour Porco Rosso est plutot l'adulte (M visait le plublic de son age). Ses histoires sont itemporelles. Tu ne trouverra pas dedans une demi douzaine de faire valoirs amusants pour faire vendre des menu McDo.
Si disney a racheter les droits d'exploitation a l'etranger des oeuvres de Myasaki, c'est pour controller sa distribution, histoire q'un Mononoke ou un Chihiro ne sorte pas en meme temps que leurs produits de fin d'année.
Bref, Kiki commence a dater et est plus accessible aux jeunes, c'est vrais, mais ca n'en est pas moins superbe. Je te recommande pour te faire une idée de louer Chihiro, par exemple.
A mon avis (tres perso), Myasaki fait parti des Grands, comme Nick Park (Wallace & Gromit) ou Lasseter (Pixar). Des types qui on marqué l'histoire de leur Art.
[^] # Re: templates variadiques
Posté par gS . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 2.
Chez nous on l'utilise pour les pimpls (Pointer to IMPLementation) une techique très simple pour séparer l'interface de l'implémentation d'un classe.
Ca évite de se soucier de faire le ménage. Un delete est si vite oublié...
a++
[^] # Re: templates variadiques
Posté par gS . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 2.
Pas besoin de locker, ca utilise les operation d'incrémentation atomiques.
Ca a un coût, certes, mais c'est quand même efficace.
Ca vient de la lib boost, qui a servi de reference pour l'implémentation dans le standard.
a++
[^] # Re: Perspectives alléchantes
Posté par gS . En réponse à la dépêche xwhiite-linux voit le jour en version 0.1. Évalué à 2.
Le bootloader mentionné est un hack basé sur le bricolage d'une sauvegarde de partie du jeu Zelda Twilight Princess.
Il permet d'executer du code maison, dont un bootloader.
Cette faille a aussi été exploitée pour créer des applications (homebrew channel) qui facilite l'installation d'autres applications.
http://wiibrew.org/wiki/Twilight_Hack
http://wiibrew.org/wiki/Homebrew_Channel
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 2.
Je conviens que ma dernière phrase pourrait être équivoque, ce n'était pas mon intention. J'essayais juste de fournir une explication qui m'aurait été utile quand je suis passé de CVS à un aute systeme.
Je ne comprends toujours pas pour quoi ca prête à rire.
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 1.
C'est quelque chose qui peut dérouter au début et c'est une notion fondamentale.
Je n'affirme a aucun moment que seuls les systemes distribuée en sont dotés. Je ne mentionne meme pas SVN.
Je ne saisis pas pourquoi je devrais rire de mon explication.
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 1.
Par exemple dans la branche beta, le patch 7300 corrige le bug 120 et le changeset concerne 5 fichiers.
Il est tres simple dans la branche pricipale, de demander a bzr d'appliquer juste ce patch, sans tous les précédents, ou d'appliquer une liste de patch qui modifie des fichiers qui n'ont pas trop divergés , ce qui représente la majorité des cas sur une appli de la taille de la notre (sinon, de toute façon, il faut résoudre les conflits).
Cette operation se nomme 'cherrypicking' dans le vocabulaire des systemes de gestion de version distribués et représente un progrès dans notre façon de gérer nos sources et nos versions.
a++
Guillaume.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 3.
Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
C'est le meme fonctionnement que CVS, tres simple.
Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).
[^] # Re: Qui utilise bzr ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 4.
Nous en sommes satisfaits et les dernières versions sont bien plus rapides.
Pour la taille de notre projet, en tout cas, (+ 400K lignes, et bientôt 8000 revisions) ca fonctionne très bien.
Les versions se suivent assez rapidement, les développeurs sont très actifs. Il manque encore peut être quelques utilitaires (aussi évolués que CVSweb, par exemple) mais ça devrait arriver vite.
Les plateformes de dev sont sous Linux et Mac, mais les electroniciens l'utilisent également sous windows.
Nous en regrettons pas notre choix.
a++
Guillaume.
[^] # Re: [X] Portable (très portable)
Posté par gS . En réponse au sondage Matériel : mon ordinateur personnel (principal) est. Évalué à 1.
[^] # Re: UTF-8 ?
Posté par gS . En réponse à la dépêche Doxygen en 1.5.0. Évalué à 4.
[^] # Re: Performances...
Posté par gS . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 2.
a++
[^] # Re: Performances...
Posté par gS . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 5.
a++
[^] # Re: Performances...
Posté par gS . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 3.
Pour le moment notre code ne contient que environ 80K lignes de code, mais ca grossit relativement vite ( la précédente version de notre soft toujours géré sous CVS a à peu pres 380K lignes ). Nous prévoyons que la nouvelle version sera plus conséquente que la précédente et pour le moment, nous n'envisageons pas de passer à autre chose que bazaar-ng.
Les perfs au commit/update ne sont pas vraiment un problème (pour nous, en tout cas), je ne pense pas que ca soit la meilleur façon de juger ce type d'outil. (a moins de faire un unpdate toute les 20 minutes :)
La fonctionnalité que j'appécie le plus sont les bound branches. Elles permettent d'émuler un fonctionnement centralisé ou chaque commit se fait simultanément sur le repository central et localement, on utilise que les commande commit/update. C'est tres pratique. Quand on le souhaite,on peu passer en mode décentralisé et se synchroniser avec la source que l'on veut ou bosser uniquement en local puis repasser en bound sur le serveur central avec une commande tres simple.
Les explications de James Blackwell sur le sujet (un des gars qui fait du support et aide les débutants) m'on vraiment bien aidé.
a++
Guillaume.
[^] # Re: GTK, QT et les autres
Posté par gS . En réponse à la dépêche Release Candidate 1 de XCB. Évalué à 7.
Cairo is a graphics library that supports vector graphics and image compositing that can be used with GDK. Since 2.8, GTK+ does most of its drawing using Cairo.
En gros Gtk utilise cairo pour la majorité de son rendu.
Cairo permet de dessiner entre autre en utilisant XCB ( et Xlib, opengl...). Donc si j'ai bien tout compris, Gtk+ pourrais déja bénéficier d'XCB...
Les distributions ne disposent peut être pas encore du cairo avec XCB, mais si ca peut marcher et que c'est vraiment plus efficace, ca ne devrait pas tarder à se généraliser.
[^] # Re: Merci!
Posté par gS . En réponse à la dépêche Premiers pilotes libres pour les imprimantes Samsung. Évalué à 2.
J'ai une 2070N payée environ 200 euros, elle est économique et fonctionne tres bien avec CUPS et a un port ethernet.
Le premier prix de cette gamme, la HL 2030, est a 95 euro et ca doit fontionner également (elle est listée comme compatible).
Avant d'acheter, vous pouvez verifier si l'imprimante est supportée la:
http://www.linuxprinting.org/printer_list.cgi
a++
# Correction de l'URL
Posté par gS . En réponse au journal Un artiste qui Kiffe le Libre!. Évalué à -4.
http://www.taolook.com/mkpello
Désolé.
[^] # Re: Alors
Posté par gS . En réponse au message Recherche d'un langage de programmation. Évalué à 1.
Une autre solution pourrait consister à utiliser C++ et la bibliotheque boost. Les smart pointers, containers, et autre outils permetent d'éviter beaucoup de problèmes de gestion de la mémoire. Il y a des outils de gestion de graphes dans boost qui doivent être intéréssants en IA : www.boost.org.
En revanche, boost représente un investicement en terme d'apprentissage...
a++
Guillaume.
# Ecouter pour découvrir
Posté par gS . En réponse à la dépêche Les labels indépendants ouvrent leur plateforme. Évalué à 1.
Il y a symbole avec un casque après le titre mais en cliquant dessus, c'est juste un lien vers la page courante (en tout cas, chez moi avec FireFox 1.5.0.3).
J'aimerais bien écouter deux ou trois trucs,il y a de styles musicaux dont j'avais jamais entendu parler...
a++
Guillaume.
[^] # Re: ET les autres SE ?
Posté par gS . En réponse à la dépêche La spécification de OpenGL 2.0 enfin en version finale. Évalué à 5.
Ca vas offrir des possibilités fantastiques pour le développement des applis mais ca complique pas mal l'écriture des drivers (qui doivent intégrer a présent un compilateur et un linker, rien que ca...). Mais heureusement, 3DLabs a mis a la disposition du plublic une implémentation de référence des ces deux outils pour simplifier les choses et surtout pour que les compilateur interpretent bien tous le code de la meme façon.
voilivoila,
a++
Guillaume.
[^] # Re: ET les autres SE ?
Posté par gS . En réponse à la dépêche La spécification de OpenGL 2.0 enfin en version finale. Évalué à 6.
Je crois que les drivers ATI faisant la meme chose ne devraient pas tarder (si ils ne sont pas deja sortis).
La version du driver que j'ai installé: 1.0.6111
Pour verifier si vos drivers (et votre carte supporte) le langage de shader:
glxinfo |grep GL_ARB_shading_language_100
Il me semble que les cartes nvidia qui le supportent sont les gammes FX (a partir de la FX5200) et les cartes ultérieures. Chez ATI, je crois aque c'est a partir de la Radeon 9500, mais c'est de mémoire, a verifier...
Les modeles précédents peuvent également etres programmée (fragment & vertex) mais en assembleur ou en utilisant un SDK comme le Cg de NVidia. Je ne parle ici que du langage de haut niveau intégé dans la lib OpenGL (GLSL).
a++
Guillaume.
[^] # Re: Sortie de GCC 3.4.0
Posté par gS . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 2.
Je l'ai essayé pour un tout petit projet fait a la maison parce que j'avais la flemme de me refaire toute la choucroute automake/autoconf pour gérer les dépendences proprement et ca marche super bien.
Il faut quelques minutes pour comprendre comment ecrire l'équivalent du makefile et hop ca roule!
Je suis en train de réflechir a la façon dont je pourrais migrer le projet de l'équipe au boulot (pas une mince affaire).
En tout cas, meme pour un tout petit projet d'une dizaine de fichiers, le bénéfice est immédiat!
[^] # Re: Sortie de GCC 3.4.0
Posté par gS . En réponse à la dépêche Sortie de GCC 3.4.0. Évalué à 5.
Comme son nom l'indique presque ccache stocke les resultats de compilation précédents et les ressorts si les sources sont identiques.
Sur notre projet, nous sommes passes de 12 minutes a 1 minute trente (et comme on utilise qmake/Qt et qu'il gere pas super bien les dépendences, on etait obligé de tout recompiler tres frequemment).
Bref, ca marche pas mal et on a pas encore eu de problemes avec.
a++
Guillaume.
[^] # Re: Kiki, la petite sorcière
Posté par gS . En réponse à la dépêche Kiki, la petite sorcière. Évalué à 3.
Je répond quand meme.
Il y a un gouffre entre la niaiserie disneyenne et Myasaki. Le public qu'il vise, par exemple, pour Porco Rosso est plutot l'adulte (M visait le plublic de son age). Ses histoires sont itemporelles. Tu ne trouverra pas dedans une demi douzaine de faire valoirs amusants pour faire vendre des menu McDo.
Si disney a racheter les droits d'exploitation a l'etranger des oeuvres de Myasaki, c'est pour controller sa distribution, histoire q'un Mononoke ou un Chihiro ne sorte pas en meme temps que leurs produits de fin d'année.
Bref, Kiki commence a dater et est plus accessible aux jeunes, c'est vrais, mais ca n'en est pas moins superbe. Je te recommande pour te faire une idée de louer Chihiro, par exemple.
A mon avis (tres perso), Myasaki fait parti des Grands, comme Nick Park (Wallace & Gromit) ou Lasseter (Pixar). Des types qui on marqué l'histoire de leur Art.
a++
Guillaume.
[^] # Re: Mon hacker préféré
Posté par gS . En réponse au sondage Mon hacker préféré. Évalué à 2.
Bin ouaip, quand meme!
[^] # Re: Un cri de désespoir du développeur d?un projet Open Source.
Posté par gS . En réponse à la dépêche Un cri de désespoir du développeur d'un projet Open Source.. Évalué à 1.
a++
Guillaume