> Est-ce qu'il y a du monde qui utilise darcs pour de vrai ?
Par rapport aux trois grands (git, hg, bzr), non. C'est le problème de l'effet réseau, plus/moins y'a de monde qui l'utilise, plus/moins on a envie de l'utiliser.
> Qu'en est-il de darcs ? Est-il réellement utilisable sur autre chose que linux (on a du linux et du windows), s'intègre-t-il dans eclipse, vs.net, etc ?
Pour ce qui est des GUI, passe ton chemin :-) C'est ligne de commande pure pour le moment, tant que personne ne s'y met pour écrire une interface ou ajouter le support dans quelque chose d'existant, genre RabbitVCS.
Il y a des binaires Mac et Windows, garde un oeil sur http://wiki.darcs.net/Binaries dans les jours qui viennent, ils vont être ajoutés pour cette nouvelle version.
> Et aussi, est-il assez performant ? (quand on parle de bazaar on comprend les problèmes de performance...)
Généralement, darcs n'est pas recommandé pour des gros projets. Par exemple, il gère peu efficacement les fichiers binaires aussi bien du point de vue taille du dépot que consommation mémoire. De mon expérience, il est quand même bien plus rapide que bazaar.
Les plus gros dépots darcs publics sont probablement celui du compilateur GHC avec >22000 patchs, de darcs même avec >8000 patchs et Tahoe-LAFS avec >4500 patchs.
> Avez-vous des retours d'utilisation tout simplement ?
En termes de fréquentation du chan IRC oui bien sûr. Ceux qui nous font pas mal de remarques sont les dévelopeurs GHC principalement. Ils ont envisagé de passer à Git pour cause de mauvaise performance de darcs il y a 2 ans et ne l'ont finalement pas fait car darcs s'est amélioré (cf http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation ). Bon, maintenant j'ai ouï dire qu'ils veulent à nouveau passer à Git parce qu'ils veulent utiliser github, c'est encore un autre problème :-)
> Le seul moyen de ne pas reconstruire une arbo à partir du premier patch est de stocker des révisions rattachées à des patchs particuliers.
> Autant s'appuyer directement sur un système basé sur les révisions qui peut appliquer des optimisations (Delta inversé, ...)
Avec quelques astuces (le pristine tree, le cache) on peut réduire les désagréments et obtenir des performances pas honteuses.
>Ensuite l'approche par clonage pose des problèmes puisque le fait de cloner n fois un repository distant ou des repositories clonés (cf. mon lien plus haut) surcharge le réseau pour rien. Il y a des possibilité d'optimiser avec un cache de chaque coté comme tu l'évoques mais ca ne règle pas le premier pb.
Depuis la version 2.2, il y a un cache de patchs pour chaque utilisateur, donc faire un deuxième clone d'un dépot distant est rapide, et faire des clones locaux également.
>Après c'est sûr que si tu éludes la question des perfs, c'est plus facile.
Je regrette de donner cette impression mais j'essaye d'expliquer pourquoi je trouve cet outil valable. En 3 ans d'utilisation je ne me suis jamais plaint des perfs, donc elles ne sont pas si horribles. Le problème c'est que comme les gens (peu nombreux) qui codent des projets "stars" de l'ampleur de Firefox ou du noyau linux sont très audibles dans la communauté du logiciel libre, tout le monde a tendance à prendre leurs préoccupations pour les siennes.
>Oui mais même lorsqu'il n'y a pas de conflit, un système qui s'appuie sur des révisions gère/peut gérer aussi efficacement les changeset que les systèmes basés sur les patchs ala darcs ou Arch.
D'accord, un tel système peut te générer le diff qui va bien quand tu lui demande de cherry-picker tel changement dans telle branche, mais ce diff n'est pas un objet de base manipulé par le système de gestion de versions, donc pas réutilisable et échangeable aussi librement qu'avec darcs.
>Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
Merci pour ton lien Mercurial, je me ferai bientôt un ptit projet sur google code pour comprendre son approche.
>cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.
Ouep, pour les perfs ça pose problème, ceci dit quand les clones de dépôts sont faits sur le même système de fichiers, les liens durs sont utilisés le plus possible.
Pour l'intégration dans les IDE, bof je vois pas en quoi un système de répertoires frères poserait problème.
Oui, je pense que darcs reste aujourd'hui plus lent que ses concurrents, mais que la différence devient sensible seulement pour les gros projets. Actuellement le projet darcs a deux étudiants "summer of code" qui travaillent sur la performance (l'un sur les transferts réseau et l'autre sur l'amélioration du cache), en plus des développeurs permanents qui s'occupent aussi de ce problème. La version 2.5 (juillet) m'a l'air bien partie, par exemple ce bug est résolu dans la branche de développement : http://bugs.darcs.net/issue1106
Sans vouloir évacuer le problème, j'ai quand même envie de dire que si je dois taper 4 commandes dans git au lieu de taper 1 commande dans darcs pour faire la même chose, darcs a beau être plus lent pour une même opération atomique, il est plus rapide pour moi. Je dirais qu'il ne faut pas éliminer darcs a priori pour ça, tout comme on n'élimine pas Python parce qu'il est plus lent que C.
Pour darcs, c'est essentiel de comprendre que gérer des patchs au lieu de gérer des révisions ça change quelque chose et c'est pas juste une représentation interchangeable avec une représentation orientée révisions.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit.
Quand il y a conflit, il faut créer un nouveau patch de résolution de conflit. Ce que je dis c'est que quand il n'y a pas de conflit (donc quand tout commute) alors il n'y a pas besoin de créer de patch supplémentaire.
Mais sinon l'exemple que tu présente est bon (à part que t'as inversé les flèches par rapport à moi). Sauf:
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
non, on aura pareil que dans ton cas de git: il faut créer un patch D qui dépend de B et de C (càd, qui modifie la même zone sur laquelle B et C sont en conflits).
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
Je peux imaginer que les power users de git habitués au checkout ne s'y retrouvent pas, en tout cas y'a de la demande pour des branches locales:
Si tu prends subversion, le graphe qui est considéré c'est un graphe où les sommets sont des révisions et les arcs veulent dire "est la révision suivante de", et le graphe ne peut former qu'une ligne.
Pour git/mercurial/bazaar, c'est pareil mais la différence est que le graphe est un graphe acyclique, càd qu'une révision peut avoir deux "révisions précédentes". C'est ce qui arrive quand on fusionne deux branches. Dans ce cas il y a un deuxième type de sommet qu'on pourrait appeler "point de fusion". Donc au moins on peut dire que git/mercurial/bazaar ont "conscience" de l'existence des branches, pas comme subversion.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de besoin de faire un patch qui résout les conflits, tu ne vois pas de trace de ta fusion.
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes. Git s'en sortait mieux, il a une notion de "fast-forward" qui crée automatiquement ce point de fusion quand tout va bien, ça qui évite de devoir toujours faire comme avec mercurial et bazaar.
Résumé : darcs est plus simple à utiliser car il implémente la notion intuitive de "ce changement-ci dépend de ce changement-là".
C'est pas faux, mais un Darcs qui marche bien sous Windows c'est une technique pour faire passer les gens à un système qui a une vraie ligne de commande :-)
J'ai dû rater un truc, car si tu connais SAT, je ne comprends pas ta nécessité d'introduire un concept de branches.
Je veux dire, tu as ton problème représenté sous forme de formule de logique booléenne et tu cherches les modèles (= assignements de valeurs de vérités aux variables booléennes) qui la satisfont. Soit tu te bricoles ton algo qui le fait (tu te modifies un DPLL), soit il existe déjà des algos (implémentés) qui t'énumèrent tous les modèles possibles d'une formule booléenne (cherche AllSAT algorithm sur le net). Après, tu prends tous tes modèles trouvés, tu leur mets un score comme tu l'as décrit pour tes branches, et tu présente à l'utilisateur les modèles du meilleur au plus mauvais. Si tu regardes l'ultraclassique algorithme DPLL, sa règle "split" est une règle de branchement.
Pour aller plus loin dans l'explication de la vanne, cette annonce du projet de loi par notre président a été faite lors d'une visite au Conseil représentatif des institutions juives de France (CRIF). Certaines personnes ont critiqué le fait que cette annonce a été faite là, représentant une sorte de "cadeau victimaire" pour la communauté juive.
Pourquoi attendre ? Tu prends un premier mplayer pour télécharger le flux, et un second pour lire le début du fichier créé, ça marche bien et tu peux te déplacer dedans.
> mais je ne pense pas que c'est la préoccupation principale du grand public de pouvoir choisir son système d'exploitation et les logiciels.
Même un consommateur entièrement satisfait par les produits Microsoft peut être intéressé par le fait de ne pas repayer la licence Windows XP à chaque fois qu'il achète un nouveau PC.
À noter aussi l'arrivée du paquet xubuntu-desktop pour avoir l'équivalent d'ubuntu-desktop et kubuntu-desktop version XFCE 4. Des versions CDs sont prévues à l'avenir comme pour Kubuntu.
C'est clair que l'auteur du site avait vraiment envie de détruire l'espéranto (et ses arguments sont parfois opposés), mais une partie de ses critiques est pertinente.
C'est une langue simple, très bien faite et intéressante mais pas parfaite pour diverses raisons (après tout, c'est le fruit du travail d'une seule personne), et je n'en serai jamais un méga-militant sachant qu'on peut faire mieux.
Voici un lien vers une liste de diffusion pour la création d'une langue internationale, où quelques choix de conception ont déjà été faits : http://groups.yahoo.com/group/WLangDev/(...)
Je précise tout de même que l'espéranto aujourd'hui marche bien en tant qu'outil de communication, avec plus de 2 millions de locuteurs dans le monde, et des sites sympa dont celui-ci d'actualités : http://gxangalo.com(...)
[^] # Re: utilisation...
Posté par geh . En réponse à la dépêche Darcs 2.5 arrive. Évalué à 5.
Par rapport aux trois grands (git, hg, bzr), non. C'est le problème de l'effet réseau, plus/moins y'a de monde qui l'utilise, plus/moins on a envie de l'utiliser.
> Qu'en est-il de darcs ? Est-il réellement utilisable sur autre chose que linux (on a du linux et du windows), s'intègre-t-il dans eclipse, vs.net, etc ?
Pour ce qui est des GUI, passe ton chemin :-) C'est ligne de commande pure pour le moment, tant que personne ne s'y met pour écrire une interface ou ajouter le support dans quelque chose d'existant, genre RabbitVCS.
Il y a des binaires Mac et Windows, garde un oeil sur http://wiki.darcs.net/Binaries dans les jours qui viennent, ils vont être ajoutés pour cette nouvelle version.
> Et aussi, est-il assez performant ? (quand on parle de bazaar on comprend les problèmes de performance...)
Généralement, darcs n'est pas recommandé pour des gros projets. Par exemple, il gère peu efficacement les fichiers binaires aussi bien du point de vue taille du dépot que consommation mémoire. De mon expérience, il est quand même bien plus rapide que bazaar.
Pour un benchmark récent tu peux regarder:
http://wiki.darcs.net/Benchmarks/Mornfall#and-for-a-big-repo(...)
Les plus gros dépots darcs publics sont probablement celui du compilateur GHC avec >22000 patchs, de darcs même avec >8000 patchs et Tahoe-LAFS avec >4500 patchs.
> Avez-vous des retours d'utilisation tout simplement ?
En termes de fréquentation du chan IRC oui bien sûr. Ceux qui nous font pas mal de remarques sont les dévelopeurs GHC principalement. Ils ont envisagé de passer à Git pour cause de mauvaise performance de darcs il y a 2 ans et ne l'ont finalement pas fait car darcs s'est amélioré (cf http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation ). Bon, maintenant j'ai ouï dire qu'ils veulent à nouveau passer à Git parce qu'ils veulent utiliser github, c'est encore un autre problème :-)
Sinon, cf http://wiki.darcs.net/ProjectsUsingDarcs
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 1.
> Autant s'appuyer directement sur un système basé sur les révisions qui peut appliquer des optimisations (Delta inversé, ...)
Avec quelques astuces (le pristine tree, le cache) on peut réduire les désagréments et obtenir des performances pas honteuses.
>Ensuite l'approche par clonage pose des problèmes puisque le fait de cloner n fois un repository distant ou des repositories clonés (cf. mon lien plus haut) surcharge le réseau pour rien. Il y a des possibilité d'optimiser avec un cache de chaque coté comme tu l'évoques mais ca ne règle pas le premier pb.
Depuis la version 2.2, il y a un cache de patchs pour chaque utilisateur, donc faire un deuxième clone d'un dépot distant est rapide, et faire des clones locaux également.
>Après c'est sûr que si tu éludes la question des perfs, c'est plus facile.
Je regrette de donner cette impression mais j'essaye d'expliquer pourquoi je trouve cet outil valable. En 3 ans d'utilisation je ne me suis jamais plaint des perfs, donc elles ne sont pas si horribles. Le problème c'est que comme les gens (peu nombreux) qui codent des projets "stars" de l'ampleur de Firefox ou du noyau linux sont très audibles dans la communauté du logiciel libre, tout le monde a tendance à prendre leurs préoccupations pour les siennes.
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 1.
D'accord, un tel système peut te générer le diff qui va bien quand tu lui demande de cherry-picker tel changement dans telle branche, mais ce diff n'est pas un objet de base manipulé par le système de gestion de versions, donc pas réutilisable et échangeable aussi librement qu'avec darcs.
>Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
Oui il faut tout recalculer tant qu'on n'a pas une sorte de système de cache. Or un dépôt darcs contient le "pristine tree" qui est la somme des patchs du dépôt: http://upload.wikimedia.org/wikipedia/commons/6/69/Darcs-rep(...)
Merci pour ton lien Mercurial, je me ferai bientôt un ptit projet sur google code pour comprendre son approche.
>cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.
Ouep, pour les perfs ça pose problème, ceci dit quand les clones de dépôts sont faits sur le même système de fichiers, les liens durs sont utilisés le plus possible.
Pour l'intégration dans les IDE, bof je vois pas en quoi un système de répertoires frères poserait problème.
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 2.
Oui, je pense que darcs reste aujourd'hui plus lent que ses concurrents, mais que la différence devient sensible seulement pour les gros projets. Actuellement le projet darcs a deux étudiants "summer of code" qui travaillent sur la performance (l'un sur les transferts réseau et l'autre sur l'amélioration du cache), en plus des développeurs permanents qui s'occupent aussi de ce problème. La version 2.5 (juillet) m'a l'air bien partie, par exemple ce bug est résolu dans la branche de développement : http://bugs.darcs.net/issue1106
Sans vouloir évacuer le problème, j'ai quand même envie de dire que si je dois taper 4 commandes dans git au lieu de taper 1 commande dans darcs pour faire la même chose, darcs a beau être plus lent pour une même opération atomique, il est plus rapide pour moi. Je dirais qu'il ne faut pas éliminer darcs a priori pour ça, tout comme on n'élimine pas Python parce qu'il est plus lent que C.
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 2.
Pour darcs, c'est essentiel de comprendre que gérer des patchs au lieu de gérer des révisions ça change quelque chose et c'est pas juste une représentation interchangeable avec une représentation orientée révisions.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit.
Quand il y a conflit, il faut créer un nouveau patch de résolution de conflit. Ce que je dis c'est que quand il n'y a pas de conflit (donc quand tout commute) alors il n'y a pas besoin de créer de patch supplémentaire.
Mais sinon l'exemple que tu présente est bon (à part que t'as inversé les flèches par rapport à moi). Sauf:
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
non, on aura pareil que dans ton cas de git: il faut créer un patch D qui dépend de B et de C (càd, qui modifie la même zone sur laquelle B et C sont en conflits).
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
Je peux imaginer que les power users de git habitués au checkout ne s'y retrouvent pas, en tout cas y'a de la demande pour des branches locales:
http://bugs.darcs.net/issue555
http://lists.osuosl.org/pipermail/darcs-users/2009-July/0205(...)
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 4.
Pour git/mercurial/bazaar, c'est pareil mais la différence est que le graphe est un graphe acyclique, càd qu'une révision peut avoir deux "révisions précédentes". C'est ce qui arrive quand on fusionne deux branches. Dans ce cas il y a un deuxième type de sommet qu'on pourrait appeler "point de fusion". Donc au moins on peut dire que git/mercurial/bazaar ont "conscience" de l'existence des branches, pas comme subversion.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de besoin de faire un patch qui résout les conflits, tu ne vois pas de trace de ta fusion.
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes. Git s'en sortait mieux, il a une notion de "fast-forward" qui crée automatiquement ce point de fusion quand tout va bien, ça qui évite de devoir toujours faire comme avec mercurial et bazaar.
Résumé : darcs est plus simple à utiliser car il implémente la notion intuitive de "ce changement-ci dépend de ce changement-là".
[^] # Re: gourage de site
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 6.
# les branches, c'est déjà dans SAT
Posté par geh . En réponse au journal Résolution des dépendances par système de branches. Évalué à 2.
Je veux dire, tu as ton problème représenté sous forme de formule de logique booléenne et tu cherches les modèles (= assignements de valeurs de vérités aux variables booléennes) qui la satisfont. Soit tu te bricoles ton algo qui le fait (tu te modifies un DPLL), soit il existe déjà des algos (implémentés) qui t'énumèrent tous les modèles possibles d'une formule booléenne (cherche AllSAT algorithm sur le net). Après, tu prends tous tes modèles trouvés, tu leur mets un score comme tu l'as décrit pour tes branches, et tu présente à l'utilisateur les modèles du meilleur au plus mauvais. Si tu regardes l'ultraclassique algorithme DPLL, sa règle "split" est une règle de branchement.
(Je n'ai pas lu ton code).
# Lien de l'interview originale
Posté par geh . En réponse au journal Me-Mix. Évalué à 1.
[^] # Re: Ce qui est d'autant plus marrant...
Posté par geh . En réponse au journal SFR, Neuf et Linux. Évalué à 10.
[^] # Re: Quelqu'un peut m'expliquer la blague ?
Posté par geh . En réponse à la dépêche Le président français propose aux écoliers d'adopter un projet libre mort sur SourceForge. Évalué à 7.
[^] # Re: Si ça se concretisait ...
Posté par geh . En réponse à la dépêche L'offensive de Microsoft contre Google. Évalué à 1.
[^] # Re: Oublis :
Posté par geh . En réponse au journal France2 parle (enfin) de la vente liée..... Évalué à 1.
[^] # Re: Je peux me tromper....
Posté par geh . En réponse à la dépêche L'UFC Que Choisir contre la vente liée. Évalué à 5.
Même un consommateur entièrement satisfait par les produits Microsoft peut être intéressé par le fait de ne pas repayer la licence Windows XP à chaque fois qu'il achète un nouveau PC.
[^] # Re: Politique
Posté par geh . En réponse au journal Interdiction de fumer dans les lieux publics des début 2007 ?. Évalué à 1.
# Et un article dans le Républicain Lorrain :
Posté par geh . En réponse à la dépêche RMLL 2006 : table ronde politique Bayrou/Billard/Cazenave/Rocard. Évalué à 5.
http://img309.imageshack.us/img309/8303/rmllarticle3dk.jpg
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par geh . En réponse à la dépêche Appel à commentaires sur le référentiel général d'interopérabilité. Évalué à 10.
[^] # Re: Bravo et merci
Posté par geh . En réponse à la dépêche GtkRadiant passe en GPL. Évalué à 4.
Merci !! J'ai enfin la réponse à ma question : "mais pourquoi est-ce qu'ils ne libèrent pas non plus les données?"
# Xubuntu
Posté par geh . En réponse à la dépêche Ubuntu 5.10 est sortie. Évalué à 9.
[^] # Re: Merci pour la traduction !
Posté par geh . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 4.
[^] # Re: mp3 ou ogg
Posté par geh . En réponse au journal Lecteurs MP3 : test du Samsung YP-F1Z. Évalué à 1.
[^] # Re: .
Posté par geh . En réponse au journal Comment les banques font croire à la sécurité. Évalué à 1.
[^] # Re: Liste incomplète
Posté par geh . En réponse au sondage La langue que je préfère. Évalué à 1.
C'est une langue simple, très bien faite et intéressante mais pas parfaite pour diverses raisons (après tout, c'est le fruit du travail d'une seule personne), et je n'en serai jamais un méga-militant sachant qu'on peut faire mieux.
Voici un lien vers une liste de diffusion pour la création d'une langue internationale, où quelques choix de conception ont déjà été faits : http://groups.yahoo.com/group/WLangDev/(...)
Je précise tout de même que l'espéranto aujourd'hui marche bien en tant qu'outil de communication, avec plus de 2 millions de locuteurs dans le monde, et des sites sympa dont celui-ci d'actualités : http://gxangalo.com(...)