Matthieu Moy a écrit 3249 commentaires

Bah, c'est simple :

Si je te demande de faire un programme de calcul du PGCD en C, tu préfères :

1) écrire le programme

2) faire tourner un programme qui génère tous les programmes C, et appuyer sur Entrée quand tu as trouvé le bon

?

(sérieux, j'espère que ce journal est au 2ème degré ...)

Je me permet de supposer que l'ensemble de ce journal est à prendre au 2ème degré, mais je vais quand même répondre.

> De toute manière, comme je l'ai précisé, je ne compte pas partir sur des fichiers textes, mais binaire.

Ce qui montre bien que tu n'as rien compris à mon calcul, puisque justement, je parle de binaire. Avec du texte, comme précisé plus bas, tu pourras peut-être monter à quelques mots, mais certainement pas à un truc suffisament non-trivial pour être copyrightable.

> À partir de combien de bits peut on consédérer un nombre comme non trivial?

Alors, on va prendre un exemple simple. Suppose que quelqu'un pose sa main sur ta joue. C'est une caresse, c'est gentil. Suppose maintenant que quelqu'un lance sa main de toutes ses forces sur ta joue, et t'envoie à l'hopital sous la force du choc. C'est un coup, c'est répréhensible par la loi.

À partir de quelle vitesse de la main considère-t-on que le geste est un coup ?

Ah, tiens, une limite arbitraire, un truc laissé à l'appréciation du juge. Bah oui, c'est comme ça un peu partout en droit, pas juste en propriété intellectuelle.

Allez, si tu trouves des thunes, tu auras 1000To de stockage.

Tu auras généré tous les fichiers possibles de taille <6 octets. Si la loi de Moore continue, d'ici quelques dizaines d'années, tu auras généré toutes les possibilités de textes de 10, voire 11 caractères, qui sait. Si on continue comme aujourd'hui, on gagne près d'un bit tous les 18 mois !!

Tiens, justement, c'est le genre de textes sur lesquels le copyright ne s'applique pas, car considérés comme trop triviaux.

(6 octets = 48 bits, soit 2^48 possibilités, donc, 48*2^48 bits de taille de stoquage, ce qui fait environ 1600To)

Maintenant, tu as deux choix : attendre que la taille des disques te permette de stoquer tous les programmes de taille 1Go, et alors faire un procès à Microsoft pour plagiat, ou alors chercher une faille dans ton raisonnement.

La seconde solution pourra porter ses fruits plus rapidement.

Je suis bien d'accord avec toi, mais avec kmail/korganizer, en IMAP simple, perte de données, en cached IMAP, ça marche.

Si j'ai bien compris, korganizer va simplement chercher les fichiers directement dans le cache IMAP de kmail.

http://lists.kde.org/?l=kde-pim&m=117503451925618&w=(...)

La solution sur IMAP (Cached IMAP) marche a peu près. Ça merdoie des fois (de temps en temps, j'ajoute un truc au calendrier, il m'averti d'un conflit entre cet événement et lui-même, et quoi que je fasse, il recommence en boucle. Ensuite, quand je tue korganizer et kmail, et que je les relance, j'ai n copies de l'événement, correspondant aux n fois ou j'ai accepté une résolution de conflit dans la boucle par exemple), mais sur cette solution particulière, j'ai jamais eu de perte de donnée.

Je suis assez déçu, parce que je pense que mon cas est déséspérément classique (besoin de synchro entre deux machines, pas trop de possibilité d'installer un serveur dédié), et j'ai eu besoin de passer par deux cas de perte de données silencieuse pour arriver à un truc valable. La tentation de passer du côté obscure à Google calendar est grande.

Attention, avec korganizer, aux dernières nouvelles, si deux instances essayent d'accèder au même fichier distant, tu peux perdre ton calendrier purement et simplement. Ça m'est déjà arrivé deux fois, oublié de fermer mon korganizer du boulot, j'arrive chez moi, il télécharge en sftp, hop hop, et oh, un calendrier vide !

Je suppose que quand tu passes de 1 à 1, c'est une augmentation de 100% ?
Et quand tu passes de 1 à 0, c'est une augmentation de 0% !

Avec Korganizer, tu as une option pour stoquer les infos sur un serveur IMAP, et te créant un compte dans Kmail, de type "cached IMAP". Mais c'est pas hyper bien fait à mon gout. Par exemple, si tu met IMAP tout court, il ne râle pas, mais il perd des données. Quand j'ai signalé ça sur la mailing-list, en gros, la réponse était « Ah bah oui, bien sûr que tu vas perdre des données, c'est pas fait pour. Fallait prendre cached imap ».

http://gcc.gnu.org/gcc-3.2/c++-abi.html

The main point of the GCC 3.2 release is to have a relatively stable and common C++ ABI for GNU/Linux and BSD usage, following the documentation at http://www.codesourcery.com/cxx-abi/

Oui, je connais. Mais honnetement, comparer ça au mode plan de word, c'est méchant pour Word. Le mode plan, c'est un vrai mode d'édition (du temps où j'utilisais word, je l'utilisait pour toute la rédaction, et je passais en mode page au moment du fignolage principalement), tu tappes du texte, titres, paragraphes, ... après, tu peux avoir le plan des titres, afficher ou masquer certains titres ou paragraphes, afficher la première ligne de chaque paragraphe, ... (en encore, je ne connais que ce qui se faisait dans Word 97, je suppose que ça a encore pas mal évolué depuis).

Le navigateur, c'est bien aussi, mais ça remplace pas.

Je ne sais pas ce qu'il en est avec GCC 4, mais en tous cas, GCC 3.2 devait avoir une ABI stable, et tout et tout, et ça n'a pas duré bien longtemps.

Même avant, je crois ;-).

Malheureusement, ça n'est pas si surprenant. L'équipe d'OOo est réduite, et le code est parfaitement imbitable ce qui rends les contributions extérieures difficiles. Du coup, malheureusement, ça n'est pas la seule fonctionalité que les gens demandent depuis des années et qui n'ai pas encore vu le jour. Il y a au moins le mode plan (il y a le navigateur dans OOo, mais le mode plan à la word, c'est aussi un mode d'édition) que beaucoup de gens considèrent comme le point bloquant pour la migration, et qui n'intéresse pas plus que ça les développeurs.

Si une distribution Linux était à la place de Windows (i.e. en position de quasi-monopole, ce qui n'est pas près d'arriver vu qu'il y a une concurrence relativement équilibrée entre les distributions), et si un environnement de bureau concurrent s'estimait laisé, je pense qu'on pourrait avoir le même genre de procès, oui. Mais ça fait beaucoup de si.

(D'ailleurs, est-ce que Kubuntu n'est pas juste une prévision de Canonical pour éviter de se prendre un procès le jour où ubuntu aura 95% de parts de marché ? ;-) ).

Ça dépends du langage. En C, l'ABI est relativement stable, pas de problème au changement de compilo. En C++, l'ABI change assez régulièrement, une applie compilée avec une version de g++ de pourra pas forcément linker avec une bibliothèque compilée avec une version plus ancienne (de mémoire, il y a eu cassage d'ABI C++ avec gcc 4.0, 3.2, 3.1 et 3.0 au moins).

Ça, c'est parce que vous n'avez pas vu la cité des enfants perdus.

Le coup de la souris avec un aimant au bout de la queue, et du fromage rapé, c'était quand même un peu plus original que de passer par la fenêtre ...

> Monotone a une approche originale. [...] une version peut avoir plusieurs filles.

Oui, mais c'est ce que font la plupart des gestionnaires de versions actuels (enfin, sauf si on considère Subversion comme un gestionnaire de versions :-P ). bzr, hg, git au moins sont basés sur le même principe.

On pourrait disserter des heures là dessus, mais GNU Arch n'est pas « décentralisé » dans le même sens que les autres (git/bzr/hg/mtn/...) : Avec par exemple git, quand je fais "git clone git://kernel.org/l/archive/de/linus/", je me retrouve avec quelque chose qui est techniquement équivalent à la branche de Linus, mais sur mon ordinateur. Ce n'est pas « une branche de ... », c'est vraiment le même. D'ailleurs, si je suis hyper intelligent, si ça se trouve, un jour, les gens trouveront que c'est ma branche qui doit être la référence, et celle de Linus qui est un clone de la mienne.

Avec GNU Arch, on distingue deux choses :

* La notion de mirroir. Oui, je peux faire un mirroir d'une archive, mais ce n'est pas quelque chose d'équivalent : le mirroir est read-only, je ne peux pas commiter dessus.

* La notion de "tag" (ou branche, en fait). Je peux dire "ma branche est le successeur de la branche officielle", et là, je peux commiter. Mais c'est ma branche. Elle a une identité différente, ...

Avec les autres systèmes, les deux notions sont confondues. Ça a l'air subtil, mais c'est une différence pas négligeable. Par exemple, avec git, si je parle de la revision 2ab504fe, je peux avoir cette révision, peut-être que quelqu'un d'autre l'aura aussi dans son archive, ... Avec GNU Arch, si je parle de la revision Matthieu.Moy@imag.fr--arch/xxx--yyy--zzz--patch-42, c'est une révision qui est dans mon archive et dans celle de personne d'autre.

Oui, mais pour moi, le fait de pouvoir être sûr de revenir exactement dans le même état plus tard, et de pouvoir parler de cet état avec d'autres gens, ça devrait être la norme, pas l'exception.

> enregistrer seulement un changement dans un fichier et pas forcément tous les changements d'un fichier.

git permet aussi de commiter des "patch hunks" individuellement.

Dans "git gui", tu as les changements prêts à être commités à gauche, en vert, et les changement non sélectionnés pour le commit, à droite, en rouge. Dans le diff, en bas de la fenêtre, tu peux faire clic-droit -> stage hunk for commit / unstage hunk from commit.

En ligne de commande, tu as "git add -i" qui fait ça, et permet même de couper un "patch hunk" en morceaux. (attention, git add ne fait pas ce que la plupart des autres XXX add font : il ajoute un changement - par défaut, un fichier - au commit qui se prépare).

Mais attention, il faut se méfier des commits selectifs. Quand on fait ce genre de trucs, on commite quelque chose qui n'a probablement jamais existé sur le disque, et donc, qui n'a jamais été testé.

> J'aime la simplicité "un dépot, une seule branche".

Rien ne t'empêche d'utiliser git et mercurial de cette façon. Tu n'as pas besoin de savoir qu'il y a la possibilité d'avoir plusieurs branches dans le même repository pour les utiliser.

> De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs

J'ai utilisé un peu Darcs, j'ai trouvé l'interface utilisateur bien foutue, claire.

Par contre, je ne l'ai pas choisi pour plusieurs raisons :

* Les performances. Pour les projets que je gère, c'est pas un vrai problème, ils sont suffisament petits, mais je veux que le gestionnaire de version que j'utilise puisse passer à l'échelle, pouvoir utiliser la même chose pour moi que les gros projets. C'est une garantie que mes connaissances pourront être réutilisées, et une garantie de pérénité pour le projet (peu de risque que git ou Mercurial soient abandonnés du jour au lendemain vu les enjeux, alors que dieu seul sait ce qu'il se passerait si l'auteur de Darcs décidait d'arrêter de le maintenir).

* L'approche orientée patch. L'historique est une succession de patchs qui ont potentiellement été réordonnés, donc, la série de patchs ne corresponds pas forcément à une série d'états qui ont vraiment existé dans l'histoire.Résultat, tu ne peux pas revenir à un état passé de ton arbre de travail. Tu ne peux pas non plus dire « j'ai un problème avec la version XYZ, est-ce que vous l'avez aussi ». Avec git ou Mercurial, si je te dis que j'ai un problème avec la révision 2f82f760e1b263, c'est non ambigu, tous les développeurs savent de quoi je parlent (même arbre de travail, même historique).

Tout à fait.

Si mes souvenirs sont bons, les études en ergonomie ont placé l'optimum pour la lisibilité (de texte en langue naturelle) plutôt autour de 60 à 70 colonnes.

D'ailleurs, si tu prends à peu près n'importe quel truc sur lequel il y a quelque chose d'écrit, il y a ce genre de limite. Soit on fait des pages petites, soit on fait des gros caractères, soit on coupe en plusieurs colonnes.

>> Bah, moi, j'ai pas envie de m'emmerder à utiliser sed parce qu'un autre développeur a décidé d'utiliser une largeur de tab non-standard.
>
>quelle ouverture d'esprit. tu es mûr pour bosser chez Microsoft, vraiment.

En général, ce qu'on reproche à Microsoft, c'est justement pas d'être trop près des standards, ni de permettre aux gens de bosser sans être forcés à utiliser des outils spécifiques pour résoudre des non-problèmes.

> bah si ils imposent pas une largeur de tabulation, c'est leur problème.

Ouais, c'est ça, on va préciser dans les sujets que les tabs font 8.

On va ajouter aussi que le caractère de fin de ligne doit être interprêté comme un retour à la ligne suivante, dire qu'on attends un code en ASCII et non en EBCDIC. On sait jamais.

Et on ajoutera aussi qu'il faut écrire le programme sur plusieurs lignes.

Et on interdira explicitement les identificateurs de plus de 1024 caractères, au cas où.

Une tab, c'est 8 caractères, point. C'est le défaut sur toutes les applications que je connaisse, et c'est pas du tout réglable sur toutes les applications que je connaisse par contre.

> En même temps, il s'agit ici d'un cas spécial vraiment rare.

C'est si rare que ça de passer par autre chose que ton éditeur de texte pour regarder du code ? T'utilises jamais "less" ? Tu envoies jamais un patch par email ? J'ai donné a2ps et cat comme exemples (pour cat, en fait, c'est le xterm qui décide de la présentation des tabs), mais il y a des tonnes de cas où la tab, c'est 8 espaces, et à peu près impossible à changer.

Si tu veux indenter à 2, met deux espaces, et ça passera partout. Si tu met des tabs, tu vas te retrouver avec une expansion x4 de ton indentation, et il y a de bonnes chances pour que tu te retrouves avec un truc illisible car il dépasse d'une fenêtre normalement dimensionnée.

D'ailleurs, puisque c'est un truc qui n'arrive jamais, pourquoi avoir suggéré sed ?

>> Car le mode "wrap" est souvent pénible à utiliser.
> Pourquoi donc ?

Là, tu me fais vraiment peur sur la lisibilité du code que tu écris.

Tu ne vois vraiment pas pourquoi c'est plus lisible d'avoir du code bien aligné plutôt que d'avoir des lignes de 500 caractères découpées arbitrairement par ton éditeur de texte ?

> ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas.

Tu ne nous a toujours pas expliqué comment tu comptais le nombre de caractères que prends une ligne, si tu considère que la tab peut faire autre chose que 8 caractères.


Le problème avec les tabs, c'est pas tellement les tabs en soi, mais c'est les gens qui jouent avec la configuration de leur éditeur et qui du coup, indentent n'importe comment.

> 1. man sed

Bah, moi, j'ai pas envie de m'emmerder à utiliser sed parce qu'un autre développeur a décidé d'utiliser une largeur de tab non-standard. D'autant que ça m'oblige à deviner la largeur de tab pour laquelle le code a été écrit (je parle d'expérience, et tous les enseignants qui ont déjà corrigé des TPs d'étudiants qui jouent avec leur largeur de tab comprennent de quoi je parle).

> 2. Le rendu dépend aussi de la police utilisée (au moins monospace ou pas).
> Tout le monde ne code pas dans un terminal ! A coté de ça, le "problème" des
> tabulations est vraiment mineur...

Tout le monde ne code pas dans un terminal, mais faut vraiment en vouloir pour coder avec une police à chasse variable.

>> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
> À tout hasard, dépasser les 80 colonnes

Ce qui confirme mon affirmation de départ : ton code sera illisible ailleurs que chez toi : du code qui tiens sur 80 colonnes chez toi va probablement dépasser chez n'importe qui n'ayant pas trifoullié sa config.

> Tu sais, si seules les tabulations sont autorisées c'est plus un problème :)
[...]
> la seule situation ou je m'autorise le mix tab/espaces

Bah, ça a l'air d'être un beau bordel, tes directives de codage.

> pour mettre tout le monde d'accord est d'utiliser les tabulations et de laisser
> l'éditeur choisir par combien d'espaces représenter une tabulation.

Ça, c'est le meilleur moyen d'être sûr que ton code sera illisible partout ailleurs que dans ton éditeur.

Si tu règle ta tabulation à 2, essayes par exemple

$ cat ton-fichier.py
$ a2ps ton-fichier.py
...

Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.

Après, il y a des trucs un peu plus subtils, du genre

SSune ligne
TTune autre ligne

(avec "S" = espace, et "TT" = une tab de largeur 2), qui s'affichera aligné chez toi, et pas chez n'importe qui ayant une configuration décente. Ou encore

TTif (une-condition-un-peu-longue &&
TTTTTTune-autre-condition) {

qui s'affichera correctement chez toi, mais nulle part ailleurs.

Bon, je m'arrête là.