La dépêche est intéressante, mais si on s'intéresse à ces systèmes en tant que langages de programmation, on reste un peu sur sa faim.
Ce système a-t-il des concepts ou des fonctionnalités spécifiques qui rendent plus faciles et agréables l'écriture des jeux ?
Quelles sont les différences principales avec Inform ?
Comme on peut lire le code source, je suis allé jeter un œil.
D'habitude, je suis effaré par le code source des applications utilisant PHP. Ce qui me gêne en priorité c'est l'absence totale de gestion responsable du flot de contrôle et des effets de bord : chaque page initialise tout ce qui bouge comme si elle était la seule sur terre, et quand on veut de la modularité on fout un "include" et on prie pour que la page incluse ne fasse pas tout péter parce que les paramètres de session ne lui plaisent pas.
Dans votre projet, le flot de contrôle (l'ordre des actions quand on demande une page) est caché par l'utilisation de Zend (je ne connais pas le framework, donc pour moi tout est caché au milieu d'une myriade de MVC, middleware, dynamic class loading, etc. etc.), par contre le découpage du code en parties indépendantes est assez raisonnable, avec l'utilisation de POO en grande quantité. Je trouve toujours curieux de voir des classes qui mélangent logique de jeu (règle, etc.) et une fonction "render" qui fait des regexp replace pour supprimer les espaces inutiles, mais c'est un choix comme un autre.
Bref, je trouve l'organisation globale du code plutôt bien.
Par contre, dans les détails, le code est par endroit un peu bof. Une fois qu'on retire tout le boilerplate lié à l'utilisation des templates, la récupération des données dans la base, etc., il y a des passages franchement pas terribles comme (dans library/Bral/Cueillir.php) :
Attention, je voudrais pas qu'on interprète mal ma remarque : je trouve le code dans l'ensemble plutôt correct, mieux que la moyenne de ce qu'on trouve en PHP sur le net. C'est juste qu'il est franchement améliorable par endroits, et comme je suis tout content que le code soit disponible en ligne je m'empresse de trouver un truc à commenter en espérant qu'il soit amélioré un jour.
La première chose qui me frappe quand je parcours le site, c'est le soin des détails. Les graphismes sont sympas, et plus généralement le contenu autour du jeu est agréable : le style d'écriture vaguement vieillot est cohérent, etc.
Un jeu libre, qui a l'air sympa, et qui soigne ces choses là, bravo !
Un détail : sur le site, l'aspect libre du jeu, bien que présent (si on clique sur "Le Projet", on a un historique remplit des détails techniques sans grand intérêt, la présentation de l'équipe (bien), et en tout petit un lien vers le code source), n'est vraiment pas mis en avant. C'est un choix comme un autre, mais ça me fait penser que vous n'encouragez pas trop la participation de la communauté.
J'imagine que c'est surtout un truc développé en petit groupe, et que les joueurs eux-mêmes ne participent pas directement au développement (et n'ont pas forcément conscience de cette possibilité). C'est compréhensible, car entretenir un développement ouvert (et pas seulement un résultat ouvert) demande du travail en plus, et on peut préférer se concentrer sur d'autres choses, mais c'est peut-être un peu dommage.
Le drame sur LinuxFR c'est qu'il est difficile de faire une news plus agréable et intéressante que les release Linux. Je pense que celle-ci y est arrivé.
Tiré de la FAQ : "SCOAP3 aims to convert to Open Access the vast majority of the literature of the field."
J'espère que ce genre d'initiatives se généraliseront à d'autres domaines de la recherche.
J'ai joué à traduire quelques phrases, c'est assez amusant, voire un peu grisant. On traduit quelques phrases, puis on redemande des phrases au hasard, on traduit, etc. Au vu des "dernières contributions", on dirait que je ne suis pas le seul.
Note technique : Je n'ai pas trouvé l'option de recherche « afficher les phrases en <telle langue> qui ne sont *pas* traduites en <telle langue> », bien qu'elle soit mentionnée comme présente dans le bugtracker. Elle me serait assez utile pour chercher des phrases à traduire.
Posté par gasche .
En réponse à la dépêche Python 2.7.
Évalué à 2.
Attention avec l'exemple du CSV : l'ordre d'un OrderedDict est l'ordre d'insertion dans le dictionnaire. Quand tu reçois deux OrderedDict avec les mêmes clés, tu ne peux pas supposer que l'ordre sera le même.
Python 3.1.2 (r312:79147, Mar 21 2010, 18:30:25)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> header = OrderedDict([('a', 'Nom de la colonne A'), ('b', 'Nom de la colonne B')])
>>> line = OrderedDict()
>>> line['b'] = 'Valeur pour B'
>>> line['a'] = 'Valeur pour A'
>>> for h in header.values(): print(h)
...
Nom de la colonne A
Nom de la colonne B
>>> for v in line.values(): print(v)
...
Valeur pour B
Valeur pour A
Il me semble qu'il faut repasser par un tri explicite des entrées du dictionnaire / de la liste, dans tous les cas.
Posté par gasche .
En réponse à la dépêche Python 2.7.
Évalué à 3.
Il me semble qu'OrderedDict ne permet pas d'associer un ordre (choisi par le programmeur) aux clés, mais se contente de conserver l'ordre d'insertion. En tout cas, c'est ce qu'indique la PEP 372 :
« Does OrderedDict support alternate sort orders such as alphabetical?
No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »
Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.
Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.
Posté par gasche .
En réponse à la dépêche Python 2.7.
Évalué à 4.
Justement, au sujet des dictionnaires ordonnés : en quoi est-ce une bonne fonctionnalité ?
Disclaimer : je ne suis pas un programmeur Python, donc je n'ai pas en tête les utilisations idiomatiques du langage.
Je ne comprends pas pourquoi cette fonctionnalité est mise en avant comme quelque chose de tellement bien. Pour moi, un dictionnaire ordonné c'est au mieux une curiosité qui sert une fois par an, au pire une API mutante qui encourage de mauvaises pratiques.
J'ai suivi le lien pour la PEP (merci pour le lien), et certaines des raisons qui sont données (paraphrasées selon ce que j'en comprends) me laissent un peu perplexe
- quand on manipule des noeuds XML, on veut stocker les attributs dans un dictionnaire, mais qu'ils restent dans l'ordre : il me semble que d'après la définition de XML, les attributs ne sont pas ordonnés, et qu'il est donc une mauvaise pratique de dépendre de l'ordre des attributs d'un document XML.
- on veut porter du code depuis PHP qui utilise implicitement le caractère ordonné du dictionnaire : est-ce que le code de départ avait vraiment besoin de l'ordre ? Je comprends l'intérêt de pouvoir porter du code même mal écrit, mais ça fait sourire d'apprendre qu'on va améliorer Python en facilitant l'import de code PHP douteux.
La PEP cite aussi deux exemples crédibles où une telle structure serait utile (les "struct" de C, dont le layout mémoire dépend de l'ordre, et à la rigueur les noms de colonnes SQL bien qu'on les manipule en général de façon non ordonnée).
Je ne pense pas que les dictionnaires ordonnés soient à bannir, mais je pense qu'ils ne sont en général pas nécessaires et qu'ils font souvent plus de mal que de bien (cf. l'exemple des attributs XML qui se contente de perpétuer de mauvaises pratiques). Les mettre dans la stdlib, pourquoi pas, mais je suis étonné de tout le bruit que ça fait, et de l'absence de mise en garde à ce sujet.
Bien sûr, mais j'ai envie de dire que "quand c'est le cas, ça se voit" : ce n'est pas "un langage de programmation moderne qui propose fermetures et des interfaces" mais plutôt "un langage de programmation fonctionnel réactif par contraintes, basé sur un système d'effets et proposant une gestion fine de la stratégie d'évaluation par coercions explicites".
Je trouve que ça manque un peu de tact quand tu évalues le travail de quelqu'un de lui demander d'abord s'il est spécialiste dans le domaine. Soit il l'est, et normalement on s'en rend compte, soit il ne l'est pas et il pourrait se vexer. On peut aussi bien se comporter en fonction du travail seulement, et pas de la personne, et ça évite ce genre d'embarras.
L'intérêt de la documentation, d'une spécification un peu formelle (mais pas forcément complètement) du langage, c'est de pouvoir savoir rapidement ce qu'est votre langage : une énumération exhaustive de ses constructions, et une description précise, par exemple, de son comportement à l'exécution, de ses règles de typage, les algorithmes d'inférence de type et de garbage collection (si ça intéresse des gens : c'est un Boehm GC).
Le parser est un bon départ : tu pourrais le prendre à l'identique, enlever toutes les productions (garder que la partie "grammaire"), et mettre ça sur le site, ça serait déjà un bon progrès.
Ce que j'ai cherché sur votre site, c'est l'analogue de ce document pour Go : The Go Programming Language Specification.
Dans un deuxième temps, je serais intéressé par un condensé d'informations sur les nouveautés du langage et les choix que vous avez fait. Pour Go, c'est ce document : Language Design FAQ.
J'ai effectivement remarqué le sens de l'humour (entre nous, je me demande si le "THREE FUCKING TIMES" ne risque pas de rebuter certains anglophones, c'est quand même un peu vulgaire), ça a son charme, mais je trouve le texte en page d'accueil trop long et trop verbeux : quand on regarde 5 minutes un nouveau langage, on a besoin de quelque chose de plus dense et informatif. Le "Poignant guide to Ooc", c'est pour dans un second temps.
Par contre, il faut retenir les exemples de code source, c'est une très bonne idée.
Bref, je pense qu'une documentation concise mais précise et complète serait le meilleur moyen, justement, d'éviter les remarques superficielles, en permettant aux gens d'avoir un aperçu en profondeur du langage en un temps raisonnable.
Parce que "prendre la peine de l'essayer", c'est une bonne idée, mais pour pouvoir tout essayer il faut commencer par se renseigner sur tout ce qu'il y a, justement, à essayer; et si on essaie mais passe à côté d'une partie des fonctionnalités, c'est dommage.
Pour revenir au "se prend trop au sérieux" (opposé à l'humeur et la détente dans les docs) : ce que je voulais dire, c'est que quand on va sur le site web, on lit en gros (j'exagère volontairement le trait) « ooc est un roksor langage qui se base sur des techniques ultra-modernes, s'inspire de C, Smalltalk, Java, Ruby et Haskell, qui va résoudre tous vos problèmes en conservant des performances de brute »
On peut considérer ça comme de l'humour, mais moi qui suis bonne poire, je me suis sérieusement attendu à voir tout ce que vous évoquiez dans ce descriptif, et donc forcément j'ai été un peu déçu.
Je pense qu'il vaut mieux se contenter des quelques points clés de votre langage, sans faire de la surenchère.
Par exemple, ooc est compilé vers du C, ça a l'avantage de vous garantir une bonne compatibilité, et c'est bien d'en parler. Par contre, c'est moins bon pour les performances et/ou l'extensibilité du langage : vous ne pouvez plus utiliser un GC exact, difficile d'optimiser la tail-recursion, etc. Il faut en parler aussi.
PS : moi non plus je ne comprends pas la question sur les "doctorants en sémantique"; il n'y a pas besoin d'être un spécialiste de la théorie pour monter son petit langage.
Ce que sous-entendais peut-être la question, c'est qu'il y a eu beaucoup de recherche sur les langages de programmation depuis l'avènement du C, qui est malheureusement assez soigneusement ignorée par la plupart des langages "modernes" de cette catégorie (D, Go, etc.). C'est vrai que c'est dommage, et ooc ne déroge pas à la règle.
Après, moi je trouve que, dans le cas de ooc, c'est compréhensible et même tout à fait normal. C'est ce que j'appelle le point de vue "langage amateur" : il s'agit de se faire plaisir, de s'intéresser à l'implémentation d'un vrai langage, de réfléchir sur certains points (la syntaxe par exemple), etc. Pas de révolutionner le domaine.
Je m'intéresse beaucoup aux langages de programmation, et je vois toujours d'un bon oeil le fait que les gens expérimentent dans le domaine, en travaillant sur une petite implémentation, des idées qu'ils ont pour corriger les problèmes des langages existants, etc.
Je pense donc qu'ooc est une bonne idée (écrire un langage, c'est amusant, donc c'est toujours une bonne idée), et je trouve l'aspect communautaire sympa.
Par contre, je trouve l'approche pas très rigoureuse. Le langage n'est décrit nulle part. J'aimerais bien savoir, par exemple, comment fonctionne l'algorithme d'inférence des types. Je suspecte que c'est un algorithme très ad-hoc (les sources par d'un "funny score system", hmm...); je trouve un peu dommage de parler d'inférence (on pense tout de suite aux langages avec une vraie inférence de type) pour un truc au final plutôt limité, et surtout imprévisible parce que non spécifié : on est un peu déçu.
De même, je trouve dommage de présenter comme "pattern matching" un sucre syntaxique qui ajoute implicitement des tests d'égalité à une variable de 'switch'. Le vrai pattern matching ( http://fr.wikipedia.org/wiki/Filtrage_par_motif ) est beaucoup plus puissant que ça, donc quand on se rend compte de ce que c'est en ooc, on est déçu.
Dans ce contexte (l'inférence n'est pas une vraie inférence, le pattern matching n'est pas un vrai pattern matching, j'espère que vos closures sont de vraies closures !), je pense qu'on peut difficilement décrire ooc comme un langage "functional-ish" : vous avez des fonctions imbriquées et anonymes, c'est bien, c'est mieux que le C, mais le langage ne me semble pas fonctionnel pour autant.
Je pense que la documentation manque un peu de rigueur. J'aimerais bien une description précise et globale du langage quelque part : une description de la syntaxe et de la sémantique du langage. Je pense qu'il serait aussi important de détailler quelque part les raisons qui vous ont poussé à lancer ce projet, une comparaison avec les concurrents (Vala ?), et surtout quelques défauts (temporaires et conceptuels) du langage : c'est bien de présenter ce que vous faites bien, mais il faudrait aussi essayer de dire ce qui est moins bien.
Bien sûr : je ne juge pas votre association qui est certainement très bien; j'ai monté quelques petits projets de traduction avec des amis, et j'ai toujours trouvé ça plutôt sympa, j'imagine dans une association ça doit être une ambiance agréable.
De toute façon, il faut relativiser : ce n'est pas parce que des gens ont un humour déplacé qu'ils sont méchants, bêtes ou incompétents techniquement.
Mon message n'était pas du tout dirigé vers l'association, c'était juste une réaction aux commentaires précédents. J'ai souvent entendu dire que les milieux geeks étaient souvent sexistes sans s'en rendre compte mais je n'ai pas eu souvent l'occasion de le constater. Pour le coup, voir des gens dire au sujet d'une affiche "Linux Loving Sluts" que « toutes les femmes en seront pas choquées » (ce qui est vrai, mais ne change rien), voire même "ça présente une femme administratrice de son système" (ce qui est très con), c'est assez instructif.
Indépendamment des considérations féministes (qui à mon avis ont déjà les voyants au rouge), je trouve la vulgarité de cette affiche choquante. C'est le genre d'humour gras que je n'aime pas.
Si j'avais été sur place, dans le contexte des gens du stand, etc., comme tu dis, je n'aurais peut-être pas protesté (quoique...), mais se souvenir de cette affiche comme un signe positif au sujet de l'association, moi ça me fait plutôt fuir.
Deuxièmement parce qu'ainsi on est sûr que les gens n'ont pas de raison de préférer développer en Flash plutôt qu'avec les technologies propres à chaque machine. La situation avant cette annonce nous laissait envisager Flash comme seule technologie portable… au moins là les gens n'ont pas d'argument technique pour le choisir, et se pencheront donc sûrement plus sur le développement d'applications natives.
Donc les gens vont passer d'un verrou propriétaire plus-ou-moins portable à un verrou propriétaire spécifique à un vendeur de matériel. Chouette.
Du reste, Apple ne se contente pas d'interdire les autres langages, il interdit aussi les API non-Apple :
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Donc ce n'est pas seulement Flash, Scheme, C#, Lua, Mozart/Oz, OCaml, et tous les autres langages qui sont interdits, mais aussi tous les toolkits/frameworks, même codés dans un des langages autorisés, qui ne viennent pas d'Apple.
Je vois mal comment on peut présenter cela d'un point de vue positif. Les seuls qui sont contents, ce sont les développeurs qui utilisent déjà la plateforme vérouillée d'Apple, puisque ça élimine des concurrents...
Je suis curieux au sujet de la Summer Art Scolarship. C'est une initiative intéressante, et je serais intéressé par plus d'information sur les résultats. J'ai survolé les pages facilement accessibles du site à ce sujet, mais elles parlent du projet avant son lancement, et j'aimerais bien des informations plus conclusives.
Peut-on trouver quelque part des images produites par cette initiative, une comparaison rapide avant/après ?
Erratum : je voulais bien sûr "laisser la priorité aux commentaires de fond".
Je me permets de rajouter que je suis tout à fait d'accord avec le point de vue de Thomas Douillard exprimé dans ce commentaire : les points précis sur le libre qui sont discutés ici semblent sans doute naturel aux habitués, mais il est aussi important de comprendre qu'un nouveau venu n'est pas forcément dans le bain, et qu'il peut y réagir différemment.
Je m'en suis rendu compte dans cette dépêche, car le ton insultant de l'auteur m'a fait réagir, d'autant plus que j'avais l'impression que les deux commentaires initiaux ([1] et [2]) qui ont lancé la polémique sur deux points différents étaient très corrects (ou "courtois" comme il est dit plus bas).
En réalité, quand on les relit attentivement, ils ne sont pas très corrects : ils ne sont pas incorrects, mais ils sont quand même très secs, voire même légèrement agaçants dans leur formulation (le "il aurait suffi" de patrick_g fait un peu donneur de leçon, et le "Qu'à la limite... Mais ..." de vermillon font tous les deux un peu "donneur de leçon") .
C'est sans doute involontaire de la part des auteurs de ces commentaires, et d'ailleurs je ne m'en suis moi-même pas rendu compte à première lecture. On est sans doute habitué sur linuxFR à ce ton un peu direct. Peut-être qu'il faudrait faire un peu plus attention la prochaine fois, à formuler ce genre de critiques avec un peu plus de souplesse.
Je pense que sur cette dépêche il a manqué une pointe de diplomatie qui aurait pu éviter le déraillage. Personne n'est particulièrement responsable, mais chacun y a mis un peu du sien (je pense en particulier aux divers commentaires du style "mais on s'en fout de ces libristes pointillistes à la con, on est là pour féliciter l'auteur et tout le reste est une réaction intolérante d'ayatollah branleurs" ), à commencer par l'auteur original qui semble avoir un caractère un peu soupe-au-lait.
Je ne vois pas ce que mon commentaire a de pathétique. Demander le respect des autres dans les commentaires, c'est pathétique ?
L'auteur de la dépêche semble confondre la licence d'une oeuvre et le respect des standards W3C par la page web qui présente cette oeuvre. Je trouve déjà curieux qu'on soit taxé d'extrêmisme (comme l'ont fait certains commentaires ici) si on lui en fait la remarque. Mais je suis d'accord sur le fait que c'est une question plutôt de second plan pour la plupart des gens (mais qui a quand même son importance), et qu'il faut laisser la propriété aux commentaires de fond sur le contenu de l'oeuvre présentée.
Par contre, insulter les gens, essayer de les ridiculiser par un discours ironique et méprisant, voire faire des menaces d'agresssion physique, il me semble que ce n'est pas normal et que ça n'a pas sa place ici, que cela plaise à l'auteur d'un livre ou non.
Je trouve dommage qu'il n'ait à ce point pas supporté la polémique, relativement de second plan devant l'appréciation générale du livre (dont tout le monde lui est reconnaissant, visiblement), mais je ne pense pas qu'il soit « pathétique » de le lui faire remarquer.
Si pour avoir plus de personnes pour poster des dépêches ou des commentaires ici, il faut accepter de se faire insulter ou prendre pour un imbécile, je pense que je préfère me contenter des dépêches de patrick_g sur le noyau Linux, et autres « petits branleurs » ou « donneurs de conseils qui ne connaissent l'informatique qu'à travers le périmètre de leur chambre ».
PS : Par contre, je ne suis pas modérateur sur LinuxFR et je ne connais pas les pratiques de la modération, mais je pense que si l'auteur demande à ce qu'on retire sa dépêche, il faudrait le faire. Le site n'y est sans doute pas obligé, mais ça me semble être une mesure de fair-play, de gérer le contenu selon le désir de son auteur. Je pense donc qu'il serait correct de respecter sa volonté en retirant le texte de la dépêche (mais en laissant les commentaires qui sont la propriété de leurs auteurs respectifs).
Je trouve ta réponse incorrecte. Les deux commentaires que tu critiques n'étaient en aucun cas malveillants, et le deuxième souligne un point relativement important. Ta réponse ( http://linuxfr.org/2010/02/27/26518.html#1108612 ) semble même indiquer que tu n'as pas compris, dans un premier temps, la signification du commentaire en question.
Tout le monde a des mauvaises journées, et tu as tout à fait le droit de passer à côté de la plaque. Le commentaire reste pertinent et intéressent, et malgré tes diverses boutades et répliques farcesques, tu n'as pas répondu sur le fond.
Alors, comme tout le monde l'a dit, choisir une licence non libre pour ton ouvrage (non, CC-BY-NC-ND n'est pas une licence libre, puisqu'elle ne donne ni liberté d'utilisation, ni liberté de modification) est un choix qui ne tient qu'à toi, et tu peux tout à fait le faire, et l'assumer complètement même sur LinuxFR. C'est juste que, pour beaucoup, ce choix en contradiction avec ce que tu dis (esprit de partage de connaissances), d'où les commentaires à ce sujet.
Par contre, ça ne te donne pas le droit d'être incorrect. Tes réponses sont ironiques, souvent méprisantes, voire carrément insultantes. Ce n'est pas parce que tu présentes ton propre travail que tu dois te montrer grossier envers des gens qui font un commentaire constructif.
Tu présentes ton travail sur LinuxFR, et tu obtiens des commentaires de libristes, ça me semble assez naturel. Que tu supportes mal la critique, parfois trop pointilleuse, et que tu réagisses de façon un peu disproportionnée, tout le monde peut le comprendre, c'est un sujet personnel, mais tu devrais éviter de te comporter comme si les autres étaient des idiots bornés.
Dis donc, cette dépêche, elle est détaillée, facile à lire, bien expliquée, chouette quoi. Elle me rappelle un peu les pavés sur le noyau Linux de l'autre, là... patrice_jet.
# Et comment est le langage de programmation ?
Posté par gasche . En réponse à la dépêche WHAT NOW? > Créer des jeux d'aventure avec JACL 2.8.0. Évalué à 1.
Ce système a-t-il des concepts ou des fonctionnalités spécifiques qui rendent plus faciles et agréables l'écriture des jeux ?
Quelles sont les différences principales avec Inform ?
# Et on peut lire le code source !
Posté par gasche . En réponse à la dépêche Braldahim, Jeu Web Libre. Évalué à 3.
D'habitude, je suis effaré par le code source des applications utilisant PHP. Ce qui me gêne en priorité c'est l'absence totale de gestion responsable du flot de contrôle et des effets de bord : chaque page initialise tout ce qui bouge comme si elle était la seule sur terre, et quand on veut de la modularité on fout un "include" et on prie pour que la page incluse ne fasse pas tout péter parce que les paramètres de session ne lui plaisent pas.
Dans votre projet, le flot de contrôle (l'ordre des actions quand on demande une page) est caché par l'utilisation de Zend (je ne connais pas le framework, donc pour moi tout est caché au milieu d'une myriade de MVC, middleware, dynamic class loading, etc. etc.), par contre le découpage du code en parties indépendantes est assez raisonnable, avec l'utilisation de POO en grande quantité. Je trouve toujours curieux de voir des classes qui mélangent logique de jeu (règle, etc.) et une fonction "render" qui fait des regexp replace pour supprimer les espaces inutiles, mais c'est un choix comme un autre.
Bref, je trouve l'organisation globale du code plutôt bien.
Par contre, dans les détails, le code est par endroit un peu bof. Une fois qu'on retire tout le boilerplate lié à l'utilisation des templates, la récupération des données dans la base, etc., il y a des passages franchement pas terribles comme (dans library/Bral/Cueillir.php) :
for ($i=1; $i<=4; $i++) {$tab[$i]["estVide"] = true;
$tab[$i]["quantite"] = 0;
$tab[$i]["id_fk"] = -1;
$cueillette[$i]["quantite"] = 0;
$cueillette[$i]["id_fk"] = -1;
$cueillette[$i]["id_type_plante"] = $plante["id_fk_type_plante"];
if ($i == 1 && $plante["partie_1_plante"] > 0) {
$tab[$i]["id_fk"] = $plante["id_fk_partie_1"];
$tab[$i]["quantite"] = $plante["partie_1_plante"];
$tab[$i]["estVide"] = false;
$cueillette[$i]["id_fk"] = $plante["id_fk_partie_1"];
$cueillette[$i]["nom_partie"] = $plante["nom_partie_1"];
}
if ($i == 2 && $plante["partie_2_plante"] > 0) {
$tab[$i]["id_fk"] = $plante["id_fk_partie_2"];
$tab[$i]["quantite"] = $plante["partie_2_plante"];
$tab[$i]["estVide"] = false;
$cueillette[$i]["id_fk"] = $plante["id_fk_partie_2"];
$cueillette[$i]["nom_partie"] = $plante["nom_partie_2"];
}
if ($i == 3 && $plante["partie_3_plante"] > 0) {
$tab[$i]["id_fk"] = $plante["id_fk_partie_3"];
$tab[$i]["quantite"] = $plante["partie_3_plante"];
$tab[$i]["estVide"] = false;
$cueillette[$i]["id_fk"] = $plante["id_fk_partie_3"];
$cueillette[$i]["nom_partie"] = $plante["nom_partie_3"];
}
if ($i == 4 && $plante["partie_4_plante"] > 0) {
$tab[$i]["id_fk"] = $plante["id_fk_partie_4"];
$tab[$i]["quantite"] = $plante["partie_4_plante"];
$tab[$i]["estVide"] = false;
$cueillette[$i]["id_fk"] = $plante["id_fk_partie_4"];
$cueillette[$i]["nom_partie"] = $plante["nom_partie_4"];
}
}
Attention, je voudrais pas qu'on interprète mal ma remarque : je trouve le code dans l'ensemble plutôt correct, mieux que la moyenne de ce qu'on trouve en PHP sur le net. C'est juste qu'il est franchement améliorable par endroits, et comme je suis tout content que le code soit disponible en ligne je m'empresse de trouver un truc à commenter en espérant qu'il soit amélioré un jour.
# Chouette, un jeu libre avec des graphismes et une interface soignée
Posté par gasche . En réponse à la dépêche Braldahim, Jeu Web Libre. Évalué à 6.
Un jeu libre, qui a l'air sympa, et qui soigne ces choses là, bravo !
Un détail : sur le site, l'aspect libre du jeu, bien que présent (si on clique sur "Le Projet", on a un historique remplit des détails techniques sans grand intérêt, la présentation de l'équipe (bien), et en tout petit un lien vers le code source), n'est vraiment pas mis en avant. C'est un choix comme un autre, mais ça me fait penser que vous n'encouragez pas trop la participation de la communauté.
J'imagine que c'est surtout un truc développé en petit groupe, et que les joueurs eux-mêmes ne participent pas directement au développement (et n'ont pas forcément conscience de cette possibilité). C'est compréhensible, car entretenir un développement ouvert (et pas seulement un résultat ouvert) demande du travail en plus, et on peut préférer se concentrer sur d'autres choses, mais c'est peut-être un peu dommage.
# Magnifique
Posté par gasche . En réponse à la dépêche Les résultats du LHC sous licence Creative Commons. Évalué à 7.
Tiré de la FAQ : "SCOAP3 aims to convert to Open Access the vast majority of the literature of the field."
J'espère que ce genre d'initiatives se généraliseront à d'autres domaines de la recherche.
# Amusant à petite dose
Posté par gasche . En réponse à la dépêche Tatoeba.org, base de données de phrases d'exemple. Évalué à 3.
Note technique : Je n'ai pas trouvé l'option de recherche « afficher les phrases en <telle langue> qui ne sont *pas* traduites en <telle langue> », bien qu'elle soit mentionnée comme présente dans le bugtracker. Elle me serait assez utile pour chercher des phrases à traduire.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . En réponse à la dépêche Python 2.7. Évalué à 2.
Python 3.1.2 (r312:79147, Mar 21 2010, 18:30:25)[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> header = OrderedDict([('a', 'Nom de la colonne A'), ('b', 'Nom de la colonne B')])
>>> line = OrderedDict()
>>> line['b'] = 'Valeur pour B'
>>> line['a'] = 'Valeur pour A'
>>> for h in header.values(): print(h)
...
Nom de la colonne A
Nom de la colonne B
>>> for v in line.values(): print(v)
...
Valeur pour B
Valeur pour A
Il me semble qu'il faut repasser par un tri explicite des entrées du dictionnaire / de la liste, dans tous les cas.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . En réponse à la dépêche Python 2.7. Évalué à 3.
« Does OrderedDict support alternate sort orders such as alphabetical?
No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »
Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.
Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . En réponse à la dépêche Python 2.7. Évalué à 4.
Disclaimer : je ne suis pas un programmeur Python, donc je n'ai pas en tête les utilisations idiomatiques du langage.
Je ne comprends pas pourquoi cette fonctionnalité est mise en avant comme quelque chose de tellement bien. Pour moi, un dictionnaire ordonné c'est au mieux une curiosité qui sert une fois par an, au pire une API mutante qui encourage de mauvaises pratiques.
J'ai suivi le lien pour la PEP (merci pour le lien), et certaines des raisons qui sont données (paraphrasées selon ce que j'en comprends) me laissent un peu perplexe
- quand on manipule des noeuds XML, on veut stocker les attributs dans un dictionnaire, mais qu'ils restent dans l'ordre : il me semble que d'après la définition de XML, les attributs ne sont pas ordonnés, et qu'il est donc une mauvaise pratique de dépendre de l'ordre des attributs d'un document XML.
- on veut porter du code depuis PHP qui utilise implicitement le caractère ordonné du dictionnaire : est-ce que le code de départ avait vraiment besoin de l'ordre ? Je comprends l'intérêt de pouvoir porter du code même mal écrit, mais ça fait sourire d'apprendre qu'on va améliorer Python en facilitant l'import de code PHP douteux.
La PEP cite aussi deux exemples crédibles où une telle structure serait utile (les "struct" de C, dont le layout mémoire dépend de l'ordre, et à la rigueur les noms de colonnes SQL bien qu'on les manipule en général de façon non ordonnée).
Je ne pense pas que les dictionnaires ordonnés soient à bannir, mais je pense qu'ils ne sont en général pas nécessaires et qu'ils font souvent plus de mal que de bien (cf. l'exemple des attributs XML qui se contente de perpétuer de mauvaises pratiques). Les mettre dans la stdlib, pourquoi pas, mais je suis étonné de tout le bruit que ça fait, et de l'absence de mise en garde à ce sujet.
[^] # Re: Bench entre GCC et LLVM
Posté par gasche . En réponse au journal Clang++ est prêt. Évalué à 3.
http://www.phoronix.com/scan.php?page=article&item=gcc_l(...)
[^] # Re: Bench entre GCC et LLVM
Posté par gasche . En réponse au journal Clang++ est prêt. Évalué à 2.
[^] # Re: Quelques questions de béotiens
Posté par gasche . En réponse à la dépêche Haiku R1/Alpha 2 est enfin disponible; 7 projets GSoC à venir. Évalué à 5.
« Béotien : utilisateur de BeOS. »
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 8.
Je trouve que ça manque un peu de tact quand tu évalues le travail de quelqu'un de lui demander d'abord s'il est spécialiste dans le domaine. Soit il l'est, et normalement on s'en rend compte, soit il ne l'est pas et il pourrait se vexer. On peut aussi bien se comporter en fonction du travail seulement, et pas de la personne, et ça évite ce genre d'embarras.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 2.
Go Language Specification : http://golang.org/doc/go_spec.html
Go Language Design FAQ : http://golang.org/doc/go_lang_faq.html
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 7.
Le parser est un bon départ : tu pourrais le prendre à l'identique, enlever toutes les productions (garder que la partie "grammaire"), et mettre ça sur le site, ça serait déjà un bon progrès.
Ce que j'ai cherché sur votre site, c'est l'analogue de ce document pour Go : The Go Programming Language Specification.
Dans un deuxième temps, je serais intéressé par un condensé d'informations sur les nouveautés du langage et les choix que vous avez fait. Pour Go, c'est ce document : Language Design FAQ.
J'ai effectivement remarqué le sens de l'humour (entre nous, je me demande si le "THREE FUCKING TIMES" ne risque pas de rebuter certains anglophones, c'est quand même un peu vulgaire), ça a son charme, mais je trouve le texte en page d'accueil trop long et trop verbeux : quand on regarde 5 minutes un nouveau langage, on a besoin de quelque chose de plus dense et informatif. Le "Poignant guide to Ooc", c'est pour dans un second temps.
Par contre, il faut retenir les exemples de code source, c'est une très bonne idée.
Bref, je pense qu'une documentation concise mais précise et complète serait le meilleur moyen, justement, d'éviter les remarques superficielles, en permettant aux gens d'avoir un aperçu en profondeur du langage en un temps raisonnable.
Parce que "prendre la peine de l'essayer", c'est une bonne idée, mais pour pouvoir tout essayer il faut commencer par se renseigner sur tout ce qu'il y a, justement, à essayer; et si on essaie mais passe à côté d'une partie des fonctionnalités, c'est dommage.
Pour revenir au "se prend trop au sérieux" (opposé à l'humeur et la détente dans les docs) : ce que je voulais dire, c'est que quand on va sur le site web, on lit en gros (j'exagère volontairement le trait) « ooc est un roksor langage qui se base sur des techniques ultra-modernes, s'inspire de C, Smalltalk, Java, Ruby et Haskell, qui va résoudre tous vos problèmes en conservant des performances de brute »
On peut considérer ça comme de l'humour, mais moi qui suis bonne poire, je me suis sérieusement attendu à voir tout ce que vous évoquiez dans ce descriptif, et donc forcément j'ai été un peu déçu.
Je pense qu'il vaut mieux se contenter des quelques points clés de votre langage, sans faire de la surenchère.
Par exemple, ooc est compilé vers du C, ça a l'avantage de vous garantir une bonne compatibilité, et c'est bien d'en parler. Par contre, c'est moins bon pour les performances et/ou l'extensibilité du langage : vous ne pouvez plus utiliser un GC exact, difficile d'optimiser la tail-recursion, etc. Il faut en parler aussi.
PS : moi non plus je ne comprends pas la question sur les "doctorants en sémantique"; il n'y a pas besoin d'être un spécialiste de la théorie pour monter son petit langage.
Ce que sous-entendais peut-être la question, c'est qu'il y a eu beaucoup de recherche sur les langages de programmation depuis l'avènement du C, qui est malheureusement assez soigneusement ignorée par la plupart des langages "modernes" de cette catégorie (D, Go, etc.). C'est vrai que c'est dommage, et ooc ne déroge pas à la règle.
Après, moi je trouve que, dans le cas de ooc, c'est compréhensible et même tout à fait normal. C'est ce que j'appelle le point de vue "langage amateur" : il s'agit de se faire plaisir, de s'intéresser à l'implémentation d'un vrai langage, de réfléchir sur certains points (la syntaxe par exemple), etc. Pas de révolutionner le domaine.
[^] # Re: Joli
Posté par gasche . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 6.
Quel est le lien entre les 'list comprehensions' et l'évaluation paresseuse ?
# Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . En réponse à la dépêche Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0. Évalué à 10.
Je pense donc qu'ooc est une bonne idée (écrire un langage, c'est amusant, donc c'est toujours une bonne idée), et je trouve l'aspect communautaire sympa.
Par contre, je trouve l'approche pas très rigoureuse. Le langage n'est décrit nulle part. J'aimerais bien savoir, par exemple, comment fonctionne l'algorithme d'inférence des types. Je suspecte que c'est un algorithme très ad-hoc (les sources par d'un "funny score system", hmm...); je trouve un peu dommage de parler d'inférence (on pense tout de suite aux langages avec une vraie inférence de type) pour un truc au final plutôt limité, et surtout imprévisible parce que non spécifié : on est un peu déçu.
De même, je trouve dommage de présenter comme "pattern matching" un sucre syntaxique qui ajoute implicitement des tests d'égalité à une variable de 'switch'. Le vrai pattern matching ( http://fr.wikipedia.org/wiki/Filtrage_par_motif ) est beaucoup plus puissant que ça, donc quand on se rend compte de ce que c'est en ooc, on est déçu.
Dans ce contexte (l'inférence n'est pas une vraie inférence, le pattern matching n'est pas un vrai pattern matching, j'espère que vos closures sont de vraies closures !), je pense qu'on peut difficilement décrire ooc comme un langage "functional-ish" : vous avez des fonctions imbriquées et anonymes, c'est bien, c'est mieux que le C, mais le langage ne me semble pas fonctionnel pour autant.
Je pense que la documentation manque un peu de rigueur. J'aimerais bien une description précise et globale du langage quelque part : une description de la syntaxe et de la sémantique du langage. Je pense qu'il serait aussi important de détailler quelque part les raisons qui vous ont poussé à lancer ce projet, une comparaison avec les concurrents (Vala ?), et surtout quelques défauts (temporaires et conceptuels) du langage : c'est bien de présenter ce que vous faites bien, mais il faudrait aussi essayer de dire ce qui est moins bien.
[^] # Re: Affiche
Posté par gasche . En réponse à la dépêche Un nouveau souffle pour Traduc.org. Évalué à 1.
De toute façon, il faut relativiser : ce n'est pas parce que des gens ont un humour déplacé qu'ils sont méchants, bêtes ou incompétents techniquement.
Mon message n'était pas du tout dirigé vers l'association, c'était juste une réaction aux commentaires précédents. J'ai souvent entendu dire que les milieux geeks étaient souvent sexistes sans s'en rendre compte mais je n'ai pas eu souvent l'occasion de le constater. Pour le coup, voir des gens dire au sujet d'une affiche "Linux Loving Sluts" que « toutes les femmes en seront pas choquées » (ce qui est vrai, mais ne change rien), voire même "ça présente une femme administratrice de son système" (ce qui est très con), c'est assez instructif.
[^] # Re: Affiche
Posté par gasche . En réponse à la dépêche Un nouveau souffle pour Traduc.org. Évalué à 2.
Si j'avais été sur place, dans le contexte des gens du stand, etc., comme tu dis, je n'aurais peut-être pas protesté (quoique...), mais se souvenir de cette affiche comme un signe positif au sujet de l'association, moi ça me fait plutôt fuir.
[^] # Re: Restriction du choix des langages sur l'iPhone
Posté par gasche . En réponse à la dépêche Panaché de brèves informatiques de la semaine. Évalué à 7.
Donc les gens vont passer d'un verrou propriétaire plus-ou-moins portable à un verrou propriétaire spécifique à un vendeur de matériel. Chouette.
Du reste, Apple ne se contente pas d'interdire les autres langages, il interdit aussi les API non-Apple :
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Donc ce n'est pas seulement Flash, Scheme, C#, Lua, Mozart/Oz, OCaml, et tous les autres langages qui sont interdits, mais aussi tous les toolkits/frameworks, même codés dans un des langages autorisés, qui ne viennent pas d'Apple.
Je vois mal comment on peut présenter cela d'un point de vue positif. Les seuls qui sont contents, ce sont les développeurs qui utilisent déjà la plateforme vérouillée d'Apple, puisque ça élimine des concurrents...
# Résultats de la Summer Art Scholarship ?
Posté par gasche . En réponse à la dépêche Publication de la version 1.8 de Battle For Wesnoth. Évalué à 4.
Peut-on trouver quelque part des images produites par cette initiative, une comparaison rapide avant/après ?
[^] # Re: Protection de Linux ? ou GNU/Linux ?
Posté par gasche . En réponse à la dépêche Script de test des mesures de protection pour Linux. Évalué à 10.
En plus, la licence est moisie, c'est une BSD avec clause de publicité !
[^] # Re: Réponse aux deux premiers commentaires
Posté par gasche . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 3.
Je me permets de rajouter que je suis tout à fait d'accord avec le point de vue de Thomas Douillard exprimé dans ce commentaire : les points précis sur le libre qui sont discutés ici semblent sans doute naturel aux habitués, mais il est aussi important de comprendre qu'un nouveau venu n'est pas forcément dans le bain, et qu'il peut y réagir différemment.
Je m'en suis rendu compte dans cette dépêche, car le ton insultant de l'auteur m'a fait réagir, d'autant plus que j'avais l'impression que les deux commentaires initiaux ([1] et [2]) qui ont lancé la polémique sur deux points différents étaient très corrects (ou "courtois" comme il est dit plus bas).
En réalité, quand on les relit attentivement, ils ne sont pas très corrects : ils ne sont pas incorrects, mais ils sont quand même très secs, voire même légèrement agaçants dans leur formulation (le "il aurait suffi" de patrick_g fait un peu donneur de leçon, et le "Qu'à la limite... Mais ..." de vermillon font tous les deux un peu "donneur de leçon") .
[1] http://linuxfr.org/comments/1108589.html#1108589
[2] http://linuxfr.org/comments/1108591.html#1108591
C'est sans doute involontaire de la part des auteurs de ces commentaires, et d'ailleurs je ne m'en suis moi-même pas rendu compte à première lecture. On est sans doute habitué sur linuxFR à ce ton un peu direct. Peut-être qu'il faudrait faire un peu plus attention la prochaine fois, à formuler ce genre de critiques avec un peu plus de souplesse.
Je pense que sur cette dépêche il a manqué une pointe de diplomatie qui aurait pu éviter le déraillage. Personne n'est particulièrement responsable, mais chacun y a mis un peu du sien (je pense en particulier aux divers commentaires du style "mais on s'en fout de ces libristes pointillistes à la con, on est là pour féliciter l'auteur et tout le reste est une réaction intolérante d'ayatollah branleurs" ), à commencer par l'auteur original qui semble avoir un caractère un peu soupe-au-lait.
[^] # Re: Réponse aux deux premiers commentaires
Posté par gasche . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 2.
L'auteur de la dépêche semble confondre la licence d'une oeuvre et le respect des standards W3C par la page web qui présente cette oeuvre. Je trouve déjà curieux qu'on soit taxé d'extrêmisme (comme l'ont fait certains commentaires ici) si on lui en fait la remarque. Mais je suis d'accord sur le fait que c'est une question plutôt de second plan pour la plupart des gens (mais qui a quand même son importance), et qu'il faut laisser la propriété aux commentaires de fond sur le contenu de l'oeuvre présentée.
Par contre, insulter les gens, essayer de les ridiculiser par un discours ironique et méprisant, voire faire des menaces d'agresssion physique, il me semble que ce n'est pas normal et que ça n'a pas sa place ici, que cela plaise à l'auteur d'un livre ou non.
Je trouve dommage qu'il n'ait à ce point pas supporté la polémique, relativement de second plan devant l'appréciation générale du livre (dont tout le monde lui est reconnaissant, visiblement), mais je ne pense pas qu'il soit « pathétique » de le lui faire remarquer.
Si pour avoir plus de personnes pour poster des dépêches ou des commentaires ici, il faut accepter de se faire insulter ou prendre pour un imbécile, je pense que je préfère me contenter des dépêches de patrick_g sur le noyau Linux, et autres « petits branleurs » ou « donneurs de conseils qui ne connaissent l'informatique qu'à travers le périmètre de leur chambre ».
PS : Par contre, je ne suis pas modérateur sur LinuxFR et je ne connais pas les pratiques de la modération, mais je pense que si l'auteur demande à ce qu'on retire sa dépêche, il faudrait le faire. Le site n'y est sans doute pas obligé, mais ça me semble être une mesure de fair-play, de gérer le contenu selon le désir de son auteur. Je pense donc qu'il serait correct de respecter sa volonté en retirant le texte de la dépêche (mais en laissant les commentaires qui sont la propriété de leurs auteurs respectifs).
[^] # Re: Réponse aux deux premiers commentaires
Posté par gasche . En réponse à la dépêche Linux aux petits oignons : texte intégral gratuit en ligne. Évalué à 4.
Tout le monde a des mauvaises journées, et tu as tout à fait le droit de passer à côté de la plaque. Le commentaire reste pertinent et intéressent, et malgré tes diverses boutades et répliques farcesques, tu n'as pas répondu sur le fond.
Alors, comme tout le monde l'a dit, choisir une licence non libre pour ton ouvrage (non, CC-BY-NC-ND n'est pas une licence libre, puisqu'elle ne donne ni liberté d'utilisation, ni liberté de modification) est un choix qui ne tient qu'à toi, et tu peux tout à fait le faire, et l'assumer complètement même sur LinuxFR. C'est juste que, pour beaucoup, ce choix en contradiction avec ce que tu dis (esprit de partage de connaissances), d'où les commentaires à ce sujet.
Par contre, ça ne te donne pas le droit d'être incorrect. Tes réponses sont ironiques, souvent méprisantes, voire carrément insultantes. Ce n'est pas parce que tu présentes ton propre travail que tu dois te montrer grossier envers des gens qui font un commentaire constructif.
Tu présentes ton travail sur LinuxFR, et tu obtiens des commentaires de libristes, ça me semble assez naturel. Que tu supportes mal la critique, parfois trop pointilleuse, et que tu réagisses de façon un peu disproportionnée, tout le monde peut le comprendre, c'est un sujet personnel, mais tu devrais éviter de te comporter comme si les autres étaient des idiots bornés.
# Bonne dépêche
Posté par gasche . En réponse à la dépêche OsmocomBB : Pour un GSM complètement libre !. Évalué à 6.
Ah ben c'est lui l'auteur !