Phlogistique a écrit 13 commentaires

  • [^] # Re: Il existe qibuild !

    Posté par . En réponse au journal Gestionnaire de dépendances en C++. Évalué à 1.

    En fait, oui et non. Il faut voir ça en deux parties:

    • d'une part il y a une bibliothèque de fonctions CMake qui permet de rendre plus facile l'écriture de CMakeList.txt. Une fois le build system CMake créé, il est utilisable avec les commandes habituelles (cmake && make)
    • d'autre part il y a des outils (écrits en Python) qui font une gestion des dépendances à proprement parler; il faut plutôt les comparer à gem/pip/cabal qu'à cmake/scons/autotools.
  • # Bronisé

    Posté par . En réponse au journal Ciao Moebius :(. Évalué à 5. Dernière modification le 10/03/12 à 15:24.

    "bron…isé"

    Excusez-moi, je suis nouveau ici, c'est à propos de Mon Petit Poney?

  • # Quantité de masques

    Posté par . En réponse à la dépêche Manifestations contre ACTA du 11 février. Évalué à 1.

    peut-être 80% de gens portant des masques.

    J'ai eu l'impression contraire; j'aurais plutôt dit 40%. (ce qui m'arrange, car je ne m'identifie pas spécialement à Anonymous)

  • [^] # Re: mon impression

    Posté par . En réponse au journal Présentation de 0 Linux, une distribution francophone. Évalué à 2.

    • Le langage de programmation Io
    • Le gestionnaire de fenêtres awesome
  • [^] # Re: Perl vs Ruby

    Posté par . En réponse à la dépêche Calendriers de l'avent Perl 5 et Perl 6. Évalué à 0.

    Ruby a du mal à se distinguer de Rails. Même si Ruby est un langage bien plus généraliste
    que PHP, au final il reste dans les faits bien plus un "concurrent" de PHP que de Perl.

    Le "concurrent" de Perl c'est plutôt Python.

    Je ne comprends pas du tout cet argument; en quoi l'existence et la popularité de Rails est un problème pour Ruby? Il y a plein de gens qui utilisent Ruby en dehors de Rails!

  • [^] # Re: Perl vs Ruby

    Posté par . En réponse à la dépêche Calendriers de l'avent Perl 5 et Perl 6. Évalué à -1. Dernière modification le 07/12/11 à 20:50.

    Son taux de pénétration sur les plateformes Unix ?

    Perl 6 n'a pas un très gros taux de pénétration, pour le coup

    la manipulation en ligne de commande ?

    Ruby a aussi les options -p, -n, -e et -i.

    les variables utilisée implicitement ?

    Ruby reprend de Perl un certain nombre d'entre elles.

  • [^] # Re: Vim ? connais pas !

    Posté par . En réponse au journal Bon anniversaire Vim ! . Évalué à -1.

    Tu confonds avec Evil.

  • [^] # Re: Interruption logicielle

    Posté par . En réponse au journal UEFI, à la découverte du nouveau BIOS…. Évalué à 10.

    Pour être exact:

    Tant que la RAM n'est pas initialisée, on ne peut pas stocker de stack, donc on ne peut pas appeller de fonctions! Le code produit par GCC ne peut donc pas être utilisé.

    Pour règler ce problème, deux solutions sont en places:
    - Les développeurs de Coreboot ont développé un compilateur C qui inline absolument tout, de façon à pouvoir être utilisé sans mémoire. Ça s'appelle ROMCC, c'est relativement bugué mais ça a le mérite d'exister. Cette solution est sur la voix de l'abandon en faveur de la seconde solution.
    - Les processeurs modernes permettent d'utiliser du "Cache-As-RAM" (CAR), c'est à dire d'utiliser le cache du processeur comme mémoire en attendant d'avoir initialisé la RAM. Il n'y a donc que le code pré-CAR et l'initialisation du CAR qui doivent être codés en assembleur; une fois que l'on peut utiliser le CAR, on peut avoir une stack et donc faire tourner du code généré par GCC.

  • [^] # Re: Petits oublis

    Posté par . En réponse au journal UEFI, à la découverte du nouveau BIOS…. Évalué à 2.

    C'est déjà effectif; et des gens d'AMD poussent fréquemment leurs changements upstream.

  • # Comme j'ai eu du mal à trouver la source

    Posté par . En réponse au journal Dennis Ritchie est Bronsonisé. Évalué à 4.

  • [^] # Re: Moi, tellement mieux

    Posté par . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 3.

    Un développeur d'x264 n'est pas un développeur d'H.264. Ça fait toute la différence.

  • [^] # Re: Sans condition d'utilisation ?

    Posté par . En réponse au journal Retour de la censure sur la tribune. Évalué à 3.

    Tu sous-entend que la seule façon d'utiliser un programme, c'est de l'exécuter?

  • [^] # Re: Weboob

    Posté par . En réponse à la dépêche Python Quvi. Évalué à 5.

    • Weboob supporte moins de sites
    • Weboob tend à supporter des interactions plus complexes avec les sites web afin de pouvoir implémenter des clients lourds génériques. Il a donc une architecture plus complexe et il est plus difficile d'implémenter un backend Weboob que de rajouter un site à Quvi.
    • Weboob fournit bien d'autres fonctionnalités que l'interaction avec des sites de vidéos (gestion de comptes en banques, passerelle vers des forums et sites de nouvelles, gestion de profil sur des sites de rencontre, etc.)