gaaaaaAab a écrit 1393 commentaires

Pour vous départager, autant aller voir la source

Pour revenir au message source, je ne suis pas du tout sûr que Linus connaisse l'identité de la personne cible de son courroux. En tout cas, dans son message, il ne dit pas "Tu devrais être rétroactivement avorté", mais (traduction libre) "le quelconque génie qui a pensé que c'était une bonne idée (…) devrait être rétroactivement avorté". Dans son message, Lennart ne précise pas que Linus s'en prend à un dév de systemd, et vu la réponse de Kay, j'aurais aussi tendance à penser qu'il l'a pas pris pour lui (ou en tout cas, qu'il ne s'en est pas plus offusqué que ça). Faudrait aussi voir à ne pas être plus royaliste que le roi.

Pour le fond de la question, est-ce que le comportement de Linus donne le mauvais exemple, je n'en sais rien. Je ne me souviens pas avoir lu de messages de gens justifiant leurs insultes en citant explicitement Linus comme exemple. Si quelqu'un a ça sous la main, ça contribuerait utilement au débat.

Il me semble aussi que les insultes sont largement plus virulentes dans les commentaires de sites de presse généraliste que sur les mailing list / forums / … de la communauté mais bon …

C'est une couche de sécurité supplémentaire (épaisseur genre nuisette), mais qui est totalement insuffisante toute seule en 2014.

D'après Alan Cox, c'était aussi insuffisant tout seul en 2007, la raison étant que chroot n'a pas été conçu pour servir de couche de sécurité. On ne peut pas reprocher à un outil de ne pas répondre à un besoin auquel il ne cherche pas à répondre.

Dans la vie quand on a un marteau, les problèmes ressemblent tous à des clous.

pour terminer le proverbe, "et quand ton marteau, c'est C++, tout ressemble à un doigt" ! :D

le terminal c'est pour les serveurs, les GEEKs,
ou pour se la peter devant les collegues en disant, regarde, moi je "maitrise" linux.

c'est triste ton avis sur le terminal

En farfouillant sur le net, j'ai trouvé des infos supplémentaires.

cf le premier message de http://www.gossamer-threads.com/lists/python/dev/651981

Si tu es en Python 2, tu peux t'en sortir simplement en ne dérivant pas ta classe de object (j'ai testé, ça marche).

Sinon, j'ai aussi trouvé une recette pour python 3. Cette recette fonctionne un peu différemment parce qu'elle crée des proxy sur des objets instanciés, et pas sur des classes. En reprenant l'exemple, comme ça, chémoisamarche :

c=Proxy(list())
c.append(3,)
print ("value : " + str(c[0]))

Mais ai-je un moyen de savoir si les méthodes magiques sont implémentées ?

oui, la fonction dir liste tous les attributs de ce qu'on lui passe en paramètres.

C'est une des raisons pour lesquelles je n'aime pas Python ( et Java également) : il complique les choses qui se font de façon simple et évidentes dans d'autres langages.

et vice et versa !

J'avais dit à une époque que je trouvais que Python était un langage qui force à se répéter, et voici un exemple typique de ce que je voulais dire.

ça ne correspond pas à mon expérience. C'est vrai qu'en étant confronté à des nouveaux problèmes, il m'a parfois fallu un peu de temps pour trouver comment faire, mais j'ai toujours réussi à atteindre un truc que je trouvais propre en Python.

Entendons-nous bien : je ne veux pas "cracher" sur Python. J'avais juste promis il y a quelques temps que je donnerais des raisons concrètes pour lesquelles je trouvais que Python force à se répéter, et en voilà un concret.

raison suivante stp (ou un autre exemple de répétition) :-)

Si elle existe, je ne l'ai pas vue, mais j'ai peut-être mal cherché.

En fait, j'ai pas trouvé non plus, mais c'est p-e parce que c'est pas comme ça qu'on ferait en Python. Tu peux peut-être t'en sortir avec un décorateur qui fabriquerait à la volée des classes dérivées des types qui t'intéressent avec les ajustements dont tu as besoin. Autrement dit, au lieu d'encapsuler ta classe dans un proxy générique, est-ce que ça serait pas plus simple d'avoir un générateur de classes proxy spécialisées ?

Attention, __getattr__ est censé renvoyé la valeur d'un attribut. Ton implémentation actuelle renvoie une méthode qui renvoie la valeur de l'attribut pour _obj. Est-ce que tu ne voudrais pas plutôt faire ? :

    def __getattr__(self,name):
        return getattr(self.__dict__['_obj'],name)

Pour l'appel direct c[0], de ce que j'ai testé, l'interpréteur utilise la méthode __getitem__, mais en l'appelant directement, sans passer par __getattr__. Du coup, tu peux t'en sortir en ajoutant la méthode:

    def __getitem__(self, key):
        return self.__dict__['_obj'].__getitem__(key)

Si tu veux pouvoir affecter un élément de la liste, il faut que tu ajoutes aussi __setitem__. Bref, pour faire propre, il faudrait ajouter tous les __<methode>__ de la classe qui t'intéresse (inclus __repr__ et __str__ pour faire joli).

Mais du coup, tu te retrouves avec un proxy spécialisé pour les listes, ce qui n'est pas forcément ce que tu veux. L'étape d'après est de lister tous les attributs de la classes que tu veux proxifier, et rajouter les méthode __*__ dont tu as besoin à l'instanciation. Et du coup, il y a surement une recette quelque part sur le net.

Edit: je vois que je répond un peu à côté de la question sur les __getitem__ et compagnie

nous sommes un fond macro, autrement dit on s'intéresse a des changements macroscopiques, a long terme, pas a la milliseconde.

c'est probablement moins nocif que le HFT, mais est-ce pour autant bien ?

La finance a bon dos, mais peut être que si les gouvernements et les gens comme toi et moi arrêtaient de vivre a crédit on ne serait pas autant dans la merde.

ouais, c'est sûr. Mais il ne faudrait pas non plus croire que la finance se résume à la bourse. Dans le vaste de monde de la finance, il y a des trucs utiles, et d'autres moins.

je ne risquerais jamais mon argent pour investir dans des startups, ou dans des bons du trésor Grec. Il y a des gens qui prennent ces risques, et il est normal qu'ils soient payes en retour, non ?

Je ne sais pas si on peut répondre à cette question sans regarder le type de société qu'on veut au niveau macroscopique. Dans la société actuelle, c'est effectivement comme ça que ça marche, donc c'est "normal". Est-ce pour autant la meilleure façon de financer les entreprises ?

Pour les états, le financement ne devrait pas passer par le bon vouloir des investisseurs. Un état a les moyens de définir ses recettes comme ses dépenses. Le fait est que le verrouillage du système politique nous enferme dans du clientélisme (local ou de classe). D'autre part, il ne me semble pas que les investisseurs privés se soient rués au secours de la Grèce. J'ai même cru comprendre que c'était plutôt le contraire, et que c'est les autres états européens qui ont sorti du pognon, avec beaucoup de réticence et après beaucoup d’atermoiements.

La bourse ne sert pas qu'a enrichir les grands patrons, elle sert aussi a financer des vrais projets.

D'après Frédéric Lordon, ça a été vrai à un moment, mais ça ne l'est plus. Malheureusement, l'article de départ n'est pas accessible publiquement, mais il y a quand même cette interview

http://blog.mondediplo.net/2010-03-12-Il-faut-fermer-la-Bourse

la recherche de Thunderbird me convient très bien, mais je reçois un volume d'e-mail très raisonnable. J'avais vu la conf sur mailpile au fosdem, et ça a l'air très très chouette. Je ne sais pas si c'est utilisable en prod mais c'est un projet à suivre.

Note que tu invoques sed une fois de trop, tu peux écrire

sed "1d; s/ .*//"

ça n'a l'air de rien, mais sur des gros volumes de données, la différence en performance peut-être significative

hmmm … alors j'avais mal compris ta question … et je pensais que t'avais testé la version avec cut :D

cut utilise aussi les délimiteurs dans la sortie, donc, pas besoin de les remettre, ils y sont déjà.

chaîne de recherche awk

Certes, mais il y avait aussi du sed dans la question, alors du coup … ;-)
non, en vrai, il y a deux raisons :

• le demandeur ajoute parfois une contrainte technologique par ignorance des alternatives plutôt que par choix délibéré de la techno vraiment adaptée à son problème,
• je ne suis pas super fan de awk, et je crois qu'on peut le remplacer par quelque chose de "mieux" (souvent sed) dans quasiment tous les cas.

avec cut, tu peux "reecrire" la chaine pour obtenir /1/2 en sortie ?

j'imagine que tu pensais /2/1 ?
Si c'est bien le cas, la réponse est, à ma connaissance, non, mais il se trouve que ce n'était pas la question ! ;-)
Pour extraire des champs sans réordonner -> cut, pour des trucs hors périmètre de cut -> autre chose

cut permet aussi de spécifier le délimiteur de champs:

cut -d '/' -f 1,3

ça me rappelle quelque chose . Eet-ce qu'il aurait pas un GPS dans son alim ce brave homme ?

Quel genre de portabilité ? C++ est très portable.

ça dépend. Si tu n'utilises toujours le même compilo sur toutes les plate formes, ça ira. Par contre, si tu utilises le compilo de Sun sur Solaris, le compilo d'HP sur HP-UX, g++ sur Linux, etc … il vaut mieux ne pas utiliser les fonctionnalités trop récentes, parce qu'elles risquent de n'être supportées que par g++.

En quoi c'est pénible ? Il y a des bibliothèques qui font la conversion des noms de symboles pour toi.

je ne parlais pas de l'interprétation des symboles manglés pour qu'ils soient lisibles par un humain (nm -C !!) mais des problèmes d'intégration au runtime.
Le mangling n'étant pas standardisé, chaque compilo utilise le sien propre. Il n'est pas imaginable de linker deux libs binaires produites par deux compilos différents. Si tu compiles tout toi même, pas de problème. Par contre, si tu link sur des libraires externes, en plus de la version de la lib, tu dois gérer un paramètre de dépendance supplémentaire. Eventuellement, si tu récupères une lib binaire dont tu n'as pas les sources, tu te retrouves contraint à l'utilisation du compilateur qui a servi à générer cette lib.
Pire, deux versions différentes d'une même suite de compilation peuvent être incompatibles entre elles (c'est le cas de g++, qui pète régulièrement la compatibilité du mangling).
Côté mise en prod, ça peut aussi être un joyeux boxon. Pour peu que l'infrastructure technique ne soient pas complètement bien contrôlée, et que plusieurs services interviennent …

tu peux toujours utiliser extern "C" pour exporter une interface plus « simple ».

oui, tu peux (en fait t'as pas le choix), mais c'est particulièrement pas objet, et ça tire son lot de contrainte. Tu ne peux pas exposer n'importe quoi via des extern "C", et ça peut demander parfois pas mal de contorsions pour arriver à un truc qui marche.

Ensuite, Python et Java étant des langage objets eux aussi, c'est plus facile de mapper le concept d'objet d'un langage vers l'autre en C++ qu'en C.

Alors là, je demande à voir. Tu vas faire du extern "C" de toute façon.

Le C++ c'est trop difficile à apprendre

"Le C++ est difficile à apprendre" n'est pas un bon argument. Par contre, "le C++ est trop difficile à apprendre", ça se discute. Pour le reformuler, la question est de savoir si le temps que tu vas investir à maîtriser les subtilités du C++ va payer. C'est impossible à mesurer à priori, on ne peut que s'appuyer sur son intuition et ce qu'on peut lire sur le sujet. Si j'avais du faire autre chose que du C il y a 10 ans, j'aurais sûrement fait du C++. Mais aujourd'hui, avec la pléthore de langage qui bénéficie de l'expérience du C++, et notamment des endroits ou le langage s'est un peu fourvoyé, j'aurais pas du tout envie de rentrer dans la complexité C++ (Avis personnel, chacun en pense ce qu'il veut).

Pareil pour le C.

pas tout à fait. Même en écrivant du C++ "non-C" (pas de gestion de mémoire manuelle, utilisation des exceptions et tout ce qu'il faut), il y a plus de fonctionnalités dans C++, et la combinatoire pour mal les utiliser est plus élevée.

Faire des cast de type à tout bout de champ par exemple.

je veux bien un exemple de code avec ce que tu considères être des "cast à tout bout de champs", parce que ça ne me parait pas être une fatalité.

Je ne dis pas que le C est supérieur au C++ (ça serait crétin). Il est indéniable que le C++ permet, pour ceux qui le maîtrisent, de développer beaucoup plus vite qu'en C. Il y a même des situations ou du code en C++ tourne plus vite que du C. Mais le C++ est un langage exigeant. La migration du C au C++ n'est pas indolore, voire coûteuse. Faut voir si ça vaut le coup ou pas. Je ne dis pas autre chose (même s'il m'a fallu plein de mots pour en arriver là).

En mettant de côté le fait que je n'aime pas le C++, je vois d'autres contextes ou choisir le C par rapport au C++ à du sens:
- une base de code existe déjà en C pour le projet,
- on a besoin de portabilité,
- une librairie dynamique (les problèmes de mangling en C++, c'est super pénible),
- une librairie qui sera bindée dans plusieurs language de plus haut niveau (Java, C++, Python, …),
- surement d'autres si je me creusais la tête plus longtemps.

Les 3 derniers relèvent un peu du même contexte : besoin d'intégration avec d'autres trucs que du C++

à partir du moment ou tu deviens distributeur de CentOS, tu dois fournir les sources (ou les avoir à dispo pendant 3 ans). Tu ne peux pas te contenter de dire "ben allez les chercher là bas". D'autant que les repository bougent tous les jours, mais pas la VM que tu fournis au départ.

j'y ai repensé, et je suis d'accord, je ne vois pas de problèmes de licence fondamental.
Mais il faut quand même fournir les sources de CentOS (avec l'infrastructure de build aussi, non ?) et ça, ça doit quand même être un peu pénible. Il faut aussi probablement ajouter touts les mentions légales nécessaires au produit final "VM + soft proprio" (genre mention des licences qui l'exigent, il y a des licences libres autre que la GPL dans CentOS)

Il est aujourd'hui ridicule de choisir le C face au C++.

Chaque langage a ses forces et ses faiblesses. Pour une tâche donnée, certains langages seront mieux adaptés que d'autres. Le fait qu'un langage soit "multi-paradigmes" ne suffit pas à le qualifier comme langage idéal pour tous les besoins. Python aussi est multi paradigmes (et j'aime beaucoup le python), c'est par pour ça que je vais en mettre partout.

La citation pertinente :

Quand ton seul outil est un marteau, tout ressemble à un clou

et la trollesque :

quand ton marteau est c++, tout ressemble à un doigt

Ca fait pas avancer le débat, mais c'est aussi constructif que ta première phrase (plus constructif même, parce qu'il y a un marteau dedans ;-) )

Disclaimer : je ne nie pas les apports du C++ au monde du développement, mais c'est un langage que je n'aime pas (pour tout un tas de raisons).

Le C++ n'est pas du "C avec des syntaxes en plus pour faire de l'objet". L'approche "je migre en C++ en n'utilisant que l'héritage" me parait super casse gueule. Très probablement, à un moment, va se présenter un problème qui nécessitera de rentrer plus profondément dans le langage (et pleurer ?! :) ).

j'ajoute deux liens :

• tout l'article est passionnant, mais j'en extrait ce qui est peut-être le plus pertinent pour un débutant en C++:

C++ has become an extremely complex language. There are countless ways of doing the same thing — almost all of them either plain wrong, dangerous, unmaintainable, or all of the above. The problem is that most code compiles and even runs.

et même, soyons fou, je propose une traduction :

C++ est devenu un langage extrêmement complexe. Il y a d'innombrables façons de faire une même chose — presque toutes sont complètement fausses, ou dangereuses, ou non maintenables, voire les trois en même temps. Le problème, c'est que la plupart du code compile, et même s'exécute.

• un article de Rob Pike (co-créateur de Go) se demandant pourquoi il n'y a pas plus de développeurs C++ qui s'intéressent à Go. tl; dr: il y a trop de fonctionnalités dans C++

Sur ce cas précis, le comportement du noyau est réglable via /proc/sys/vm/overcommit_memory

la question me parait tout à fait légitime. La plupart des licences libres (en tout cas GPL like) entrent en oeuvre au moment de la redistribution.

oui mais la CE, c'est pas le clampin moyen :-)

j'ai répondu plus longuement à ton premier message sur la question. Evitons de mélanger les fils !