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

Elzen · Le 23/01/2011, à 13:37

helly a écrit :

Le truc du haut ?

Pardon ?

Pylade a écrit :

AMHA, on ne comprend pas tout de suite l'effet pellicule ; tu devrais utiliser une autre image. Et puis Peut-être que les bandes de la pellicule sont un chouïa trop larges.

Bah disons que si je rétrécis les bandes du haut, proportionnellement, on voit moins des bureaux précédents et suivants… ça peut le faire, remarque, mais ça me paraissait normal d'en mettre la moitié de chaque…

(Et j'utilise pas d'image, justement, j'ai fait ça à la va-vite : j'ai coloré le fond de la fenêtre en noir et j'ai rajouté des composants dedans pour faire les carrés blancs. Oui, c'est très moche, je sais ^^ Si quelqu'un a un .svg (pour que ça puisse s'adapter à la taille de l'écran) qui fasse pellicule sous la main, j'veux bien ^^)

Edit : ah, et si vous avez d'autres propositions d'images pour faire d'autres effets que pellicule, j'veux bien aussi, je rajouterai une option pour choisir celle qu'on veut ^^

Edit2 pour pas double-poster : c'est plus convainquant ?

(Si vous avez d'autres idées de déco possibles, j'suis preneur ^^)

Dernière modification par ArkSeth (Le 23/01/2011, à 21:12)

grim7reaper · Le 23/01/2011, à 19:55

Déjà la largeur des bandes est bien meilleure
Sinon, oui dans l'ensemble ça rend mieux (l'idéal serait d'avoir une vraie image SVG pour que ça ressemble plus à une pellicule)

Dernière modification par grim7reaper (Le 23/01/2011, à 19:57)

nany · Le 23/01/2011, à 20:10

helly · Le 23/01/2011, à 20:45

Mais c'est quoi le but du truc ? Ça bouffe 50% de l'écran .

Pylades · Le 23/01/2011, à 20:52

Helly, t'as des yeux, non ? Tu sais lire ? Bon, ben recule d'une page et sers-t-en…

Sinon, /me recherche désespérément un howto de qualité ou une bonne doc sur Readline. Même sur le site de Gnu il n'y a rien de convaincant…

grim7reaper · Le 23/01/2011, à 20:55

Ouais c'est pas la joie pour GNU Readline (et c'est encore pire pour le binding Haskell, c'est pour ça que je suis partie sur Haskeline finalement).
Un truc qui fonctionne des fois : à défaut de doc regarde du code qui s'en sert.

Elzen · Le 23/01/2011, à 21:20

grim7reaper a écrit :

Déjà la largeur des bandes est bien meilleure
Sinon, oui dans l'ensemble ça rend mieux (l'idéal serait d'avoir une vraie image SVG pour que ça ressemble plus à une pellicule)

Merci

le n@nyl@nd a écrit :

Ouais, mais c'est dans le mauvais sens, donc il faudrait le refaire…

Et puis l'inconvénient du SVG, c'est que c'est retaillable, mais pas déformable : pour les écrans qui n'ont pas la même largeur relative que le mien, j'peux pas garantir que le résultat ne soit pas assez bancal, alors que là j'suis à peu près sûr de moi.

Mais si vous avez des conseils pour améliorer le dessin, j'veux bien aussi ^^ (j'ai un peu changé de tactique par rapport à ce matin : je dessine dans un gtk.gdk.Pixbuf et je le mets dans une image au dessus, ç'plus propre).

Tiens, débilité du moteur de forum : il convertis les balises img en url dans les quotes, et après, il veut pas poster parce qu'il y a une balise url dans une autre -_-

helly a écrit :

Mais c'est quoi le but du truc ? Ça bouffe 50% de l'écran .

Ça ne bouffe de l'écran qu'au moment où tu le lances (et à ce moment-là, ça en bouffe 100%, jusqu'à ce que tu le fermes).

Tu vois ce qui se passe quand tu fais ctrl+alt+bas sous Compiz ? Bah le but, c'est d'avoir un truc de ce genre-là quel que soit le gestionnaire de fenêtres.

kamui57 · Le 23/01/2011, à 22:20

j'aime bien, peut-être pourrais-tu faire les rectangles blancs moins larges, pour avoir des proportions se rapprochant de celles de l'image du n@nyl@nd ?

grim7reaper · Le 23/01/2011, à 22:33

Bon, suite à quelque tests je change d'approche pour le CLFB : j'ai revu le rôle des fonctions decodeCmd et execCmd.

Pour le moment que du bon (simplification de la REPL, plus besoin de la monade Writer, code plus logique au final).
Seul bémol, j'ai dû amoindrir la pureté la fonction de la fonction decodeCmd (mais bon, on a rien sans rien).

Migration du code en cours…

Elzen · Le 23/01/2011, à 22:36

kamui57 a écrit :

j'aime bien, peut-être pourrais-tu faire les rectangles blancs moins larges, pour avoir des proportions se rapprochant de celles de l'image du n@nyl@nd ?

Hmm… j'essayerai.

Par contre, ça fait un peu bizarre juste au moment du déclenchement, quand il fait le tour de tous les bureaux pour prendre les screenshots, mais bon ^^"

Dernière modification par ArkSeth (Le 23/01/2011, à 22:36)

helly · Le 23/01/2011, à 22:52

BN à 1 point tiens !

Sir Na Kraïou · Le 24/01/2011, à 00:03

.

gnuuat · Le 24/01/2011, à 00:14

static char* gwd(void)
{
    size_t n = WD_SIZ_BASE; // Nom plus explicite ? On comprend que c'est une taille, mais pas de quoi :/
    char* ret = NULL; // De meme...
    do
    {
        free(ret);
        ret = malloc(n * sizeof(ret)); // Si tu tombes sur une archi completement frappadingue
        // Je trouve que mettre la partie droite est plus explicite + suppression du else.
        if (ret == NULL)
            die(-1, "Alloc' failed.\n");
        errno = 0;
        if (!getcwd(ret, n))
        {
            if (errno == ERANGE)
                n += n/2;
            else if (errno == ENOENT)
                // Ca a quel comportement "..." "..." O__o ?
                die(-2, "The working directory was removed. "
                        "This error is not handled yet.\n");
            else
                die(-1, "Unknown error occured.\n");
        }
    } while (errno);
    // Faire plus explicite dans la condition de la boucle : mettre la partie droite de la condition
    return ret;
}

grim7reaper · Le 24/01/2011, à 00:32

gnuuat a écrit :

size_t n = WD_SIZ_BASE; // Nom plus explicite ? On comprend que c'est une taille, mais pas de quoi :/
char* ret = NULL; // De meme...

Bah c'est quand même explicite (dans ce contexte bien sûr) que ret signifie return et WD signifie Working Directory…

gnuuat a écrit :

ret = malloc(n * sizeof(ret)); // Si tu tombes sur une archi completement frappadingue

Faudra le dire combien de fois : sizeof(char) vaut TOUJOURS 1 peut importe l'archi (même s'il est codé sur 24 bits comme sur certains DSP).
C'est dans la norme, si le compilo de l'archi ne respecte pas la norme ce n'est pas le code qui est dans l'erreur mais le concepteur du compilo.
Au passage, ton truc est faux (c'est sizeof *ret à la limite, mais pas sizeof ret).

Sinon, que tu veuille mettre un sizeof(*ret) pour des raisons esthétiques, je n'y vois pas d'objections. Mais que tu nous sortes un argument pseudo‑technique pour justifier ton truc -_-"

Après pour la partie droite, sur des conditions simples comme ça je trouve ça inutile (mais bon là c'est subjectif, les deux choix sont valables).

Dernière modification par grim7reaper (Le 24/01/2011, à 00:32)

gnuuat · Le 24/01/2011, à 00:49

grim7reaper a écrit :

gnuuat a écrit :
size_t n = WD_SIZ_BASE; // Nom plus explicite ? On comprend que c'est une taille, mais pas de quoi :/
char* ret = NULL; // De meme...
Bah c'est quand même explicite (dans ce contexte bien sûr) que ret signifie return et WD signifie Working Directory…

Cool, ça signifie que c'est une chaine de caractère à retourner... Et sinon c'est quoi cette chaine de caractère à retourner ?
Non, mais parce que s'il n'y avait pas l'utilisation de la macro WD_SIZ_BASE pour l'initialisation de n, on pourrait se poser quelques questions... Des noms de variables plus explicites, c'est toujours mieux.

grim7reaper a écrit :

gnuuat a écrit :
ret = malloc(n * sizeof(ret)); // Si tu tombes sur une archi completement frappadingue
Faudra le dire combien de fois : sizeof(char) vaut TOUJOURS 1 peut importe l'archi (même s'il est codé sur 24 bits comme sur certains DSP).
C'est dans la norme, si le compilo de l'archi ne respecte pas la norme ce n'est pas le code qui est dans l'erreur mais le concepteur du compilo.
Au passage, ton truc est faux (c'est sizeof *ret à la limite, mais pas sizeof ret).
Sinon, que tu veuille mettre un sizeof(*ret) pour des raisons esthétiques, je n'y vois pas d'objections. Mais que tu nous sortes un argument pseudo‑technique pour justifier ton truc -_-"
Après pour la partie droite, sur des conditions simples comme ça je trouve ça inutile (mais bon là c'est subjectif, les deux choix sont valables).

Nuhu, me aculpa, c'est effectivement sizeof(*ret).
C'est vrai que mon argumentation était un peu molle, mais imaginons qu'il décide de transformer sa chaine de caractère en structure (qui a dit pseudo objet ?), ça lui ferait ça de moins...

edit :
Par contre là c'était pas une critique :

die(-2, "The working directory was removed. "
                        "This error is not handled yet.\n");

Je me demandais juste quel comportement avait le compilateur C face à "..." "...", j'avoue ne jamais l'avoir croisé/pensé avant, et ça m'intéresserait de savoir (ça a pas l'air d'être une erreur, car sinon le compilateur lui aurait gueulé dessus).

Dernière modification par gnuuat (Le 24/01/2011, à 00:51)

grim7reaper · Le 24/01/2011, à 00:58

gnuuat a écrit :

Cool, ça signifie que c'est une chaine de caractère à retourner... Et sinon c'est quoi cette chaine de caractère à retourner ?
Non, mais parce que s'il n'y avait pas l'utilisation de la macro WD_SIZ_BASE pour l'initialisation de n, on pourrait se poser quelques questions... Des noms de variables plus explicites, c'est toujours mieux.

Ouais, après reflexion je suis d'accord.
ret c'est sympa pour renvoyer juste une valeur du genre code d'erreur mais quand on renvoie un truc qui à un peu plus de sens autant donner un nom plus parlant.

gnuuat a écrit :

C'est vrai que mon argumentation était un peu molle, mais imaginons qu'il décide de transformer sa chaine de caractère en structure (qui a dit pseudo objet ?), ça lui ferait ça de moins...

Là d'accord, c'est un meilleur argument .
Cela dit, s'il remplace sa chaîne de caractère par une pseudo-structure (je suppose que tu penses à une structure qui gèrerai la chaîne en interne comme le type string de certains langage) je pense qu'il va allouer qu'une seule pseudo‑structure (et non pas n !) donc dans ce cas il faut quand même qu'il modifie sa ligne d'allocation.
Au final, le gain n'est pas flagrant : il faudra quand même revenir faire une modif' (seule la raison change).

gnuuat a écrit :

edit :
Par contre là c'était pas une critique :
die(-2, "The working directory was removed. "
                        "This error is not handled yet.\n");
Je me demandais juste quel comportement avait le compilateur C face à "..." "...", j'avoue ne jamais l'avoir croisé/pensé avant, et ça m'intéresserait de savoir (ça a pas l'air d'être une erreur, car sinon le compilateur lui aurait gueulé dessus).

Concaténation.
Ça permet de respecter les limites au niveau taille de ligne (genre 80 caractères) sans multiplier les appels au fonction d'I/O

Après, pour rester portable il faut respecter les limites de tailles pour les chaînes littérales : 509 caractères pour du C89, 4095 pour du C99 et pas de limite pour du C++.

Dernière modification par grim7reaper (Le 24/01/2011, à 04:01)

Pylades · Le 24/01/2011, à 01:16

Hum, dans une fonction qui s'appelle gwd, qui est appelée pour donner sa valeur à pwd, et qui a pour principale tâche d'appeler getcwd, je pense que l'on peut aisément devenir ce qu'est le retour.
Mais c'est vrai qu'un nom plus adapté serait peut-être mieux…

Et si je fais en sorte que ce ne soit plus une chaîne, je ne peux tout simplement plus appeler getcwd, donc bon… je ne crois pas qu'un sizeof *ret s'impose…

Et la concaténation des chaînes littérales, c'est autrement plus élégant que les

"…\
…"

et c'est ce qui est conseillé de faire.

gnuuat · Le 24/01/2011, à 01:28

Pylade a écrit :

Hum, dans une fonction qui s'appelle gwd, qui est appelée pour donner sa valeur à pwd, et qui a pour principale tâche d'appeler getcwd, je pense que l'on peut aisément devenir ce qu'est le retour.
Mais c'est vrai qu'un nom plus adapté serait peut-être mieux…

De toute façon, la lisibilité, c'est toujours purement subjectif.

Pylade a écrit :

Et si je fais en sorte que ce ne soit plus une chaîne, je ne peux tout simplement plus appeler getcwd, donc bon… je ne crois pas qu'un sizeof *ret s'impose…

getcwd(wd->string, wn->len);

Pylade a écrit :

Et la concaténation des chaînes littérales, c'est autrement plus élégant que les
"…\
…"
et c'est ce qui est conseillé de faire.

Je connaissais pas, ça à l'air sympa .

kamui57 · Le 24/01/2011, à 01:45

grim7reaper a écrit :

gnuuat a écrit :
Cool, ça signifie que c'est une chaine de caractère à retourner... Et sinon c'est quoi cette chaine de caractère à retourner ?
Non, mais parce que s'il n'y avait pas l'utilisation de la macro WD_SIZ_BASE pour l'initialisation de n, on pourrait se poser quelques questions... Des noms de variables plus explicites, c'est toujours mieux.
Ouais, après reflexion je suis d'accord.
ret c'est sympa pour renvoyer juste une valeur du genre code d'erreur mais quand on renvoie un truc qui à un peu plus de sens autant donner un nom plus parlant.
gnuuat a écrit :
C'est vrai que mon argumentation était un peu molle, mais imaginons qu'il décide de transformer sa chaine de caractère en structure (qui a dit pseudo objet ?), ça lui ferait ça de moins...
Là d'accord, c'est un meilleur argument .
Cela dit, s'il remplace sa chaîne de caractère par une pseudo-structure (je suppose que tu penses à une structure qui gèrerai la chaîne en interne comme le type string de certains langage) je pense qu'il va allouer qu'une seule pseudo-structure (et non pas n !) donc dans ce cas il faut quand même qu'il modifie sa ligne d'allocation.
Au final, le gain n'est pas flagrant : il faudra quand même revenir faire une modif' (seule la raison change).
gnuuat a écrit :
edit :
Par contre là c'était pas une critique :
die(-2, "The working directory was removed. "
                        "This error is not handled yet.\n");
Je me demandais juste quel comportement avait le compilateur C face à "..." "...", j'avoue ne jamais l'avoir croisé/pensé avant, et ça m'intéresserait de savoir (ça a pas l'air d'être une erreur, car sinon le compilateur lui aurait gueulé dessus).
Concaténation.
Ça permet de respecter les limites au niveau taille de ligne (genre 80 caractères) sans multiplier les appels au fonction d'I/O
Après, pour rester portable il faut respecter les limites de tailles pour les chaînes littérales : 509 caractères pour du C89, 4095 pour du C99 et pas de limite pour du C++.

Intéressants comme trucs !

Кຼزດ · Le 24/01/2011, à 02:01

Hop.

Rolinh · Le 24/01/2011, à 02:03

Pylades · Le 24/01/2011, à 02:09

pylade.kill(19);

gustare · Le 24/01/2011, à 02:10

j'en suis

grim7reaper · Le 24/01/2011, à 02:13

Tiens donc, un nouveau

Bienvenue.

Tu codes en quoi ?
(vu ton avatar tu dois coder en Scheme )

Pylades · Le 24/01/2011, à 02:17

'lut !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1476 Le 23/01/2011, à 13:37

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

#1477 Le 23/01/2011, à 19:55

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

#1478 Le 23/01/2011, à 20:10

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

#1479 Le 23/01/2011, à 20:45

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

#1480 Le 23/01/2011, à 20:52

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

#1481 Le 23/01/2011, à 20:55

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

#1482 Le 23/01/2011, à 21:20

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

#1483 Le 23/01/2011, à 22:20

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

#1484 Le 23/01/2011, à 22:33

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

#1485 Le 23/01/2011, à 22:36

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

#1486 Le 23/01/2011, à 22:52

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

#1487 Le 24/01/2011, à 00:03

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

#1488 Le 24/01/2011, à 00:14

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

#1489 Le 24/01/2011, à 00:32

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

#1490 Le 24/01/2011, à 00:49

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

#1491 Le 24/01/2011, à 00:58

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

#1492 Le 24/01/2011, à 01:16

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

#1493 Le 24/01/2011, à 01:28

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

#1494 Le 24/01/2011, à 01:45

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

#1495 Le 24/01/2011, à 02:01

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

#1496 Le 24/01/2011, à 02:03

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

#1497 Le 24/01/2011, à 02:09

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

#1498 Le 24/01/2011, à 02:10

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

#1499 Le 24/01/2011, à 02:13

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

#1500 Le 24/01/2011, à 02:17

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

Pied de page des forums