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

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

Scores totaux, depuis le début :

1) 3447    nesthib
2) 3080    samuncle
3) 2923    Pylade
4) 2194    Кຼزດ
5) 1706+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1673    cm-t
7) 1301    na kraïou
8) 866    helly
9) 862    \\Ouranos//
10) 659    gnuuat
11) 597    tshirtman
12) 565    Lagierl
13) 429    Rolinh
14) 368    nathéo
15) 358    The Uploader
16) 263    Kanor
17) 196    Askelon
18) 189    :!pakman
19) 121    ǤƦƯƝƬ
20) 99    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) 34    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 09/06/2011, à 07:42

Scores de la période en cours :

1) 80    Pylade
2) 43    nesthib
3) 42    Кຼزດ
4) 37    samuncle
5) 36    cm-t
6) 24    tshirtman
7) 23    :!pakman
8) 22    na kraïou
9) 20    nathéo
10) 13    grim7reaper
11) 10    Rolinh
11) 10    The Uploader
13) 4    \\Ouranos//
13) 4    kamui57
15) 1    xapantu

Kanor · Le 09/06/2011, à 08:41

http://www.alsacreations.com/article/li … istes.html
http://www.w3.org/TR/CSS21/generate.html
http://www.pompage.net/traduction/listes

Elzen · Le 09/06/2011, à 12:00

@ :!pakman :

Ah, j'comprends mieux cette histoire de tableau dans un lien. Sauf que pourquoi t'essayes à tout prix de mettre un tableau ? Si c'est pour la mise en page, utiliser un tableau pour faire de la mise en page, c'est juste mal.

D'autant que rien n'interdit, par exemple, de mettre une balise <img /> dans un <a>, et éventuellement aussi un <span> autour du texte. En CSS, tu passes l'image et le span en « display: inline-block; », et tu leurs règles une taille fixe à chacun des deux, et comme ça les deux ont bien leur taille adéquate, le texte peut être centré, et t'as pas utilisé de gros truc moche.

Sinon, si tu veux avoir les deux séparément (mais pas en tableau, parce qu'utiliser un tableau pour un rendu comme ça, c'est juste pas adapté (pense à l'accessibilité )), tu peux aussi penser à la balise <label> : quand l'attribut « for » de cette balise contient un id existant dans la page, le navigateur transmet tous les événements qu'il reçoit à l'élément possédant cet id, il me semble.

@ tout le monde :

J'essayerais bien de faire un truc d'extinction/fermeture de session propre à Touhy, mais est-ce que vous connaîtriez un moyen d'éteindre/fermer la session/redémarrer l'ordi en console qui ne nécessite ni mot de passe, ni bidouillage du fichier sudoers ? Parce que gksudo poweroff, ça le fait pas, quoi

tshirtman · Le 09/06/2011, à 12:06

dbus?

exemple:

dbus-send --system --dest=org.freedesktop.Hal --type=method_call --print-reply /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Shutdown

Dernière modification par tshirtman (Le 09/06/2011, à 12:09)

Kanor · Le 09/06/2011, à 12:08

ArkSeth regarde upower
voila un exemple de code
http://gitorious.org/batti

Sinon les labels c'est seulement pour les balise de formulaire

The Uploader · Le 09/06/2011, à 12:10

+1 dbus, sans ça sudo devient obligatoire, et au bout d'un moment ça gonfle.. (ça sert de monter sa ArchLinux...)

Dernière modification par The Uploader (Le 09/06/2011, à 12:11)

tshirtman · Le 09/06/2011, à 12:18

cela dit, hal est en déprécation, apparement gnome-power-manager est passé à packagekit, mais lui aussi semble déprécié… donc je ne sais pas quelle est la meilleur approche, hors, la ligne dbus que j'ai trouvé semble dépendre de hal…

https://wiki.ubuntu.com/Halsectomy
http://wiki.debian.org/HALRemoval

Dernière modification par tshirtman (Le 09/06/2011, à 12:19)

Elzen · Le 09/06/2011, à 12:22

@The Uploader : ouais, ça sert à poster des retours aux autres quand ils posent des questions comme ça, sûrement. Encore que pour ça, se taper le manuel entier devrait suffire, installer vraiment n'est pas forcément utile. À part ça, j'vois pas à quoi ça sert, non

@Kanor : ah ouais, tiens, quelle bêtise j'ai dit, moi ? S'rai peut-être temps que j'me réveille un peu… Sinon, je confirme que pour un rendu comme ça, sémantiquement, c'est un placement en liste, qu'il faut. Et on peut effectivement réussir le truc avec des images en :before en CSS, en effet ^^

@tshirtman : c'est pas censé être en voie d'extinction, hal ? Et si non, y a une liste des commandes DBus qui lui sont associées dispo quelque part ?

The Uploader · Le 09/06/2011, à 12:37

Ben justement, le manuel n'a jamais dit que je devais à la fois lancer dbus en tant que daemon (/etc/rc.conf) et avec la session (dans ~/.xinitrc), alors que c'est le cas.

udev/upower et autres remplacent HAL, si je me ne trompe pas... (enfin sauf sous BSD, problème de licence je crois..)

Dernière modification par The Uploader (Le 09/06/2011, à 12:40)

tshirtman · Le 09/06/2011, à 12:38

↑↑

:!pakman · Le 09/06/2011, à 12:39

Thanks pour les liens et réponses
Je regarde tout ça !

Kanor · Le 09/06/2011, à 12:43

Mais personne ne me lit ;-)

Elzen · Le 09/06/2011, à 12:47

Kanor, si si, j'suis en train d'essayer de comprendre le code en question ^^

Ç't'un gestionnaire de batterie en System Tray, c'est ça ?

Kanor · Le 09/06/2011, à 12:56

la gestion de batterie n'a aucun interet pour ta demande mais il gére aussi l'arrét l'hibernation ..
(regarde le fichier src/PowerBackend.py)
sinon champagne
https://linuxfr.org/users/albert_/journ … -a-un-clou
\o/ \o/

il reste encore flash et le web sera enfin un espace "pur" (;-) )

Dernière modification par Kanor (Le 09/06/2011, à 13:00)

The Uploader · Le 09/06/2011, à 13:07

Silverlight disparaître : Windows Phone montre le contraire d'après les commentaires.

.NET disparaître : Rien ne le laisse croire, loin de là.

Et Flash résiste encore bien! >_< (il commence à se faire bien attaquer, mais on est qu'au tout début de la dératisation..)

Dernière modification par The Uploader (Le 09/06/2011, à 13:08)

tshirtman · Le 09/06/2011, à 13:15

L'article me parait bien léger… des devs s'inquiètent par ce qu'une présentation grand public n'a pas parlé de silverlight, OMG… quoi… ça m'étonnerait que microsoft l'entère aussi facilement… ils vont faire plus d'html, c'est cool, en dehors de ça… rien à signaler pour l'instant…

Pylades · Le 09/06/2011, à 16:01

grim7reaper a écrit :

Pylade a écrit :
Ben alors, c’est la manière normale de faire de déclarer sa globale dans chaque fichier où elle est utilisée…
Est ce que j'ai dis le contraire une seulfe fois ?
Non, bon bah alors -_-"

Alors je dois juste interpréter ça :

grim7reaper a écrit :

[…]
Je ne dirais pas ça, certes ça compile.
Pour le reste… :]

comme un « les globales c’est mal » ?

grim7reaper a écrit :

Pylade a écrit :
Après ce n’est juste pas thread safe, mais je ne vois pas d’autres surprises possibles…
Pas que.
Ça a d'autres effets comme péter la réentrance aussi…

Mouais enfin pour moi ce n’est pas vraiment un problème. ^^
La principale fonction qui lit ma static pour le moment c’est die, donc de toute façons ce n’est pas réentrant…

grim7reaper a écrit :

Pylade a écrit :
(Ça indique si je tourne en interactif ou pas.)
Bah tu pourrais t'en passer alors (enfin ça dépend comment tu architectures ton code, mais si c'est bien fait je pense tu peux clairement t'en passer).

C’est bien possible. Mais la seule manière de faire que je vois, là, c’est de la passer à chaque fonction qui peut appeler die, et j’ai trouvé ça trop lourd. Mais je suis bien conscient que ce n’est pas très élégant.

grim7reaper · Le 09/06/2011, à 18:07

Pylade a écrit :

Alors je dois juste interpréter ça :
grim7reaper a écrit :
[…]
Je ne dirais pas ça, certes ça compile.
Pour le reste… :]
comme un « les globales c’est mal » ?

Hum, non pas tout à fait (stun peu radical comme point de vue).
Faut plutôt interpréter ça comme « les globales c'est une source d'emmerdes ».

Pylade a écrit :

La principale fonction qui lit ma static pour le moment c’est die, donc de toute façons ce n’est pas réentrant…

Certes, actuellement t'es pas concerné par ça
Mais si par exemple tu gérais les signaux (donc avec handler & cie), bah tu pourrais pas appeler die dans un handler. Genre tu captes un SIGINT, bah tu peux pas appeler die dans son handler. Bon en fait tu peux vu que le C est permissif, mais ça risque de mal se passer (encore que y'aurait peut‑être pas trop de merde avec cette fonction, mais ça resterait très moche).

Pylade a écrit :

C’est bien possible. Mais la seule manière de faire que je vois, là, c’est de la passer à chaque fonction qui peut appeler die, et j’ai trouvé ça trop lourd. Mais je suis bien conscient que ce n’est pas très élégant.

Quand y'a qu'une variable, ouais c'est lourd.
Mais je pense que c'est pas vraiment le cas actuellement. Le CLFB c'est un interpréteur, et les interpréteurs ont en général un contexte d'exécution. Ici t'as l'état (interactif ou pas), le mode (verbeux ou pas), etc.
Donc je pense que ça justifie une structure Context à passer à chaque fonction (du moins celle qui le nécessite), ça me semblerait propre (et c'est relativement courant comme pratique, genre quand t'embarques l'interpréteur Perl dans du C ou du Lua dans du C).

Perso, j'avais fait comme ça dans mon compilateur :

typedef struct Source_
{
    FILE* fp;
    char* filename;
    FILE* out;
    char* outfile;
    Symbol_table var_tbl;
    char token_value[MAX_LEN_IDENT];
    unsigned int lineno;
    unsigned int nb_var;
    Token_type token;
    char unget;
} Source;

Quasiment toutes les fonctions prenaient un Source* en paramètre.

Ça se retrouve aussi (même si le cas est un peu différent) quand tu fais des ADT, t'as bien le paramètre (this|me|self|autre nom) que tu passes à toutes tes fonctions.

Dernière modification par grim7reaper (Le 09/06/2011, à 18:08)

Pylades · Le 09/06/2011, à 18:31

grim7reaper a écrit :

Pylade a écrit :
La principale fonction qui lit ma static pour le moment c’est die, donc de toute façons ce n’est pas réentrant…
Certes, actuellement t'es pas concerné par ça
Mais si par exemple tu gérais les signaux (donc avec handler & cie), bah tu pourrais pas appeler die dans un handler. Genre tu captes un SIGINT, bah tu peux pas appeler die dans son handler. Bon en fait tu peux vu que le C est permissif, mais ça risque de mal se passer (encore que y'aurait peut‑être pas trop de merde avec cette fonction, mais ça resterait très moche).

Mais je n’écris sur la static qu’au tout début de l’exécution. Donc si je veux installer un handler, je le fais après avoir écrit et tout va bien, non ?

Sinon, je coup de la structure qui contient le contexte, c’est une bonne idée, je note. Mais là aussi, on est tenté de faire un pointeur global vers la structure… Et quand on y pense, ça ne change rien à la réentrence, puis que de toutes façons la fonction ira chercher ses informations par le pointeur vers la structure de contexte…

Elzen · Le 09/06/2011, à 18:47

Bon, j'ai fini plein de MàJ plus ou moins utiles sur cette bidouille infâme qu'est Touhy… esthétiquement et dans l'utilisation, je trouve que ça rend plutôt pas mal du tout. Niveau code, par contre, comme j'viens de le dire…

Bon, il me reste mon Launcher à coder, mais comme j'ai un prototype fonctionnel dont j'me sers en attendant (absolument pas releasable, mais satisfaisant pour mon utilisation personnelle), j'vais plutôt essayer de me finir le gestionnaire de bureau, qui pour l'instant n'affiche plus aucune icône.

Concernant les options Pylade-proof de ce dernier, la pseudo-transparence fonctionne bien, maintenant, mais je n'ai toujours pas réussi la transmission des clics, malgré quelques tentatives à l'aveugle aussi infructueux que mes recherches de doc. Si quelqu'un a des infos, le sujet est toujours ouvert.

:!pakman · Le 09/06/2011, à 19:08

Ça y est, le problème est résolu avec une liste, merci !
Validé XHTML !
Si vous voulez voir l'évolution du truc :
www.tunix.fr

(Ahlala, la pub gratuite )

Dernière modification par :!pakman (Le 09/06/2011, à 19:22)

grim7reaper · Le 09/06/2011, à 19:31

Pylade a écrit :

Mais je n’écris sur la static qu’au tout début de l’exécution. Donc si je veux installer un handler, je le fais après avoir écrit et tout va bien, non ?

Oui ça devrait (dans 97% des cas) le faire (c'est pour ça que j'ai dit qu'il n'y avait pas trop de merde)…
Mais ça n'est pas réentrant pour autant, tu peux recevoir un signal avant que ta variable soit initialisé et donc t'auras pas forcément le comportement attendu.
Genre le mec veut le prog en interactif, tu lis bien la valeur et paf, t'es interrompu avant l'affectation effective. Bah dans ton handler tu vas considérer que t'es pas en interactif, alors qu'en fait tu l'étais. Après, ça ne te pose peut‑être pas de problème selon le traitement que tu fais, mais ça reste craignos comme type de code…

Pylade a écrit :

Sinon, je coup de la structure qui contient le contexte, c’est une bonne idée, je note. Mais là aussi, on est tenté de faire un pointeur global vers la structure…

Hum, bah c'est pas l'idée du siècle.
Ça limite vachement (genre tu peux pas faire cohabiter plusieurs contextes, etc).

Pylade a écrit :

Et quand on y pense, ça ne change rien à la réentrence, puis que de toutes façons la fonction ira chercher ses informations par le pointeur vers la structure de contexte…

Au contraire, ça change tout.
La fonction sera réentrante si elle utilise un pointeur sur la structure plutôt qu'une globale (dans le handler t'auras pas accès au pointeur de la structure que tu utilises dans le programme, donc tu risques pas de la lire/modifier).

Pylades · Le 09/06/2011, à 19:56

grim7reaper a écrit :

Pylade a écrit :
Mais je n’écris sur la static qu’au tout début de l’exécution. Donc si je veux installer un handler, je le fais après avoir écrit et tout va bien, non ?
Oui ça devrait (dans 97% des cas) le faire (c'est pour ça que j'ai dit qu'il n'y avait pas trop de merde)…
Mais ça n'est pas réentrant pour autant, tu peux recevoir un signal avant que ta variable soit initialisé et donc t'auras pas forcément le comportement attendu.
Genre le mec veut le prog en interactif, tu lis bien la valeur et paf, t'es interrompu avant l'affectation effective. Bah dans ton handler tu vas considérer que t'es pas en interactif, alors qu'en fait tu l'étais. Après, ça ne te pose peut‑être pas de problème selon le traitement que tu fais, mais ça reste craignos comme type de code…

Ben si je choppe un signal avant d’avoir fait l’affectation, il aura l’action par défaut, vu que je n’aurai pas encore installé mon propre handler.

grim7reaper a écrit :

Pylade a écrit :
Sinon, je coup de la structure qui contient le contexte, c’est une bonne idée, je note. Mais là aussi, on est tenté de faire un pointeur global vers la structure…
Hum, bah c'est pas l'idée du siècle.
Ça limite vachement (genre tu peux pas faire cohabiter plusieurs contextes, etc).

Mouais, enfin je me vois mal faire cohabiter plusieurs contexte pour le moment. Mais je sais, on ne peut pas prévoir comment va évoluer un code et devrait toujours s’arranger pour être le plus maintenable possible.

grim7reaper a écrit :

Pylade a écrit :
Et quand on y pense, ça ne change rien à la réentrence, puis que de toutes façons la fonction ira chercher ses informations par le pointeur vers la structure de contexte…
Au contraire, ça change tout.
La fonction sera réentrante si elle utilise un pointeur sur la structure plutôt qu'une globale (dans le handler t'auras pas accès au pointeur de la structure que tu utilises dans le programme, donc tu risques pas de la lire/modifier).

int plop(int* p)
{
  return *p;
}

int main(void)
{
  int i;
  int* p = &i;
  i = 42;
  printf("%d\n", plop(p));
  i = 1337;
  printf("%d\n", plop(p));
  return 0;
}

Soit je n’ai pas compris ce qu’était une fonction réentrante, soit plop n’est pas réentrante… et pourtant elle utilise un pointeur passé en argument…

tshirtman · Le 09/06/2011, à 20:22

je pense qu'il voulait dire "aura la possibilité technique d'être réentrante sans se tirer une balle dans le pied"…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 09/06/2011, à 07:42

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

#102 Le 09/06/2011, à 07:42

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

#103 Le 09/06/2011, à 08:41

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

#104 Le 09/06/2011, à 12:00

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

#105 Le 09/06/2011, à 12:06

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

#106 Le 09/06/2011, à 12:08

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

#107 Le 09/06/2011, à 12:10

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

#108 Le 09/06/2011, à 12:18

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

#109 Le 09/06/2011, à 12:22

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

#110 Le 09/06/2011, à 12:37

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

#111 Le 09/06/2011, à 12:38

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

#112 Le 09/06/2011, à 12:39

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

#113 Le 09/06/2011, à 12:43

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

#114 Le 09/06/2011, à 12:47

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

#115 Le 09/06/2011, à 12:56

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

#116 Le 09/06/2011, à 13:07

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

#117 Le 09/06/2011, à 13:15

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

#118 Le 09/06/2011, à 16:01

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

#119 Le 09/06/2011, à 18:07

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

#120 Le 09/06/2011, à 18:31

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

#121 Le 09/06/2011, à 18:47

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

#122 Le 09/06/2011, à 19:08

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

#123 Le 09/06/2011, à 19:31

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

#124 Le 09/06/2011, à 19:56

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

#125 Le 09/06/2011, à 20:22

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

Pied de page des forums