/* Topic des codeurs couche-tard [4] */

sweetly · Le 02/06/2011, à 23:26

(franchement en ada, c'est easy avec vim )

Elzen · Le 02/06/2011, à 23:50

Ç'pas un langage périmé, Ada ? Il me semble vaguement qu'un de mes profs nous avait dit que c'était encore plus vieux que le pascal, ou un truc comme ça…

Sinon, j'suppose que ça va pas vous plaire, alors j'poste pour avoir vos suggestions d'améliorations : je viens de retoucher mon script python qui épingle automatiquement les fenêtres minimisées (pour qu'on puisse les récupérer au alt+tab sur n'importe quel bureau) et les désépingle quand elles réapparaissent, histoire de faire en sorte qu'il ne les laisse pas épinglées quand on le kille. Verriez-vous plus propre que ça ?

if (__name__ == "__main__"):
    import gtk, signal
    for sig in range(1, 65, 1):
        try: signal.signal(sig, stop)
        except: pass
    try: gtk.main()
    except KeyboardInterrupt: stop()

(stop étant la fonction qui se contente juste de désépingler toutes les fenêtres gérées par le truc)

nesthib · Le 03/06/2011, à 01:11

plop

cm-t · Le 03/06/2011, à 01:39

'Nuit;

Pylades · Le 03/06/2011, à 02:16

@ The Uploader : set number.

@ Elzen : l’interruption clavier, ça balance un SIGINT. Le kill de base, ça balance un SIGTERM. Donc je ne suis pas sûr de la réussite de l’entreprise.

Pourquoi c’est spécifiquement quand j’ai besoin du site de grim7reaper qu’il est down ?

Pylades · Le 03/06/2011, à 03:18

/me vient de découvrir gettext. Hum, ça serait cool de pouvoir tester un *.mo sans avoir besoin de l’installer dans le système de fichiers (par exemple, si l’on n’est pas root ; ou si l’on ne veut pas toucher à ce qui est hors de son répertoire personnel sans passer par un gestionnaire de paquets (ou alors juste pour éditer un fichier de conf (Lisp style ))).

Compteur du TdCCT · Le 03/06/2011, à 06:42

Scores totaux, depuis le début :

1) 3420    nesthib
2) 3046    samuncle
3) 2858    Pylade
4) 2166    Кຼزດ
5) 1695+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1653    cm-t
7) 1284    na kraïou
8) 866    helly
9) 862    \\Ouranos//
10) 659    gnuuat
11) 576    tshirtman
12) 565    Lagierl
13) 424    Rolinh
14) 352    The Uploader
15) 348    nathéo
16) 263    Kanor
17) 196    Askelon
18) 166    :!pakman
19) 121    ǤƦƯƝƬ
20) 95    kamui57
21) 93    petifrancais
22) 78    edge_one
22) 78    pierguiard
24) 70    gulp
25) 42    sakul
26) 39    Le Rouge
27) 37    ilagas
28) 33    xapantu
29) 30    keny
30) 26    gustare
30) 26    d10g3n
32) 25    GentooUser
32) 25    Morgiver
34) 24    ไ୦บเઢ'
34) 24    Steap
36) 20    CROWD
37) 18    Ph3nix_
38) 16    kouskous
39) 15    timsy
40) 12    stratoboy
40) 12    sailing
42) 11    alexises
42) 11    Crocoii
44) 10    Toineo
44) 10    NutMotion
44) 10    pseudovingtcinqcaracteres
44) 10    pfriedZ
44) 10    CasseTaTele
44) 10    Zeibux
44) 10    THS`
51) 8    Mornagest
52) 7    Vista
53) 6    ubuntlin
53) 6    asma.geek
55) 5    tendances-tdct
55) 5    kinouchou
57) 4    danychou56
57) 4    Neros
57) 4    Biaise
57) 4    totoflute
57) 4    pinballyoda ㋛
57) 4    NLS le pingouin
57) 4    ceric
57) 4    Dice-Man
65) 3    Revan26914
65) 3    raspouillas
65) 3    sweetly
68) 2    SoJaS
69) 1    geenux
69) 1    ArzhurBZH

Répartition Posts/heure

Compteur du TdCCT · Le 03/06/2011, à 06:42

Scores de la période en cours :

1) 16    nesthib
1) 16    cm-t
3) 15    Pylade
4) 14    Кຼزດ
5) 5    Rolinh
5) 5    na kraïou
7) 4    \\Ouranos//
7) 4    The Uploader
9) 3    samuncle
9) 3    tshirtman
11) 2    grim7reaper

tshirtman · Le 03/06/2011, à 09:59

@arkseth: le dernier 1 du range est inutile, sinon tu es suit de ne pas connaître le numérotée du signal que tu envoyer? Par ce que si il y a des comportements sur sigusr1 ou 2, ça peut être dangereux.

aussi, faire l'import dans le "if __name__ == '__main__':" ne me semble pas une très bonne pratique… ça veux dire que si tu utilise ton truc en tant que module, et déporte tes classes/méthodes en dehors de ce if, elles n'auront pas accès à cet import…

Dernière modification par tshirtman (Le 03/06/2011, à 11:53)

xapantu · Le 03/06/2011, à 10:39

Pylade a écrit :

/me vient de découvrir gettext. Hum, ça serait cool de pouvoir tester un *.mo sans avoir besoin de l’installer dans le système de fichiers (par exemple, si l’on n’est pas root ; ou si l’on ne veut pas toucher à ce qui est hors de son répertoire personnel sans passer par un gestionnaire de paquets (ou alors juste pour éditer un fichier de conf (Lisp style ))).

Tu peux le faire, bindtextdomain(DOMAIN, LOCALE_DIR);

Elzen · Le 03/06/2011, à 12:21

Pylade a écrit :

@ Elzen : l’interruption clavier, ça balance un SIGINT. Le kill de base, ça balance un SIGTERM. Donc je ne suis pas sûr de la réussite de l’entreprise.

Le truc fonctionne, ça c'est sûr, j'ai testé

Après, peut-être en effet que si le Ctrl+C balance un SIGINT, le try-catch autour du gtk.main() n'a aucun intérêt…

tshirtman a écrit :

@arkseth: le dernier 1 du range est inutile, sinon tu es suit de ne pas connaître le numérotée du signal que tu envoyer? Par ce que si il y a des comportements sur sigusr1 ou 2, ça peut être dangereux.

Le dernier 1 du range me paraît plus lisible que sans quand même ^^
Quand ce truc est lancé en tant que module indépendant, j'veux que n'importe quel signal potentiellement mortel que se reçoive l'appli cause l'arrêt du truc. Le script ne fait qu'une cinquantaine de lignes, et je n'ai programmé absolument rien d'autre.

tshirtman a écrit :

aussi, faire l'import dans le "if __name__ == '__main__':" ne me semble pas une très bonne pratique… ça veux dire que si tu utilise ton truc en tant que module, et déporte tes classes/méthodes en dehors de ce if, elles n'auront pas accès à cet import…

C'est le but aussi ^^
Lu en tant que module, ce script ne fait strictement rien d'autre que son boulot, et c'est le programme appelant qui se charge de maintenir le truc en activité, de récupérer éventuellement les signaux et d'appeler stop() s'il y a besoin de s'arrêter (et cette fonction ne fait que remettre les fenêtres dans leur état initial, rien d'autre).
C'est seulement si le script est lancé indépendamment de tout le reste qu'il doit se maintenir lui-même en vie (d'où l'import de gtk juste pour faire gtk.main()) et veiller lui-même à rendre le système dans son état d'origine quand on le tue (d'où l'import de signal).

grim7reaper · Le 03/06/2011, à 12:38

ArkSeth a écrit :

Ç'pas un langage périmé, Ada ? Il me semble vaguement qu'un de mes profs nous avait dit que c'était encore plus vieux que le pascal, ou un truc comme ça…

Oulà, pas du tout !
C'est encore très utilisé dans certains domaines (et c'est apparu au début des années 80, alors que le Pascal c'est en 1970).

Pylade a écrit :

Pourquoi c’est spécifiquement quand j’ai besoin du site de grim7reaper qu’il est down ?

Parce qu'en ce moment je ne suis pas chez moi et que tout le monde n'a pas ma tolérance au niveau du bruit (mon PC étant vieux et encrassé, il souffle pour un rien) donc le serveur est down la nuit
Je reviendrai à une haute disponibilité quand je serai de retour chez moi et/ou quand j'aurai acheté mon nouveau PC (comme ça je relèguerai celui qui me sert de serveur dans une pièce extérieure).

C'était quoi que tu voulais voir ?

Dernière modification par grim7reaper (Le 03/06/2011, à 12:53)

Pylades · Le 03/06/2011, à 20:48

Ouais, je m’en doute bien…

C’était pour voir l’affichage d’un #define. Donc c’est bon, là.

xapantu a écrit :

Pylade a écrit :
/me vient de découvrir gettext. Hum, ça serait cool de pouvoir tester un *.mo sans avoir besoin de l’installer dans le système de fichiers (par exemple, si l’on n’est pas root ; ou si l’on ne veut pas toucher à ce qui est hors de son répertoire personnel sans passer par un gestionnaire de paquets (ou alors juste pour éditer un fichier de conf (Lisp style ))).
Tu peux le faire, bindtextdomain(DOMAIN, LOCALE_DIR);

Yeah, merci beaucoup.

ArkSeth a écrit :

Pylade a écrit :
@ Elzen : l’interruption clavier, ça balance un SIGINT. Le kill de base, ça balance un SIGTERM. Donc je ne suis pas sûr de la réussite de l’entreprise.
Le truc fonctionne, ça c'est sûr, j'ai testé
Après, peut-être en effet que si le Ctrl+C balance un SIGINT, le try-catch autour du gtk.main() n'a aucun intérêt…

Ah, oui, je vois pourquoi ça fonctionne… Et en effet, rechercher le KeyboardInterrupt en plus n’a aucun intérêt.

ArkSeth a écrit :

tshirtman a écrit :
@arkseth: le dernier 1 du range est inutile, sinon tu es suit de ne pas connaître le numérotée du signal que tu envoyer? Par ce que si il y a des comportements sur sigusr1 ou 2, ça peut être dangereux.
Le dernier 1 du range me paraît plus lisible que sans quand même ^^

Hum… comment dire ? Je ne pense pas que tu rajoutes de la lisibilité, bien au contraire.

ArkSeth a écrit :

Quand ce truc est lancé en tant que module indépendant, j'veux que n'importe quel signal potentiellement mortel que se reçoive l'appli cause l'arrêt du truc. Le script ne fait qu'une cinquantaine de lignes, et je n'ai programmé absolument rien d'autre.

Sont potentiellement mortels : ALRM HUP INT KILL PIPE POLL PROF TERM USR1 USR2 VTALRM STKFLT PWR. Il faut regarder comment se comporte un script Python sur chacun de ces signaux. Après, les autres c’est pour les bugs de Python, donc tu n’as pas à t’en soucier.
Sinon, faut voir aussi comment tu veux intercepter les signaux qui stoppent le programme…

ArkSeth a écrit :

tshirtman a écrit :
aussi, faire l'import dans le "if __name__ == '__main__':" ne me semble pas une très bonne pratique… ça veux dire que si tu utilise ton truc en tant que module, et déporte tes classes/méthodes en dehors de ce if, elles n'auront pas accès à cet import…
C'est le but aussi ^^
Lu en tant que module, ce script ne fait strictement rien d'autre que son boulot, et c'est le programme appelant qui se charge de maintenir le truc en activité, de récupérer éventuellement les signaux et d'appeler stop() s'il y a besoin de s'arrêter (et cette fonction ne fait que remettre les fenêtres dans leur état initial, rien d'autre).
C'est seulement si le script est lancé indépendamment de tout le reste qu'il doit se maintenir lui-même en vie (d'où l'import de gtk juste pour faire gtk.main()) et veiller lui-même à rendre le système dans son état d'origine quand on le tue (d'où l'import de signal).

Je ne suis pas convaincu. Mais alors pas du tout…

Elzen · Le 03/06/2011, à 21:51

Pylade a écrit :

Hum… comment dire ? Je ne pense pas que tu rajoutes de la lisibilité, bien au contraire.

Bah j'sais pas, moi le range(début, fin, pas) me paraît super lisible…

Pylade a écrit :

Sont potentiellement mortels : ALRM HUP INT KILL PIPE POLL PROF TERM USR1 USR2 VTALRM STKFLT PWR.

Donc j'pourrais juste récupérer ceux-là, ouais…

Pylade a écrit :

Je ne suis pas convaincu. Mais alors pas du tout…

Bah… t'peux développer ? Parce que si j'ai pas la bonne approche, ç'pas comme ça que j'vais le voir, quoi…

Au fait, toujours pour ce module : s'il y a plusieurs autres modules qui l'importent, il y a un moyen automatisé de le savoir, ou faut que j'fasse mon propre truc ? Genre si j'veux désactiver un module qui a l'a importé, mais qu'un autre module continue de s'en servir, que le truc reste actif quand même…

nesthib · Le 03/06/2011, à 22:24

plop

Sir Na Kraïou · Le 03/06/2011, à 22:35

Plæp.

Pylades · Le 03/06/2011, à 22:55

ArkSeth a écrit :

Bah j'sais pas, moi le range(début, fin, pas) me paraît super lisible…

En même temps, il te paraît super lisible de ne jamais aller à la ligne dans ton BBcode, alors je ne suis pas sûr que tu sois un bon exemple.

ArkSeth a écrit :

Pylade a écrit :
Sont potentiellement mortels : ALRM HUP INT KILL PIPE POLL PROF TERM USR1 USR2 VTALRM STKFLT PWR.
Donc j'pourrais juste récupérer ceux-là, ouais…

Surtout tester comment se comporte un script Python sur chacun d’eux… D’ailleurs, un script Python semble bien supporter un SIGPIPE. Mais bon, la plupart de ces trucs c’est pour des erreurs assez chelou. Je serais toi, je me contenterais d’intercepter SIGHUP, SIGINT, SIGUSR1, SIGUSR2 et SIGTERM…
D’ailleurs, tu ne pourras jamais intercepter un SIGKILL

ArkSeth a écrit :

Pylade a écrit :
Je ne suis pas convaincu. Mais alors pas du tout…
Bah… t'peux développer ? Parce que si j'ai pas la bonne approche, ç'pas comme ça que j'vais le voir, quoi…

Ben, disons que je ne comprends pas ce qui justifie ce comportement, qui ne paraît pas élégant du temps. T’façons, j’ai tendance à ne pas trop être fan des if __name__ == '__main__': tout court, alors…

ArkSeth a écrit :

Au fait, toujours pour ce module : s'il y a plusieurs autres modules qui l'importent, il y a un moyen automatisé de le savoir, ou faut que j'fasse mon propre truc ? Genre si j'veux désactiver un module qui a l'a importé, mais qu'un autre module continue de s'en servir, que le truc reste actif quand même…

Ben je dirais que c’est au module qui importe d’agir ou pas ; cela dit il doit exister une variable Python pour ça, probablement un truc du genre __parent_name__. Mais cela semble moche de faire comme ça, de prime abord.
Il faudrait qu’on en sache un peu plus sur ton code pour être plus constructifs, en fait…

Pylades · Le 03/06/2011, à 22:56

Ah, et je proteste contre le bot pour hier. Je vais me rajouter mes points.

Rolinh · Le 03/06/2011, à 23:15

Pourquoi il a pas compté? De toute façon, c'est pas important les points nan?
Parler de programmation et relatif sur ce post je trouve vraiment sympa mais écrire un message pour faire plop bah... comment dire... je vois pas l'intérêt...
(c'est pas à toi que je pense parce que tu ne le fais pas)

samυncle · Le 03/06/2011, à 23:36

.

Pylades · Le 03/06/2011, à 23:38

Rolinh a écrit :

Pourquoi il a pas compté? De toute façon, c'est pas important les points nan?

C’est une filiale du TdCT, ici. Mais, c’est vrai que ça joue un moindre rôle ici par rapport au TdCT.

Rolinh a écrit :

Parler de programmation et relatif sur ce post je trouve vraiment sympa mais écrire un message pour faire plop bah... comment dire... je vois pas l'intérêt...
(c'est pas à toi que je pense parce que tu ne le fais pas)

Des fois fois quand même… ^^

Bon, Elzen, j’ai regardé mais il ne semble pas y avoir de variable du style __parent_name__, désolé. T’façons je ne trouve pas ça joli.

tshirtman · Le 03/06/2011, à 23:43

Pylade a écrit :

j’ai tendance à ne pas trop être fan des if __name__ == '__main__': tout court, alors…

Moi j'aime bien, tu écrit un module, et dans le cas ou il est appelé directement, tu peux donner un comportement particulier… sans perturber le moins du monde les programmes qui veulent utiliser ses fonctionnalités… c'est cool

Ben je dirais que c’est au module qui importe d’agir ou pas ; cela dit il doit exister une variable Python pour ça, probablement un truc du genre __parent_name__. Mais cela semble moche de faire comme ça, de prime abord.
Il faudrait qu’on en sache un peu plus sur ton code pour être plus constructifs, en fait…

Hum, je suis d'accord aussi que c'est moche, de tenter de savoir qui t'importe et faire des traitements particuliers…

samuncle a écrit :

.

hey, hey, tu peux passer sur le topic d'USF? j'essaye de mettre à jour le fichier de licences d'USF… et je ne sais pas exactement tout ce dont tu es l'auteur, et sous quelle licence!

Dernière modification par tshirtman (Le 03/06/2011, à 23:44)

Pylades · Le 04/06/2011, à 00:00

tshirtman a écrit :

Pylade a écrit :
j’ai tendance à ne pas trop être fan des if __name__ == '__main__': tout court, alors…
Moi j'aime bien, tu écrit un module, et dans le cas ou il est appelé directement, tu peux donner un comportement particulier… sans perturber le moins du monde les programmes qui veulent utiliser ses fonctionnalités… c'est cool
[…]

Ben en fait, c’est pour une question d’architecture, que je n’aime pas trop : je n’ai toujours pas trouvé de cas où il serait justifié d’utiliser un même fichier tantôt en temps que programme, tantôt en temps que module.

Elzen · Le 04/06/2011, à 00:17

Pylade a écrit :

En même temps, il te paraît super lisible de ne jamais aller à la ligne dans ton BBcode, alors je ne suis pas sûr que tu sois un bon exemple.

Ç'pas vrai
(Le BBCode, j'le fais pas pour être lisible, j'le fais pour qu'il bouffe le moins de place possible dans la BdD du serveur )

Pylade a écrit :

D’ailleurs, tu ne pourras jamais intercepter un SIGKILL

Ouais, ça je sais, d'ailleurs signal.signal() n'en veut pas, c'est même pour ça qu'il y a un try-catch dans mon code d'origine.

Pylade a écrit :

Ben, disons que je ne comprends pas ce qui justifie ce comportement, qui ne paraît pas élégant du temps. T’façons, j’ai tendance à ne pas trop être fan des if __name__ == '__main__': tout court, alors…

Bah, il me semble (j'peux me gourrer) que quand on veut utiliser un truc tout seul, indépendamment du reste, le mieux est de lancer seulement le script python en question tout seul.
Donc quand un même script peut être potentiellement intéressant à lancer seul, mais est quand même prévu au départ pour être intégré dans le reste du programme, bah, j'lui rajoute un if __name__ == '__main__': pour lui rajouter ce qui lui manque pour tourner, c'est-à-dire le plus souvent au moins l'appel à gtk.main().
Sur certains autres scripts, je fais appel au module optparse de la même manière (alors que quand ils sont importés, les options sont gérées au dessus).

D'un autre côté, j'ai jamais prétendu que Touhy serait un exemple en matière de propreté de code… ou alors un exemple à ne pas suivre, justement ^^ Ça reste de l'infâme bidouille du début jusqu'à la fin, mais c'est comme ça que ça a été imaginé à la base ^^

Pylade a écrit :

Ben je dirais que c’est au module qui importe d’agir ou pas ; cela dit il doit exister une variable Python pour ça, probablement un truc du genre __parent_name__. Mais cela semble moche de faire comme ça, de prime abord.

Ouais, j'vais juste rajouter un truc, en fait, plus j'y réfléchis, plus ça me paraît la moins mauvaise solution.

Pylade a écrit :

Il faudrait qu’on en sache un peu plus sur ton code pour être plus constructifs, en fait…

Promis, dès que j'ai quelque chose qui tourne, je release ça et j'écoute tout ce que vous râlez dessus ^^

Pylades · Le 04/06/2011, à 00:48

ArkSeth a écrit :

Pylade a écrit :
En même temps, il te paraît super lisible de ne jamais aller à la ligne dans ton BBcode, alors je ne suis pas sûr que tu sois un bon exemple.
Ç'pas vrai
(Le BBCode, j'le fais pas pour être lisible, j'le fais pour qu'il bouffe le moins de place possible dans la BdD du serveur )
[…]

Hum, je ne pense pas que ça soit en économisant cinq ou six caractères que tu auras un impact considérable sur la taille de la BdD (d’ailleurs, cette simple justification est en train de mettre toutes tes économies par terre ).

T’aurais meilleur compte à écrire en style SMS.

Bon, pour le reste, je dis juste que je ne vois pas vraiment de cas où un même fichier pour avoir cette dualité. Mais si tu m’en montre un, alors je dirait que le if __name__ == '__main__': peut s’avérer utile dans au moins un cas.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2426 Le 02/06/2011, à 23:26

Re : /* Topic des codeurs couche-tard [4] */

#2427 Le 02/06/2011, à 23:50

Re : /* Topic des codeurs couche-tard [4] */

#2428 Le 03/06/2011, à 01:11

Re : /* Topic des codeurs couche-tard [4] */

#2429 Le 03/06/2011, à 01:39

Re : /* Topic des codeurs couche-tard [4] */

#2430 Le 03/06/2011, à 02:16

Re : /* Topic des codeurs couche-tard [4] */

#2431 Le 03/06/2011, à 03:18

Re : /* Topic des codeurs couche-tard [4] */

#2432 Le 03/06/2011, à 06:42

Re : /* Topic des codeurs couche-tard [4] */

#2433 Le 03/06/2011, à 06:42

Re : /* Topic des codeurs couche-tard [4] */

#2434 Le 03/06/2011, à 09:59

Re : /* Topic des codeurs couche-tard [4] */

#2435 Le 03/06/2011, à 10:39

Re : /* Topic des codeurs couche-tard [4] */

#2436 Le 03/06/2011, à 12:21

Re : /* Topic des codeurs couche-tard [4] */

#2437 Le 03/06/2011, à 12:38

Re : /* Topic des codeurs couche-tard [4] */

#2438 Le 03/06/2011, à 20:48

Re : /* Topic des codeurs couche-tard [4] */

#2439 Le 03/06/2011, à 21:51

Re : /* Topic des codeurs couche-tard [4] */

#2440 Le 03/06/2011, à 22:24

Re : /* Topic des codeurs couche-tard [4] */

#2441 Le 03/06/2011, à 22:35

Re : /* Topic des codeurs couche-tard [4] */

#2442 Le 03/06/2011, à 22:55

Re : /* Topic des codeurs couche-tard [4] */

#2443 Le 03/06/2011, à 22:56

Re : /* Topic des codeurs couche-tard [4] */

#2444 Le 03/06/2011, à 23:15

Re : /* Topic des codeurs couche-tard [4] */

#2445 Le 03/06/2011, à 23:36

Re : /* Topic des codeurs couche-tard [4] */

#2446 Le 03/06/2011, à 23:38

Re : /* Topic des codeurs couche-tard [4] */

#2447 Le 03/06/2011, à 23:43

Re : /* Topic des codeurs couche-tard [4] */

#2448 Le 04/06/2011, à 00:00

Re : /* Topic des codeurs couche-tard [4] */

#2449 Le 04/06/2011, à 00:17

Re : /* Topic des codeurs couche-tard [4] */

#2450 Le 04/06/2011, à 00:48

Re : /* Topic des codeurs couche-tard [4] */

Pied de page des forums