Krunch a écrit 3959 commentaires

Ben on est au moins trois alors.

Faire bien attention si on utilise des masques ACL ou des paramètres default. Dans ce cas ca couvre les droits des utilisateurs non propriétaires.

D'ailleurs apparement getfacl sous Linux l'indique en commentaire dans ce cas. Par exemple :

user::rw-
user:foobar:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

ddd supporte les breakpoints conditionnels apparement. C'est pas très joli mais c'est à la souris (avec possibilité d'entrer des commandes gdb à la main quand même).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

pas envie de repasser 3500 fois dans la même méthode pour arriver jusqu'au 3500ieme pattern qui provoque le bug

J'ai pas vu le code/bug concerné mais tu sais que tu peux mettre des conditions sur les breakpoints ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est pas tellement la compilation en elle même qui fait perdre du temps mais plutôt le fait d'éditer pour rajouter/enlever les printf et parfois l'exécution.

Pour le debug de code concurrent, c'est toujours bien chiant mais les printf ont tendance à heisenbugger assez bien aussi dans ce cas. J'ai plutôt l'impression que la solution est d'utiliser un debugger système du genre de dtrace (qui fait plus du logging que du debugging proprement dit d'ailleurs).

Le problème c'est que bien souvent on printf debug rien que pour savoir si on est arrivé à un endroit dans le code alors qu'on peut aussi bien le faire plus rapidement avec un debugger sans avoir à modifier le code. S'il est vraiment intéressant de savoir régulièrement si un est passé par un endroit donné, alors autant laisser un debug() en permanence.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

s/write(1)/write(2)/ bien sûr.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est ce dont je parle en disant :

les systèmes de cache la rendent souvent inutile si on n'en tient pas compte

Si on veut se passer de fflush(3) et de write(1) (qui est moins portable), on peut faire un coup de setbuf(stdout, NULL) au début ou utiliser stderr qui n'est pas bufferisé par défaut.

moi j'aimais bien le debug à coup de PRINTF, ca permettait de commenter le code tout en générant des logs compréhensibles pour les autres développeurs

Relis ma définition :

J'appelle « printf debugging » le fait d'ajouter du code temporaire dans le seul but de débugger du code existant.

Ce que tu fais j'appelle ça du logging.

Par ailleurs, pour répondre à galactikboulay, le fait que printf(3) flush à chaque "\n" n'est sans doute pas très standard.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben c'est un peu le principe des mods que les joueurs de HL, Quake, UT et autres connaissent bien. Pour les autres je suis pas sûr mais pour UT on me dit que les « règles » du jeu de base sont disponibles aussi et qu'elles sont modifiables sans outil tiers. UT2004 n'est sans doute pas le premier jeu à faire ça non plus d'ailleurs.

http://download.beyondunreal.com/browse.php?dir=official/ut2(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est plutôt l'inverse ça. Les règles du jeu font partie des données qu'on fournit au moteur pour qu'il produise le jeu. Par ailleurs ça m'étonnerait quand même que ces règles soient sous une licence libre. Si c'est le cas, j'imagine qu'il y a des quelque part des gens qui sont en train d'écrire (ou ont déjà écrit) de quoi les convertir dans un format utilisable par Freeciv.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben oui, et donc au lieu de « throw new Error(); » tu peux aussi bien dire « abort(); ». Ca permet de tracer aussi précisement l'origine du problème mais c'est plus efficace et ça reste utilisable dans les langages qui ne supportent pas les exceptions. Ou bien tu parlais d'exceptions non fatales mais alors je vois pas le rapport.

Au passage, si on veut vraiment, en C aussi on peut avoir des exceptions : http://www.freetype.org/david/reliable-c.html
Et plein d'autres trucs d'ailleurs : http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html http://developer.gnome.org/doc/API/2.0/gobject/index.html

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je dirais plutôt que le fait que ce texte n'existe pas est une observation. Une conclusion serait par exemple que tu es le seul bon programmeur sur le net. Une autre serait qu'utiliser des printfs pour debuger un programme est considéré comme tout à fait correct par la majorité des programmeurs.

C'est pas parce qu'un tel article existerait déjà que celui qui l'aurait écrit serait un bon programmeur. Il y a plein d'articles très mauvais écrits par des mauvais programmeurs. Que cet article ci soit bon ou non, c'est au lecteur de juger mais si l'article existait déjà je n'aurais pas eu à l'écrire. L'intérêt de l'avoir écrit c'est que maintenant qu'il existe, j'aurai juste à ressortir le lien quand le sujet sortira dans une conversation plutôt que d'expliquer mon point de vue pour la 42ème fois.

utiliser un debugger apporte aussi son lot d'inconvénients et n'est pas forcement un meilleur choix.

D'ailleurs, pour trouver un bug, même les solutions les pires sont acceptables si les meilleures n'ont rien donné...

C'est bien comme ça que je l'entend. Il n'y a pas de solution miracle. Mon journal tente de montrer au programmeur débutant qui ne connait que le printf debugging les limites de cette méthode.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

À la base, techniquement, au niveau sécurité, j'ai un peu de mal à voir en quoi Windows NT et ses descendants sont moins bien conçus que Unix/Linux. Les systèmes de privilèges ont l'air assez similaires en fin de compte. J'ai plutôt l'impression que les problèmes de virus de Windows sont dûs à une configuration par défaut trop laxiste, des utilisateurs qui ne comprennent pas ce qu'ils font et une grande distribution de l'OS (ce qui augmente la motivation des attaquants).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

[Microsoft, ] si soucieux de son image

Si c'était le cas ça se saurait. Tu confondrais pas avec Apple par hasard ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

$ awk -F: '$1 ~ /^plop$/ { print "cet identifiant existe" }' < /etc/passwd

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

La libc GNU permet aussi d'avoir un backtrace depuis le programme lui même (sans fork()er gdb par contre). Personnellement je trouve ça assez gadget. Pourquoi rajouter du code si on peut le faire avec un programme externe (et quelques lignes dans le Makefile si on est vraiment fainéant) ?

http://www.gnu.org/software/libc/manual/html_node/Backtraces(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben il dit bien qu'il sait se servir de gdb et qu'il l'utilise tout le temps. Juste qu'il l'utilise pas n'importe comment.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un peu comme le « Avoid debuggers » de hacknot.info :

I've noticed that habitual use of symbolic debuggers also tends to discourage serious reflection on the problem. It becomes a knee-jerk response to fire up the debugger the instant a bug is encountered and start stepping through code, waiting for the debugger to reveal where the fault is.

Un debugger n'est pas une solution miracle non plus, c'est qu'un outil qui peut aider quand on l'utilise intelligemment (j'ai aussi l'impression que « single-stepper » est rarement un bon moyen de trouver un bug). Dans le mail de Torvalds je ne vois pas non plus où il dit que le printf debugging c'est supair.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Non t'as raison j'ai oublié de passer le fichier en argument à vi.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pas besoin d'exceptions pour avoir un backtrace sans relancer le programme. En C, une fois que t'as ton coredump, un passage par gdb suffit pour retrouver l'endroit du segfault ou de l'abort(3) (assert(3) appelle abort(3) quand son argument est faux).

Concernant les exceptions, je recommande les lectures suivantes :
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/03/17/397468.(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Par contre $() est spécifique à Bash alors que `` est censé être disponible sur tout shell compatible sh.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Voilà https://linuxfr.org/~Krunch/22577.html

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Personnellement je pense que le principal intérêt des jeux vidéo libres est leur durée de vie. La plupart des jeux propriétaires n'ont des utilisateurs que pendant une durée relativement courte (2 ou 3 ans ?) alors qu'un jeu libre abouti est joué pendant bien plus longtemps.

Une raison pour cela est que la distribution du jeu coûte de l'argent à l'éditeur et après un certains temps, vendre un jeu coûte plus d'argent qu'il n'en rapporte. Ce facteur a tendance à s'estomper avec les systèmes de distribution en ligne (Steam,...) mais il est virtuellement inexistant pour les jeux libres gratuits.

Même en faisant abstraction du coût de la distribution, lorsqu'un jeu n'est pas maintenu, il devient rapidement inutilisable sur les nouvelles plateformes. Je ne suis sans doute pas le seul a avoir quelques jeux au fond d'une armoire auxquels j'aimerais bien pouvoir rejouer mais qui ne tournent pas sur autre chose que Windows 9x. Bien sûr il existe des projets (dosemu, wine,...) permettant de pallier à ce problème avec plus ou moins de succès mais c'est rarement la panacée. D'un autre côté, un jeu libre sera toujours jouable sur la plateforme du moment tant qu'il y aura au moins une personne assez motivée pour vouloir y jouer. Enfin, en théorie. En pratique il faut quand même un certains nombre de personnes techniquement compétentes mais ça reste possible bien plus facilement que pour un jeu propriétaire.

Une alternative qui me semble viable est de garder le jeu sous une licence propriétaire pendant quelques années avant de le passer sous une licence libre pour la postérité. C'est un peu ce que fait id Software mais de manière encore un peu trop limitée à mon goût puisque les données restent sous licence propriétaire.

À noter que cet argumentaire reste valable pour les logiciels qui ne sont pas des jeux mais j'ai l'impression que les logiciels « classiques » sont beaucoup plus interchangeables que les jeux. Et puis en pratique les logiciels propriétaires « classiques » ont généralement une durée de vie bien plus correcte que celle des jeux propriétaires.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et l'Artistic License elle compte pas non plus ? http://dev.perl.org/licenses/artistic.html

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Lisp + Perl = Haskell

Sinon dans la liste des langage intéressants qu'il faudrait que j'apprenne un jour il y a Erlang, Objective-C et Smalltalk.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un autre gestionnaire de fenêtres dans la même veine que Ion mais qui pousse l'idée un peu plus loin : WMII http://wmii.de/wmii/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est à mettre dans le Makefile (CFLAGS += -D_XOPEN_SOURCE=500), pas dans le code.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.