gaaaaaAab a écrit 1393 commentaires

hmmm bizarre
pas de libenia chez moi, pourtant, j'ai bien un libecore-file

$ dpkg -l |grep libecore-file
ii libecore-file0 0.9.9.043-0cvs20080617 Ecore File Library
$ dpkg -l |grep libenia; echo $?
1


à noter que je tire unstable sur ce repository en question.

apt-get vs aptitude ... non monsieur, je ne rentrerais pas dans ce troll sordide :D
C'est comme tu veux. J'utilise apt-get parce que, mais aptitude est surement très bien aussi.

C'est le configure de calaos qui échoue ? Tu peux poster le log ?

ecore et libecore-file font partie du projet enligthenement. Possible que ça soit packagé quelque part dans debian, mais j'ai pris l'habitude de pointer sur le repository http://debian.alphagemini.org/

heu ... non ! grep renvoie 0 quand des lignes passent le filtre, et pas 0 quand rien ne passe.

$ echo bla |grep -v 'i';
bla
$echo $?
0
$ echo bla |grep -v 'a';
$echo $?
1


avec -v, le filtre est inversé, mais pas le retour de grep.

je réponds à ce commentaire mais c'est une réponse à plusieurs commentaires en fait.
Je suis justement en train de relire code complete [1], et ce qu'on peut reprocher à la fonction en exemple, c'est d'avoir une homogénéité séquentielle, ce qui n'est pas l'idéal.
Forcément, sur cet exemple "creux", on ira pas très loin, mais sur un exemple plus concret, il y aurait surement des moyens de réorganiser le code à plus haut niveau pour qu'on ne se retrouve pas dans cette situation.

[1] http://www.amazon.fr/Code-Complete-Steven-C-McConnell/dp/073(...)
Il y a aussi une VF. Quand je vois comment ce bouquin m'a fait progresser, je ne peux que vivement vous encouragez à le lire si ce n'est pas déjà fait.

flûte, lu trop de vite
s/de vous/de toi/ ...

Manifestement, aucun de vous n'a foi en l'orthographe :D

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