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.
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!
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.
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.)
[^] # Re: Il existe qibuild !
Posté par Phlogistique . 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:
# Bronisé
Posté par Phlogistique . En réponse au journal Ciao Moebius :(. Évalué à 5. Dernière modification le 10 mars 2012 à 15:24.
Excusez-moi, je suis nouveau ici, c'est à propos de Mon Petit Poney?
# Quantité de masques
Posté par Phlogistique . En réponse à la dépêche Manifestations contre ACTA du 11 février. Évalué à 1.
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 Phlogistique . En réponse au journal Présentation de 0 Linux, une distribution francophone. Évalué à 2.
[^] # Re: Perl vs Ruby
Posté par Phlogistique . En réponse à la dépêche Calendriers de l'avent Perl 5 et Perl 6. Évalué à 0.
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 Phlogistique . En réponse à la dépêche Calendriers de l'avent Perl 5 et Perl 6. Évalué à -1. Dernière modification le 07 décembre 2011 à 20:50.
Perl 6 n'a pas un très gros taux de pénétration, pour le coup
Ruby a aussi les options -p, -n, -e et -i.
Ruby reprend de Perl un certain nombre d'entre elles.
[^] # Re: Vim ? connais pas !
Posté par Phlogistique . En réponse au journal Bon anniversaire Vim ! . Évalué à -1.
Tu confonds avec Evil.
[^] # Re: Interruption logicielle
Posté par Phlogistique . 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 Phlogistique . 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 Phlogistique . En réponse au journal Dennis Ritchie est Bronsonisé. Évalué à 4.
https://plus.google.com/u/0/101960720994009339267/posts/ENuEDDYfvKP
[^] # Re: Moi, tellement mieux
Posté par Phlogistique . 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 Phlogistique . 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 Phlogistique . En réponse à la dépêche Python Quvi. Évalué à 5.