gaaaaaAab a écrit 1387 commentaires

hmm ça se discute.

Je considère, comme Michel, qu'il faut pouvoir justifier chaque choix technique dans le code, en descendant au niveau de détail de la ligne de code. Le problème, c'est que quand un code est bien écrit, il peut y avoir plusieurs justifications (se renforçant mutuellement) pour certaines lignes de code.
SI je devais documenter absolument tous les éléments que je prends en compte quand je code, ben je coderais pas beaucoup :D

D'après moi, ce qu'il faut documenter dans le code, c'est plutôt l'intention qui le guide.

Ils ont par contre oublié de t'enseigner l'orthographe :D

Concernant le style de code, il n'y a pas de règle absolue, ça dépend vraiment du contexte. Je vise toujours la meilleure lisibilité possible quand je code, et en fonction du contexte, ça passe parfois par une variable de statut renvoyée en fin de fonction (comme tu le dis) et parfois par des retours en erreur au fil de la fonction.

Je précise aussi que je fais principalement de la maintenance de code, et que dans ce contexte là, on ne peut pas toujours se permettre de ré écrire tout tout beau tout propre.

Ca ne qualifie pas le driver sous jacent comme étant de la merde.

Si je ne me trompe pas, tu réagissais à :

Techniquement, c'est merdique dans le sens ou le pilote en question duplique la moitié de Xorg (leur propre gestion du multi-écran, leur propre GLX, etc ...)

Je n'interprète pas du tout ce qu'a écrit GeneralZod de la même façon que toi.
La qualité technique, ce n'est pas seulement le fait de savoir si ça marche ou si ça marche pas.
Si effectivement le driver nvidia duplique des fonctionnalités de X (ce que je n'ai pas vérifié, je fais confiance au commentaire), c'est Mal.

pour prendre un exemple trollesque, fesse de bouc, c'est de la merde, et pourtant, ça marche très bien.

Sinon, j'ai l'impression que tu t'énerves quand même un peu tout seul là.

Si, dès qu'on modifie le programme, le compilo crie, ou est "La liberté d'améliorer le programme et de publier ses améliorations." ?

je ne suis pas sur que ton exemple soit très pertinent.

FUD: Fear, Uncertainty, Doubt

Là, je vois pas ou est le FUD. Et dans l'autre commentaire ou tu utilises ce terme non plus en fait ...

je trouve un algorithme permettant de compresser tout fichier à une taille de 2 octet, j'aimerai pouvoir en profiter et le vendre.

ça existe déjà. Le seul petit problème, c'est que c'est de la compression destructive :D

il faut que l'innovation soit réelle et non triviale pour un expert du domaine.

le problème, c'est que cette formulation laisse beaucoup de place à l'interprétation.
La formule qu'avait retenu les opposants aux brevets logiciels pendant toute le débat (avant l'abandon de la directive) discriminait ce qui était brevetable de ce qui ne l'était pas sur le fait que l'invention mettait en oeuvre les forces de la nature en pas.
Pour clarifier, l'idée, c'est que si le logiciel n'était qu'un élément intervenant dans une invention débordant du cadre du logiciel (ex: l'ABS), il était brevetable (dans la contexte global de l'invention), sinon, il ne l'était pas.

Un article un peu ardu mais ça vaut le coup d'aller le lire. Ou plutôt, il *faut* aller lire ça :

http://www.groklaw.net/article.php?story=20091111151305785

ah mince, j'ai fait une vanne pourrie pour dyslexiques ...
--> []

Je ne suis pas sûr que ce que tu essaies de faire soit possible en ayant des espaces dans tes datas alors que l'espace est le caractère séparateur ... en tout, pour l'instant, je ne vois pas comment écrire ça suivant ton approche initiale.

Si tu contrôle le script qui génère ce que tu veux mettre dans ton tableau, tu peux jouer sur l'impôt sur la fort^w^w^w^w Input Field Separator :


$ export IFS="-"
$ VAR=($(echo A B C-D E F))
$ echo ${VAR[0]}
A B C


une autre méthode forcément moins satisfaisante, est de faire l'affectation des VAR[i] dans une boucle.

dommage qu'ils les aient pas impliqué ...

http://counter.li.org/

rabat-joie! :p

oui :)

ça marche pas "comment" ?
quel est le résultat de la commande ?

sinon, je ne suis pas trop sûr de que signifie la syntaxe %.h.gch: %.h
j'aurais plutôt écrit
.h.gch:
ou
%.gch: %h

c'est juste dommage qu'on puisse pas désactiver le machin une fois qu'on a compris que c'était un poisson d'Avril (au bout d'environ une demi seconde) ...
bon, ben pas de linuxfr aujourd'hui, ça fait trop mal aux yeux

mouais, succès très mitigé. Sur javafr, c'est "tiens y'a cet outil là il fait p-e un peu ce que tu veux", sur ubuntu-fr, c'est, en gros, STFW, et ici, pas mieux.

ma réponse initiale "bas du front", c'était "utilise vim". J'aurais du faire ça, j'aurais été pertinenté à mort ;)
mais finalement, je ne l'ai pas fait parce qu'il y a *un* truc positif dans cette question, c'est que maintenant, je sais que antlr existe.
et puis c'est un cas d'école de "comment il faut surtout pas poser des questions" =)

ah ? tu trouves que ça a fonctionné toi ? :D

Bon, on en est tous passé par là ... ton message m'a fait penser à
http://www.gnurou.org/writing/smartquestionsfr que j'en ai profité pour relire.

sinon, il semblerait que antlr sache générer du code dans les langages définis là : http://www.antlr.org/wiki/display/ANTLR3/Code+Generation+Tar(...)
ce qui ne veut pas forcément dire qu'antlr est inutilisable, mais qu'il va y avoir plus de boulot.
pour écrire des parsers, j'ai souvent entendu parler de lex et yacc (ou flex et bison), c'est peut-être une piste à creuser.

Je pense qu'il y a des gens ici qui en connaissent plus que moi sur les grammaires formelles, du coup, il y a p-e des outils mieux adaptés à ton problème ... encore faut-il que tu le précises un peu plus.

pour la discussion sur le H264, un article sur osnews sur le sujet :

http://www.osnews.com/story/23031/Mozilla_Stick_to_Your_Idea(...)

et nous te saurons gré de ne pas faire attention qu'à l'orthographe, parce que là, tu fais quand même deux fautes pour en corriger une :)

en inversant le critère (éliminer toutes les valeurs <= 100), ça donne un truc comme ça :

~$ cat bla
-35
-100
-1000
38943
$ grep -v -- "-[0-9]\{3,\}" bla
-35
38943


à adapter s'il y a plusieurs champs par ligne de fichier.

oops, copié/collé la mauvaise ligne de l'historique du shell ...

sed -n 's/user_pref("mail.server.server\([0-9]*\)\.type.*/\1/p' prefs.js |sort -n | tail -1

ok, je me demandais si un simple wc -l suffisait (mais grep -c, c'était incontestablement mieux), mais vu ce commentaire, la réponse est non.

ton xargs | awk pour récupérer la dernière ligne peut se remplacer par un tail

et grep | awk | cut par un sed

Du coup :
grep mail.server.server'.*'.type prefs.js | sort -n |tail -1 | sed 's/.\{29\}\([0-9]*\).*/\1/'

sed '/keyword1\|keyword2/ { s/keyword3//g}'

raisonnement logique, mais le monde de l'entreprise n'est pas toujours rationnel.
Il arrive que des choix technologiques soient fait pour des raisons purement arbitraires. Ca va du "le patron de cette boite c'est mon copain alors on choisit sa technologie" à "on ne peut pas dépendre d'un seul fournisseur alors on va prendre le produit de machin même s'il est moins bien que celui de bidule".

sur le principe, avec un makefile du genre:


$ cat makefile

all: cmd1 cmd2

cmd1:
while [ 1 ]; do echo "hu"; sleep 5; done

cmd2:
while [ 1 ]; do echo "ha"; sleep 3; done
.PHONY: cmd1 cmd2


ensuite:
$ make -j 2
while [ 1 ]; do echo "hu"; sleep 5; done
hu
while [ 1 ]; do echo "ha"; sleep 3; done
ha
ha
hu
ha
ha
hu


en oubliant pas que make exige des tabulations en début des lignes de commande (ici, devant chaque while), mais je ne sais pas comment faire apparaitre ça proprement sur linuxfr.
pour toi, ça sera make -j 8 (man make)

yapuka(c) écrire une moulinette pour générer le makefile (parce que se cogner les 400 commandes à la main, c'est pas glop) et roule :)

je me répète, mais comme tu sembles n'avoir pas lu mon autre commentaire, mettre de l'eau sur un livre ne le rend pas inutilisable.
Je comprends que ça t'embêtes pour ta démonstration, mais un livre, c'est pas *si* fragile que ça. Quant à la pérennité des livres électroniques, je veux bien te suivre sur le plan théorique, mais admet qu'on manque un petit peux de recul sur la question.

Une fois qu'on aura bien trollé pour décider si le livre électronique est mieux que le livre papier, ça nous dira pas si le grand public suivra.

D'après ce que je vois sur le grand 'Ternet, sont considérés comme gros lecteurs les gens qui lisent plus de 20 livre par ans [1]. Chiffre non recoupé, j'ai vu le chiffre de 12 ailleurs (mais je ne sais plus ou).

Je ne sais pas quelle est la proportion de gros lecteur dans la population. Ca demanderait plus de recherche documentaire.
En tout cas, si on se réfère au premier paragraphe de [2] citant une étude de TNS Sofres (Mars 2008):
le nombre de livres lus est en baisse : si 42 % des Français lisaient plus de cinq livres en 1983, ils ne sont plus que 34 % aujourd'hui

Les gens vont-il vraiment acheter des ebooks en masse pour s'en servir 5 fois par an ?

A tempérer, puisque d'après [3], la lecture ne serait pas en perte de vitesse. Mais comme le contenu est payant, on a pas le détail.

[1] http://www.grinzane.net/Osservatorio2003/Osservatorio2003_FR(...)
[2] http://www.actualitte.com/actualite/1315-lecture-France-habi(...)
[3] http://www.scienceshumaines.com/index.php?id_article=4988&am(...)

Hop un verre d'eau et tu perds ton livre.
il est hyper-dépendant d'un verre d'eau mal placé

heu ... non. D'après mon expérience, même avec une bouteille d'eau complète (mal refermée qui se vide dans tout le sac à dos), le livre résiste.
Certes, il est gondolé à mort, mais l'encre et le papier tiennent bien.

en plus, le livre, il résiste probablement au micro onde, alors que pas l'e book.
Alors, on fait moins le malin ? :o)

--> []