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.
Aller plus loin
- Site de LLVM (10 clics)
- Notes de version (4 clics)
# ...
Posté par rewind (Mastodon) . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 10.
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 rewind (Mastodon) . Évalué à 10.
Ç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...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ...
Posté par Julien04 (site web personnel) . Évalué à 10.
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 Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ...
Posté par BAud (site web personnel) . Évalué à 2.
- 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 BAud (site web personnel) . Évalué à 8.
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 rewind (Mastodon) . Évalué à 3.
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 Elfir3 . Évalué à 3.
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 claudex . Évalué à 2.
Ç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 claudex . Évalué à 4.
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 rewind (Mastodon) . É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.
[^] # Re: ...
Posté par patrick_g (site web personnel) . Évalué à 2.
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 rewind (Mastodon) . Évalué à 2.
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 BAud (site web personnel) . Évalué à 2.
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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par rewind (Mastodon) . Évalué à 10.
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 patrick_g (site web personnel) . Évalué à 4.
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 BAud (site web personnel) . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 4.
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 El Titi . Évalué à 3.
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 El Titi . Évalué à 2.
http://knol.google.com/k/pourquoi-knol-et-wikip%C3%A9dia-ne-(...)
[^] # Re: ...
Posté par barmic . Évalué à 2.
(CC-BY) à la différence de knol qui laisse toute liberté à l'auteur sur la distribution."
Ca risque d'urler dans les chaumières...
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ...
Posté par El Titi . Évalué à 2.
C'est pas déjà le cas ?
[^] # Re: ...
Posté par patrick_g (site web personnel) . Évalué à 4.
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 windu.2b . Évalué à 4.
[^] # Re: ...
Posté par Vivien MOREAU . Évalué à 5.
« URIne ! », c'est tout de même mieux que le laconique « source ? ».
[^] # Re: ...
Posté par Zenitram (site web personnel) . Évalué à 8.
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 patrick_g (site web personnel) . Évalué à 5.
Oui. Oumph lui a ajouté 50 XP.
[^] # Re: ...
Posté par claudex . Évalué à 2.
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 rewind (Mastodon) . Évalué à 8.
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 El Titi . Évalué à 4.
Ca pourrait en intéresser plus d'un.
[^] # Re: ...
Posté par El Titi . É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 nazcafan . Évalué à 6.
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 Aissen . Évalué à 3.
[^] # Re: ...
Posté par DrBuenol . Évalué à 2.
C'est une transparence totale (enfin,dans l'impression,car le site du zero ca reste closed source)
[^] # Re: ...
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: ...
Posté par Vivien MOREAU . Évalué à 4.
Ça spamme, ça édite n'importe quoi n'importe comment etc.
Bref, pour moi c'est justement un contre-exemple.
# Comparatif
Posté par patrick_g (site web personnel) . Évalué à 10.
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 rewind (Mastodon) . Évalué à 5.
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 Patrick Lamaizière (site web personnel) . Évalué à 6.
Ben oui déjà il est libre.
les pixels au peuple !
[^] # Re: Comparatif
Posté par patrick_g (site web personnel) . Évalué à 8.
[^] # Re: Comparatif
Posté par Gniarf . Évalué à 7.
[^] # Re: Comparatif
Posté par patrick_g (site web personnel) . Évalué à 3.
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 Gniarf . Évalué à 7.
[^] # Re: Comparatif
Posté par Zenitram (site web personnel) . Évalué à 2.
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 Axel R. (site web personnel) . Évalué à 7.
euh, bougez pas, je suis déjà ------> []
# ...
Posté par M . Évalué à 1.
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 Antoine . Évalué à 2.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
>> 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 Patrick Lamaizière (site web personnel) . Évalué à 10.
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 !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: clang et FreeBSD
Posté par M . Évalué à 5.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.