#126 Le 15/06/2010, à 23:56
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
Premièrement, je me demande si je dois aller complétement vers de l’ADT. Cela aurait le mérite de fournir une API cohérente, mais j’ai quand-même des scrupules à faire des fonctions pour juste positionner un drapeau booléen. Je sais bien que dans un langage complétement orienté objet, on appliquerait la sacro-sainte loi de l’encapsulation ; mais demander l’utilisation d’une fonction pour une action aussi triviale qu’un opt->takes_value=1;, j’ai du mal.
Perso, je le ferais mais ça n'engage que moi.
C'est une habitude que j'ai prise au cas où le code évoluerait plus tard. Je me dis que ça ne coûte quasiment rien et que ça peut faire gagner beaucoup de temps.
Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).
Aujourd'hui c'est juste un "=1" mais si un jour te prend l'envie pour une raison x ou y de faire une initialisation plus complexe, des vérifications plus poussés, des traitements en plus,… et bien ça ne change absolument rien pour l'utilisateur : il appelle toujours ta fonction.
Dans le cas contraire, il doit réécrire tout le code qui initialise le champ takes_value et ça ce n'est pas cool pour lui.
Après c'est mon avis, c'est à toi de voir comment tu le sens et selon ta façon de coder.
Ensuite, j’hésite à protéger l’utilisateur contre un SIGSEGV s’il donne un NULL à manger à un destructeur. E.D. le faisait, dans un exemple de code, mais je ne suis pas sûr que dans mon cas cela soit très appréciable. En effet, j’ai conçu l’API de sorte à ce que l’utilisateur n’ait à aucun moment le besoin ni même l’envie de passer NULL aux destructeurs. Un tel cas a de très fortes chances de résulter de l’erreur de l’utilisateur ; et donc l’avertir qu’il a fait quelque chose de pas net via un SIGSEGV ne me semble pas une mauvaise chose.
Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )
Par exemple, mpc (music player daemon) SIGSEGV dès que tu te gourres dans ses options en ligne de commande et je trouve ça super chiant (en plus je doit nettoyer les coredump générés après).
Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".
Encore une fois ça n'engage que moi.
Et enfin troisièmement, j’hésite à créer un destructeur partiel pour mes structures gérant les options. Je m’explique : pour effectuer le traitement des options, j’ai besoin que les structures soient renseignée sur plusieurs points, notamment la liste des arguments de la ligne de commande qui permettrons d’activer une option. Or, une fois le traitement des options effectué, ces renseignements deviennent inutiles. Comme les structures ne sont pas immédiatement détruites, car elles restent nécessaires pour en tirer le résultat du traitement des options, et influencer le comportement du programme. Donc j’hésite à faire un destructeur partiel qui serait appelé à la fin de ma fonction principale de traitement. Cela permettrait d’économiser un peu de mémoire, mais pas beaucoup (je suis quand-même assez économe en mémoire). Je me demande si cela vaut vraiment la peine de détruire les structures dédiées aux options en deux fois… pour un gain assez faible.
Je n'ai pas tout saisi (pour moi une structure = un destructeur donc j'ai du mal à saisir le concept de destructeur partiel ) et ça semble assez spécifique à l'architecture de ta bibliothèque donc je ne prononcerais pas (ça m'éviteras de dire des conneries aussi ).
@nesthib : un bot IBM .
@ArkSeth : En GTK je suppose, non ?
Peut-être en écoutant ce qui se passe sur la fenêtre root (et ses filles).
Pour chopper la root tu peux voir ça, peut-être qu'une adaptation au clavier est faisable.
Mais je ne suis pas sûr d'avoir compris ton besoin exact.
Dernière modification par grim7reaper (Le 16/06/2010, à 00:05)
Hors ligne
#127 Le 16/06/2010, à 00:03
- nesthib
Re : /* Topic des codeurs couche-tard [1] */
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#128 Le 16/06/2010, à 00:27
- cm-t
Re : /* Topic des codeurs couche-tard [1] */
'Nuit
Actu Ubuntu ☺/
Pauses Ubuntu sur Paris \_< -t
[(π)] La Quadrature du net
Hors ligne
#129 Le 16/06/2010, à 00:48
- helly
Re : /* Topic des codeurs couche-tard [1] */
plop
Archlinux-wmii-dwb.
Un problème résolu ? Faites le savoir en mettant [résolu] à côté du titre de votre topic.
Un problème non résolu ? Faites le savoir en insultant ceux qui cherchent à vous aider.
Un site bleu super remasterised©, un wiki cherchant des volontaires pour traduire un site.
Hors ligne
#130 Le 16/06/2010, à 00:48
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
si tu veux pour wget par contre ton code suivant est largement améliorable (cf. mon post)
Quitte à être vraiment performant :
wget -q 'http://forum.ubuntu-fr.org/extern.php?action=online_full&type=rss' -O - | sed -e 's/^[^"]*"/<a/' -e 's/<[^>]*>//g' -e 's/, /\n/g' | uniq -dc
Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr… ^^ Et puis pour le -c à uniq, mouais, bof… pas très important…
/me & /you dans un combat de ce soir ^^
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#131 Le 16/06/2010, à 01:06
- nesthib
Re : /* Topic des codeurs couche-tard [1] */
Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr…
vala t'as tout compris ! puisque sed est en mémoire autant s'en servir
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#132 Le 16/06/2010, à 01:15
- Кຼزດ
Re : /* Topic des codeurs couche-tard [1] */
Plop
dou
Hors ligne
#133 Le 16/06/2010, à 01:25
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).
Oui, justement, je profite de n’avoir pas avoir encore fait de release pour pouvoir figer l’API de haut niveau dans la forme qui me semble la meilleure.
Mais tu as probablement raison.
Cela me semble lourd de demander à l’utilisateur de une fonction pour une simple assignation. D’autant plus qu’il faudra alors lui expliquer que j’ai besoin d’un static const char* à un moment. Alors que si je le laisse faire l’assignation, il est sensé s’en rendre compte (quoique… il est toujours bon de le mentionner).
Mais je crois que je vais m’en remettre à cette sage décision.
Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )
Ce n’est pas toi qui m’avait recommandé de mettre le pointeur passé au destructeur à NULL pour obtenir un SIGSEGV au cas où un codeur négligeant réutilise une structure détruite ?
Par exemple, mpc (music player daemon) SIGSEGV dès que tu te gourres dans ses options en ligne de commande et je trouve ça super chiant (en plus je doit nettoyer les coredump générés après).
Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…
(Tiens, tant qu’on est sur ce sujet, tu savais que dpkg SIGSEGV ? Ce n’est vraiment pas sérieux, ça ; il faudrait que je retrouve le sujet.)
Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".
J’étais plutôt partisan des destructeurs void…
Je n'ai pas tout saisi (pour moi une structure = un destructeur donc j'ai du mal à saisir le concept de destructeur partiel ) et ça semble assez spécifique à l'architecture de ta bibliothèque donc je ne prononcerais pas (ça m'éviteras de dire des conneries aussi ).
En fait l’idée c’était de détruire une structure en deux fois, histoire de libérer un peu de mémoire entre temps. Mais ça ne fait gagner que peu de mémoire, et si le dev est sérieux, il s’arrange pour détruire complétement toutes mes structures le plus tôt possible.
Donc oublie.
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#134 Le 16/06/2010, à 01:29
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
Pylade a écrit :Après, pour la troisième expression de sed, bof, j’utiliserais tr, question de perfs, on s’en fout un petit peu de l’espace avant le nom. Remarque, rajouter un pipe supplémentaire risque probablement d’annuler le gain de perfs procuré par tr…
vala t'as tout compris ! puisque sed est en mémoire autant s'en servir
Nan, mais même en partant du principe que tr est déjà en mémoire, la mise en place et l’utilisation du pipe doivent à elles seules suffire à annuler le peu de perfs gagnées…
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#135 Le 16/06/2010, à 01:36
- nesthib
Re : /* Topic des codeurs couche-tard [1] */
Pylade qui s'auto-flagelle
edit : rien
Dernière modification par nesthib (Le 16/06/2010, à 02:01)
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#136 Le 16/06/2010, à 01:47
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
grim7reaper a écrit :Je l'ai vu dans mon projet sur les labyrinthes, j'ai pas mal modifié les structures internes et les fonctions de génération mais je n'ai pas eu a modifier une seule ligne de code des algorithmes de plus haut niveau (grâce à cette "encapsulation", tant que l'interface de communication est stable, le code de haut niveau ne change pas d'un poil).
Oui, justement, je profite de n’avoir pas avoir encore fait de release pour pouvoir figer l’API de haut niveau dans la forme qui me semble la meilleure.
Mais tu as probablement raison.
Cela me semble lourd de demander à l’utilisateur de une fonction pour une simple assignation. D’autant plus qu’il faudra alors lui expliquer que j’ai besoin d’un static const char* à un moment. Alors que si je le laisse faire l’assignation, il est sensé s’en rendre compte (quoique… il est toujours bon de le mentionner).Mais je crois que je vais m’en remettre à cette sage décision.
Figer une API c'est un truc relatif, rare sont les bibliothèques qui n'évoluent plus du tout.
C'est pour ça que je fais comme ça, c'est "au cas où".
Ça peut être inutile la majorité du temps, mais quand ça bouge au moins je suis prêt .
grim7reaper a écrit :Je suis d'avis que tu ne laisse pas la SIGSEGV mais que tu gères le NULL. La SIGSEV n'a pas pour rôle d'avertir un utilisateur de bibliothèque (selon moi).
Une SIGSEGV je trouve que ça ne fait pas propre, genre travail baclé (tu ne sais pas si le dev l'a laissé là intentionnellement ou si c'est un bug )Ce n’est pas toi qui m’avait recommandé de mettre le pointeur passé au destructeur à NULL pour obtenir un SIGSEGV au cas où un codeur négligeant réutilise une structure détruite ?
Oui, mais là tu n'a aucun moyen de la prévenir autrement.
S'il libère le truc et le réutilise ça fonctionneras parfois et d'autre fois ça planteras. Le fait de mettre à NULL fera toujours planter et il pourra trouver son erreur, là il n'y a aucun autre moyen.
Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.
Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…
Oui, mais le dev n'est pas censé savoir si quand la lib SIGSEGV c'est normal parce qu'il a merdé ou si c'est un bug de ta part.
grim7reaper a écrit :Je pense qu'un message (ou pour une lib un code d'erreur) ça fait plus "pro".
J’étais plutôt partisan des destructeurs void…
Ha, mais moi aussi je suis partisan des destructeurs en void .
Là je parlait des fonctions en général. Mettre un exit() ou autre truc qui kill le programme dans une lib je trouve que ça la fout mal.
C'est à l'appelant de gérer ça, toi tu ne connais pas le contexte donc tu ne quittes pas le prog du gars à l'arrache, normal quoi.
Hors ligne
#137 Le 16/06/2010, à 02:58
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
Figer une API c'est un truc relatif, rare sont les bibliothèques qui n'évoluent plus du tout.
C'est pour ça que je fais comme ça, c'est "au cas où".
Ça peut être inutile la majorité du temps, mais quand ça bouge au moins je suis prêt .
Oui, t’as raison. C’est comme quand tu me disais de réduire la taille d’une de mes fonctions. Je l’ai fait un peu à contre-cœur, mais sachant que c’était sage. Et maintenant je suis bien content de l’avoir fait.
Donc on ne sait jamais, je pourrais un jour être bien content de passer par une fonction pour ça.
Oui, mais là tu n'a aucun moyen de la prévenir autrement.
S'il libère le truc et le réutilise ça fonctionneras parfois et d'autre fois ça planteras. Le fait de mettre à NULL fera toujours planter et il pourra trouver son erreur, là il n'y a aucun autre moyen.
Argument reçu, je suis convaincu.
Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.
Mouais, m’enfin avec free ce n’est pas pareil…
Pylade a écrit :Enfin, je voulais que les SIGSEGV s’adressent au dev, pas à l’utilisateur final…
Oui, mais le dev n'est pas censé savoir si quand la lib SIGSEGV c'est normal parce qu'il a merdé ou si c'est un bug de ta part.
C’est vrai. Je n’y avais pas pensé. Je suis encore un peu un noob…
Ha, mais moi aussi je suis partisan des destructeurs en void .
Là je parlait des fonctions en général. Mettre un exit() ou autre truc qui kill le programme dans une lib je trouve que ça la fout mal.
C'est à l'appelant de gérer ça, toi tu ne connais pas le contexte donc tu ne quittes pas le prog du gars à l'arrache, normal quoi.
Tout à fait d’accord.
Pour moi, le SIGSEGV avait plus valeur d’avertissement que de sortie du programme, mais à la réflexion, je conçois que cela soit interprété comme tel.
Bon, j’ai mes réponses, je vais suivre mes deux premières pistes et laisser tomber la troisième.
Merci beaucoup !
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#138 Le 16/06/2010, à 03:09
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
grim7reaper a écrit :Pour le fait de gérer le NULL dans les destructeur je me base aussi sur free() qui ne bronche pas quand on lui envoie NULL, il se contente de ne rien faire.
Mouais, m’enfin avec free ce n’est pas pareil…
C'est vrai, c'est un choix arbitraire que j'ai fait.
J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .
Je suis encore un peu un noob…
Ça va, là tu commences à en savoir plus que le gars moyen sur le C .
Et puis, on est tous le noob de quelqu'un.
Merci beaucoup !
De rien.
Allez BN World !
Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).
Hors ligne
#139 Le 16/06/2010, à 03:24
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .
Et fclose est l’archétype du destructeur…
Sinon, j’y pense (à l’instant, je dois être un peu fatigué) : si je documente le fait que NULL fait crasher, ça passe, non ? Cette question continue de me titiller un peu…
Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).
Ben bon courage pour tes révisions, alors.
Et moi je vais me pieuter. \o/
BN.
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#140 Le 16/06/2010, à 03:27
- samυncle
Re : /* Topic des codeurs couche-tard [1] */
.
Hello world
Hors ligne
#141 Le 16/06/2010, à 03:32
- nesthib
Re : /* Topic des codeurs couche-tard [1] */
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#142 Le 16/06/2010, à 12:58
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
Hello World !
Tiens, le compteur a eu un coup de mou.
Le responsable commence a être fatigué de marquer 10 points tout les soirs
grim7reaper a écrit :J'ai choisi de me calquer sur le comportement de free(), mais j'aurais pu me choisir de copier fclose() qui lui plante avec un NULL en paramètre .
Et fclose est l’archétype du destructeur…
Sinon, j’y pense (à l’instant, je dois être un peu fatigué) : si je documente le fait que NULL fait crasher, ça passe, non ? Cette question continue de me titiller un peu…
Dans l'absolu oui ça passe (fclose() le fait bien).
Après moi je ne le ferais pas car ce n'est pas mon "style", mais le faire n'est pas incorrect.
Sinon fclose() n'est pas plus l'archétype du destructeur que free() (qui libère aussi une structure).
grim7reaper a écrit :Demain je révise la programmation linéaire et surtout le calcul diff' (la note que je vais ramasser dans cette matière conditionne fortement mon passage en 2nde année, va falloir gérer ).
Ben bon courage pour tes révisions, alors.
Merci
Dernière modification par grim7reaper (Le 16/06/2010, à 12:59)
Hors ligne
#143 Le 16/06/2010, à 12:59
- Compteur du TdCCT
Re : /* Topic des codeurs couche-tard [1] */
Scores totaux, depuis le début :
1) 525 samuncle
2) 440 nesthib
3) 435 Pylade
4) 393+5 grim7reaper ** bonus +5 pour avoir répondu à ce post : ./viewtopic.php?pid=3486252#p3486252 **
5) 341 mathieuI
6) 239 cm-t
7) 189 helly
8) 163 gnuuat
9) 121 ǤƦƯƝƬ
10) 107 tshirtman
11) 83 petifrancais
12) 50 \\Ouranos//
13) 38 pierguiard
14) 37 ilagas
15) 30 keny
16) 25 GentooUser
17) 23 Kanor
18) 19 Le Rouge
19) 18 Ph3nix_
20) 14 kouskous
21) 12 stratoboy
21) 12 sailing
23) 11 Lagierl
24) 10 CROWD
24) 10 Toineo
26) 9 xapantu
27) 8 Mornagest
28) 7 Vista
29) 6 Zeibux
29) 6 Р'tite G☢gole :mad:
31) 5 timsy
32) 4 danychou56
32) 4 Neros
32) 4 Biaise
35) 3 gulp
36) 1 ceric
36) 1 pfriedK
36) 1 geenux
Codez-vous trop tard le soir ?
Demandez au Compteur du TdCCT pour le savoir !
J’ai été généreusement codé par tshirtman ; d’ailleurs, voici mon code source. TdCCT CEP : ./viewtopic.php?pid=3493579#p3493579 (p3492608).
Hors ligne
#144 Le 16/06/2010, à 12:59
- Compteur du TdCCT
Re : /* Topic des codeurs couche-tard [1] */
Scores de la période en cours :
1) 150 Pylade
2) 130 samuncle
3) 115 grim7reaper
4) 113 nesthib
5) 106 mathieuI
6) 66 gnuuat
7) 56 helly
7) 56 cm-t
9) 32 tshirtman
10) 20 keny
11) 15 \\Ouranos//
11) 15 ǤƦƯƝƬ
13) 13 petifrancais
13) 13 pierguiard
15) 9 Kanor
16) 7 Vista
17) 5 sailing
17) 5 timsy
19) 4 Toineo
19) 4 Lagierl
19) 4 xapantu
22) 3 gulp
22) 3 Р'tite G☢gole :mad:
24) 2 kouskous
24) 2 Mornagest
Codez-vous trop tard le soir ?
Demandez au Compteur du TdCCT pour le savoir !
J’ai été généreusement codé par tshirtman ; d’ailleurs, voici mon code source. TdCCT CEP : ./viewtopic.php?pid=3493579#p3493579 (p3492608).
Hors ligne
#145 Le 16/06/2010, à 13:46
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
42 points me séparent de Pylade (si on ne tient pas compte du bonus de 5 points).
Hors ligne
#146 Le 16/06/2010, à 13:55
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
Tiens, le compteur a eu un coup de mou.
Le responsable commence a être fatigué de marquer 10 points tout les soirs
Ouais, c’est un peu ça, j’avoue… Enfin, une bonne nuit (ou bonne matinée) va m’a permis de bien récupérer. C’est ça va mieux, parce qu’hier, ce n’était tip-top au réveil (heureusement, le soir, les démons de minuit me tiennent éveillé et en forme).
Du coup, j’ai complétement oublié à nesthib que j’avais encore amélioré la ligne permettant de détecter les doublons :
wget -q 'http://forum.ubuntu-fr.org/extern.php?action=online_full&type=rss' -O - | sed -e 's/: </\n</' -e 's/<[^>]*>//g' -e 's/, /\n/g' | uniq -dc
Tellement cool que je l’ai mis en alias.
Tiens, pourquoi j’ai perdu la coloration syntaxique dans le .bash_aliases ? À cause des double quotes que j’ai été obligé de mettre ?
Hum, apparemment ça ne vient pas des double quotes, mais quand même de la ligne permettant de détecter les doublons… Bizarre… Investigations futures possibles.
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#147 Le 16/06/2010, à 20:03
- nesthib
Re : /* Topic des codeurs couche-tard [1] */
euh… en quoi c'est amélioré ? parce que la je vois pas
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#148 Le 16/06/2010, à 21:19
- grim7reaper
Re : /* Topic des codeurs couche-tard [1] */
Plop à 1 point.
J'assure mes arrières, ce soir je risque de ne pas faire long feu…
Dernière modification par grim7reaper (Le 17/06/2010, à 04:43)
Hors ligne
#149 Le 16/06/2010, à 21:20
- Pylades
Re : /* Topic des codeurs couche-tard [1] */
J’ai encore amélioré le première expression, que j’avais déjà améliorée, qui passe de
s/^[^"]*"/<a/
à
s/: </\n</
ce qui est, tu en conviendra, à la fois plus court et plus efficace en termes de perfs.
Ainsi, le boulot est fait avec une seule courte ligne de commande, et pas un script bidon complet.
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#150 Le 16/06/2010, à 21:52
- Elzen
Re : /* Topic des codeurs couche-tard [1] */
@ArkSeth : En GTK je suppose, non ?
Peut-être en écoutant ce qui se passe sur la fenêtre root (et ses filles).
Pour chopper la root tu peux voir ça, peut-être qu'une adaptation au clavier est faisable.
Mais je ne suis pas sûr d'avoir compris ton besoin exact.
Mon besoin exact, c'est d'avoir des raccourcis claviers, tout simplement ^^
Rien de particulièrement particulier, j'voudrais savoir le faire dans le cas général (genre comme un lecteur de musique, pouvoir effectuer une action (mettre en pause, par exemple) alors que la fenêtre principale est fermée et qu'il n'y a plus qu'une icône dans le systray, ce genre de trucs. Ça m'embête de savoir que c'est possible sans trouver comment ^^)
Sinon, dans la série des questions bizarres, j'ai peut-être mal fait un truc, mais je n'arrive pas à mettre une image de fond à une barre de menus (vous savez, avec un set_app_paintable sur le widget et un set_back_pixmap sur sa fenêtre une fois réalisé)... elles ont une situation différente des autres composants, ou j'ai juste loupé mon coup, selon vous ?
Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]
Hors ligne