LLVM 2.7 est sorti

Posté par . Modéré par patrick_g.
Tags :
42
27
avr.
2010
Technologie
Une nouvelle version de LLVM est sortie, elle est numérotée 2.7, elle suit la 2.6 qui est sortie 6 mois avant, le 23 octobre 2009.

Cette version, si elle reste dans la continuité de la 2.6, marque surtout une étape pour Clang et sa compatibilité avec le C++. Effectivement depuis début février, Clang est capable de compiler LLVM. LLVM 2.7 est la première version capable de se compiler toute seule sans aucune aide de gcc.

Plus de détails dans la suite de la dépêche…

NdM : Un très grand merci aussi à Rewind qui nous a également proposé une dépêche très complète sur le sujet. Le choix a été difficile et, après discussions, nous avons opté pour la fusion des news.
Cette dépêche est donc le résultat du travail de Zarikotaba ET de Rewind.
Cette version est sortie après 1 mois et 14 jours de maturation, le master bug (#6586) pour cette version a été posé le 11 mars 2010.
Cette période a permis à la communauté de corriger quelques bugs, mais il faut noter que les versions ne semblent pas spécialement déchaîner les passions puisque certains bugs sont restés orphelins pendant plusieurs semaines.
Quelques appels à contribution ont été lancés avant que les bugs ne soient pris en charge. Certains qui n'impactaient que des configurations vraiment particulières (du fortran sur darwin par exemple) ont même été descopés de cette version.

Autour de cette version, on peut trouver :
  • La bibliothèque LLVM : Low Level Virtual Machine. Elle permet de construire des applications qui peuvent générer du code, des compilateurs, des machines virtuelles, etc. ;
  • Un ensemble d'outils cohérents, notamment Clang, qui est un frontend C, Objective C et C++. (Son but est d'être un remplaçant de gcc) ;
  • Jusqu'à la version 2.6, LLVM proposait llvm-gcc, un front-end C basé sur GCC 4.2 pour pouvoir compiler du C avec LLVM. Cependant cette solution était très intrusive dans le code source de GCC ce qui empêchait de la maintenir proprement. Heureusement, GCC 4.5 a introduit des greffons permettant de modifier ses éléments internes et en particulier toute la partie optimisation et génération de code.

    Le projet DragonEgg, qui sort pour la première fois avec cette version 2.7 de LLVM, est donc un greffon pour GCC 4.5 remplaçant l'optimisation et la génération de code de GCC par celle de LLVM. Le résultat est donc le même qu'avec l'ancienne version llvm-gcc mais elle est complètement externe à GCC. Il suffit alors d'ajouter "-fplugin=/path/to/dragonegg.so" sur la ligne de commande d'un GCC normal pour le transformer en llvm-gcc.

MC (Machine Code Framework)

Un nouveau sous-système sous lib/MC, dédié au traitement du code natif est apparu.
Les compilateurs classiques (gcc par exemple) passe par différentes étapes pour générer du code natif :

Source (C/C++...) -> [frontend] -> Représentation intermédiaire -> [Backend] -> fichier assembleur

Le fichier assembleur produit (extension en .s) est créé dans un répertoire temporaire. Le compilateur invoque alors un autre programme : un assembleur (GNU as par exemple), qui prend ce fichier texte en entrée et génère le code natif.

Le constat est simple : le compilateur passe du temps à formater un fichier .s qui sera immédiatement lu par l'assembleur pour générer du binaire. Par exemple, 20% du temps de compilation avec clang -O0 -g est passé dans la génération et le formatage de ce fichier.
On doit pouvoir écrire directement les binaires, sans passer par un programme assembleur externe.

Dans les précédentes versions des classes spécifiques étaient capables de générer des binaires Elf, Coff et MachO. Mais le code ne s'intégrait pas correctement avec le mécanisme de génération des fichiers textes en .s.

Les instructions et leur encodage sont contenues dans des fichiers *.td que les développeurs LLVM appellent des TableGen. Pour un backend particulier (un processeur ou une famille de processeurs supportés) un ensemble de fichiers en *.td définissent des informations qui servent à générer des parties du code spécifique à une target : affichage, encodage, décodage des instructions ou de l'assembleur. On trouve des fichiers *.td contenant les conventions d'appel de fonctions, des instructions, des sous-ensemble d'instructions (SIMD, NEON...), des informations de schedule...

L'idéal du projet MC est d'unifier toutes les informations qui sortent de ces fichiers *.td. Pour les cas simples, une modification dans un de ces fichiers devrait permettre de générer automatiquement un assembleur, un désassembleur et un backend LLVM.

Le projet MC a été intégré dans LLVM 2.7, mais c'est surtout dans les futures versions que l'on sentira les améliorations :
  • Avec l'outil llvm-mc, on a déjà à notre disposition un assembleur et un désassembleur ;
  • Clang va traiter directement l'assembleur inline dans le code et remonter des erreurs plus claires ;
  • Une fois que le JIT aura été mis-à-jour, il supportera l'assembleur inline.

Pour plus d'informations, je vous encourage à lire le billet très complet de Chris Lattner sur le blog de LLVM.

Metadata extensible

Un des buts de LLVM est de permettre une séparation nette entre le frontend qui est responsable d'analyser le code source (C/C+++...) et le backend qui est capable de générer du code natif.
Le lien entre le frontend et le backend se fait grâce à une représentation intermédiaire ("IR") qui est une sorte d'assembleur haut-niveau spécifique à LLVM.

Pour que le frontend puisse passer un maximum d'informations au backend, un système de métadonnées flexible et extensible a été introduit dans LLVM.
Ce système permet d'attacher à une instruction des informations diverses et variées qui peuvent être récupérées par le backend. Des exemples d'utilisation :
  • Les informations de debug qu'un ObjectWriter pourra écrire dans les sections dwarf d'un binaire ;
  • Des informations de type qui peuvent servir à affiner les analyses sur les dépendances mémoire ;
  • Un marqueur "non-temporal" qui permet de générer des accès mémoires qui ne reste pas dans le cache et donc qui ne le perturbe pas. (Pour des données rarement utilisées...).

Pour plus d'informations, un article a été publié sur le blog de LLVM concernant ces métadonnées.

Divers

Le JIT - Just In Time compiler - compilateur à la volée en français - permet de générer du code dans un tampon mémoire (sans passer par un fichier).
La version 2.7 permet maintenant d'instancier plusieurs JIT dans le même process pour préparer des tampons de code en parallèle.

VMKit a démarré comme un projet pour implémenter une Java Virtual Machine (JVM) et une CLI Virtual Machine (qui sert de base à Microsoft .Net) en utilisant LLVM et notamment ses capacités de compilation statique et just-in-time (JIT). Le projet est maintenant un framework complet pour écrire des machines virtuelles. Il offre notamment un garbage collector compatible avec le multi-threading à travers le sous-projet MMTk - Memory Management Toolkit.

Outre ce changement de philosophie et MMTk, la version 2.7 apporte une meilleure gestion des informations de début dans la JVM avec notamment le numéro des lignes, en utilisant les nouvelles métadonnées.

De nombreuses améliorations ont été apportées sur l'ensemble du code :
  • Le support du processeur MicroBlaze a été initié ;
  • La passe GVN (Global Value Numbering) qui permet de supprimer des chargements redondants est plus agressive, notamment sur les chargements avec adresse complexes ;
  • La passe instCombine qui permet de recombiner les instructions et les opérations mathématiques pour faire apparaître les simplifications a été refactorée ;
  • La convention d'appel particulière à GHC (Glasgow_Haskell_Compiler) est supporté : GHC a gagné récemment un backend LLVM.

Dans les détails qu'il faut également noter :
  • LLVM s'est doté d'un nouveau serveur, le dépôt SVN est bien plus rapide qu'avant !
  • LLVM s'est doté d'un logo. C'est un dragon, une vouivre (wyvern) pour être plus précis. La nouvelle mascotte n'a pas encore de nom officiel.

Outre les sous-projet LLVM déjà mentionnés, on peut aussi noter que LLVM est utilisé dans de nombreux projets externes. Parmi ceux-ci, on peut remarquer :
  • Unladen Swallow, une implémentation de Python par Google qui utilise un backend LLVM ;
  • LLVM-LUA utilise LLVM pour ajouter la compilation statique et just-in-time à la machine virtuelle LUA ;
  • MacRuby est une implémentation de Ruby pour Mac basée sur LLVM ;
  • Roadsend PHP est une implémentation de PHP basée sur LLVM.
  • GHC (Glasgow Haskell Compiler) est un compilateur pour le langage fonctionnel Haskell.
  • # ...

    Posté par . Évalué à 10.

    "À quoi ça sert que Ducros il se décarcasse ?"

    Au delà de ma frustration d'avoir passé tant de temps pour écrire une dépêche pour qu'au final, elle ne soit pas retenue (ou si peu), je ne peux m'empêcher de soulever (une fois de plus) le problème des dépêches en attente et dont on ne sait rien... Du coup, du travail en double, du coup, des frustrations, du coup, on ne m'y reprendra pas de sitôt...

    Et vive les journaux...
    • [^] # Re: ...

      Posté par (page perso) . Évalué à 10.

      >>> e ne peux m'empêcher de soulever (une fois de plus) le problème des dépêches en attente et dont on ne sait rien

      Je comprends ta frustration (est-ce que tu a vu mon mail interne ?) mais d'un autre côté:

      - Du fait de la fusion des news les informations pertinentes concernant LLVM 2.7 sont accessibles aux lecteurs. C'est le plus important je pense non ?
      - Tu est crédité dans la NdM en tant que co-auteur.
      - La situation a déclenché une réflexion chez les modéros pour mettre en place quelque chose pour éviter que le cas se reproduise.
      Dans l'intervalle il faut peut-être utiliser https://linuxfr.org/redacteurs/ pour annoncer qu'on projette d'écrire une news sur un sujet ?

      >>> du coup, on ne m'y reprendra pas de sitôt...

      Bien entendu tu es libre de faire ce que tu veux mais je pense que ce serait une erreur.
      Nous essayons d'encourager les contributions et là, paf, un problème se pose qu'il est difficile de résoudre de façon satisfaisante. Je comprends que tu sois un peu déçu mais je t'assure qu'on en parle sur la mailing list interne et et que nous allons essayer d'améliorer les choses.
      Je te remercie une nouvelle fois pour ton travail.
      • [^] # Re: ...

        Posté par . Évalué à 10.

        > La situation a déclenché une réflexion chez les modéros pour mettre en place quelque chose pour éviter que le cas se reproduise.

        Ça a aura au moins servi à ça. Je ne vais pas taper sur vous, ni ce que vous faites, parce que vous y passez certainement beaucoup de temps et que vous y mettez du coeur. Mais il faut quand même avouer que ce problème n'est pas nouveau et que je trouve dommage qu'il ait fallu ça pour faire bouger les choses. J'espère vraiment que la nouvelle version RoR corrigera ce genre de situation, ça permettra à mon avis plus de contribution et moins de frustration (ça, c'est du slogan).

        Alors là, je rumine encore, mais ça passera dans quelques jours...
        • [^] # Re: ...

          Posté par . Évalué à -3.

          Ne rumines plus mon rewind<,
          Grande moule< aimée,
          Plein de bisoux sur la truffe :-)
          • [^] # Re: ...

            Posté par . Évalué à 2.

            Elle est où la truffe, sur une moule ?

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: ...

        Posté par (page perso) . Évalué à 10.

        Petite question au passage : pourquoi ne pas rendre accessible à tout le monde les dépêches en attente ?

        Ca ressemble à une stimulation des "compétiteurs" par le secret, qui encourage à proposer une dépêche de qualité pour essayer de doubler les autres.
        Ou, c'est pour focaliser les lecteurs sur la version "finale" des dépêches, afin de faire plus d'audience ?

        Hors, ces 2 "tentatives d'explications" sont à l'opposée de la philosophie du libre, et sont surement fausses, mais je ne trouve pas d'autre justification.

        Y a t'il une explication "historique" à ce mode de fonctionnement ?
        • [^] # Re: ...

          Posté par (page perso) . Évalué à 2.

          Surtout que les relecteurs ont l'air d'être recruté par copinage. Certains n'écrivent pas tant de contenus que ça sur le site...

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: ...

            Posté par (page perso) . Évalué à 2.

            Il y a beaucoup de critères qui rentrent en ligne de compte dans la sélection de relecteur :
            - les écrits (dépêches et journaux) effectivement
            - les commentaires
            - la participation au forum
            - la participation régulière au site
            - l'orthographe / grammaire
            - par exemple, lors de la dernière rencontre admodérolecteur, au final il y a eu un vote des présents (et des échanges qui continuent sur la ML)

            Le copinage n'entre pas en ligne de compte directement, même si le fait de connaître la personne peut influer, ce n'est pas le 1er critère en tout cas.
            Il y a des cas où les écrits sont de bonne qualité et la personne n'est pas retenue en relecteur, un argument que j'ai entendu est que c'est pour lui permettre de continuer à rédiger ainsi o_O (comme quoi d'être relecteur fait diminuer le nombre de soumission de dépêches :/ ça pour le coup c'est pas forcément corroboré très fortement, même si ça peut correspondre à certains, même si je ne pense pas que c'est simplement d'être relecteur qui entraîne cela mais plutôt des éléments extérieurs).
        • [^] # Re: ...

          Posté par (page perso) . Évalué à 8.

          Petite question au passage : pourquoi ne pas rendre accessible à tout le monde les dépêches en attente ?

          Cela avait été évoqué dans les commentaires sur ce bug corrigé depuis : http://linuxfr.org/tracker/672.html

          En bref : il y a aussi du spam dans les dépêches, à ne pas faire apparaître systématiquement. En outre, il n'y a pas que le cas "on a deux dépêches de bonne qualité", c'est assez exceptionnel. En réalité, c'est plus souvent "machin est sorti" "machin est out" et les deux dépêches sont largement incomplètes : si on ne fait apparaître que le titre, cela risque de décourager quelqu'un de proposer une dépêche bien rédigée.
          C'est un peu pourquoi, une autre approche que celle qui est suggérée a été retenue : se coordonner via la tribune rédacteur http://linuxfr.org/redacteurs/ voire utiliser http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr si vous souhaitez rédiger à plusieurs sur un wiki. C'est améliorable mais c'est ce qui est prévu iirc dans la version en RoR qui intègrera nativement un wiki (mais pas forcément / obligatoirement prévu pour cette utilisation en revanche, je ne sais plus, même si c'est ce que je souhaiterais).

          Hors, ces 2 "tentatives d'explications" sont à l'opposée de la philosophie du libre, et sont surement fausses, mais je ne trouve pas d'autre justification.

          Tu supposes à tort que ce fonctionnement "opaque" est voulu. En réalité, la possibilité à un rédacteur (ou un simple lecteur) de participer à la relecture n'a tout simplement jamais été codé, c'est bien une raison historique qui donne cet état de fait.

          Pour la refonte en RoR, l'invitation de certaines personnes à la relecture a été prévue (faudra tester...), cela avait fait l'objet d'une description dans le tracker, que je ne retrouve plus.
          • [^] # Re: ...

            Posté par . Évalué à 3.

            Et pourquoi ne pas faire apparaître que les titres des dépêches en attente avec (par exemple) plus de 3000 caractères donc qui montrent déjà un certain contenu. Ça laisse invisible les petites dépêches que l'équipe de modérateurs peut fusionner après et ça permet de ne pas dupliquer deux fois un gros travail.

            Ce serait une solution temporaire. La vraie solution serait quand même un système où on puisse :
            - rédiger une news à plusieurs avec comme corrolaire de pouvoir avoir plusieurs auteurs pour une news
            - corriger une news qu'on a déjà posté / écrire une news sur le long terme (c'est ce que fait patrick_g pour les news sur le noyau et il peut le faire parce qu'il est dans l'équipe mais pourquoi ne pas l'étendre à tous).
            Alors certes, ça implique tout un système de droit assez complexe pour savoir qui peut voir/éditer une news mais on y gagnerait tous je pense.
            • [^] # Re: ...

              Posté par . Évalué à 3.

              Et pourquoi ne pas faire apparaître que les titres des dépêches en attente avec (par exemple) plus de 3000 caractères donc qui montrent déjà un certain contenu.

              LinuxFr en J2ee is out !

              Changelog v2010.10----------------------------------------------------------------------
              > bug fixé
              > un autre bug fixé
              > viré une fôte d'orthographe sur la page d'accueil
              ...
              ...
              ...
              > ajouté patrick_g dans la liste des personnes ayant le plus influencé les meilleurs contributeurs
            • [^] # Re: ...

              Posté par (page perso) . Évalué à 2.

              - rédiger une news à plusieurs avec comme corrolaire de pouvoir avoir plusieurs auteurs pour une news

              Ça c'est déjà possible avec le wiki. Chaque fois que je fais une news, je l'écris sur le wiki, je poste le lien sur la tribune des rédacteurs et je la laisse quelques jours au moins avant de la poster. Ça permet d'être relu par des gens (ça n'arrive pas tout le temps mais parfois c'est le cas).

              c'est ce que fait patrick_g pour les news sur le noyau et il peut le faire parce qu'il est dans l'équipe mais pourquoi ne pas l'étendre à tous

              Il me semble qu'il écrit ses news tout seul et les poste une fois fini, je ne vois pas en quoi il est avantagé par rapport à un autre.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: ...

                Posté par (page perso) . Évalué à 4.

                Ça c'est déjà possible avec le wiki.

                Mais c'est vrai qu'il est mal connu, même des modéros. Lors de la sortie de FF3.5, j'avais préparé une dépêche sur le wiki mais je n'étais pas là le jour de la sortie, et quelqu'un d'autre avait poster une dépêche peu détaillée. Et les modéros n'ont pas pensé à ajouter ce que j'avais fait dans le wiki, il a fallu que je poste la dépêche pour ça.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: ...

                Posté par . Évalué à 2.

                > Il me semble qu'il écrit ses news tout seul et les poste une fois fini, je ne vois pas en quoi il est avantagé par rapport à un autre.

                Il peut faire des sommaires et des textes structurés, impossible sans toucher au code parce que pour le commun des mortels, les balises h2 disparaissent et les balises a sont vidés de leurs attributs.
                • [^] # Re: ...

                  Posté par (page perso) . Évalué à 2.

                  >>> Il peut faire des sommaires et des textes structurés, impossible sans toucher au code parce que pour le commun des mortels, les balises h2 disparaissent et les balises a sont vidés de leurs attributs.

                  Hem...ça n'a rien à voir avec le sujet je pense ça. Ta news, avant que nous n'options pour celle de zarikotaba, avait été amélioré par les modéros pour ajouter les balises qui vont bien.
                  Pareil pour la news sur la photographie sous Linux par exemple. Initialement la mise en page était inexistante et les modéros ont bossé pour structurer tout ça.

                  Donc c'est vrai que templeet mange des balises à la soumission des news (et c'est hypra chiant) mais cela ne change rien pour les contributeurs car la mise en page est corrigée à l'étape de modération.
                  • [^] # Re: ...

                    Posté par . Évalué à 2.

                    Oui mais bon, c'est du boulot en plus pour vous, et celui qui contribue n'est pas assuré que tout y sera au final, parce que ça ne dépend pas de lui. Donc, pas très satisfaisant des deux côtés.

                    Après, je suis bien conscient que ce sont les limites de Templeet, mais c'est assez chiant pour les contributeurs aussi.
                    • [^] # Re: ...

                      Posté par (page perso) . Évalué à 2.

                      bin justement, http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr est là pour cela, ça permet de se coordonner en permettant l'édition à plusieurs, pour des sujets le méritant ou avec suffisamment de monde motivé.
                      Tu peux même l'ajouter sur ta page principale de LinuxFr via http://linuxfr.org/user_prefs.html (bon, après les liens ne fonctionnent pas, mais c'est ma faute à cause du rss en atom pété sur le wiki, mais tu peux aller sur http://demoll.tuxfamily.org/linuxfr/DerniersChangements ou mieux sur http://linuxfr.org/redacteurs/ pour annoncer qu'une rédaction collaborative est en cours).

                      Cette discussion devrait être poursuivie sur http://linuxfr.org/tracker/ :) en ouvrant une demande d'amélioration (même si je n'ai pas vérifié que le tracker a été amélioré dans la version RoR /o\, la plupart des données ayant été importées :D).
                      Après, oui, ce sont des limites de templeet qui nous ont fait trouver ces "contournements" et justifié un changement de technologie (yen a marre de templeet qui mange les balises, même en tant que relecteur / modo ça nous dérange hein, même si nous faisons notre mieux pour que ça ne se voit pas :p).

                      Au fait, tu as vu que tes XPs ont été augmentées ? :D
                      * Moyenne: 4.44 / 18 : 2
                      * XP: 825/20/19
                      tu en as désormais 825 et jerome_misc aka j est à peine devant toi sur la 5ème page avec 917 ;-) (perso, en postant peu de dépêches, je talonne Floxy, patrick_g et jarillon en première page, mais ils trichent j'en suis sûr :p TINC comme dit en:Backbone_cabal même si j'ai des doutes :D).
                      • [^] # Re: ...

                        Posté par (page perso) . Évalué à 4.

                        On peut revoir les XP's, ils sont plus cachés ?
                      • [^] # Re: ...

                        Posté par . Évalué à 10.

                        Comme je l'ai dit, les XP ne m'importe pas du tout (tant que je peux plussoyer et commenter), je préfère la "reconnaissance de mes pairs". Or là, je constate aussi que zarikotaba a un compte qui date de deux semaines, n'est pas revenu commenté cette news et pourtant, c'est à lui qu'on a attribué la news. Je veux bien qu'on favorise les nouveaux mais à ce point là, quand même. Faites un peu confiance à vos contributeurs de longue date aussi. Ou alors, la prochaine fois, je me crée un multi.

                        Par ailleurs, zarikotaba étant nouveau (et peut-être même éphémère), je doute qu'il connaisse le wiki non-officiel ou la tribune rédacteurs (déjà que moi je la connaissais à peine). Alors je ne pense pas que si j'avais utilisé le wiki, on aurait eu une collaboration.
        • [^] # Re: ...

          Posté par (page perso) . Évalué à 4.

          >>> Petite question au passage : pourquoi ne pas rendre accessible à tout le monde les dépêches en attente ?

          A mon sens plusieurs raisons (c'est juste mon avis):

          - Donner la visibilité sur les news soumise signifie donner aussi donner la visibilité sur le spam ou les conneries qu'on reçoit.
          - Donner la visibilité sur les news soumise déflore le texte avant publication.
          - Donner la visibilité sur les news soumise risque de décourager les soumissions alors que la dépêche dans le pipe n'est pas terrible.
          - Donner la visibilité sur les news soumise brouille la distinction entre dépêche soumise et dépêche acceptée après modération.

          La vraie raison importante c'est la dernière.
          L'équipe de LinuxFr est là pour avoir une ligne éditoriale, pour choisir des news et en rejeter d'autres, pour tenter de les améliorer, corriger les fautes, vérifier les liens, etc.
          Il y a un paquet d'items qui sont listés dans les directives de modération et c'est très utile de lire ce texte: https://linuxfr.org/moderateurs/moderation.html#ligne

          Rendre visible le texte des news soumise serait à mon avis une erreur car cela dévaloriserait et rendrait un peu obsolète ce rôle de la modération. Pour poster plus ou moins ce qu'on veut sans étape de modération il y a déjà les journaux.
          Une dépêche ce n'est pas un journal !

          En revanche rendre visible le titre des news soumise (et éventuellement sa longueur et son auteur) est tout à fait envisageable à mon avis.
          Cela permettrait peut-être d'éviter la déconvenue de Rewind. Je crois que si il avait vu dans le pipe une dépêche sur LLVM 2.7 ayant une longueur conséquente il n'aurait pas pris la peine d'écrire la sienne.
          Évidemment cette solution n'est pas bullet proof: Une dépêche longue mais mal foutue pourra décourager les soumissions de dépêches meilleures; une publication quasi-simultanée de dépêches conduira au même problème qu'actuellement, etc

          Mais ce serait peut-être mieux que ce qui existe en ce moment.
          • [^] # Re: ...

            Posté par (page perso) . Évalué à 2.

            il n'aurait pas pris la peine d'écrire la sienne.

            bin c'est tout simplement contreperformant donc ;-)
            Là on avait deux dépêches très complémentaires et très bien rédigées, les fusionner a apporté une dépêche plus complète.
            Du point de vue rédacteur, il n'y a pas à focaliser sur un refus, d'autant que bon, un admin peut ajouter les points manquants aux XPs (50 ajoutés lorsque la dépêche est acceptée, rien de retiré quand elle est refusée :p) et en plus tu as fait l'effort de mettre une NdM qui reflète bien le travail effectué en modération et la qualité de la dépêche soumise par rewind initialement.
            • [^] # Re: ...

              Posté par (page perso) . Évalué à 4.

              >>> Du point de vue rédacteur, il n'y a pas à focaliser sur un refus

              Sauf que rewind a eu les boules de ne pas voir se dépêche retenue. Certes cela aurait juste été de l'égo-boosting...mais c'est important pour les contributeurs.

              >>> les fusionner a apporté une dépêche plus complète

              Ce serait mieux d'avoir une belle dépêche dès le début sans que nous n'ayons à nous palucher le fusionnage vraiment galère des news ;-)
              • [^] # Re: ...

                Posté par . Évalué à 3.

                C'est marrant parce que la dilution des contributions dans un but (un seul article pour un sujet) encyclopédique vs article personnel (plusieurs articles sur un même sujet) correspond à la différence entre les lignes editoriales de wikipédia et de knol.

                Knol permet à un auteur de diffuser des articles mais avec différents niveaux d'ouverture et de contrôler les retours sur son article (pas de modif, relecture, modification collaborative, ...)

                Peut-être qu'il ne serait pas si inintéressant que ça de s'inspirer de certaines de ces idées.

                Par exemple:
                un contributeur qui soumet sa dépêche pourrait indiquer s'il souhaite que sa dépêches soit fusionnée ou s'il souhaite simplement une relecture, une modération et des commentaires en prenant le risque de revoir sa copie lui-même.
                Bien entendu, il accepte et des articles concurrents soit postés et qu'une fois sa dépêche posté son contenu soit libre.
                (CC-BY) à la différence de knol qui laisse toute liberté à l'auteur sur la distribution.


                De son coté DLFP accepterait de poster plusieurs dépêches sur un même sujet.
                • [^] # Re: ...

                  Posté par . Évalué à 2.

                  J'ai oublié un petit lien pour illustrer mes propos:
                  http://knol.google.com/k/pourquoi-knol-et-wikip%C3%A9dia-ne-(...)
                • [^] # Re: ...

                  Posté par . Évalué à 2.

                  "Bien entendu, il accepte et des articles concurrents soit postés et qu'une fois sa dépêche posté son contenu soit libre.
                  (CC-BY)
                  à la différence de knol qui laisse toute liberté à l'auteur sur la distribution."


                  Ca risque d'urler dans les chaumières...

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                  • [^] # Re: ...

                    Posté par . Évalué à 2.

                    Vraiment ?
                    C'est pas déjà le cas ?
                    • [^] # Re: ...

                      Posté par (page perso) . Évalué à 4.

                      Comme rien n'est spécifié c'est le régime restrictif du droit d'auteur classique qui s'applique je crois.
                      C'est pour ça que baud123 m'a judicieusement incité à préciser le CC-BY-SA sur les news noyau.

                      A noter que dans la version démo du site RoR que j'ai pu voir il y a une case à cocher lors de la soumission pour mettre le texte sous CC-BY-SA. Super idée !
                  • [^] # Re: ...

                    Posté par . Évalué à 4.

                    Urler, c'est quand on écrit une URL ?!?
                    • [^] # Re: ...

                      Posté par . Évalué à 5.

                      Tout à fait. C'est un synonyme d'URIner.

                      « URIne ! », c'est tout de même mieux que le laconique « source ? ».
            • [^] # Re: ...

              Posté par (page perso) . Évalué à 8.

              Du point de vue rédacteur, il n'y a pas à focaliser sur un refus

              Ben euh... Si.
              Ca joue peut-être sur l'égo de la personne, mais c'est quand même une reconnaissance de voir son nom apparaitre dans le "posté par".

              un admin peut ajouter les points manquants aux XPs (50 ajoutés lorsque la dépêche est acceptée, rien de retiré quand elle est refusée :p)

              Est-ce que ça a été fait pour Rewind? Le problème dans le refus c'est que du coup on ne sait pas si notre travail a été "payé" (oui, c'est con, c'est psychologique car les points LinuxFr ne rapportent rien, mais c'est comme ça : l'humain a besoin de reconnaissance).

              en plus tu as fait l'effort de mettre une NdM qui reflète bien le travail effectué en modération et la qualité de la dépêche soumise par rewind initialement.

              Il reste que c'est moins que "Posté par". Je sais, c'est psychologique, mais ça reste la seule gratification qu'on a à poster des dépêches, alors c'est compréhensible que les rédacteurs y attachent de l'importance.
              Un intermédiaire serait peut-être la possibilité technique d'avoir plusieurs noms dans le "Posté par" ("Posté par zarikotaba et Rewind").

              PS : même problème avec les journaux montés en dépêche, l'auteur initial est "juste" dans un NdM, pas dans le "Posté par".
              • [^] # Re: ...

                Posté par (page perso) . Évalué à 5.

                >>> Est-ce que ça a été fait pour Rewind?

                Oui. Oumph lui a ajouté 50 XP.
              • [^] # Re: ...

                Posté par (page perso) . Évalué à 2.

                PS : même problème avec les journaux montés en dépêche, l'auteur initial est "juste" dans un NdM, pas dans le "Posté par".

                Sauf dans le flus rss où c'est bien l'auteur initial qui est crédité.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: ...

                Posté par . Évalué à 8.

                Alors, je vous rassure tous, mon ego va bien. Ça m'a frustré sur le coup et encore maintenant, je me dis "quel dommage !" mais il y a des choses bien plus grave que de ne pas avoir une news publié sur linuxfr. Tout comme les XP, je m'en fous, je n'ai pas proposé une news pour ça mais simplement parce que j'aime bien LLVM, point.

                Et pour répondre un cran plus haut, je trouve que la fusion fait un peu fouilli, alors que j'avais fait un effort de structuration, en séparant plus nettement ce qui relève de LLVM, et ce qui relève des projets satellites genre CLang, MC, VMKit, etc. Je suis déçu par ça surtout, le reste (XP toussa) m'importe assez peu.
                • [^] # Re: ...

                  Posté par . Évalué à 4.

                  Tu ne pourrais pas poster ta dépêche en commentaire comme certains le font lorsqu'ils se sont faits griller.
                  Ca pourrait en intéresser plus d'un.
          • [^] # Re: ...

            Posté par . Évalué à 3.


            Rendre visible le texte des news soumise serait à mon avis une erreur car cela dévaloriserait et rendrait un peu obsolète ce rôle de la modération. Pour poster plus ou moins ce qu'on veut sans étape de modération il y a déjà les journaux.
            Une dépêche ce n'est pas un journal !


            C'est assez drôle cette réflexion, en fait.
            Le seul intérêt des dépêches serait donc de satisfaire l'égo d'une caste ?
            Oui cette remarque est ironique mais tu as tendu la perche.

            Les modéros font un travail formidable mais se plaignent aussi du surcroit de travail que ca engendre et du manque de vocation pour les dépêches.

            Maintenant si on se reposait la question de l'intérêt des dépêches par rapport au journaux.
            Aujourd'hui une certaine confusion est entretenue entre les 2.

            A mon sens le journal est une forme d'expression personnelle alors que la dépêche qui propose des articles de fond plus fouillé et se prête mieux à un travail plus plus collégial (rédaction collaborative, relecture et modération). Ceci n'est d'ailleurs pas incompatible avec la promotion de journaux en dépêche.


            Je vois assez bien l'intérêt de mettre a disposition un espace partagé ou les volontaires s'inscrivent pour mettre la main à la pâte sur une dépêche donnée pour peu qu'on ait un workflow qui:
            - se contente de proposer la recherche les dépêches en cours
            ou ne propose que la visu des titres.
            - demande de s'inscrire avant de la consulter voire de participer à la relecture à l'edition.


            Ca devrait suffire à effacer les inconvénients que tu pointes.
            Faut être motivé pour s'inscrire à toutes les news pour les voir en avant première et en plus une recherche pourrait dissuader les posteurs de journaux fous qui grillent la politesse aux dépêches sans le savoir.
        • [^] # Re: ...

          Posté par . Évalué à 6.

          Je suis très mitigé sur la stratégie qui consisterait à rendre accessible à tout le monde les dépêches en attente.
          Les dépêches en attente peuvent contenir des erreurs, des imprécisions des fautes de syntaxe, des trolls et Cie. Les gens, poussés par leur curiosité naturelle, auraient d'une part un article beaucoup moins plaisant à lire (et l'expérience DLFP en pâtirait) et comme effet de bord, ils auraient moins envie de lire le « produit fini ».

          Ceci étant, je pense qu'il faut qu'il y ait un mécanisme pour que les gens intéressés par un même sujet puissent collaborer. Le rôle des relecteurs pourrait être étendu à un rôle de coordinateur au cas par cas, non ?
      • [^] # Re: ...

        Posté par . Évalué à 3.

        La page rédacteurs n’est pas très visible, et aucun des deux rédacteurs n’a annoncé qu’il se lançait dans une news sur LLVM. Si rewind l’avait, fait, il aurait pu se faire doubler quand même par quelqu’un qui n’utilise pas la page. Bref, la page n’a d’intérêt que si tout le monde l’utilise.
    • [^] # Re: ...

      Posté par . Évalué à 2.

      Moi j'aime bien le systéme du site du zero: Un genre de wiki pour faire les news,c'est supra productif et encourageant.
      C'est une transparence totale (enfin,dans l'impression,car le site du zero ca reste closed source)
      • [^] # Re: ...

        Posté par (page perso) . Évalué à 4.

        Sans parler de la mentalité qui règne là bas…

        Envoyé depuis mon lapin.

      • [^] # Re: ...

        Posté par . Évalué à 4.

        Ben justement, regarde un peu mieux et tu verras que la situation n'est pas du tout si rose que ça.

        Ça spamme, ça édite n'importe quoi n'importe comment etc.

        Bref, pour moi c'est justement un contre-exemple.
  • # Comparatif

    Posté par (page perso) . Évalué à 10.

    Je signale un comparatif effectué par Phoronix entre GCC 4.5 et LLVM 2.7
    La page est ici => http://www.phoronix.com/scan.php?page=article&item=gcc_l(...)

    Pour les décideurs pressés on peut résumer en disant que GCC reste meilleur que LLVM dans les performances des binaires générés. Et ça sans parler de son support pour plus de langages ou plus de plateformes hardwares.
    Mais bon comme le dit Phoronix: "LLVM also does have other advantages over the GNU Compiler Collection that cannot be benchmarked".
    • [^] # Re: Comparatif

      Posté par . Évalué à 5.

      Je pense qu'il ne faut pas voir que la performance. LLVM et GCC offre des fonctionnalités complémentaires. Certes pour GCC, il y a les multiples architectures, ou plus de langages (et encore, si on compte les projets externes, LLVM couvre pas mal de langages).

      Côté LLVM, on a la possibilités de faire soit de la compilation statique, soit du JIT, et la représentation intermédiaire est bien documentée, à tel point que ça en fait une sorte d'assembleur générique et portable.

      Ce que j'aime dans LLVM, c'est qu'il est possible de créer un petit langage en quelques jours et d'en faire une implémentation rapidement. Chose qui paraît impossible avec GCC. Et en plus, LLVM laisse totalement le choix des paradigmes du langages, alors que j'ai toujours entendu dire qu'en dehors des langages plus ou moins proches du C, GCC est difficile.

      Je vois un avenir certain à LLVM, même si GCC aura toujours une place de choix, pour des raisons différentes. Il y a largement de la place pour deux compilateurs exceptionnels comme nous avons là.
    • [^] # Re: Comparatif

      Posté par (page perso) . Évalué à 6.

      LLVM also does have other advantages over the GNU Compiler Collection that cannot be benchmarked.

      Ben oui déjà il est libre.

      les pixels au peuple !

      • [^] # Re: Comparatif

        Posté par (page perso) . Évalué à 8.

        Trop gros celui-là.
        • [^] # Re: Comparatif

          Posté par . Évalué à 7.

          et pourtant, au niveau modularité, gcc ne se pose pas là. ("non, vous comprenez, si on fait un truc trop modulaire, ses salauds du proprio pourront y insérer leurs crottes plus facilement" "mais, et ceux du libre ? ils ne peuvent plus ajouter un langage ou un bidule facilement" "bah tant pis pour leur gueule, la Cause avant tout !")
          • [^] # Re: Comparatif

            Posté par (page perso) . Évalué à 3.

            1) Le code de GCC est placé sous une licence libre (la GPLv3) donc dire que l'avantage de LLVM c'est qu'il est est libre c'est faux.

            2) Après modification de la Runtime Library Exception pour éviter les risques de "propriétarisation" on a maintenant les plugins dans GCC. Donc question modularité y'a du mieux.
            • [^] # Re: Comparatif

              Posté par . Évalué à 7.

              juste on a failli attendre, et la raison n'était pas technique.
            • [^] # Re: Comparatif

              Posté par (page perso) . Évalué à 2.

              1) Le code de GCC est placé sous une licence libre (la GPLv3) donc dire que l'avantage de LLVM c'est qu'il est est libre c'est faux.

              Il m'est d'avis qu'il s'agissait simplement d'une boutade pour voir si le troll BSD vs GPL prenait ;-)

              2) Après modification de la Runtime Library Exception pour éviter les risques de "propriétarisation" on a maintenant les plugins dans GCC. Donc question modularité y'a du mieux.

              Ca s'améliore... Ah la politique (car il s'agit uniquement de politique...)! Mais il reste impossible à un logiciel proprio d'embarquer le JIT sans devoir diffuser tout le code source de l'appli (c'est voulu, c'est un choix réfléchi, je sais), mais du coup LLVM a l'avantage de le permettre, et ça peut jouer dans sa diffusion ou dans la liste des entreprises qui mettront des sous dedans.
  • # ça avance bien...

    Posté par (page perso) . Évalué à 7.

    on dira ce qu'on voudra, ça avance mieux depuis que Bernadette Chirac est rentrée au CA de LLVM...

    euh, bougez pas, je suis déjà ------> []
  • # ...

    Posté par . Évalué à 1.

    LLVM 2.7 est la première version capable de se compiler toute seule sans aucune aide de gcc.
    Et tu compiles comment ton clang qui compile llvm ?

    gcc est capable de se compiler en se reposant sur un mini-compilo C en C qui peut etre compiler avec la plupart des compilo C (C89, ansi, ...).

    Je suis pas sur qu'il y ai la meme chose pour llvm...
    • [^] # Re: ...

      Posté par . Évalué à 2.

      Et tu compiles comment ton clang qui compile llvm ?

      Avec clang?
      Ou un compilateur C/C++ système peut-être.
      (réponse au hasard, je n'ai jamais essayé, mais si c'est du C standard ça devrait passer)
  • # Oh, la belle verte !

    Posté par (page perso) . Évalué à 4.

    >> Les compilateurs classiques (gcc par exemple) passe par différentes étapes pour générer du code natif :


    >> Le fichier assembleur produit (extension en .s) est créé dans un répertoire temporaire.
    Dur à parser. Préférer peut-être « Le fichier assembleur qui est produit »

    >> un assembleur (GNU as par exemple),
    Je me dis qu'il serait bien d'imposer les balises italiques, et qu'on écrive GNU as, car si on ne connaît pas, on peut croire que "as" est une typo.

    >> Une fois que le JIT aura été mis-à-jour
    Pourquoi des traits d'union ? Une fois que j'aurais fini-ma-soupe, j'irai au cinéma ?

    Vous expliquez « JIT, » un mot très courant, mais pas « section dwarf. » Moralité, je comprend pas tellement le paragraphe de métadonnées (et un JIT pourrait compiler vers un fichier, rien ne l'en empêche et ça pourrait être quand même rentable. Ce qu'on lui demande, c'est juste de générer dynamiquement du code (machine) spécialisé.)


    >> Le JIT - Just In Time compiler - compilateur à la volée en français
    Dans "JIT", il n'y a pas le mot "compiler". Et on ne dit pas (?) "JIT compilateur". On préférera sans doute quelque chose comme "Le compilateur JIT −Just In Time, ou Juste-à-temps− est un compilateur qui génère du code dynamiquement blablabla".
  • # clang et FreeBSD

    Posté par (page perso) . Évalué à 10.

    L'utilisation de clang pour compiler FreeBSD a pas mal évolué. Maintenant tout compile, noyau et userland et le système démarre. Il reste pas mal de tests de runtime à faire évidemment pour trouver les bugs.

    http://www.freebsd.org/news/status/report-2010-01-2010-03.ht(...)

    L'analyse statistique de LLVM est assez bluffante je trouve, il y a l'analyse faite sur le code FreeBSD là :
    https://www.spoerlein.net/scan-build/freebsd-head/

    les pixels au peuple !

    • [^] # Re: clang et FreeBSD

      Posté par . Évalué à 3.

      FreeBSD expérimente la compilation par LLVM (licence BSD) au détriment de GCC (licence GPLV3)... Enfin il reste du boulot vue l'analyse statique du code par clang (comme pour TrollFr, il faut valider le certificat pour voir le 2e lien que tu donnes).

      Extrait de la page :
      2010-02-28 : 15251 potential bugs found
      2010-04-06 : 15586 potential bugs found
      2010-04-24 : 15591 potential bugs found

      Olala, ça va croissant :-)

      D'après eux, c'est que le décompte fluctuant des bugs est habituellement dû à des corrections/bugs dans le script du scanner, et/ou le scanner lui même chopant plus ou moins bien le code source, par conséquent plus de bugs pototentiellement repérés ("Fluctuating bug counts are usually due to fixes/bugs in the scanner script, and/or the scanner itself catching more/less source code and therefore more possible bugs").
      • [^] # Re: clang et FreeBSD

        Posté par . Évalué à 2.

        Au passage, à supposer qu'ils corrigent tous ces bugs, ça aurait la vertu de débugger leur script d'analyse statique, LLVM/clang et FreeBSD ;-)
    • [^] # Re: clang et FreeBSD

      Posté par . Évalué à 5.

      L'analyse statistique de LLVM est assez bluffante je trouve,
      Il reste pas mal de faux positif car pour le moment l'analyse est faite fonction par fonction. Mais c'est tres prometteur et deja utilisable.

      A noter http://klee.llvm.org/ qui à l'air super intéressant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.