Matthieu Moy a écrit 3251 commentaires

Euh, oui, ca, c'est l'API interne de LLVM qui fait une petite abstraction de l'OS, pas grand chose a voir avec la portabilité du bytecode ...

Euh, si c'est à libc++ que tu fais référence, non, ça n'a pas grand chose à voir avec la portabilité du bitcode.

Le plus gros soucis que libc++ résous, c'est le fait que la libstdc++ de GNU est GPLv3 et que les employés Apple ne sont pas autorisés à toucher à du code GPLv3. Y'a d'autres avantages techniques, mais je n'ai jamais entendu parler de portabilité du bitcode pour ça.

De toutes façons, le problème est vraiment le langage (et un peu la manière de le compiler), pas la bibliothèque. Du moment où tu donnes sizeof(), #ifdef, et l'arithmétique de pointeur au programmeur, c'est a peu près impossible d'avoir quoi que ce soit vraiment différent du source et qui soit portable.

Le bitcode LLVM n'a jamais été fait pour être portable. Si tu compiles du C, dès la sortie du préprocesseur (d'où les #ifdef), tu n'es plus portable, parce que le code préprocessé n'est pas le même selon les plateformes.

Si tu veux du bitcode portable, il faut avoir un langage fait pour (Java, les trucs de .NET, Caml, ...), ou distribuer les sources.

Je n'ai pas l'impression que les patchs viennent d'Oracle. L'auteur est Justin P. Mattock qui poste avec un adresse @gmail et après un rapide coup d'oeil sur le net, je n'ai pas l'impression qu'il bosse pour Oracle.

J'ai raté quelque chose ?

Ça ne marche pas avec Git parce que jusqu'à il y a peu, personne n'avait pris la peine de coder la détection des renommages de répertoires (et c'est très dommage). La détection automatique des renommages, ça a l'avantage de pouvoir améliorer l'outil sans toucher au format de stockage, mais ça a l'inconvénient que les cas non codés dans l'outil ne sont pas gérés ;-).

Bonne nouvelle : il y a une série de patchs en préparation pour ajouter ça :

* yd/dir-rename (2010-10-29) 5 commits
- Allow hiding renames of individual files involved in a directory rename.
- Unified diff output format for bulk moves.
- Add testcases for the --detect-bulk-moves diffcore flag.
- Raw diff output format for bulk moves.
- Introduce bulk-move detection in diffcore.

Je ne sais pas comment a été prise la décision, mais je suppose que la licence a joué beaucoup. Dans un système BSD, ça gênait pas mal de monde qu'un truc aussi essentiel qu'un compilo C soit GPL.

Dans le lien que tu donnes, je trouve :

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them.

Maintenant, faudrait que tu nous expliques ce que tu entends par « forker dans son coin ». Ce que permet un DVCS, c'est d'avoir des branches qui sont hébergées ailleurs que sur le dépôt principal. Ça change quoi que mes branches soient hébergées sur mon site perso, sur github, ou dans l'archive du projet ? Ce qui est important, c'est de savoir quel code est dans la branche principale (i.e. le trunk sous SVN), mais imposer à tout le monde d'héberger ses branches au même endroit, je vois pas l'intérêt.

Ce qui fait que les gens poussent d'une manière ou d'une autre leur code en upstream, ce n'est pas l'outil, c'est pour les 1001 raisons qui font que l'open-source marche. La gloire d'avoir du code à soi en upstream, le fait de ne pas avoir à maintenir une branch séparée longtemps, ...

Avec SVN, tu peux forker sans problème. svnsync par exemple te permet même de récupérer l'historique. Côté « fork », les VCS sont à peu près tous à égalité. Le problème, c'est le merge qui peut suivre le fork.

Ce qui est marrant, c'est qu'ailleurs, tu dis que le workflow de Linux est exemplaire, et justement, le workflow de Linux, c'est exactement ce que tu as l'air de critiquer ici.

En vrai, ça t'est déjà arrivé de donner les droits sur une branche à quelqu'un que tu ne connaissait pas et qui n'avait pas encore envoyé de code ?

Moi, ce que je vois autour de moi, c'est qu'il faut galérer à envoyer des patchs avec un outil qui le fait mal pendant un moment avant d'avoir ça.

> Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au
> mainteneur est pour moi une manière de faire très peu en adéquation avec un
> développement ouvert.

Tu proposes quoi comme alternative avec un VCS centralisé ? J'en vois deux :

1) Je veux contribuer à un projet, je commence par demander les droits pour commiter sur le dépôt du projet. Une fois que j'aurais cette autorisation, je pourrais faire mes commits là bas.

2) Je veux contribuer à un projet, je n'ai pas les droits. Je fais un "svn checkout", je code, je fais "svn diff" et j'envoie le résultat par email.

Pour la version 1), je ne sais pas si ça t'es déjà arrivé d'être autorisé à commiter sur le SVN d'un projet avant d'avoir fait tes preuves avec du code, mais perso, ça ne m'est jamais arrivé, même en rêve. Maintenant, admettons que ça arrive. Cool, je peux commiter sur le dépôt, je n'ai même pas besoin de parler du code sur la mailing-list avant de commiter. C'est plutôt un handicap pour le côté communautaire, non, de pouvoir commiter sans discuter ?

Reste la solution 2), et c'est justement là qu'un DVCS est infiniment plus puissant/pratique, puisque tu peux faire tes commits en local, donc gérer assez facilement plusieurs patchs (y compris si les patchs dépendent les uns des autres).

Le fait qu'on puisse cloner un dépôt est justement quelque chose qui force un fonctionnement communautaire. Avec un VCS centralisé, tu as en général une short-list de gens qui ont les droits pour les commits, et le fait que techniquement ils aient ce droit leur donne un très grand pouvoir de décision. Les gens qui ne sont pas sur la short-list sont mis à l'écart. Avec un DVCS, tu peux aussi avoir un petit nombre de gens qui ont accès au dépôt de référence (éventuellement, ce petit nombre peut être 1), mais si ils abusent de leur pouvoir, les autres contributeurs peuvent continuer à travailler et à s'organiser. Un corolaire est que les mainteneurs n'abusent pas de leurs pouvoir pour les projets gérés par un DVCS.

> Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web
> (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un
> développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et
> l'abandonne au bon vouloir.

Quelle différence avec un SVN accessible en lecture seule, publié et abandonné au bon vouloir ?

> Mais il faut rajouter une étape, "push" pour envoyer ta branche sur le repo "centrale".

Oui, c'est pas un scoop qu'il faut faire un push pour envoyer des commits sur un repo distant. Mais le fait que le commit soit sur une autre branche ou pas ne change pas grand chose.

Si tu aimes travailler en centralisé, travaille en centralisé avec Git, il te suffit de faire un push derrière chaque commit (éventuellement un "push --set-upstream").

> prend ma branche de dév truc_machin, il faut configurer un "remote, ...". Complexe.

Tu n'as pas besoin de configurer un remote pour accéder à une branche. Tu as besoin de ça pour accéder à un autre repository. Mais rien ne t'empêche d'avoir plusieurs branches dans le même repository git.

> * des outils tels stgit, Mq ou autre

"git rebase -i" (y'a une extension Histedit pour Mercurial qui a l'air de faire grosso-modo pareil) est excellent aussi.

> Il n'existe pas forcément d'algorithme.
> C'est peut-être simplement une liste de cas tous différents…

Vu que l'espace d'état est fini, une liste de tous les cas, c'est un algorithme (bourrin, mais c'est un algorithme quand même).

Ou alors, tu te poses la question « By jove, que peut donc bien faire l'entrée "Visualize all branch history" du menu "Repository" de git gui ? ».

Ou alors, tu regardes dans le menu « View » de gitk, tu trouves « New view », et tu cherches la/les cases à cocher qui vont bien.

Je connaissais gitk --all, mais pas leurs équivalents graphiques, il m'a fallu plus de temps pour rédiger ce message que pour trouver les options. Bref, l'auteur du journal n'avais pas très envie de trouver visiblement.

> tu commit tout le temps, chaque truc, tu ne perd jamais l'historique

Pas seulement. Tu peux aussi nettoyer ton historique avant d'envoyer, et donc tes conneries intermédiaires restent privées (mais tu les avait quand même commitées en local), tu n'embêtes pas le reste du monde avec. C'est pas toujours souhaitable, mais c'est quasi-indispensable dans un contexte où la revue de code est importante.

Je n'ai pas dit que j'avais la preuve que la factorisation était moins dure que NP-complet, j'ai dit que si on arrivait à factoriser en temps polynomial, ça ne suffirait pas à prouver que P=NP.

Git gère depuis longtemps les dépots distants sur serveurs WebDAV (extension de HTTP, non-spécifique à Git), mais c'est un peu une bidouille : il n'y a pas d'intelligence sur le serveur, donc c'est largement moins efficace.

Plus récemment, Git a appris un protocole « smart HTTP », comme ce que Mercurial savait faire depuis longtemps : un protocole spécifique à Git (avec script CGI côté serveur) plus efficace. Le principal intérêt par rapport à SSH étant d'être plus firefall/proxy-friendly.

Mercurial a eu de l'avance sur ce point, mais je ne pense pas qu'il reste de différence notable aujourd'hui.

> > Par exemple factoriser un nombre est actuellement un problème NP. Si on arrive à factoriser un nombre en temps P, alors tous les problèmes NP pourrons être transformés en P ?
> Oui.

Euh, aux dernières nouvelles, la factorisation en facteurs premiers, c'est NP, mais pas NP-complet. Par exemple, ça se fait en temps polynomial sur un ordinateur quantique, alors qu'il n'y a toujours pas d'algo connus pour résoudre les problèmes NP-complets en temps polynomial sur ordinateurs quantiques (ou alors, j'ai raté un truc).

Résoudre un algo NP-complet en temps polynomial ferait tomber tous les autres, mais factoriser un nombre en facteurs premiers, non, ça ne suffirait pas.

Plus précisément : si P = NP et qu'on a un moyen raisonablement efficace de réduire un problème NP à un problème P, alors la plupart des algo utilises en crypto posent problème.

On considère en théorie que « polynomial = pas cher » et « exponentiel = cher », mais un algo en N^100, en pratique, c'est pas si différent d'un truc exponentiel (le comportement pour N très grand est différent, mais de toutes façons, on aura atteint les limites de la machine bien avant de s'en rendre compte).

> En un an, il a coulé de GHz sous les ponts

Bah, pas tant que ça justement. Aujourd'hui, la course est plus au nombre de coeurs et à la RAM qu'au GHz. Si mes souvenirs sont bons, les premières machines grand public 1GHz, on les a vu apparaitre y'a environ 10 ans. Donc, même y'a plus d'un an, c'était quand même assez loin derrière.

Les listes Yahoo, c'est du passé maintenant. Freecycle a sa propre base de données, avec ses propres bugs dedans et tout maintenant. Enfin, ça s'arrange, mais à une époque, le moindre caractère accentué faisait planter l'ensemble (et quand on habite en Rhône Alpes avec un ^ sur le o, y'avait pas moyen d'accéder au groupe !). Y'a un moteur de recherche (qui vaut ce qu'il faut, mais il existe).

Y'a d'autres alternatives, comme http://www.recupe.net/ par exemple.

> J'ai toujours eu un esprit très mal placé il semble ....

Pas tant que ça :

http://fr.wiktionary.org/wiki/biter
« (1905) De l’argot de Polytechnique, de bite. »

Effectivement, je connaissais pas.

> github permet l'utilisation de ssh sur le port 443 (https).

Jamais entendu parler d'un SSH sur le port 443 chez GitHub.

Par contre, ils ont le protocole Git tunelisé dans du HTTPS (de mémoire, un ajout qui date de la fin des Git 1.6.x), donc chiffré et sur le port 443, mais ça, ça n'a rien à voir avec SSH.

Toi, tu n'as pas regardé comment marchait gitosis ...