Campagne de dons pour le compilateur PCC - LinuxFr.org\nBeaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer. Il est d'ailleurs inclus dans l'arbre des sources de projets comme OpenBSD et NetBSD depuis plus d'un an. En terme de performance, ce petit compilateur est capable de produire des exécutables 15 fois plus rapidement que ceux de GCC (seulement 5 fois plus rapidement si l'on active les tests internes de validité, les « sanity checks »), pour une vitesse d'exécution environ 10% plus lente. Cette relative lenteur s'explique par le fait que PCC ne fait des optimisations que sur l'allocateur de registres (alors que l'on peut en faire à plein d'autres endroits). De nombreuses améliorations sont à faire ou à terminer, c'est pourquoi le projet à besoin de votre aide. Historique\nPortable C Compiler a originellement été écrit par Stephen C. Johnson des laboratoires Bell vers la fin des années 70. Il a été le compilateur préféré sur System V et sur les version 4.x de BSD. Il n'a été remplacé par GCC qu'en 1994 avec 4.4BSD.\nDepuis 2002, le code source a subi un gros nettoyage et plus de la moitié à été réécrit. Ainsi la version actuellement disponible est une modernisation de ce compilateur.\nPlan pour la version 1.0\nLes dons permettront de faire avancer grandement le projet. Voici la liste des tâches prévues :\nAmélioration de la conversion vers la forme Static Single Assignment.\nSSA est une représentation intermédiaire permettant entre autre de réaliser des optimisations. La conversion des arbres d'expressions d'une fonction en une forme SSA et vice-versa requiert :\nla création d'un graphe de flux de contrôle (CFG) ;\nla construction d'un arbre dominant ;\nle calcul de la frontière de dominance ;\nles fonctions d'insertions phi ;\nla re-numérotation des variables temporaires.\nAmélioration de la prise en charge des fonctionnalités de la norme C99.\nDe nos jours, la norme C99 est probablement la norme du C la plus utilisée. Elle a introduit quelques fonctionnalités qui peuvent simplifier la vie des programmeurs mais qui ne sont pas encore disponibles dans PCC :\namélioration des nombres complexes : prise en charge des types de données _Complex et _Imaginary ;\namélioration des tableaux dynamiques dans les entêtes/prototypes : la prise en charge des tableaux automatiques à taille variable (variable-length arrays) existe déjà mais pas pour les prototypes de fonctions ;\namélioration des déclaration abstraite dynamique : prise en charge de la possibilité d'utiliser les déclarateurs abstraits (abstract declarators) partout dans le code.\nAmélioration de la compatibilité avec GCC\nLe compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC :\nattribute() : prise en charge de la syntaxe de attribute() et contrôle des extensions couramment utilisée ;\ntypeof() : prise en charge du mot clé typeof() ;\nplage de nombres du mot clé case : prise en charge des plages de nombres donnés à l'instruction case ;\nénumération incomplète : prise en charge de la déclaration avancée des enums ;\nchamp anonyme dans les structures et unions : prise en charge de l'utilisation des membres anonymes compatible à la fois avec GCC et son utilisation historique.\nPortage de PCC sur l'architecture amd64.\nTout reste à faire pour cette architecture de plus en plus courante :\nmise en œuvre du générateur de code ;\nmise en œuvre du générateur de code FPU (pour les calculs à virgule flottante) ;\nmise en œuvre du générateur de code PIC (utilisé pour charger le code des bibliothèques logicielles).\nLes dons se font par l'intermédiaire de l'association « BSD Fund » qui fonctionne de la même manière que « Linux Fund ». Elle a pour objectif de financer les projets, événements et initiatives en rapport avec les systèmes BSD.\nL'objectif de la campagne de dons de PCC est de 12 000 dollars (soit environ 9 329 euros). L'argent sera versé à Anders Magnusson après que l'ensemble des points ci-dessus aient été complétés.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 12:31 . Évalué à 9.\n>>> Beaucoup voient en lui une alternative viable à GCC qui pourra à terme le remplacer\nHeu...alternative peut-être...mais uniquement si on veut compiler du C !\nPour les autres langages supportés par GCC (C++, Java, Fortran, Ada, Objective-C) elle est ou l'alternative ?\n>>> pour une vitesse d'exécution environ 10% plus lente\nOu sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture.\nQuand à la motivation du projet PCC il est certain qu'une situation de monopole n'est jamais saine. GCC a beau être un superbe soft il vaut mieux pour le logiciel libre que des alternatives émergent (on pense à LLVM par exemple). PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance.\nJe ne peux toutefois m'empêcher de trouver curieuse la justification apportée par Theo de Raadt dans cette interview d'octobre 2007: http://www.thejemreport.com/content/view/369/\nJe cite : "What other hurdles remain in replacing GPL-licensed programs in OpenBSD?\nTdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem...".\nSi Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre. Un monde ou IBM, Red Hat, Novell, Bull, Google, l'INRIA, et de nombreuses autres entreprises et universités ne contribuent pas au développement de GCC (allez donc voir les affiliations des auteurs des articles des différents GCC summits).\nDire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.\nPosté par Victor le 10/11/08 à 12:40 . Évalué à 7.\nJe crois qu'un autre (enfin c'est un bout de celui que tu cites) argument est que GCC est vraiment un gros bazar monolithique difficile à maintenir (même si il l'est effectivement).\nTout comme un objectif de LLVM était de faire un truc un peu plus modulaire (si je ne me trompe pas, je suis pas un pro de tout ces trucs), je pense que PCC va aussi essayé de répondre à cette problématique.\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 12:42 . Évalué à 10.\nÀ propos de gcc j'avais entendu dire que son architecture avait volontairement été rendu moins pratique par Sallman, pour rendre plus difficile les extension propriétaires. Est-ce que que quelqu'un serait dire si cela à un fond de vérité ou si il s'agit de pure légende urbaine (si on peu qualifier un sujet aussi pointu d'urbain…) ?\nMon premier message écrit tout en bépo sur linufr ! Bon je suis encore loin de ma vitesse de frappe en AZERTY.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 12:52 . Évalué à 10.\n>>> À propos de gcc j'avais entendu dire que son architecture avait volontairement été rendu moins pratique par Sallman, pour rendre plus difficile les extension propriétaires. Est-ce que que quelqu'un serait dire si cela à un fond de vérité ou si il s'agit de pure légende urbaine\nC'est la vérité vraie (même si le mail ou il déclare ça date de 2000):\nY'avait eu une discussion sur LWN ou j'avais aussi posté le lien vers ce mail et il y a des commentaires intéressants:\nPosté par Metzgermeister le 10/11/08 à 20:33 . Évalué à 5.\nJe sais bien que Stallman est très attaché à l'aspect éthique du logiciel libre, mais de là empêcher une solution plus pratique et qui rendrait le logiciel meilleur pour de tels motifs... J'imagine que Stallman est aussi opposé aux modules Linux :)\nPosté par reno le 11/11/08 à 12:20 . Évalué à 5.\n>N'est-ce pas choquant ?\nChoquant dans quel sens? Surprenant?\nNon, c'est cohérent pour RMS..\nRéfléchi à ce qu'a impliqué la création de la license GPL par rapport aux logiciels libres qui existaient déjà sous license BSD, MIT: plutôt que de contribuer aux logiciels libre existant, c'est créer une incompatibilité afin d'avoir une license qui (du point de vue de RMS) défend mieux les droits des utilisateurs.\nOn est d'accord ou pas avec RMS, mais il est assez cohérent dans ses actions d'après ce que j'en sais.\nPosté par psychoslave__ (site Web personnel) le 11/11/08 à 15:37 . Évalué à 2.\nJe ne trouve pas l'exemple pertinent. Réécrire les logiciels sous GPL, ça n'empêche en rien de les écrire en essayant d'en faire une implémentation propre et avec une architecture qui vise l'efficacité technique.\nMaintenant je ne sais pas si choisir une architecture logiciel moins bonne techniquement à été un bon choix politique, peut être. Moi je comparais plutôt ça au fait de pousser theorra pour la vidéo sur internet alors que celui-ci est loin d'être la meilleur solution technique.\nPosté par reno le 12/11/08 à 11:27 . Évalué à 2.\nRe-écrire plutôt que de contribuer a l'existant pour une quantité d'homme-heure donnée donne un résultat inférieur sur le plan technique car il y a duplication du code (sauf dans le cas particulier ou l'existant est pourri mais ce n'était pas la raison utilisé pour coder un OS sous license GPL plutot que de contribuer à *BSD).\nSinon pour theora, tu pense à quoi comme meilleur solution technique?\nDirac? Il est très gourmand au niveau CPU donc je ne suis pas convaincu que ce soit une bonne idée de l'utiliser pour diffuser des vidéos sur Internet et les autres formats ont des problèmes de brevets logiciels aux USA.\nPosté par Zenitram (site Web personnel) le 12/11/08 à 13:12 . Évalué à 3.\nH264/AVC, et de loin.\net les autres formats ont des problèmes de brevets logiciels aux USA.\nCe n'est pas technique, donc non éliminatoire pour le poste de meilleure solution technique.\nSinon, ben on fait avec ce qu'on a, soit Theora pour le présent, Dirac pour le futur.\nPosté par totof2000 le 10/11/08 à 12:53 . Évalué à 7.\nEuh ... C'est certainement ce dont ont besoin de nombreux projets comme les BSD .... Avoir un compilateur qui compile tout et fait le café c'est bien, mais pour la base d'un OS écrit en C, c'est peut-être pas utile ....\nFais-la, fais le bench puisque tu sembles aussi sur de toi ...\nSi Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre.\nEuh ... OpenBSD a audité/réécrit une grosse partie du code de OpenBSD en ayant pour objectif la sécurité. Faire la même chose pour le compilateur qui génère le code semble bien compliqué pour une "usine à gaz" tel que GCC. Par contre un compilateur plus simple permettrait aux équipes OpenBSD de le maintenir eux-même ou au moins de remonter les problèmes rencontrés plus facilement ..... C'est l'intérêt majeur d'un tel projet .....\nJe vois bien les deux compilateurs cohabiter sans problème ... tout au moins pour les BSD .. PCC chargé de compiler le système de base, et GCC s'occuper des logiciels supplémentaires, qui eux ne sont pas forcément écrit en C.\nPosté par reno le 10/11/08 à 18:48 . Évalué à 6.\n>Fais-la, fais le bench puisque tu sembles aussi sur de toi ...\nAhem, en science c'est à celui qui fait une affirmation de la prouver et non pas le contraire..\nAffirmer "[PCC fournit] une vitesse d'exécution environ 10% plus lente [que GCC]" sans benchmark: ca n'a pas grande valeur..\nJ'imagine que ce chiffre n'est pas sorti au hasard, donc il doit y avoir quelque chose derriere pour le justifier.\nCela dit les besoins d'un OS sont très particulier et Linus lui-même rale relativement souvent contre gcc qui casse du code en 'sur-optimisant'.\nPosté par ErrTu le 10/11/08 à 19:08 . Évalué à 4.\nAu niveau des performances, voilà ce qu'en dit Anders Magnusson :\nPosté par M le 10/11/08 à 22:40 . Évalué à 2.\nJe rêve ou on se fout de nous :\n> Under which conditions? Which level of optimization are you using for the gcc benchmarks? Which version? 90% of gcc's performance with a register allocator alone is quite a claim.\nYes, it is. I haven't tested it since I wrote the register allocator some years ago, so it may have been against 2.95.\nPosté par vosgien_ le 10/11/08 à 23:07 . Évalué à 3.\nJe rêve où tu fais exprès de volontairement couper la réponse de ragge qui contient les vrais chiffres ?\nI used bytebench. Hm, a rerun on some of the passes shows that the difference is not much more against gcc 3.3.5 with -O2:\nTest pcc -O gcc -O2 % of gcc performance\ndhry2 1197813 1359242 88%\nint 168286 186189 90%\nfloat 190144 192564 99%\narithoh 2264451 3354473 67%\nshort 198920 198930 100%\ndouble 145081 192597 75%\nThe cases where pcc is significantly slower is missing optimizations like strength reduction etc.\nPosté par M le 11/11/08 à 00:35 . Évalué à 2.\ne rêve où tu fais exprès de volontairement couper la réponse de ragge qui contient les vrais chiffres ?\noui, je parle du bench des 10% plus lent que gcc.\nCelui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.\nPS : je ne parle même pas du fait que -O2 est utilisé au lieu de -O3.\nPosté par herodiade le 11/11/08 à 00:47 . Évalué à 5.\n> Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.\nCette remarque au sujet la version de gcc ne manque pas d'ironie. Il est plus que probable que ragge utilise cette version parce que c'est celle qui est incluse dans OpenBSD pour les architectures i386 et amd64. C'est une vieille version parce qu'ils (les devs. d'OpenBSD) n'arrivent pas à suivre le rythme et à maintenir eux-même les versions plus récentes de gcc (les devs. de gcc ne maintiennent pas le port OpenBSD pour eux). Ce qui explique qu'ils cherchent une porte de secours...\nSinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement, où quelques "low hanging fruits" sont encore à portée de main.\nPosté par ribwund le 11/11/08 à 01:05 . Évalué à 2.\nHum, 3.3.5 c'est du vieux quand même ;)\nC'est avant la réarchitecture de GCC (et c'est vrai que si quand ils disent que le code de GCC est dégueu, c'est du code de GCC3 qu'ils parlent, je les comprends).\nPosté par patrick_g (site Web personnel) le 11/11/08 à 01:14 . Évalué à 2.\n>>> Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement\nC'est vrai que cela n'est pas ridicule sur ce benchmark.\nN'oublions pas toutefois que GCC 3.3.5 est loin, très loin, d'être une version récente. Depuis ce vénérable ancêtre de 2004 il y a quand même eu un paquet de versions de GCC :\nEt la toute nouvelle version 4.4 est sur le point de sortir. Comparer les perfs de PCC avec GCC 3.3.5 est donc biaisé (mais on est d'accord que c'est la version présente dans l'arbre des ports d'OpenBSD donc c'est ça qui compte pour eux).\nPosté par beagf (site Web personnel) le 11/11/08 à 10:44 . Évalué à 8.\nSans faire de commentaire sur le fond du débat, mais ta liste ne représente strictement rien...\nQuelle quantité d'amélioration y a-t-il dans chaque version que tu cite ? Est-ce que l'équipe de Gcc fais une nouvelle version à chaque correction d'une faute d'orthographe ? Est-ce qu'il y a une nouvelle version à chaque fois que l'amélioration de perf atteint 10% de gain par rapport à la précédente ?\nBref, ce n'est pas parce qu'il y a eu de nombreuse version depuis la 3.3.5 que les perfs sont meilleur. Donc, on a des bench par rapport à la 3.3.5 et ces tout. Pour avoir des infos face au dernières version, il faut là aussi faire des benchs.\nPosté par ymz le 12/11/08 à 10:45 . Évalué à 3.\nPourquoi ne pas demander un support de TCC dans CompBench ? (c' est un benchmarker de compilation selon scénarios -appli déclarées, etc etc-). Avec le fonctionnement de CompBench, vous auriez un ensemble de résultats pouvant être comparé, entre GCC x.x et TCC, non ?\nEn plus, c' est le bon moment pour demander une feature comme la prise en charge de PCC\n(Peut être même la branche Melt de Gcc ? Voir le compilateur TCC de Mr Bellard)\nPosté par ymz le 12/11/08 à 10:48 . Évalué à 2.\nPosté par auve le 10/11/08 à 23:29 . Évalué à 10.\nDisclaimer : je ne suis pas OpenBSDiste.\nJe ne pense pas qu'on se foute de nous, juste qu'il ne faut pas perdre de vue l'optique selon laquelle ces benchs ont été effectués.\nPCC a vocation à remplacer le compilateur de base par défaut d'OpenBSD. Ce dernier fut jusqu'à relativement récemment*, si je ne m'abuse, un GCC 2.95 assez lourdement modifié pour gérer certaines choses, en particulier certaines formes de vérification dynamique servant à contrer les attaques par débordement & co. Je crois que maintenant c'est un 3.3, avec le 2.95 uniquement pour certaines architectures matérielles. Il est donc parfaitement logique et cohérent de comparer avec ces vieilles versions de GCC pour évaluer pragmatiquement l'impact sur OpenBSD.\nPar contre, généraliser à « PCC est seulement 10% plus lent que la dernière version de GCC », c'est à mon avis naïf, voire mensonger.\n<voyance>Selon moi l'écart va avoir tendance à se creuser, GCC me semblant être en train de décoller dans la recherche académique, et à bouger peut-être un peu plus vite sur certains points (passage au C++ selon la proposition d'Ian Lance Taylor ?). Les effets bénéfiques de la concurrence pure et non faussée :-) ?</voyance>\n* : Un GCC plus moderne est évidemment disponible dans les ports.\nPosté par Étienne le 10/11/08 à 13:31 . Évalué à 10.\nIl me semble avoir lu plusieurs fois des commentaires de Marc Espie se faisant remarquer que seules les architectures x86 et powerpc étaient correctement maintenues et qu'ils avaient régulièrement des problèmes pour les architectures plus exotiques. D'autre part, les dev OpenBSD se plaignent de la difficulté à faire inclure des patchs.\nVoir par exemple http://undeadly.org/cgi?action=article&sid=2007091519520(...)\nPosté par herodiade le 10/11/08 à 23:42 . Évalué à 10.\n>Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre\n> Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.\nIl apparait que TdR en sait un poil plus long que toi sur les compilos et la façon dont ils sont maintenus. Un boût de phrase, évident mais implicite t'aurait sans doute aidé à comprendre ce dont parle Théo : il n'est pas assez maintenu ... pour les choses qui importent à OpenBSD.\nEn l'occurrence, OpenBSD se traine sur certaines plateformes un vieux gcc 2.95 (et les autres sont restées en 3.3, d'ailleurs) parce que support par le gcc "upstream" a été délaissé. Le support pour la plateforme OpenBSD est lui aussi, bien entendu, à la charge des devs OpenBSD : les grosses boites qui paient des développeurs à plein temps pour améliorer gcc n'ont que fiche des OpenBSD sur Vax et archis pour bricoleur dinosaures. Le m68k n'est sans doute plus assez corporate. Ces grosses boites font évoluer le logiciel, très vite (ce qui est d'autant plus dur à suivre, du coup), précisément, et l'écart à rattraper pour maintenir les fonctionnalités _qui importent à OpenBSD_ se creuse chaque jour.\nCe mode de fonctionnement est tout à fait justifié de la part de gcc, mais il explique aussi le malaise de certains développeurs qui doivent de facto assurer pendant leurs loisir le maintient d'un code qui change très vite, qui change d'une façon qui ne respecte en rien leurs besoins, un code vieux de 23 ans de patchs accumulés, un code qui est volontairement structuré pour ne pas être modulaire.\nPosté par patrick_g (site Web personnel) le 11/11/08 à 00:08 . Évalué à -2.\nDonc ton avis c'est que les fonctionnalités qui importent vraiment à OpenBSD c'est la compatibilité avec VAX et m68k ?\nC'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque, tellement monstrueux que ça vaut le coup de garder une version 2.95 ;-)\nBon trêve de plaisanterie. TdR veut un compilo simple et qui intègre les modifs du projet OpenBSD. Il est évident que GCC ne réponds pas à ces critères et il est donc légitime de sa part de chercher ailleurs. Tout le monde comprends ça....mais pas besoin de sa part de troller en disant que GCC est un projet qui n'est pas maintenu upstream.\nPosté par herodiade le 11/11/08 à 00:39 . Évalué à 10.\n> C'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque [...]\nMais bon sang, on parle d'un OS d'amateurs, de gens qui développent pour le plaisir, alors oui, Vax est capital, et ils y consacrent du temps. Tu semble ne pas le croire, mais ça l'est vraiment, pour eux, au moins.\nEn tout cas parler de "marché", fut-ce au figuré, montre où se niche la confusion. C'est précisément là où se trouve le sel des BSD (et certainement où devait être le fun dans le petit monde de Linux avant 1998 environ) : une petite famille, peu de développeurs, tous sont connus, peu de patchs (on peut suivre les changements), bref des projets à taille humaine ; un engouement pour les vieilles machines, du code pour le plaisir du code (ou pour sa beauté, sa simplicité avant son efficacité, par ex.) comme de l'art pour l'art, ou plutôt de l'artisanat, et vraiment rien de corporate. Pas de "marché". GCC pour sa part est touché par l'excès inverse.\nD'ailleurs, cette propriété en soi ça suffit à expliquer ce travail sur PCC (bien que ça ne soit pas la seule raison) : même s'il est probable que ça fasse un compilateur plus lent et moins complet, il y a un certain nombre de développeurs qui ont envie de mettre les mains dans les entrailles d'un compilateur au code clean et à dimension humaine. Juste pour le plaisir du bricolage, de l'amateurisme éclairé.\nPosté par reno le 11/11/08 à 13:25 . Évalué à 4.\nUn exemple qui montre bien le coté traditionnaliste d'OpenBSD est qu'ils ont réimplémenté CVS..\nAyant (ab)usé de CVS je comprends ce qui les attire: c'était un logiciel ou si tu as corrompu certaines donnée, tu peux lancer un vi et corriger à la main.\nMais ceci dit je considère quand même que c'est un logiciel qui a fait son temps et si j'avais à choisir un logiciel de gestion de configuration j'irais plutôt voir du coté de Mercurial (git m'a l'air compliqué a utiliser) que de CVS..\nPosté par Metzgermeister le 11/11/08 à 15:39 . Évalué à 2.\nCela dit, si CVS est un outil qui leur convient, et si le besoin se fait sentir d'améliorer ledit outil en produisant une autre version, pourquoi pas ? Après tout, leur OpenNTPD n'est pas mal du tout :-)\nPosté par Thierry Thomas (site Web personnel) le 11/11/08 à 18:59 . Évalué à 4.\nL'avantage de CVS, c'est qu'il est écrit en C, et peut donc être inclus dans le système de base.\nPosté par Patrick Lamaizière (site Web personnel) le 10/11/08 à 23:57 . Évalué à 10.\nGcc a laissé tomber des architectures toujours maintenues dans OpenBSD, de ce point de vue on peut pas dire que gcc est maintenu.\nJe t'invite à lire les commentaires de Marc Espie sur gcc.\n# pas tout jeune\nPosté par Jean-Max Reymond (site Web personnel) le 10/11/08 à 12:51 . Évalué à 6.\nj'ai bossé dessus en 1986( ce qui ne me rajeunit pas :-( ) et il y avait à l'époque déjà beaucoup de choses à améliorer ! ceci dit, je pense que gcc est pour l'instant sans égal et la vitesse de compilation est quand même assez anecdotique avec les CPU monstrueux dont on dispose maintenant.\n[^] # Re: pas tout jeune\nPosté par Mathieu Segaud le 10/11/08 à 14:01 . Évalué à 6.\n> la vitesse de compilation est quand même assez anecdotique avec les CPU monstrueux\n> dont on dispose maintenant\njustement, dans le cas d'un projet comme les *BSD, ce n'est pas anecdotique. Il y a plusieurs architectures à maintenir et à compiler. Pour un même code, le temps de compilation entre gcc3 et gcc4 a pu doubler. Certes on peut arguer du fait que oui, maintenant on a des proco rapides, mais d'une part il n'est pas tjs facile de mettre à jour le matériel à son bon gré (problème de fonds) ni non plus sage: cela permet de cacher un constat médiocre, i.e. doubler à machine égale le temps d'exécution d'une tâche est une régression sévère.\nPosté par Larry Cow le 10/11/08 à 15:09 . Évalué à 10.\ndoubler à machine égale le temps d'exécution d'une tâche est une régression sévère\nSi et seulement si on parle bien de la même tâche. Le fait que GCC4 est plus lent à compiler que GCC3 peut également signifier qu'il fait mieux son travail (code mieux vérifié, mieux optimisé, ...)\nPosté par B16F4RV4RD1N le 10/11/08 à 15:10 . Évalué à 8.\noui mais si les utilisateurs finaux ont un système dont les binaires s'exécutent 10 % plus lentement, ce n'est pas une régression quelque part ?\nPosté par tanguy_k (site Web personnel) le 10/11/08 à 18:51 . Évalué à 6.\nle temps de compilation entre gcc3 et gcc4 a pu doubler\nEt c'est super pénible, surtout en C++\nCa ralentit énormément la productivité (processus modification code - compilation - test) et ca donne envie d'utiliser des langages interprétés.\nUn compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial. Rien n'empêche après de fournir un binaire à l'utilisateur compilé avec GCC et toutes les optimisations qui vont avec.\nPosté par Victor STINNER (site Web personnel) le 10/11/08 à 20:01 . Évalué à 3.\n« le temps de compilation entre gcc3 et gcc4 a pu doubler (...) Et c'est super pénible, surtout en C++ (...) et ça donne envie d'utiliser des langages interprétés. »\nTiens, c'est exactement pour ça que je suis passé du C++ au Python :-) Le C++ est quand même un cas particulier avec ses horribles templates qui augmentent considérablement le temps de compilation. D'ailleurs, il me semble que les autotools n'exploitent toujours pas la précompilation des entêtes C++ :-( Quand j'utilise Borland C++ Builder, la précompilation des entêtes faisait passer le temps de compilation de 5/10 minutes à 60 secondes.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 20:20 . Évalué à 2.\n>>> Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial.\nPourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0) et à la fin de l'écriture du programme on n'a plus qu'a optimiser à fond (-O3).\nPosté par Troy McClure (site Web personnel) le 10/11/08 à 20:42 . Évalué à 4.\nle probleme c'est le c++ moderne qui repose sur des kilometres de templates et de meta-conneries, qui eux même font l'hypothese que "les ptites fonctions et les ptites classes qui font rien c'est pas grave parce que y'a la bonne le compilo qui fait le menage" . Quand l'optimiseur est activé, ça inline effectivement tout ça en éliminant le code mort et ça va vite. Quand l'optimiseur est off tu te retrouve avec un binaire 5x plus gros (10x si en plus t'as mis du -g) , qui du coup met nettement plus de temps à linker, et surtout qui tourne 25x moins vite (et encore ça peut etre pire)\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 21:47 . Évalué à 2.\nJuste pour savoir, c'est pour quel genre de projet que tu utilises du C++ et quelles sont les avantages qu'il te procure pour que les inconvénients que tu cites en vailles la peine ?\nPosté par Troy McClure (site Web personnel) le 10/11/08 à 22:47 . Évalué à 2.\nLe premier avantage c'est que je connais c++ et pas java :)\nEnsuite pour des projets du genre traitement audio en temps-reel ça repond bien aux contraintes de performance, et actuellement tout l'ecosysteme est à 95% en c++ donc ça reste un choix assez naturel. Après c'est vrai que sur d'autres projets j'aurais un peu plus de mal a dire "seul le c++ répond au cahier des charges"\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 23:16 . Évalué à 0.\nTiens tu fais quoi dans l'audio ?\nPosté par herodiade le 10/11/08 à 23:52 . Évalué à 5.\n> Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0)\nParce que c'est bien trop lent de toutes façons (la différence avec ou sans optims est minimale).\nLe projet OpenBSD se fait fort de compiler ses binaires pour toutes les architectures supportées (y compris de _très vieilles archis_) sur la plateforme elle-même. Ce qui évite par ex. de faire comme les devs NetBSD, qui s'aperçoivent parfois des mois après qu'une archi est cassé parce que ça passait bien à la cross-compilation... Et ça permet de stress tester le noyau en cours de développement sur ces architectures : c'est de l'intégration continue, en somme. Évidemment ça marche moins bien quand on a un compilo lent et mal supporté (mal supporté : sur l'archi/plateforme en question, comme tu semble ne pas comprendre...).\nPosté par Littleboy le 11/11/08 à 02:39 . Évalué à 2.\nEuh, tu compiles deja en mode debug, donc avec les optimisations desactivees...\n# PCC... déjà pris ce nom\nPosté par Patrice FERLET (site Web personnel) le 10/11/08 à 12:55 . Évalué à 2.\nJe pense qu'on va se marrer le jour où quelqu'un va me packager PCC, alors que je package Roadsend PHP Compiler dont l'exécutable se nomme "pcc"...\nCa me rappelle mes déboire avec le navigateur "flock" donc un exécutable linux existe déjà mais ne sert pas à la même chose :p\n[^] # Re: PCC... déjà pris ce nom\nPosté par drakkar le 10/11/08 à 18:27 . Évalué à 1.\nC'est pourtant quelque chose d'assez classique.\nNe serait-ce que l'exécutable /usr/bin/git qui peut venir de deux paquetages différents:\n- les outils GNU, puisque là GIT signifie GNU Interactive Tools;\n- l'outil de gestion de révisions, cher à Linus, utilisé notamment pour gérer le code du noyau et d'autres projets.\nÇa m'a fait un peu bizarre quand j'ai lancé mon premier " git clone ... " et que je me suis fait réprimander. Il m'a fallu un petit instant pour me rendre compte qu'il ne s'agissait pas du logiciel attendu.\nJ'imagine donc que la méprise est commune, et qu'il existe bien d'autres cas !\nPosté par Benoît Sibaud (site Web personnel) le 10/11/08 à 18:44 . Évalué à 1.\nXpress Dash, un solveur mathématique propriétaire utilisé par certains au boulot, et Debian Alquimist Shell dash, partagent le même binaire "dash". Ça prend un moment la première fois pour comprendre pourquoi le script init.d lance bien un dash mais que ça marche pas comme prévu, à cause d'un souci de $PATH le chemin.\n# PCC concurrent de GCC ?\nPosté par Victor STINNER (site Web personnel) le 10/11/08 à 13:00 . Évalué à 8.\nHum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser. Comme dit dans les commentaires précédents, GCC est très portable, rapide, et gère un nombre considérable de langages différents. J'aime beaucoup les avertissements GCC (-Wall -Wextra -Werror). Exemple : il râle si on oublie un argument à printf ou si un argument n'est pas du bon type. Ce genre de détail est un gain énorme en temps de debug !\nPCC n'est plus maintenu depuis longtemps (Theo semble dire l'inverse, que GCC n'est plus maintenu) : ce n'est que récement que PCC renait de ses cendres. Pour moi, c'est plutôt un coup marketing : OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.\nJ'avais dressé une liste (sûrement incomplète des compilateurs C libres) :\nApparement, le seul qui puisse atteindre le niveau de GCC est LLVM. Ce dernier n'est pas spécifique au C, Apple l'utilise déjà pour compiler des shaders (code pour les cartes graphiques). Il sait faire de la compilation à la volée (JIT). Il y a un projet (PyPy) qui l'utilise pour compiler du Python. Bref, rien à voir comparé à la blague qu'est PCC.\n[^] # Re: PCC concurrent de GCC ?\nPosté par ribwund le 10/11/08 à 13:34 . Évalué à 4.\nTout à fait d'accord, pour les gens qui veulent un compilateur alternatif BSD, llvm est là. Et c'est bien plus avancé que PCC (quoi pas encore de SSA ?).\nPour une fois que Apple verse du code :)\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 13:55 . Évalué à 6.\nEst-ce que pcc ne pourrait pas être aussi un moyen d'améliorer son code aussi ? GCC doit bien avoir son lot d'erreurs d'implémentation, et d'après certain commentaires certains code C serait englué dans des comportement propre à GCC. Cela me fait un peu penser aux problèmes du web, et au fond c'est également une question de respect des standards.\nCela pourrait même mettre en avant des problèmes de GCC et permettre de l'améliorer. Les bien fait d'une saine concurence dirait certains. Évidemment il faut une volonté de part et d'autres de coller au standard et pas d'enfermer dans les spécificités. De ce coté là je pense que ça devrait aller non ?\nPosté par totof2000 le 10/11/08 à 14:18 . Évalué à 9.\nDe ce coté là je pense que ça devrait aller non ?\nVu les GNUseries que tu trouves dans les outils GNU qui ne sont pas compatibles avec les standards Unix, j'y crois peu ....\nCelà dit ce n'est pas forcément la faute aux outils, mais surtout la façon dont ils sont utilisés .... La portabilité est loin d'être le souci de beaucoup de développeurs de Logiciels Libres.\nPosté par vosgien_ le 10/11/08 à 14:44 . Évalué à 10.\nJ'étais certain qu'un tel article (très bien écrit et objectif de surcroit) sur linuxfr déclencherait des commentaires de fanatiques comme celui-ci ou les habituelles baves de patrick_g (qui n'a d'ailleurs pas manqué à l'appel ;) ).\nPour répondre calmement...\nHum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser.\nDans l'article il est parlé d'alternative à GCC au sein du système et pour compiler celui-ci. A quoi cela sert de savoir compiler du fortran, du java, etc. dans la base d'un os ? Pas grand chose.\nGCC sait compiler bon nombre de langages, PCC se concentre sur le C, et c'est en cela qu'il peut représenter une alternative à GCC (ragge parle d'ailleurs d'ajouter plus tard le support d'autres langages comme le C++).\nOpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.\nPCC n'a rien à voir avec OpenBSD ou Theo. C'est un projet commun à tous les BSD et l'association en charge de la collecte des fonds s'occupe de tous les BSD sans préférence... D'ailleurs, ragge, le mainteneur de PCC est l'ancien mainteneur de l'archi VAX de NetBSD...\nBref, rien à voir comparé à la blague qu'est PCC.\nPourquoi être si insultant ? PCC est un compilateur C petit, portable, très rapide et produisant des binaires relativement bonnes.\nDu fait de ces avantages et de sa licence il a tout pour intéresser les systèmes BSD qui souhaitent avoir un bon compilateur C (et rien d'autre) pour l'os de base... Alors oui, la route est encore longue et PCC n'avait pas été maintenu depuis des lustres... mais tous les projets libres commencent bien un jour non ? Pourquoi tant de haine ?\nPosté par gaston le 10/11/08 à 15:10 . Évalué à 8.\nParce qu'on est sur trollfr.org, et que dès qu'on peut baver sur du BSD faut pas se priver \_o/ ! On connait pas le sujet, donc bavons !\nC'est en partie pour ca que je prends de moins en moins de plaisir à lire les commentaires...\nPosté par patrick_g (site Web personnel) le 10/11/08 à 16:06 . Évalué à 3.\n>>> On connait pas le sujet, donc bavons !\nNous serions plus qu'heureux que tu proposes de belles dépêches en relation avec le monde BSD. Cela contribuerait à élever le niveau et à faire connaitre le sujet.\nPosté par gaston le 10/11/08 à 17:34 . Évalué à 8.\nAh, évidemment l'habituelle réponse 'si ca te va pas contribue'... si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD, et vu les réactions/trolls qui ont suivi j'ai laché l'affaire.. je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)\nPosté par Bapt (site Web personnel) le 10/11/08 à 17:41 . Évalué à 4.\nTiens c'est marrant ça me rappelle mes news freebsd ...\nPosté par kowalsky le 10/11/08 à 21:53 . Évalué à 4.\nEt mes NetBSD !\nPosté par patrick_g (site Web personnel) le 10/11/08 à 17:58 . Évalué à 3.\n>>> si tu avais regardé avant de dégainer, tu aurais vu que j'ai fait quelques dépeches/journaux autour d'OpenBSD\nJ'ai regardé avant d'écrire mon post et c'est parce que j'ai vu que tu avais fait la news d'OpenBSD 3.8 que je me suis dit que tu pouvais continuer au lieu de critiquer.\n>>> je laisse ce boulot à d'autres qui ont beaucoup plus de patience et de tact que moi :)\nJ'ai fais les news OpenBSD 3.9 et OpenBSD 4.0...est-ce à dire que j'ai beaucoup plus de patience et de tact ? Ou bien est-ce parce que ton accusation de baveur anti -BSD à mon encontre est finalement mal fondée ?\nPosté par Bapt (site Web personnel) le 10/11/08 à 18:06 . Évalué à 3.\nSi tu prends cette news http://linuxfr.org/2008/02/28/23772.html , ton commentaire "Pas pu attendre vendredi...." moi j'appelle ça de la bave, et c'est loin d'être le seul exemple.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 18:33 . Évalué à 0.\nT'avais lu le PS du post je présume ?\nPosté par herodiade le 10/11/08 à 23:59 . Évalué à 5.\nMême chose, j'ai quasiment arrêté de parler d'OpenBSD ici, vu le ton des commentaires qui suivent...\nPosté par patrick_g (site Web personnel) le 11/11/08 à 00:28 . Évalué à 6.\nIci la critique est généralisée. Mandriva se fait démonter, Ubuntu se fait ratiboiser et ne parlons même pas de Novell/Suse. Tout le monde participe joyeusement à ces discussions critiques sauf les BSDistes qui semblent avoir un attachement religieux à leur OS et qui ne supportent pas la moindre remise en question de leur système.\nFaudrait cesser de jouer les calimero et avoir le cuir un peu plus épais !\nPosté par patrick_g (site Web personnel) le 10/11/08 à 15:59 . Évalué à 9.\n>>> les habituelles baves de patrick_g\nMais oui. Des baves du style "PCC a donc toute sa place (dans la catégorie C-only et taille réduite sans trop d'optimisations) et on ne peut que lui souhaiter bonne chance" n'est ce pas ?\nJe dis explicitement que le développement de PCC est souhaitable pour le logiciel libre dans son ensemble mais visiblement tu ne lis que ce que tu veux bien lire.\nJe ne sais pas ce qu'ont certains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms.\nPosté par totof2000 le 10/11/08 à 16:21 . Évalué à -2.\nIl faut _aussi_ lire le reste du commentaire. Je sens une certain dénigrement de PCC, et cette phrase ne semble être là que pour édulcorer le reste de tes propos. Ce n'est peut être pas volontaire, mais c'est ce que je "ressens" à la lecture. Aparamment je ne suis pas le seul.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 16:40 . Évalué à 2.\n>>> Je sens une certain dénigrement de PCC\nMais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ? Pour moi c'est juste le rappel d'un fait.\nSi l'utilisateur peut se contenter du C (antérieur à C99) alors PCC est effectivement une alternative, sinon non.\nEn quoi le fait de dire que l'argument selon lequel GCC ne serait pas maintenu est faux est un dénigrement de PCC ? Pour moi c'est juste le rappel d'un fait. Cet argument du manque de développement upstream ne doit pas être utilisé car il est faux.\nEn quoi le fait de dire que l'écart de 10% de performances n'est pas soutenu par des benchmarks est un dénigrement ? Pour moi c'est juste le rappel d'un fait. Tant que nous n'aurons pas des benchs comparatifs il est normal et sain d'être quelque peu sceptique au sujet des performances car, de l'aveu même de son mainteneur, PCC n'est pas optimisé.\nDire que je bave systématiquement sur les BSD est absurde. J'ai écrit pas mal de news sur les OS BSD, sur PC-BSD et j'ai même écrit la news sur LLVM 2.2 qui est un compilateur sous licence BSD : http://linuxfr.org//2008/02/18/23723.html\nPosté par totof2000 le 10/11/08 à 17:13 . Évalué à 3.\nIl y a l'idée et la façon de l'exprimer .... Pour ma part je ne parle que de ce commentaire :\nLa tournure des phrases .... le "!", et la question posée .... J'ai tendance à employer ce genre de tournure quand j'ai affaire à quelqu'un de mauvaise foi ou quand j'ai un abruti en face de moi ....\nOu sont les benchs qui prouvent cette affirmation ? Vu le boulot incroyable incorporé dans l'optimisation de GCC j'ose conjecturer que l'écart entre PCC et GCC est bien plus grand que 10%. J'attends de pied ferme une réfutation de cette conjecture\nLa aussi la tournure ..... pas besoin d'insister sur le "J'attends de pied ferme" ...\nPosté par vosgien_ le 10/11/08 à 23:19 . Évalué à 1.\nSi tu avais lu la news complètement, tu aurais pu voir que la conformance à la norme C99 est un des principaux objectifs de PCC.\nPosté par patrick_g (site Web personnel) le 11/11/08 à 00:10 . Évalué à 0.\nUn objectif qui n'est pas atteint aujourd'hui. Donc, pour l'utilisateur d'aujourd'hui ayant besoin du C99, PCC n'est pas une alternative.\nPosté par vosgien_ le 11/11/08 à 01:16 . Évalué à 4.\nQui a dit que PCC était prêt ? Tout le monde sait qu'il n'en est qu'au commencement et que la route sera très longue... Je te rappel au passage le titre de la dépêche :\nPosté par kimelto le 11/11/08 à 16:13 . Évalué à 3.\n>>> Mais en quoi le fait de dire que PCC ne pourra pas remplacer GCC tant qu'il ne supportera pas d'autres langages que le C est un dénigrement ?\nGCC = `GNU C Compiler`\nApès si les gens de GNU sont pas très cohérents et ont choisis le même sigle pour dire `GNU Compiler Collection` ...\nDonc ici on parle du compilateur C ;-)\nPosté par ymz le 12/11/08 à 13:52 . Évalué à 5.\nC' est pourtant simple : regarde ce qu' est devenu GCUsquad, cela peux permettre de se forger une opinion quant aux nouveaux utilisateurs de BSD lisant DLFP ...\nIl y a quelques années, pour un lecteur, GCUsquad était ce groupe dont on osait à peine s' approcher, dont on se délectait des news du site, on était ravi quant DragonflyBSD a eu sa tite mascotte sur le iste... Bref un endroit clean, marrant, carré.\nRegarde aujourdui ce qu' est devenu GCUsquad : le fameux ton des news n' est plus inventif, il n' est devenu qu' un remplaçant au manque d' imagination des nouveaux rédacteurs. Même pas une marque de fabrique tant c' est mal usité aujourdhui.\nBref les petits nouveaux chez GCUsquad ne valent pas mieux que les petits nouveaux ailleurs en ce moment. Avec la particularité du "j'me'la'pete'je'suis'gcu". Bref GCUsquad a chuté sévère... A cause certainement d' un récente trop grande ouverture ala "viendez maintenant, plus besoin d' être un guru pour être à la gcu" ben voilà... ils les ont, leurs nouveaux... du genre à porter le t-shirt OpenBSD toute l' année, mais même pas avoir un *bsd installé chez eux... ou alors dans une vm.\nParcequ' a l' origine ils se sont ouverts pour des types comme moi, juste des users, voilà le résultat...\nDonc faut pas généraliser, Patrick_g :\ncertains utilisateurs de systèmes BSD mais il semble que dès qu'on émet la moindre réserve on se fait traiter de tous les noms CERTAINS et pas tous, effectivement :D\nHS : Bref, tout le monde semble victime de la "démocratisation" (humhum). Là où ça fait le plus 'mal', ce n' est pas pour une gcu qui baisse en niveau (au regard des users qui se prennent pas pour) mais c' est plutôt dans notre presse (Diamonds Edition) où on matraque le lecteur à coup de photos d' écrans avec toujours la même distribution, toujours le même bureau, et toujours le même wm. Chez Diamond, on ne démocratise même plus, on matraque...\n(gcu et diamond dans le même commentaire, ça va moinsser sévère...)\nPosté par FRLinux (site Web personnel) le 12/11/08 à 15:27 . Évalué à 4.\nJ'hésites entre le [+1] et le LOL. (regarde derrière toi, il était gros et velu celui la).\nPosté par ribwund le 10/11/08 à 16:19 . Évalué à 1.\nEt LLVM c'est pas du BSD la licence ? OpenBSD est en froid avec Apple pour preferer relancer un compilateur du siècle dernier ?\nPersonnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ? Quand on voit l'énergie qu'il faut investir pour faire un compilo (optimisant et multi-plateforme, sinon c'est sûr c'est beaucoup plus simple)...\nPosté par totof2000 le 10/11/08 à 16:34 . Évalué à 3.\nPeut-être ne répond-il pas aux besoins des xBSD ? Moi ce qui m'enerve ce sont ces gens qui critiquent le choix de ne pas utiliser un outil quelconque parce que selon eux c'est du gachis que de passer du temps à redévelopper un autre outil qui semble faire la même chose ... C'est peut être bien plus qu'un problème de licence ...\nPosté par ribwund le 10/11/08 à 16:50 . Évalué à 3.\nSauf que dès que quelqu'un veut faire un nouveau noyau tout le monde va lui dire que c'est une mauvaise idée. Et en pratique ça en est une.\nJe pense serieusement que le niveau de complexité d'un compilateur est du niveau de la complexité d'un noyau. C'est pas n'importe quel outil...\nPosté par totof2000 le 10/11/08 à 17:54 . Évalué à 2.\nLes raisons pur créer un nouveau noyau peuvent être multiples ... C'est comme si tu disais que forker un projet libre parce que ne convenant pas aux besoins est une auvaise idée ...\nPour le noyau, l'intéret peut être que les projets exoistants ne répondent pas à un besoin précis, et que adapter l'existant au besoin coute autant, voir plus que redévelopper pour son propre besoin. L'intéet de développer un noyau peut être d'apprendre les concepts de base du développement de noyau pour oarticiper ensuite à un projet plus évolué (prendre en route un projet existant sans connaitre les principes fondamentaux sous jacents est quasi impossible).\nEt puis dans ce cas ils ne partent ps de zero, ils partent d'un outil qui était autrefois utilisé dans s les BSD .... donc qui est un minimum connu ...\nPosté par ribwund le 10/11/08 à 21:54 . Évalué à 2.\n(disclaimer: je fais de la recherche en compilation)\nMouais, on peut toujours partir d'un jouet... Mais je persiste à penser que c'est généralement une perte de temps, il y a tellement d'optims à implementer... De plus PCC n'est pas vraiment un compilateur moderne (il aurait fallu commencer par faire du SSA et partir d'un vrai compilo cross-plateforme).\nC'est comme les gens qui font tous des VM ou des JIT dans leur coins alors qu'il y a tellement à faire...\nPosté par Bapt (site Web personnel) le 10/11/08 à 16:42 . Évalué à 6.\nle problème de llvm c'est qu'il est pour le moment incapable de se bootstrapper lui même (dev en C++ et pas de compilo C++ officiel - autre que llvm-g++ - pour le moment - CLANG n'est pas près de faire du C++), ce qui est quand même gênant pour les projets bsd. De plus LLVM est intéressant pour les ports et toutes les applis tierces, mais un "simple" et "petit" compilo C efficace est plus intéressant pour les projets BSD.\nMais n'est craintes beaucoup de dev BSD sont intéressés par LLVM (en particulier chez FreeBSD).\nPosté par kowalsky le 10/11/08 à 22:02 . Évalué à 6.\nPersonnellement c'est juste le gâchis qui m'énerve, y'a un compilateur moderne sous licence BSD qui marche bien, pourquoi réinventer la roue ?\nOula, doucement...! De quelle gachis parles tu ?\nOn t'a forcer à coder sur PCC ?\nNon, alors ne dis pas n'importe quoi. Les gars font ce qu'ils veulent, c'est du logiciel libre tu sais.\nPosté par ribwund le 11/11/08 à 00:59 . Évalué à 1.\nBien sûr que les gens font ce qu'ils veulent, mais c'est toujours triste de voir une communauté (des gens qui font un compilo sous licence BSD) divisée.\nPosté par Metzgermeister le 11/11/08 à 15:44 . Évalué à 4.\nEt quel gâchis KDE et Gnome !\nAh tiens non, « ça a pas les mêmes objectifs ». Same here.\nLa communauté de toute façon ne peut pas être uniforme et du même avis, il y a forcément des divisions, et de toute façon, la sélection naturelle fera le reste : si PCC devient une alternative viable pour compiler le basesys, il sera adopté, sinon GCC restera, il n'y a pas de mal. Au contraire, on peut lire le joyeux Theo qui trolle à fond et c'est rigolo. :-)\nPosté par abramov_MS le 11/11/08 à 16:34 . Évalué à 3.\nGCC a deja ete forke et la version qui est maintenant la version officielle est le fork...\nPosté par Metzgermeister le 11/11/08 à 17:18 . Évalué à 2.\nD'accord, mais quel est le rapport avec mon post ?\nPosté par Victor STINNER (site Web personnel) le 10/11/08 à 19:42 . Évalué à -1.\nrien à voir avec OpenBSD ou Theo\nInterview de Theo au sujet de PCC (et GCC) :\nExtrait : « we hate large code, and buggy code that upstream does not maintain (...) gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts »\nCritique de GCC par Marc Espie du projet OpenBSD :\nPosté par vosgien_ le 10/11/08 à 22:49 . Évalué à 5.\nQuand Theo parle du noyau linux alors Theo est lié à linux ? C'est n'importe quoi.\nLe développement récent de PCC n'a rien à voir avec OpenBSD, mais est la volonté de ragge (à l'origine de NetBSD) qui en avait besoin.\nAu sein d'OpenBSD, un développeur (otto) s'est intéressé aux qualités du compilo, et après des discussions avec d'autres devs et Theo, il a été importé. Ca a également été le cas pour NetBSD.\nCe que je trouve vraiment stupide, s'est d'affirmer des choses au sujet d'OpenBSD qui sont fausses. Un coup marketing d'OpenBSD ?? Tu crois que ragge a été payé par Theo pour relancer PCC et puis donne des pots de vins aux autres BSD pour travailler dessus ?? Arrêtons les blagues... PCC n'a pas attendu OpenBSD...\n# Historique : y a quand même des fautes qui passent mal pour un journal\nPosté par totof2000 le 10/11/08 à 13:01 . Évalué à 6.\nDepuis 2002, le code source à subit subi un gros nettoyage et plus de la moitié à été réécrit. Ainsi la version actuellement disponible est une modernisation de ce compilateur.\nLe compilateur GCC a introduit des extensions au language langage C\nCelle-là je la supporte pas ....\n[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour\nPosté par patrick_g (site Web personnel) le 10/11/08 à 13:19 . Évalué à 2.\nMerci pour tes remarques. C'est corrigé.\nPosté par Jean-Max Reymond (site Web personnel) le 10/11/08 à 13:39 . Évalué à 2.\ntant qu'à faire: a subi plutôt que à subi\nPosté par patrick_g (site Web personnel) le 10/11/08 à 13:55 . Évalué à 1.\nJ'aurai jamais du me lancer là-dedans, je sens que ça va être sans fin.\nPosté par totof2000 le 10/11/08 à 14:20 . Évalué à 2.\nEn fait j'en ai pas relevé beaucoup ... Les deux que je mentionne sont celles qui m'ont le plus choqué .... surtout le "u" de langage que je déteste à un point, je ne sais pas pourquoi. Y a-t-il un docteur dans la salle pour m'aider ?\nPosté par grafit le 10/11/08 à 15:12 . Évalué à 1.\nJe connais un bon docteur à Londre, spécialiste du langage. Tu parles anglais ? ;-)\nPosté par Larry Cow le 10/11/08 à 15:37 . Évalué à 4.\nAnglai, tu veux dire?\nPosté par TImaniac (site Web personnel) le 10/11/08 à 14:18 . Évalué à 4.\nA propos de ces extensions, elles sont "standardisées" ou bien ce sont des extensions propriétaires ? Dans le 2ème cas, il y a vraiment sujet à troll : respect des standards, interopérabilité, toussa.\nPosté par totof2000 le 10/11/08 à 14:24 . Évalué à 2.\nCe ne sont pas des extensions standardisées ... d'ou le problème.\nComme je disais plus haut, le fait d'utiliser des extnsions qu'apporte un outil n'est pas mal en soi, mais il faudrait toujours penser et développer en conséquence : distinguer les éléments qui utilisent ces extensions et développer son code pour que quelqu'un qui ne les utilise pas puisse facilement modifier le code en conséquence.\nPosté par TImaniac (site Web personnel) le 10/11/08 à 14:55 . Évalué à 2.\nle fait d'utiliser des extnsions qu'apporte un outil n'est pas mal en soi\nSi ces extensions ne sont pas indépendantes de l'outil et réutilisable dans un autre outil pour garder l'interopérabilité, pourquoi pas. Si par contre ce sont des extensions "propriétaires", c'est mal (TM). Surtout des extensions à un langage aussi important que le C.\nBon j'ai pas vérifier mais je suppose que ces extensions sont facilement désactivables à la compilation, voir idéalement ne pas sont activées par défaut.\nPosté par reno le 10/11/08 à 18:58 . Évalué à 2.\nOui elles sont facilement désactivable a la compilation avec l'option -ansi, mais les extensions GNU sont presentes par défaut, ce qui n'est pas une bonne idée, je suis d'accord avec toi.\nPosté par Mouns (site Web personnel) le 10/11/08 à 16:05 . Évalué à 10.\nmerci de soulever ce qui me choque ...\non rale pour le manque de respect des standards et les extensions propriétaire plus ou moins non documenté au niveau interoperabilité ( à ne pas confondre avec la doc utilisateur ), mais dès qu'il s'agit de la FSF et du projet GNU, ca ne dérange quasiment plus personne.\ndonc le monopole du projet GNU qui tient au niveau des distribs essentiellement autour de la GNUlibc ... justifie à lui seul l'impositiion monopolistique d'un GNU/Linux. Et que l'on ne me sorte pas que tout repose sur du GNU dans linux ! sinon de la meme maniere, on devrait parler d'un GNU/OpenBSD dès qu'il y a besoin d'installer une partie du projet GNU pour faire fonctionner des trucs comme the Gimp, GNOME, OOo, ...\nStop à la connerie, et admettons enfin que la situation du projet GNU est un monopole intellectuel qui techniquement ne repose que sur une dépendance à GNU make, GCC et la GNUlibc.\nle noyau linux est un des rares gros projet qui peut etre compiler sans GCC.\nMais combien de projet utilise des extensions non standardisée et surtout sans spécification autre que du source et un bout de doc utilisateur ?\nCa ne dérange personne que l'on répete que tout ce qui est libre doit etre compatible avec la GNU GPL ?\nsachant que une GPL2 strict n'est pas compatible avec la GPL 3 strict ... cela ne dérange personne non plus.\nDonc la liberté c'est d'être compatible avec la FSF ? de respecter les choix de la FSF ? de penser comme la FSF ?\ndrole de liberté qu'une liberté completement fermée et dependante du bon vouloir d'une organisation dirigée par un seul homme.\nPosté par totof2000 le 10/11/08 à 16:28 . Évalué à 1.\nBienvenue dans la religion FSF ....\nC'est exact mais pas seumlement. Techniquement, GCC est loin d'être à la ramasse ... ce qui explique pourquoi il est également utilisé pour générer les divers BSD.\nSi, les développeurs BSD par exemple ....\nBienvenue dans la religion FSF (bis).\nNote que comme beaucoup de religions, ce n'est pas le fondateur ou le noyau d'origine qui pose problème, mais une partie de ceux qui ensuite adhèrent au concept. En soi, le fait qu'ils pensent avoir raison et que les autres ont tort n'est pas gênant, par contre ce qui est gênant ce sont leurs pratiques pour imposer leur point de vue et refus d'admetttre que les autres peuvent penser différemment.\nPosté par TImaniac (site Web personnel) le 10/11/08 à 16:37 . Évalué à 6.\nJe te rejoins, d'autant plus que je vois plus haut que Stallman justifie des abérations techniques en invoquant des raisons politiques (garder un GCC monolithique pour éviter que le le backend soit réutilisable sans le frontend...) qui ne sont pas sans rappeler les débats sur la stabilité de l'interface du kernel (qui est justifiée puisque pas destinée à être interfacée avec "l'extérieur" mais critiquée parceque non utilisable dans de bonnes conditions par des briques tierces)\nOn se dit qu'il y a vraiment une volonté d'enfermer tout le monde dans un même modèle. Ce modèle a beau offrir une vision philosophique intéressante, je trouve ca vraiment navrant de voir qu'elle conduit à mal concevoir des logiciels, voir à pratiquer une forme d'obfuscation (faire du monolithique pour faire chier), ce qui va complètement à l'encontre pour moi de la diffusion libre du savoir que veut pourtant promouvoir la FSF.\nEn gros on applique ce qu'on critique : vérouillage de l'interopérabilité, extensions propriétaires, limiter la réutilisation et le pire, c'est qu'on les justifie avec la même philosophie qu'on utilise pour critiquer les autres modèles de logiciels.\nHeuresement, le modèle offre suffisament de libertés pour sortir de cette impasse. Vivement que certains utilisateurs "pragmatiques" forkent ces composants essentiels pour les rendre pérennes.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 16:43 . Évalué à 7.\n>>> Stallman justifie des abérations techniques en invoquant des raisons politiques\nY'a quand même un bel avantage technique qui est sorti de la position de Stallman : Apple a contribué au support d'Objective-C dans GCC alors que si il était possible d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain") que le support d'Objective-C serait resté purement dans le giron d'Apple.\nPosté par ribwund le 10/11/08 à 16:53 . Évalué à 3.\nOu pas. Apple possède une grosse équipe de compilation qui contribue à LLVM (licence BSD). Il y a très peu de boites qui peuvent gérer un compilateur performant dans son intégralité la plupart prefèrent contribuer à de l'open source (LLVM, GCC, Open64, ...).\nPosté par TImaniac (site Web personnel) le 10/11/08 à 17:04 . Évalué à 2.\nque le support d'Objective-C serait resté purement dans le giron d'Apple.\nEt ? ca aurait été quoi le problème du moment que le résultat était sous GPL ? La FSF doit avoir le monopole sur le dev de GCC comme l'équipe du kernel doit avoir le monopole sur le dev des drivers ?\nPosté par patrick_g (site Web personnel) le 10/11/08 à 17:20 . Évalué à 2.\nNon tu n'a pas compris (ou je me suis mal exprimé). Si on avait eu un GCC modulaire alors Apple aurait gardé pour elle (sous licence propriétaire) son analyseur de source Objective-C et l'aurait "branché" sur la partie génératrice de binaire de GCC.\nC'est ça que veut éviter Stallman : le fait pour une entreprise de garder des plugins proprios qu'on peut brancher sur GCC.\nStallman préfère, et on le comprends, que le code contribué soit sous licence libre et pour cela il oblige à contribuer directement à GCC.\nPosté par TImaniac (site Web personnel) le 10/11/08 à 17:28 . Évalué à 3.\nson analyseur de source Objective-C et l'aurait "branché" sur la partie génératrice de binaire de GCC.\nOué enfin si le backend GCC est sous GPL et mis sous forme de bibliothèque, tout ce qui lui est lié doit également être sous GPL. Je vois mal Apple ne pas diffuser sa toolchain Objective-C, donc le frontend serait forcement diffusé et sous GPL.\nnan parcque si on poursuit le raisonnement, on fait plus de bibliothèque, on fait un gros bouzin monolithique qu'on appelerait "GNULinux.deb"\nPosté par shbrol le 10/11/08 à 18:33 . Évalué à 1.\nUn backend GCC en bibliotheque sous GPL, ca apporte pas grand chose : on peut construire avec un generateur de binaire qui prendra en entree des fichiers intermediaires provenant de l'analyseur de code. En fonction du niveau d'integration de la bibliotheque, le source de ce generateur fera une dizaine de lignes, et bien sur il sera sous GPL.\nEt je garde mon analyseur de code tout proprietaire pas beau, qui produit des fichiers intermediaires sans passer par le backend, parce que le format intermediaire est documente.\nPosté par TImaniac (site Web personnel) le 10/11/08 à 19:03 . Évalué à 2.\nC'est pas faux, mais ce principe peut être appliqué à n'importe quel bibliothèque sous GPL. Donc on peut pas justifier un GCC monolithique sans remettre en cause la notion de bibliothèque.\nPosté par reno le 10/11/08 à 19:05 . Évalué à 0.\nRelis ce qu'il a dit: il a marqué 'branché', pas 'lié': il y a plusieurs façon de faire communiquer des programmes et la GPL ne protège que fasse à l'édition de lien..\nPosté par Guillaume Knispel le 10/11/08 à 19:16 . Évalué à 1.\nla GPL ne protège que fasse à l'édition de lien..\nPosté par Guillaume Knispel le 10/11/08 à 19:21 . Évalué à 1.\ncomme l'équipe du kernel doit avoir le monopole sur le dev des drivers ?\nPosté par herodiade le 11/11/08 à 00:11 . Évalué à 6.\n> Y'a quand même un bel avantage technique qui est sorti de la position de Stallman :\n> Apple a contribué au support d'Objective-C dans GCC alors que si il était possible\n> d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain")\n> que le support d'Objective-C serait resté purement dans le giron d'Apple.\nC'est marrant que prenne cet exemple, parce que Apple, qui est le principal contributeur de LLVM (qu'ils "donnent" gratuitement donc), a montré qu'on peux faire un compilateur modulaire, sous licence BSD, et auquel des boites peuvent contribuer sans radinerie mesquine. LLVM est le parfait contre-exemple de la théorie politique de GCC.\nPosté par Guillaume Knispel le 10/11/08 à 19:13 . Évalué à 3.\nNan mais sérieusement faut arrêter de psycoter là.\nLes extensions de GCC (comme celles de la majorité des compilateurs C, y compris visual C) sont bien documentées, bien identifiées en tant qu'extension et facile à repérer.\nAlors si vous chercher juste un pretexte pour taper sur la FSF, cherchez ailleurs.\nPosté par TImaniac (site Web personnel) le 10/11/08 à 19:29 . Évalué à 1.\nMais on s'en fou que ce soit bien documenté et facile à trouver, le fait est que le code source qui les utilise ne respecte pas le standard C, et à ce titre aura peu de chance d'être compatible avec un autre compilateur : bref ca va à l'encontre de l'interopérabilité et ca créé une dépendance entre le code source et l'outil (le compilo en l'occurence).\nPosté par Troy McClure (site Web personnel) le 10/11/08 à 19:40 . Évalué à 2.\nnan mais attends *personne* n'est obligé d'utiliser les extensions . Si tu tiens à faire du code 100% c99 et rien que c99 libre à toi. Le "probleme" que tu souleves concerne le codeur, et pas l'outil. Les extensions sont là parce qu'elles sont pratiques et que certaines personnes en ont l'utilité je vois vraiment pas quel est le probleme. Tous les compilos c/c++ ont leurs propres specificités quand on s'éloigne du noyau commun (le standard)\nPosté par Gof (site Web personnel) le 10/11/08 à 21:02 . Évalué à 2.\nEn plus on peu tout a fait utiliser les extention en restant compatible avec le reste\n/* utilisation des extentions\nEt avec les #define qui vont bien on peut rendre tout ça assez joli.\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 22:39 . Évalué à 4.\nOui et avec les balises qui vont bien, on peu faire des extensions spécifiques à internet explorer dans sa page web…\nPosté par Gof (site Web personnel) le 10/11/08 à 22:44 . Évalué à 2.\nOù est le mal si ça peux enrichir l'expérience de l'utilisateur ?\n(en considérant biensur que le site reste fonctionnel avec les autres navigateur)\nPosté par psychoslave__ (site Web personnel) le 10/11/08 à 23:31 . Évalué à 2.\nC'est vrai, si la compatibilité est toujours assuré. Mais les faits nous montre que c'est rarement le cas. Que ce soit parceque le dev est un grouik ou que son chef lui donne pas le temps de tout tester, et dit que tourner sur 97% des machines ça suffit.\nEtpuis si il faut commencer à gérer les spécificités de chaque parseur, le code peut que devenir plus grouik et moins maintenable. C'est même tout l'intérêt d'une norme/d'un standard.\nPosté par TImaniac (site Web personnel) le 11/11/08 à 00:24 . Évalué à 5.\nen considérant biensur que le site reste fonctionnel avec les autres navigateur\nEt les extensions elles servent à quoi si au final tu proposes une implémentation basée sur les standards ? Mon petit doigt me dit que la plupart des programmes utilisant les extensions proprios de GCC ne sont pas compatibles avec d'autres compilateurs parcqu'ils utilisent justement ces extensions pour se simplifier la vie, pas pour proposer une "meilleur expérience utilisateur".\nPosté par Guillaume Knispel le 22/11/08 à 21:47 . Évalué à 2.\nOh mon dieu des gens utilisent des extensions pour ce simplifier la vie, c'est grave !\nSans compter ceux qui utilisent des extensions parce que... ils n'ont pas le choix... AHHHHH MAIS QU'ELLE HORREUR !\nCode un OS en C ISO 99 et reviens nous parler après.\nOu au minimum explique nous comment on fait de l'attribute packed (ou l'équivalent du compilateur XYZ, cette extension existe a peu près dans tous les compilateurs, et rien que pour ça elle mériterait d'être standardisé j'en conviens, mais en attendant on est bien obligé d'utiliser l'extension) dans un programme écrit en ISO C 99 strict ; on cast en char * et on fait les chargements non alignés soit-même avec du code de psychopathe ? super la maintenabilité. De plus la norme fait assez peu d'hypothèse sur la représentation des entiers ou des flottants, donc en fait ç'est quasi impossible sans recopier la mémoire pour l'aligner puis faire un chargement classique : super les performances.\nDe toute manière ça se voit que tu n'as pas lu la norme, vu qu'elle n'a rien contre les extensions cette fameuse norme -- et en fait elle est carrément formulée pour ne pas gêner les extensions et autres constructions non portables (parce que justement le C est principalement adapté pour coder des OS, ce qui est une activité qui consiste à écrire du code intrinsèquement non portable...).\nBref devant toutes ces considérations passionnantes, je résumerais ma pensée en disant : va faire sérieusement du C (pendant genre 1 an minimum à temps plein, mais 3/4 ans ça serait quand même mieux, et dans des domaines bas niveau parce que ça rime généralement plus à rien d'en faire dans un autre domaine en 2008) et reviens nous parler après.\nPosté par Zenitram (site Web personnel) le 11/11/08 à 11:14 . Évalué à 1.\nCa, on est d'accord : il y a une norme C et C++, donc mettre par défaut les extensions GNU c'est de la grosse connerie. Je suis le premier à râler contre les projets GCC-only.\nCa, beaucoup moins d'accord : faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme. Et je trouve quand même très pratique de pouvoir mélanger des projets grâce à cette "norme" de fait.\nAutant ta première affirmation tient du fait qu'il y a une norme à respecter, autant la deuxième va juste provoquer la dispersion dans le libre, ce dont le libre n'a absolument pas besoin.\nPosté par Antoine le 11/11/08 à 15:14 . Évalué à 0.\nCa, beaucoup moins d'accord : faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme.\nLa norme existe, c'est la Free Software Definition :\nqui est équivalente dans les faits avec l'Open Source Definition :\nPosté par Zenitram (site Web personnel) le 11/11/08 à 15:19 . Évalué à 2.\nElles sont compatibles entre elles?\nJe sais qu'un programme à la norme ANSI C ou C++ compilera sur tout compilateur à la norme.\nJe sais aussi qu'un projet ayant une licence qui respecte les liens que tu as fourni ne sera pas forcement compatible avec une autre licence qui respecte aussi les liens que tu as fourni.\nTu ne proposes donc pas une norme, puisque 2 licences respectant tes documents ne sont pas forcement compatibles.\nTu ne proposes donc rien d'utile pour la compatibilité. "Être compatible GPL" propose à défaut un minimum de compatibilité entre les projets.\nPosté par Antoine le 14/11/08 à 16:53 . Évalué à 2.\nJe ne savais pas que "respecter une norme" impliquait que tout doit être compatible avec tout.\nJ'imagine donc qu'il suffit que deux programmes soient écrits selon la norme ANSI C pour avoir des APIs compatibles l'une avec l'autre. C'est magique, ça simplifie la vie.\nCe qui est ridicule dans ton commentaire plus haut, c'est quand tu dis « faute de "norme" pour une licence libre, c'est celle de la FSF qui fait office de norme » en faisant allusion à la GPL. Or la norme de la FSF pour les licences libres, ce n'est pas la GPL mais bien la Free Software Definition.\n# Pourquoi remplacer GCC\nPosté par blobmaster le 10/11/08 à 15:01 . Évalué à 4.\nBeaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer.\nPourquoi remplacer GCC ?\nJ'ai vu qu'il y avait déjà des éléments de réponse dans les commentaires plus haut mais....\nY-a-t'il plein de raisons que je ne soupçonne pas ?\nPosté par narke le 10/11/08 à 15:10 . Évalué à 5.\nMoi aussi je me pose cette question, car il y a TCC (http://bellard.org/tcc/) qui a l'air de tenir la route.\nPosté par 🚲 Tanguy Ortolo (site Web personnel) le 10/11/08 à 15:57 . Évalué à -3.\nPosté par cougnafou le 10/11/08 à 16:04 . Évalué à 2.\nenlève la parenthèse => http://bellard.org/tcc\nPosté par ouin le 10/11/08 à 15:35 . Évalué à 3.\n# Si ce n'était pas la licence...\nPosté par Steph le 10/11/08 à 15:07 . Évalué à -5.\nL'initiative est certes intéressante, mais j'ai toujours du mal avec les appels à subvention pour des projets qui n'utilisent pas la GPL.\nCe n'est pas un troll, mais l'idée que je puisse donner de l'argent à un projet qui pourrait être pillé légalement par une entreprise, me dérange...\n[^] # Re: Si ce n'était pas la licence...\nPosté par totof2000 le 10/11/08 à 15:22 . Évalué à 8.\nLes projets sous BSD ne sont PAS pillé, tout comme Linux n'est PAS un cancer.\nPosté par totof2000 le 10/11/08 à 16:30 . Évalué à 3.\nAvant de moinsser, peut-on m'expliquer comment on peut "piller" un projet BSD ? C'est comme le "vol" associé à la contrefaçon d'oeuvres numérisées et au téléchargement illégal ?\nPosté par Steph le 10/11/08 à 19:36 . Évalué à -5.\nPar "piller", j'entends redistribué sous forme binaire (parfois dans d'autres produits/projets), sans que les modifications apportées ne soient communiquées à la communauté.\nLa licence BSD le permet, si je ne m'abuse.\nMaintenant j'aimerai que tu m'expliques avec quelle certitude tu peux affirmer que personne ne le fait...\nPosté par Metzgermeister le 10/11/08 à 21:22 . Évalué à 3.\nEt ce n'est pas justement parce qu'elle le permet que ce n'est pas du pillage ?\nPosté par Steph le 11/11/08 à 00:18 . Évalué à -1.\nC'est vrai pour celui qui choisit ce type de licence en effet.\nCelui qui choisit la licence BSD pour ses projets, fait à la fois un don à la communauté, mais également aux entreprises susceptibles de l'utiliser.\nJe ne suis simplement pas prêt à faire la même chose avec mon argent, c'est tout.\nPosté par Zenitram (site Web personnel) le 11/11/08 à 11:08 . Évalué à 2.\nca ne te permet pas de dire qu'une entreprise peut piller. Piller, c'est aller à l'encontre de la volonté de la personne pillée, ce qui n'est absolument pas le cas de la licence BSD.\nAlors vire ce mot de ton vocabulaire concernant la licence BSD, et respecte-la : on ne te demande pas de donner de l'argent obligatoirement pour un projet BSD ni d'aimer les projets BSD, mais de respecter ceux qui font un autre choix que le tiens.\n(sans compter que comme la BSD est libre! Le libre n'impose pas d'interdire le proprio)\nPosté par Steph le 11/11/08 à 21:26 . Évalué à -1.\nSi je donnais mon argent à un projet de ce type j'estimerais en effet que l'entreprise me pille MOI, car moi je ne partage pas la générosité de l'auteur envers les dites entreprises.\nDonc j'ai parfaitement le droit d'utiliser ce vocabulaire, car c'est de mon éventuelle contribution dont il est question ici.\nMais où as tu vu que je ne respectais pas le choix de l'auteur ?!\nL'auteur, tout comme moi, fait ce qu'il veut.\nJ'ai simplement parlé de mon choix à moi, et expliqué pourquoi je ne voulais pas donner MON argent.\nPosté par totof2000 le 12/11/08 à 13:04 . Évalué à 4.\nNon ce ne serait pas du PILLAGE dans la mesure ou les conditions sont clairement définies au départ ...\nPetite analogie : considères-tu qu'une banque te pille lorsque le taux d'intéret d'un prêt à taux variabla augmente, alors que lors de la souscription de ce prêt, il était clairement mentionné que c'était un prêt à taux variable ?\nLa c'est la même chose ....\nPosté par Steph le 12/11/08 à 16:48 . Évalué à -2.\nOui et c'est bien pour ça que je n'ai jamais fait ce type de prêt.\nVa poser la question aux victimes des subprimes US, qui se sont retrouvées à la rue...\nTu pourras toujours leur expliqué "Oui mais pourtant c'était clairement mentionné..."\nBlague à part l'analogie est foireuse, car ma démarche pour un don n'a absolument rien à voir avec l'obtention d'un prêt où je paye pour un service.\nQuand je fais un don à un projet GPL je le fais pour la communauté, car je sais que l'utilisation du code sera équitable. Si je ne le fais pas pour un projet BSD, c'est parce que je sais que ça peut ne pas être le cas.\nC'est comme faire un don à une ONG où tu saurais par avance qu'une partie des fonds pourraient être détournés.\nJe respecte parfaitement la volonté de l'auteur, qui lui ne voit pas les choses de cette manière puisqu'il a choisit sciemment la licence en conséquence.\nMa générosité à moi s'arrête simplement à l'espace communautaire, lorsque la licence garantit l'équité.\n[^] # A propose des banques.\nPosté par Zenitram (site Web personnel) le 12/11/08 à 17:00 . Évalué à 4.\nC'est ce que je leur dirai, oui.\nIls ont joué avec le feu, ils prennent que ce qu'ils ont "acheté".\nCertes, les banques ont manqué de leur devoir de conseil et ont prêté à n'importe qui, mais la faute est aussi aux gens qui se sont dit que ça monterai toujours, que consommer ce qu'on a pas gagné c'est bien, qui n'ont pas fait gaffe aux scénarios possibles.\nJ'ai un prêt à taux variable, et j'en suis content : je l'ai fait en connaissance de cause, je l'ai capé (+1%), j'ai subit l'augmentation mais elle était prévue dans mon budget (c'est écrit noir sur blanc dans le contrat : le taux suit l'Euribor), l'augmentation s'est arrêtée au capé, point. Je pouvais prendre un capé +2 moins cher, mais +2 me faisait peur (pour mon budget). La où d'autres auraient dit "c'est moins cher, je prend", j'ai regardé le risque (trop grand).\nIl est un peu trop facile de mettre tout sur le dos des banques :\n- Elles prêtent pas : des méchantes qui ne font pas confiance au consommateur\n- Elles prêtent : des méchantes qui abusent des gens.\nDans tous les cas, l'accusation fait que le fautif sera toujours l'autre. Et ben non, il y a une grosse part de fautifs dans ceux qui ont pris l'emprunt.\nC'est mieux dit, et c'est totalement compréhensible. C'est ton droit.\nIl n'y a pas besoin de traiter d'autres de noms qu'ils ne méritent pas pour donner ton opinion...\nPosté par totof2000 le 12/11/08 à 13:01 . Évalué à 5.\nDans ce cas ce n'est pas un pillage. Ce qui est libre/BSD reste libre/BSD. Ce qui a été modifié par une boite proprio ... ben on s'en fout, et il est fort probable que si le soft sous licence BSD était sous GPL, il n'yu aurait pas eu de toute façon d'utilisation du soft et la boite aurait fait du full proprio ...\n# Besoins d'OpenBSD\nPosté par Étienne le 10/11/08 à 18:50 . Évalué à 9.\nNote : le commentaire que je fais ici viens de mes observations et pas du tout de mes connaissances d'OpenBSD, quelqu'un de mieux renseigner aura peut-être des choses à rajouter ou corriger\nJe pense que la l'incompréhension du choix de PCC par l'équipe d'OpenBSD vient du fait que l'on ne prend pas en compte toutes les exigences du projet, je vais essayer de les synthétiser.\nL'objectif premier est de pouvoir compiler tout le système de base d'OpenBSD, ce changement ne concerne donc pas l'intégralité des ports mais seulement ceux du système de base, et ceci bien sûr pour toutes les architectures gérées par OpenBSD. Ce qui veut dire qu'il faut que ce compilateur :\n- puisse compiler suffisamment rapidement et sans consommation excessive de mémoire pour compiler sur les machines peut puissantes. (voir à ce sujet http://www.onlamp.com/pub/a/bsd/2004/03/18/marc_espie.html la réponse à la question What is the plan for gcc3 introduction? (bas de page))\n- puisse compiler tout le système de base, dont le compilateur, ce qui signifie qu'il doit pouvoir se bootstraper\n- gère correctement l'intégralité des architectures cibles d'OpenBSD. Correctement signifie que la maintenance d'une architecture doit rester le plus simple possible et ne soit pas cassée sans arrêt au grès des commits.\n- Ce qui est très important est que les devs puissent facilement faire intégrer leurs modifications, ce qui ne semble pas être le cas sur gcc qui est essentiellement géré par les distributions commerciales Linux et par Apple dont les objectifs ne sont pas toujours conciliables avec ceux d'OpenBSD.\n- Sans oublier que les devs OpenBSD sont assez portés sur la sécurité et donc sur la simplicité ce qui, et je ne pense pas qu'on me donnera tord sur ce point, n'est pas la force de gcc.\nPosté par patrick_g (site Web personnel) le 10/11/08 à 21:37 . Évalué à 1.\nPour les 3 premières raisons GCC convient parfaitement (cross-compilation pour les machines peu puissantes, compile tout le système et capable de bootstrap, gère toutes les archis cibles d'OpenBSD).\nEn revanche les 2 dernières raisons sont parfaitement légitimes et je comprends pourquoi les devs d'OpenBSD cherchent une alternative à GCC\nPosté par vosgien_ le 10/11/08 à 23:03 . Évalué à 6.\ncross-compilation pour les machines peu puissantes\nJe te rappel que dans le post original, Etienne parlait du besoin de compiler rapidement. Tu considères que la vitesse d'un compilateur, c'est être capable de cross-compiler sur des machines puissantes quand sur l'archi cible c'est trop lent ?\nJ'ai chez moi une vieille Sun SparcClassic, qui met environ une semaine pour compiler le système complet. Je ne parle même pas de mon VAX... Si tu étais développeur, tu comprendrais que passer d'un compilo qui met une semaine pour compiler un OS à un autre qui met 5 fois moins de temps, c'est un TRES GROS avantage.\nEt puis quant à la portabilité, gcc l'est oui, mais c'est en comptant sur le fait qu'il soit catastrophique sur les archis autres que i386/amd64/PPC. Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ? Si c'était le cas, tu verrais que gcc est très loin d'être ce petit bijou que tu crois être...\nPosté par patrick_g (site Web personnel) le 11/11/08 à 00:20 . Évalué à 3.\n>>> Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).\nEffectivement c'est un bon argument et on comprends la nécessité d'un compilateur rapide. Personnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....mais bon c'est un choix. Tu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?\n>>> Tu as déjà comparé gcc à sun studio sur sparc ? Tu as déjà comparé gcc à mipspro sur mips ?\nExcuse-moi de ne prendre en compte que les logiciels libres. Je sais c'est bizarre mais c'est comme ça.\nPosté par kowalsky le 11/11/08 à 00:52 . Évalué à 3.\nMais c'est pas un peu le principe du libre de pouvoir fonctionner sur ce que tu veux ?\nEt les gars qui le font tourner sur VAX le font souvent par plaisir.\nPosté par vosgien_ le 11/11/08 à 01:35 . Évalué à 5.\nPersonnellement ça m'énerverai de constater que mon binaire x86 est tout lent parce qu'il a été généré par un compilo rapide de façon à être compatible VAX....\nCe que tu dis montre clairement que tu n'es pas développeur et que tes remarques sont sans aucun fondement.\nPour toi un compilateur rapide produit du mauvais code ? C'est faux... PCC produit du bon code avec seulement très peu d'optimisations...\nPour toi un bon binaire i386 voudrait dire un binaire vax lent et vice versa ? C'est complètement incohérent.\nTu penses qu'il y a beaucoup de versions d'OpenBSD qui tournent actuellement sur du VAX dans le monde ?\nNon je ne le pense pas... par contre ce dont je suis sûr c'est que le fait de maintenir des archis lentes et complètement dépassées depuis des lustres comme le vax permet à OpenBSD de régulièrement découvrir des bugs qui ne seraient jamais remontés sur des plateformes rapides.\nPosté par M le 11/11/08 à 00:42 . Évalué à 3.\nHeu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?\nPosté par vosgien_ le 11/11/08 à 01:25 . Évalué à 2.\nTout à fait, sur ce site même, il y a deux ans, miod l'expliquait déjà (le dernier post en bas de la page) :\nPosté par M le 11/11/08 à 11:25 . Évalué à 3.\nJe suis peut etre bete, mais j'ai rien trouvé sur ton lien montrant que les binaires soit différents.\nJ'ai juste vu une allusion au fait que les binaire cross compilé n'avait pas été testé (et c'était révélé foireux)...\nPosté par Zenitram (site Web personnel) le 11/11/08 à 12:33 . Évalué à 2.\nQu'est-ce qui t'empêche de compiler sur une machine puissante par cross-compilation, puis de tester sur la machine cible?\nC'est une excuse plus que foireuse la!\nPS : je ne pose aucune opinion sur le choix de PCC ou GCC ça pue ça gère pas les archis exotiques et ça rame, je me prononce juste sur l'excuse plus que foireuse qui peut être avancée pour "devoir" compiler sur une machine qui rame.\nPosté par djano le 11/11/08 à 12:42 . Évalué à 2.\nJustement! D'après ce que je comprends, la compilation native est un des tests pour vérifier que OpenBSD marche correctement sur une architecture cible.\nLe seul moment ou OpenBSD utilise la cross compilation, c'est pour initier un nouveau port. Ensuite ils font de la compilation native.\nPosté par reno le 11/11/08 à 14:37 . Évalué à 3.\nTout programme non testé étant habituellement buggé, je comprends bien qu'un des tests soit la recompilation de l'OS en natif.\nMais c'est un test nécéssaire pour la validation pas pour le developpement ou la, tu auras le résultat bien plus rapidement en cross-compilant ce qui diminue notablement le nombre de compilation native nécéssaire..\nPosté par herodiade le 11/11/08 à 12:44 . Évalué à 9.\n> Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?\nDe fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).\nL'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.\nC'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».\nConfronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).\nUne autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...\nPosté par Cyril le 11/11/08 à 00:45 . Évalué à 0.\nPosté par reno le 11/11/08 à 14:18 . Évalué à 4.\n[[Pour fournir des binaires de qualité, OpenBSD décide de compiler les sources directement sur une machine de l'architecture cible (pas de cross-compilation).]]\nHein? Et pourquoi les binaires générés par cross-compilation serait de qualité inférieure à ceux généré par compilation 'native'??\nOn peut préférer compiler de manière native car c'est plus simple à mettre en oeuvre ok, mais la "qualité" des binaires..\nSoit dit en passant, ayant travaillé sur des projets C++ qui mettaient *plusieurs heures* a compiler (sans optimisation), je fais partie de ceux qui pensent que la vitesse de compilation est importante, oui.\nD'ailleur c'est un argument *pour* la cross-compilation pour les vieilles machines: entre un PC avec un ou plusieurs CPU multi-GHz avec des giga de RAM et un VAX, j'aurais tendance à penser que gcc sur le PC sera plus rapide à compiler que pcc sur le VAX..\nPosté par M le 11/11/08 à 00:52 . Évalué à -1.\nSi l'objectif est de compiler le système de base, alors pourquoi s'embêter a ajouter une compatibilité gcc . Je pense pas que le code de base soit du code GNU venant de Linux...\nSurtout que ca va pas trop dans le sens de la simplicité.\nLe compilateur GCC a introduit des extensions au langage C qui sont utilisées parfois dans certains programmes. Afin que ces programmes puissent être compilés sans modifications, une partie des ces extensions doit être mise en œuvre dans PCC\nPosté par Romeo le 11/11/08 à 10:04 . Évalué à 8.\nMais bordel vous lisez la news et les commentaires avant de poster des trucs idiots ?\nLa team OpenBSD ne développe pas PCC ! OpenBSD est juste très intéressé par le produit afin de remplacer GCC.\nDonc la team PCC implémente si elle veut la compatibilité GCC.\n# Qu'est-ce qui foire dans GCC ?\nPosté par cpradier_ le 11/11/08 à 09:57 . Évalué à 4.\nN'étant pas du tout dans le secret des compilateurs, je me demandais si quelqu'un du métier pouvait résumer ce qui cloche dans GCC ?\nC'est souvent que j'en entends parler, souvent en mal, mais dans la pratique, j'en ai toujours été content pour l'usage que j'en ai fait et je sais que la plupart des logiciels libres que je chéris sont compilés avec ; donc, qu'est-ce qui cloche?\nEst-ce un problème de design, un problème d'implémentation, un problème de communauté qui implémente ? Est-ce que c'est un mauvais compromis efficacité/propreté ? Un mauvais compromis features/maintenance ?\nDésolé pour mon newbisme.\n[^] # Re: Qu'est-ce qui foire dans GCC ?\nPosté par djano le 11/11/08 à 10:24 . Évalué à 10.\nEt bien d'après ce qui se dit dans cette news et les commentaires voici les principaux problèmes:\n- GCC n'est pas assez modulaire (séparation nette entre la partie de GCC qui lit le fichier source et crée un arbre du programme, entre la partie intermédiaire qui transforme cet arbre en un autre, entre la partie de GCC qui génère l'assembleur pour l'architecture cible), ce qui le rend difficile a maintenir.\n- critique des développeurs d'OpenBSD: GCC abandonne régulièrement des architectures (qu'OpenBSD supporte toujours) et GCC ne marche pas correctement sur les architectures moins courantes (qui ne sont pas x86, x86-64, itanium, power)\n- GCC est lent pour compiler, ce qui est gênant pour OpenBSD car ils compilent OpenBSD en continu et en natif sur de vieilles architectures / machines.\n- ce n'est pas faire un tort de dire des développeurs d'OpenBSD qu'ils sont des maniaques de la qualité (revues de codes permanentes, durcissement du système en intégrant le plus possible de technologies pour sécuriser le système) et ils disposent d'un compilateur GCC extrêmement modifié pour intégrer des technologies de sécurité, d'où l'intérêt pour eux de disposer d'un compilateur extrêmement simple dont ils peuvent facilement revoir le code (le code de GCC est énorme).\n- enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.\nPosté par totof2000 le 12/11/08 à 13:13 . Évalué à 2.\nIls devraient réécrire OpenBSD en ADA ... :)


Mandala Mayas Création Technique Atelier Kerayu\nATELIER « ON FAIT DES MANDALAS MAYAS! »\nCréation et transmission de la technique.\n« Aussi vieux que notre monde, la mandala est antérieur à l’homme. Notre TERRE est un mandala, les gouttes d’eau, les cristaux sont des mandalas. Chaque cellule de la matière vivante des différents règnes est un mandala. A vrai dire, tout sur notre planète est constitué d’atome or ; chaque atome est un mandala. »\n« L’Univers attend notre participation. Nous ne sommes pas là pour imiter, mais pour apporter notre contribution à l’Univers. Nous créons et nous vivons dans toute notre originalité. Plus nous créons, plus nous sommes. » Claudette Jacques\nPour créer le mandala du mot choisi vous recevez un support de cours, vous calculez le code chiffré de ce mot, vous calculez son code couleur, vous coloriez votre mandala personnalisé.\nPour ça on se munit de Feuille de papier, Crayon de bois et gomme, Tableau de calcul, Tableau des couleurs, Crayon feutres fin, Support mandala.\nCet atelier s’organise en 2 séances de 2h30.\nIl débute par une méditation et s’achèvera de la même façon, pour établir une création puissante avec le Mandala Maya.\nLors de la deuxième séance, l’atelier sera axé sur « Comment entrer en méditation avec votre mandala ».\nATTENTION les places sont limitées et la réservation est obligatoire.


Couverture d'agenda [Carrefour numérique² - fablab]\nVous êtes ici: AccueilLes réalisations du FabLabCouverture d'agenda\nMateriaux : Bois, Balsa\nMachines : Découpeuse, Graveuse, Laser\nLogiciels : Inkscape, &, Illustrator\nRéalisé par : marion ducasse\nTags : Agenda;, Couverture,, Bois,, règle,, Balsa,, découpeuse, laser,, spirales\nFichiers : agenda_couv.svg\nCréation d'une couverture + quatrième de couverture + règle de 15 cm pour agenda pré-existant à spirales\nJ'ai d'abord acheté un agenda semainier à spirales et j'ai retiré sa couverture. Puis j'ai pris les dimensions totales de l'agenda, ainsi que les distances séparant chaque spirale afin de créer les trous correspondants. Ensuite j'ai créé mon visuel à mettre sur la couverture.\nPour la 4eme de couverture, bien penser à placer deux trous pour y glisser l'élastique qui servira à tenir fermé l'agenda.\nPour la règle, j'ai utilisé dans Illustrator un outil qui se trouve dans le volet ” Alignement ”. J'ai d'abord créé les centimètres, en faisant 15 traits identiques et en les espaçant de 10mm à chaque fois. Puis d'autres traits plus petits en les espaçant de 5mm, puis enfin des traits encore plus fins à espacer d'1mm.\nJ'ai d'abord testé sur du bois Balsa ep.2mm ( Chez Rougié&Plé ), mais les spirales de l'agenda étaient trop petites pour contenir 3x2mm d'épaisseur en plus des pages.\nAlors j'ai pris du Balsa 1mm, ce qui m'a permis d'avoir un agenda où on peut facilement tourner les pages sur les spirales. Mais du coup la couv est plutôt fragile. Pour la rendre plus solide je l'ai vernie avec un Glassificateur ( = durciceur ) trouvé chez Cultura.\nC'est la règle surtout qui est trop fragile. Comme l'idée est de pouvoir la retirer et la replacer régulièrement sur les spirales (elle sert de marque-page pour retrouver vite la semaine en cours), elle est composée d'encoches, qui se cassent assez facilement quand on retire/remet en place la règle sur les spirales.\nPour finir j'ai passé un élastique dans les trous prévus à cet effet, puis je l'ai cousu à a main - mes talents de couturière ne sont clairement pas ceux qui mettent en valeur le rendu final.\nJ'ai galéré un peu à trouver les réglages du laser ( mon deuxième test a pris feu ). En effet le balsa est vraiment fin et fragile. Sur le 1mm, pour graver, j'ai par 3 fois eu des réglages trop puissants ce qui a fait que ca a traversé l'épaisseur et découpé au lieu de graver.\nVoici les réglages qui finalement ont fonctionné sur le Balsa 1mm sur la Speedy 300:\nGravure : Puissance 5 vitesse 10\nGravure pour les petits éléments : Puissance 8 vitesse 10\nA voir comment évolue ce Balsa fragile, est-ce qu'il va tenir 1 an à être ouvert et refermé, je n'en sais rien. Une fois refermé avec l'élastique, l'ensemble est assez compact donc ca devrait tenir, même dans un sac à main. Ce qui m'inquiète le plus reste la Règle car c'est celle qui sera le plus soumise à des mouvements.\nMon conseil si quelqu'un se lance dans une couverture / 4eme de couverture en bois : Prendre un objet avec des spirales relativement grosses. Ca vous permettra d'avoir un 2 voire 3mm d'épaisseur sur chacune des deux couvertures.\nprojets/couverture_d_agenda.txt · Dernière modification: 2019/01/13 18:35 par marion_ducasse


Éditorial N° 219\nL’orthographe est l’âme des mots\nCette préface de Jean Dutourd au Grand Livre de l’orthographe, de Jean-Yves Dournon (L’Archipel, 2005, 288 p., 17,95 €) démontre une nouvelle fois l’influence de la musique et de la peinture sur la pensée de notre président.\nLes mots ne sont pas seulement des sons, ils ont une forme qui n’est pas moins importante. C’est ici que l’orthographe apparaît. La filosofie n’est pas tout à fait la même chose que la philosophie, de même que Notre-Dame de Paris n’est pas l’abbaye de Westminster.\nNous vivons dans deux univers : celui de la musique et celui de la peinture. La langue que l’on appelle « maternelle » a sa mélodie et sa forme. La mélodie résonne à notre oreille depuis notre naissance et nous avons ouvert les yeux sur des formes qui ne ressemblent à aucune autre.\nDepuis combien de siècles parle-t-on français en France ? Les historiens font remonter cela à 843, date du traité de Verdun qui, pour la première fois, ne fut pas rédigé en latin mais dans le patois gallo-germanique en usage à cette époque. Il a fallu six ou huit siècles encore pour qu’un lecteur curieux de poésie se résignât à lire Villon. Telle fut mon expérience vers l’âge de quinze ou seize ans. Après quelques essais décourageants, j’eus l’intuition que toute la beauté de cette poésie était cachée par l’orthographe surchargée de lettres inutiles, de tournures archaïques, de lourdeurs grammaticales, etc.\nMême remarque à propos de Joinville, Rabelais, Montaigne, voire du cardinal de Retz. Dès que l’on faisait mentalement l’effort de remplacer la vieille orthographe par l’orthographe moderne, fût-ce «ij’estois » par « j’étais », tout se mettait à resplendir, c’était comme des peintures nettoyées.\nL’orthographe française d’aujourd’hui qui donne au français moderne son visage particulier (j’oserai dire « son ovale parfait ») est celle qui s’est fixée au xixe siècle, dont les fondateurs sont les grands écrivains de cette période, de Chateaubriand à Proust, et qui a été codifiée par Littré. C’est de cette orthographe-là que Jean-Yves Dournon dévoile les secrets, les mystères, la mécanique, les règles, les irrégularités. Il y a dans son livre tout ce qu’un lecteur français peut savoir sur ce qu’il y a de plus précieux : le langage, c’est-à-dire son âme.