rewind a écrit 3413 commentaires

Tu dois dezipper un fichier de 1gb, tu preferes quoi ?

Je regarde l'API de zlib qui permet de décompresser en flux au fur et à mesure donc je fais un widget qui permet d'afficher la progression de la décompression que je mets à jour au fur et à mesure que je décompresse. Ça ne fige pas l'interface, ça permet à l'utilisateur d'avoir un rendu et pas besoin de thread ou de process séparé.

Il est bien connu que combattre un extrême avec son extrême opposé, ça marche à tous les coups.
Il est également parfaitement moral d'adopter les mêmes méthodes jugées nauséabondes que ses adversaires, mais en expliquant que "c'est eux qui ont commencé!", on pourra toujours dire après que c'est eux qui manquent de morale et nous qui nous qui n'avons pas le choix.

Je n'ai porté aucun jugement moral pour ma part, c'est toi qui ramène tout à ça. Tu as l'air de considérer la bataille des mots comme quelque chose qu'il faut éviter, pas moi. Ce n'est pas une méthode nauséabonde, c'est juste un des plus vieux trucs au monde. Quand tu lis 1984, tous les mots ont changé et veulent dire le contraire de ce qu'ils signifiaient au départ. Tu veux vivre dans un monde comme ça ? Pas moi. Et pour ne pas vivre dans un monde avec de l'informatique de confiance, il faut utiliser d'autres mots et combattre ceux-là. Ou alors, donne-moi une méthode «morale».

L'explication logique, c'est "voilà la seule définition de la Liberté valide: celle de la sainte FSF/OSI". Cette définition de la Liberté est subjective et non rationnelle.

La FSF ou l'OSI n'ont rien de saint. Mais faudrait peut-être se réveiller. La FSF et ses quatre libertés, c'est le milieu des années 80, les DFSG, c'est 1997, l'OSI, c'est 1998. Ça fait plus de 20 ans, et presque 30 pour la FSF, que tout le monde du logiciel s'accorde sur la même notion de liberté (à quelques chouias près). Ça date pas d'hier. Donc, vouloir remettre en cause ça, je te souhaite bien du courage. Les seuls qui veulent le remettre en cause, c'est ceux qui font du Shared Source, c'est-à-dire qui veulent faire passer des vessies pour des lanternes.

Cf ce que je disais ci-dessus: œil pour œil, combattre le mal par le mal, tout ça, très peu pour moi!

C'est juste mener une bataille sur un terrain. Point. Rien de moral, aucune notion de bien/mal là dedans, juste des points de vue différents. On a encore le droit de défendre un point de vue ou pas ? C'est mal de ne pas être d'accord ?

Les arguments sont certes indépendants de GNU, mais indissociables de la FSF/OSI ou tout simplement d'une définition de la Liberté que tu souhaites imposer en jugeant ce qui est Libre (mot à forte connotation positive) et ce qui est privateur (mot à connotation fortement négative).

Je ne juge rien, je constate des choses, basé sur le droit d'auteur, puisque le logiciel est régi par le droit d'auteur.

Moi je te dis, et c'est ma conviction, qu'on ne convainc les gens non engagés/impliqués/initiés qu'en ayant une approche la plus neutre possible.
Tout ce qui ressemble de près ou de loin à "nous c'est le bien et eux le mal" de la part de quelqu'un qui n'a pas déjà une très forte aura lui fera perdre immédiatement en crédibilité.
Utiliser des mots à forte connotation positive et négative, c'est chercher cette assimilation au bien et au mal.

C'est toi qui n'arrête pas de tout ramener à une question morale. J'ai, depuis le début, dit qu'il n'y avait rien de moral là dedans, juste des questions banalement juridiques. Et des mots pour caractériser des situations juridiques différentes. Dont un, «libre», qui est utilisé depuis plus de 20 ans !

D'autre part, quand j'essaie de convaincre, je n'use pas d'arguments moraux qui passent pour des arguments d'autorité, donc qui sont irrecevables selon moi. Je fais appel au raisonnement des gens, à leur sens critique. Je te mets au défi de me présenter le logiciel libre de façon neutre, surtout si tu ne veux pas utiliser les définitions acceptées par tous et qui n'ont rien de morales.

Conclusion: je continuerai à dire qu'utiliser le mot "privateur" est non seulement un terme qui décrit mal les faits, mais qui en plus dessert la cause en faisant une fois de plus passer les Libristes pour des prosélytes.

Ça, c'est ton point de vue. Tu n'as répondu à aucun des arguments que j'ai avancés sur le non-sens qu'il y a à utiliser privateur, et sur la justesse du terme privateur par rapport à la définition de libre d'un point de vue juridique. Tu n'as qu'un point de vue moral sur la question, et dans ces cas là, chacun sa morale je dirais.

À t'écouter, on a l'impression qu'il ne faut rien faire, accepter les choses telles qu'elles sont (ou telles que les autres, qui n'ont pas forcément les même intérêts, les façonnent) et qu'au final, avec de la morale, tout le monde ira dans le droit chemin et comprendra, on ne sait trop comment, les choses. Excuse-moi de ne pas partager cette vision du monde.

c'est surtout un parti pris extrêmement biaisé. Même la GNU GPL prive l'utilisateur de certains droits (par exemple celui de faire tout et n'importe quoi avec ce code).

Absolument pas. Comparé à un logiciel privateur, la GPL donne le droit de distribuer le logiciel dans certaines conditions. Tu n'as pas ce droit avec un logiciel privateur puisque souvent, tu n'as pas le droit de le distribuer tout court.

Après, on peut troller sur copyleft vs non-copyleft, mais c'est un tout autre débat et il y a d'autres fils de discussion dans ce journal pour troller sur le sujet.

C'est justement ce référentiel centro-libriste qui fait qu'utiliser "privateur" et expliquer pourquoi n'aura pas d'écho auprès du grand public.

Ha ben tu peux utiliser le référentiel d'en face et dire, comme le fait CrEv un peu plus haut, que le droit d'auteur protège. Donc un logiciel privateur sera dorénavant un logiciel protecteur et donc, par conséquent, un logiciel libre sera un logiciel agresseur (ben oui, puisqu'il n'est pas protecteur). C'est du même niveau que "informatique de confiance" (qui ne fait pas confiance à l'utilisateur). Allez, maintenant, je t'invite à aller expliquer que les logiciels agresseurs sont une très bonne chose, on va rire.

M. Lambda ne connaît ni la FSF ni l'OSI. Quand tu lui expliquera ce que c'est et que donc "privateur", c'est "pas Libre suivant l'OSI et la FSF", il écoutera autant que le créationniste qui tente de le convaincre que si c'est pas dans la Bible, c'est que c'est pas vrai.

On peut aussi donner une explication simple et pédagogique, hein. Tu nous fais un joli homme de paille là.

Tu justifies "privateur" en disant que ça définit bien "le camp d'en face" vu de "ton camp à toi". C'est à peine plus relevé que les surnoms affectueux donnés à l'ennemi en temps de guerre.

Mais oui, nous vivons dans un monde merveilleux où toutes les personnes ont le même intérêt. Je regrette de te l'apprendre, mais Microsoft qui désigne la GPL comme un cancer nous considère bien comme son ennemi. Ce n'est pas la guerre, mais il y a une bataille quand même. Sinon, l'APRIL n'aurait pas grand chose à faire.

Et puis, en regardant comme ça, je dirais que quasiment tout contrat est privateur. C'en est même la définition: ajouter des contraintes aux deux parties, alors que chaque clause est faite pour réduire le champ des droits minimum donnés par la Loi.

Réduire ? Je ne pense pas. Justement, une licence libre accorde plus de droits que la loi (qui par défaut n'accord pas grand chose pour le droit d'auteur, à part l'usage à titre privée).

Enfin, question finale:
Pourquoi tant de haine??
Tu n'aimes pas les logiciels propriétaires? Et bien ne les utilise pas et fiche la paix aux éditeurs!
Tu veux militer pour le Libre? Et bien promeut le Libre au lieu d'insulter "le camp d'en face" (ce qui ne marche quasiment jamais d'ailleurs).

Mais je ne hais personne, je l'ai dit, il n'y a pas de morale à avoir là dedans, juste du juridique bien froid. Et utiliser le mot privateur n'empêche personne de faire du logiciel privateur. Je le répète, chacun fait bien ce qu'il veut de son code, comme la loi l'y autorise. Personnellement, je préfère le libre, et j'explique pourquoi c'est mieux. Mais je ne vais pas aller mettre la tête des auteurs de logiciels privateurs au bout d'une pique pour autant (en revanche, certains auteurs de logiciels libres comme Lennart P.[/troll]).

Je vais prendre le contre-pied de ce journal et dire qu'on n'est pas obligé d'adhérer à la secte du grand GNU quand on utilise le mot privateur, on peut aussi l'utiliser parce qu'on a réfléchi à la question et qu'on a des arguments (j'en ai donnés quelques-uns).

Moi je suis partisan de dire privateur à la place de propriétaire et cela, pour deux raisons.

Tout d'abord, logiciel propriétaire est un non-sens. Personne n'est propriétaire d'un logiciel, le logiciel est régi par le droit d'auteur et le droit d'auteur n'accorde pas un droit de propriété mais un monopole temporaire. 70 ans après la mort du dernier auteur de MS DOS, ce logiciel sera dans le domaine public et donc sera utilisable, modifiable, distribuable par tout le monde. Le terme propriétaire est inadéquat et ne peut qu'entretenir une confusion.

Ensuite, le terme privateur s'oppose à libre. Et effectivement, du point de vue du droit d'auteur, on prive l'utilisateur de certains droits. Que ce soit la FSF (avec les 4 libertés) ou l'OSI (ou les DFSG), on a une définition des droits minimum qu'un logiciel doit accorder pour se revendiquer libre (GPL ou BSD, peu importe). Si un de ces droits n'est pas accordé, c'est bien une privation du point de vue de l'utilisateur dans un référentiel libre. Donc privateur est tout à fait approprié.

Je vois beaucoup de message ici qui se placent sur le plan de la morale, mais on n'est pas dans le domaine de la morale, on est dans le domaine du droit, à mon sens. Dire qu'un logiciel est privateur n'a rien de péjoratif, chacun distribue bien ses logiciels comme il le souhaite. C'est juste une caractérisation juridique du logiciel : il prive l'utilisateur de certains droits qui seraient accordés avec un logiciel libre. Point. Rien d'autre.

Enfin, les mots ne sont jamais neutres. Croire qu'une expression est plus neutre qu'une autre est un leurre. Les mots utilisés portent souvent une arrière-pensée et la bataille des mots est aussi importante à mener que le reste. Regardez ces quelques termes : "propriété intellectuelle", "informatique de confiance", "le téléchargement, c'est du vol", etc. Vous comprendrez que nous, qui faisons du logiciel libre, avons tout intérêt à employer des mots précis pour mieux faire comprendre les choses, parce que nous n'avons pas des millions de brouzoufs pour faire des campagnes de pub. Et je pense que le mot privateur permet de mieux expliquer ce qu'est un logiciel libre alors que propriétaire (avec tout l'imaginaire qu'il y a avec ce mot) ne fait qu'embrouiller.

Quand je lis ces posts, je n'appelle pas vraiment ça de l'évolution mais de la maintenance…

Tu sélectionnes l'URL telle qu'affichée dans Firefox

Du coup, ça marche moins bien avec Chromium ;)

Bah, autant dire que le C++ est imbittable, ce qui est probablement vrai. Ça fait quelques années que j'ai tendance à utiliser systématiquement des langages de haut niveau, et quand je vois des trucs comme ça, c'est clair que je n'ai aucune envie d'y retourner :-)

Sauf qu'on aura toujours besoin de langage comme C/C++ pour implémenter des trucs qui doivent aller vite, comme les interpréteurs de langage haut niveau ou des compilateurs. Chacun son domaine.

Mais bon, il y a plus imbittable que le code C++: les erreurs retournées par le compilateur, avec un petit bonus quand la STL est impliquée et qu'il faut scroller dans le terminal pour retrouver le début de la dernière erreur…

Effectivement, tu n'as pas dû utiliser un compilateur C++ depuis bien longtemps et notamment clang parce qu'il y a eu de très très très gros progrès sur les messages d'erreur. clang a commencé et gcc est en train de s'y mettre.

Si tu ne veux pas montrer ton membre dans l'espace public, il suffit d'encapsuler l'appel à Visitor::visit dans une fonction qui renvoie la valeur du membre. Au passage, cela permet de donner un vrai nom à la fonction au lieu de visit.

visit n'est jamais appelé directement de l'extérieur (il l'est uniquement dans les fonctions accept), c'est bien accept qui est appelé mais soit, on peut reprendre ton argument et l'adapter à accept. C'est juste une question de style et de simplicité et de choix.

L'implémentation classique du modèle n'est d'ailleurs pas ce que tu donnes: dans Base la méthode accept est virtuelle et abstraite et implémentée dans les classes concrètes Derived1, Derived2. Dans ce cas Visitor::visit(Base& b) est b.accept(*this).

Alors ça, ça dépend de ce qu'est Base et de ce qu'est Derived1 et Derived2. Et si on applique le petit plus que j'évoque (appeler le visiteur de la classe mère), tu auras un accept pour Base.

Je ne dis pas le contraire. C'est juste que je ne trouve pas que c'est considérablement plus complexe au vu de la différence de complexité entre l'implémentation polymorphe et template.

Je ne trouve pas l'une tellement plus complexe que l'autre. La complexité ne se trouve pas au même endroit, c'est tout.

Là où ça deviens vraiment plus complexe c'est si tu souhaite paralléliser le calcul des sous résultats.

Alors là, pour le coup, ça ne change strictement rien, ça dépendra essentiellement de l'état interne de ton visiteur (est-ce qu'on peut appeler le visiteur en même temps sur la branche droite et la branche gauche, pour reprendre l'exemple) et pas de la manière dont tu as implémenté ton visiteur (template ou polymorphisme).

Ajouter un attribut à ton visiteur avec un accesseur.

Pas que. Comparons.

Version avec le type de retour.

Type *visitBinaryExpression(BinaryExpression& expr) {
  Type *left = expr.getLHS()->accept(*this);
  Type *right = expr.getRHS()->accept(*this);
  return ComputeType(left, right);
}

Version sans le type de retour.

void visitBinaryExpression(BinaryExpression& expr) {
  expr.getLHS()->accept(*this);
  Type *left = getResult();
  expr.getRHS()->accept(*this);
  Type *right = getResult();
  Type *result = ComputeType(left, right);
  setResult(result);
}

Ben je préfère la première version dans ce cas, beaucoup plus lisible et compréhensible.

Justement, je trouve plutôt utile que le compilateur refuse de compiler quand le cas n'est pas pertinent, ça évite les bogues…

Quand tu ajoutes une classe à ta hiérarchie, avec le visiteur polymorphe, tu dois déjà surcharger le accept. Bon, tu peux mettre un truc vide dans accept mais c'est un coup à l'oublier après (ça m'est déjà arrivé). Du coup, tu vas ajouter une méthode virtuelle au visiteur pour traiter cette nouvelle classe. Et il faudra ensuite ajouter toutes les surcharges dans tous les visiteurs. Enfin bref, tu te retrouves à devoir ajouter plein de code pour une simple petite classe.

Avec la version template, sans rien faire dans le accept et dans le visit, ça compile, et ça tombe dans le cas de base. Après, tu ajoutes le cas qui va bien dans le visit, et là, ça va même marcher pour quelques visiteurs pour lesquels tu auras regroupé les traitements pour une des classes mères. Donc dans ce cas, avec très peu de code, ça fonctionne plutôt pas mal.

Je ne vois vraiment pas l'intérêt?

Disons que tu veux afficher tes structures, là pas de souci, tu peux utiliser le visiteur qui renvoie void. Ensuite, tu veux calculer un truc sur tes structures, tu peux vouloir un visiteur qui renvoie directement le résultat du calcul plutôt que de passer par un membre. Exemple concret : tu veux calculer le type d'une expression binaire, tu vas définir un visiteur qui renvoie un truc de type Type que tu vas appliquer à des trucs de type Expression. Tu vas d'abord récupérer le Type de l'expression de gauche (à l'aide du même visiteur), puis le type de l'expression de droite puis, en fonction de l'opérateur, tu vas calculer le type de l'expression binaire et le renvoyer. Ne pas utiliser de type de retour va complexifier considérablement ton code.

Pas vraiment un plus, puisque tu le dis toi-même, ça s'applique aussi à la version polymorphe?

C'est un plus dans le sens où ça se fait rarement sur les versions polymorphes (je n'ai jamais vu aucun exemple qui le faisait) mais que ça pourrait se faire.

Si je résume, on aurai la version template qui permet d'éviter d'avoir à utiliser la RTTI et de casser l'ABI, et la version polymorphe qui elle offre de meilleures performances?

En gros. C'est plus subtil, il y a aussi des considérations de style, de flexibilité, etc.

Pour le coup, je trouve qu'en essayant d'adapter au pied de biche un pattern objet à CaML, tu rends le CaML illisible. Je suis entièrement avec ta conclusion ceci-dit.

avec en plus pas d'exemple concret d'utilisation dans la vraie vie

Tu as mal lu, j'ai mis un lien sur une utilisation dans LLVM (les compilateurs utilisent beaucoup ce design pattern).

cette implémentation ressemble fortement a celle dans Modern C++ Design (qui pourrait être cité en référence aussi)

Je n'ai jamais lu ce bouquin (je devrais peut-être) donc c'est assez difficile de le mettre en référence. Mais comme tu le cites ici, du coup, l'erreur est réparée ;)

Haaa :) Il y en a un qui l'a remarqué. Je l'ai pas mis pour faire du C++11 absolument mais pour voir si c'était pris en charge par la coloration C++. Et en fait, non.

Quant à savoir si C++11 permet d'améliorer les choses, je dirais non sur ce plan là effectivement.

D'ailleurs, question style: est-ce que rajouter 'virtual' en plus de 'override' n'est pas un peu redondant.

Oui et non. Je sais que certains préconisent de ne pas mettre de virtual pour les réimplémentations de méthodes virtuelles, mais j'ai toujours trouvé ça très perturbant. Du coup, je l'ai toujours mis systématiquement. Maintenant, avec un override, ça ne serait sans doute pas nécessaire mais ça n'apporte pas la même information je trouve. Et comme override se situe en fin de ligne, c'est assez difficile d'avoir un aperçu de toutes les méthodes virtuelles. Tandis qu'avec un virtual systématique, on le voit mieux je trouve. Mais comme tu dis, c'est une question de style.

Je ne dirais pas que ça complexifie le code. Avec un peu de préprocesseur, on parvient à générer un maximum de chose assez facilement. LLVM a d'ailleurs de ce point de vue des techniques assez intéressantes. Par exemple, dans le cas des instructions LLVM, ils ont un fichier dans lequel sont décrites toutes les instructions de manière assez simple. Et ils se servent de ce fichier pour générer plein de trucs dont le code de base du visiteur, que j'ai écris à la main ici mais dont on voit bien qu'il est assez répétitif. Ils le font pour plein de choses et c'est souvent fait de manière assez intelligente je trouve, et assez compréhensible.

Pour les cas complexes, ils ont un autre outil qui s'appelle TableGen.

Petite correction, avec -fno-rtti, on a quand même droit aux exceptions. Il faut ajouter -fno-exception pour enlever complètement les exceptions. Dans LLVM, il n'y a ni exception, ni RTTI activé. Mais ils ont quand même leur propre système de RTTI à base d'enum, comme montré ici, qui leur permet de faire un genre de dynamic_cast.

J'ai essayé avec clang++ et g++ pour des résultats assez similaires. Ce qui ne m'étonne pas tant que ça vu que clang++ produit des binaires compatibles avec ceux de g++, donc utilise les mêmes structures pour type_info, et fait globalement la même chose.

Oui, je voulais mettre celui-là mais tu auras remarqué sur ton propre lien qu'il est faux à cause de la parenthèse finale. Et comme je ne me souvenais plus du code pour le mettre avec un % et qu'il était déjà très tard, j'ai fait au plus vite. Mais comme tout le monde arrive à tomber sur le bon lien assez vite, je me dis que j'ai bien fait de ne pas trop chercher. Et si un généreux admin peut le changer, ça sera nickel ;)

La vraie question est : que veux-tu faire après ta thèse ? Si tu veux rester dans le milieu universitaire, alors une thèse CIFRE n'est pas forcément la meilleure idée parce que souvent, les thèses CIFRE ont trop peu de contenu scientifique, ou alors, il faut se battre constamment contre son entreprise pour faire des choses intéressantes. Si tu veux rester dans le privé, alors faire une thèse ne t'apportera rien puisque la France est le seul pays au monde où il vaut mieux avoir un bac+5 qu'un bac+8. De rien ! ;)

Et donc ils m'auront plus peur!

Bien sûr que si, ils auront encore peur ! C'est grâce à la peur qu'ils ne se rebelleront pas contre ces dispositifs, donc ils continueront d'avoir peur et on pourra leur refourguer d'autres saloperies !

Chacun est libre d'avoir les fantasmes qu'il veut, mais là on parle d'en donner une illustration concrète et là, on ne fait pas ce qu'on veut. Si un dessinateur a des fantasmes pédophiles, je doute qu'un dessin pédophile soit légal.

Oui, dans notre société, c'est « la femme qui fait la cuisine », la « femme au foyer ».

C'est justement en continuant à véhiculer ce genre de clichés qu'on les perpétue.

Je n'ai pas dit que c'était la faute des femmes. J'ai dit qu'elles aussi jouaient un rôle

Et bien, je le répète, non elle ne joue pas de rôle, elles sont exposés aux mêmes images et aux mêmes publicités, elles n'ont pas des comportements sexistes consciemment comme le laisse penser ce «elles jouent un rôle».

Mais des femmes qui se prétendent féministes, et pour qui il est hors de question de laisser l'éducation des enfants au père, parce que c'est un gros incapable (au passage, on lui a pas laissé la chance d'essayer, hein), il y en a aussi. Et c'est à elles que pensent les gens qui se plaignent « des féministes ».

Comportement ultra-minoritaire au sein du mouvement féministe. Et dénoncé par ce même mouvement. Et qui ne justifie toujours en rien le sexisme, ce n'est pas parce qu'une toute petite minorité de femmes agissent comme des sexistes que les hommes peuvent se permettre de l'être.

La nature et les réalités biologiques n'ont aucune incidence sur des comportements qui sont essentiellement sociaux. On ne va pas refaire le débat sur le mariage pour tous, mais les opposants invoquaient également ce genre d'arguments débiles. Le sexisme n'est pas dû au fait que les hommes soient plus «fort», il est dû au fait que les hommes imposent socialement cette force sur les femmes. Et que si on se considère un minimum civilisé, on doit tout faire pour que les hommes et les femmes soient traités de la même manière.