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

Pylades · Le 15/01/2011, à 13:34

ArkSeth a écrit :

Merci pour les explications, Pylade, et j'comprends mieux pourquoi tu me sortais (à tord ) que ça ne faisait pas ce que j'attendais :
Pylade a écrit :
Ensuite, les exception peuvent être levée en cas d'erreur de « code » (SyntaxError ou NameError, par exemple) ou d'erreur d'exécution (car il n'y a pas de compilation, on ne détecte donc pas les erreurs de « code » en amont)
Justement, celles-là, je veux que ça les bloque aussi ^^
Dans la pratique, les exceptions que je reçois sont même quasiment tout de temps des problèmes dans mon code, je n'ai encore jamais vu le chargement d'un module planter de lui-même, sans que j'ai fait une bêtise.

Ça erreur, en général, on ne les intercepte pas. On commente éventuellement le chargement du module jusqu'à la résolution de l'erreur, mais on ne les ignore pas. Il ne faut pas oublier que pour un langage compilé, tu te prendrais une erreur de compilation ou une segfault (oui, je sais, on peut intercepter les SIGSEGV ; mais c'est en général une mauvaise idée et ne protège de toutes façons pas d'un plantage).

ArkSeth a écrit :

Ceci dit, effectivement, je n'avais pas pensé à l'infime probabilité de risques que l'utilisateur fasse un Ctrl+C dans la microseconde au cours de laquelle le programme tente de charger un plugin…

Un module peut prendre plus d'une seconde à se charger, ça dépend de plein de choses… La probabilité peut être significative. C'est alors un bug.

ArkSeth a écrit :

Y a moyen de dire « toutes les exceptions, quelles qu'elles soient, sauf celle-là » ?

Non, car ça n'aurait pas de sens. Cependant, tu peux toujours faire ce truc pas joli :

try:
  import plugin
except KeyboardInterrupt:
  raise KeyboardInterrupt
except:
  print('loading failled')

C'est juste moche et ça ne te donnera pas l'endroit où tu étais lors de l'interruption.

ArkSeth a écrit :

M'enfin, dans le pire des cas, il n'y à qu'à en faire deux d'affilée, ça doit marcher…
[…]

J'espère que tu conviendra que c'est très moche et que cela constitue un bug (continuer en ignorant un plugin alors que l'on a demandé une interruption. Par ailleurs, il y a des cas où deux fois ne suffisent pas, comme dans le compteur, où l'on essaie quinze fois d'ouvrir une une page. À chaque ^C, ce n'est pas la page qui n'a pas pu être chargé, cependant on fait comme si et on repart dans un nouvel essai…

Pour le reste, je ne vois que deux façons de faire : lorsqu'une erreur survient, soit essayer de remédier à l'erreur et continuer l'exécution, soit s'arrêter proprement ; en fonction de l'erreur. Mais quand tu n'as aucune idée de ce qu'est l'erreur, tu ne peux pas choisir le comportement approprié. Tu décide alors d'ignorer l'erreur. Je ne trouve pas ça propre et potentiellement dangereux, c'est tout.

Et si tu n'es toujours pas d'accord, tant pis, fin de la discussion sur ce point.

Elzen · Le 15/01/2011, à 13:51

J'voudrais juste ton avis sur le comportement du gnome-panel (ou autres trucs de ce genre) sur le fait de prévenir l'utilisateur qu'un module n'a pas pu être chargé pour quelque raison que ce soit (et de lui proposer, accessoirement, de le virer de sa config, ce qu'il faudrait aussi que je fasse, d'ailleurs), de façon à ce qu'un plantage pour un module précis ne fasse pas en sorte que le seul module fautif empêche pas toute l'appli de se lancer et, dans l'hypothèse où tu conviendrais avec moi que c'est quand même un comportement plus agréable à l'utilisation qu'un plantage généralisé lorsque l'erreur ne porte que sur un seul petit module mais que tu ne t'attendais pas à ce plantage, que tu m'expliques comment tu envisages de mettre en place ce comportement de façon propre

Dernière modification par ArkSeth (Le 15/01/2011, à 13:53)

Pylades · Le 15/01/2011, à 14:29

ArkSeth a écrit :

[…] (et de lui proposer, accessoirement, de le virer de sa config, ce qu'il faudrait aussi que je fasse, d'ailleurs) […]

Ça, en revanche, c'est très bien. Pour être propre il faudrait connaître la liste des exceptions que le module est susceptible de lever lors de son chargement. Ainsi, tu agis en fonction de chacun d'entre elle. Et si l'exception est inattendue, c'est qu'il y a quelque chose à corriger, compromettant potentiellement le bon déroulement de ton application, donc dans ce cas autant planter en affichant un message de diagnostic un peu précis, le traceback.

Bon, sinon je ne connais pas suffisamment gnome-panel pour en parler.

Édit : par virer de la config, à la relecture je crois que je n'ai pas bien saisi ce que tu voulais dire. J'avais pensé à proposer de continuer en n'utilisant pas le plugin, ou s'arrêter. Mais en effet, proposer de retirer le plugin du fichier de configuration, pourquoi pas… mais là il faut bien être sûr que le problème vient du plugin en lui-même.

Dernière modification par Pylade (Le 15/01/2011, à 14:36)

Elzen · Le 15/01/2011, à 14:53

Pylade a écrit :

Et si l'exception est inattendue, c'est qu'il y a quelque chose à corriger, compromettant potentiellement le bon déroulement de ton application

Nan, seulement du plugin, qui ne connaît du reste de l'application que la référence d'un composant GTK vers son conteneur.

Pylade a écrit :

J'avais pensé à proposer de continuer en n'utilisant pas le plugin

Bah c'est ça que j'essaye de faire, justement, et pour lequel j'te demande comment tu ferais de manière propre.

Parce qu'à moins de lister X cas possibles et de déclarer pompeusement « le reste ne devrait pas se produire », auquel cas je traiterais les X cas possibles exactement comme je traite actuellement n'importe quel cas pouvant survenir (à savoir prévenir et continuer), mais où les cas non-prévus causeraient un plantage généralisé qui est exactement le contraire de ce que je veux obtenir, je ne vois pas comment faire.

(Et j'ai aussi quelques doutes sur le fait que « except machin: print machin ; except truc print truc ; except bidule: print bidule » soit plus propre qu'un « except: print » général quand on veut que ça marche pour le cas général)

Pylades · Le 15/01/2011, à 15:03

Ben tu peux faire ça :

try:
  import plugin
except (FirstError, SecondError, ThirdError):
  print('The plugin could not be loaded.', file=sys.stderr)

Si l'exception levée est imprévue, je trouve qu'il vaut mieux planter et avoir un traceback, mais bon, tu fais comme tu veux…

Dernière modification par Pylade (Le 15/01/2011, à 15:04)

grim7reaper · Le 15/01/2011, à 23:47

Bon, j'ai enfin un peu remis le nez dans le code du CLFB.

Actuellement je suis en train de modifier ma fonction execCmd pour qu'elle utilise la monade Writer.

execCmd :: Command -> IO [Command]

devient donc

execCmd :: Command -> IO (Writer [String] String)

Ce qui me permet de gérer le mode verbeux de manière un peu plus propre

Elzen · Le 15/01/2011, à 23:52

Tiens, pour le CLFB, on avait même pas parlé des histoires de montage/démontage de périphériques… les gestionnaires de fichiers graphiques font ça, pourtant. Ça pourrait faire une troisième extension possible (mais alors il faudrait que ça puisse gérer les périphériques réseaux genre avec sshfs et curlftpfs).

grim7reaper · Le 15/01/2011, à 23:56

Mouais, plus ça va plus il devient bloated ce CLFB, je voyais plus un truc KISS à la base. Ok c'est juste en option optionnelle, mais quand même…
Après c'est juste mon impression.

Moi la gestion des périphériques je la délègue à udev.

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

Elzen · Le 16/01/2011, à 00:01

Disons que quand tu as le CLFB lancé et que tu te rends compte que tu n'as pas encore monté la clef/le périphérique réseau sur lequel tu veux aller chercher/mettre les fichiers, ça fait un peu bizarre de devoir quitter, monter et relancer (ou passer par une autre fenêtre/un autre onglet/un autre TTY) pour faire ça… mais bon, c'est peut-être pas nécessaire, effectivement.

grim7reaper · Le 16/01/2011, à 00:05

udev gère l'automount (pour les périph' réseau je ne sais pas vu que je n'en ai jamais utilisé, mais pour les périph' « standard » il le fait c'est sûr)

helly · Le 16/01/2011, à 00:09

Bon, demain je me remet à bosser la trad (appliquer la 2 ème fournée de suggestions de grim) et bosser le langage entant que tel…

grim7reaper · Le 16/01/2011, à 00:12

Je te ferais une troisième fournée dès que j'aurais un moment

helly · Le 16/01/2011, à 00:14

Prend ton temps hein  !

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

Sinon, tu as commencé le CLFB (ne serait-ce qu'un peu) ?

J'ai l'impression d'être un peu le seul à avoir produit un embryon de truc ^^

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

The Uploader · Le 16/01/2011, à 00:24

Wouhou, j'ai une voiture qui bouge! \o/

#include <SDL/SDL.h>
#include <SDL/SDL_framerate.h>

int main()
{
    SDL_Surface*  ecran;
    SDL_Surface* sprites;
    SDL_Surface* decor;
    SDL_Event event;
    Uint8 *touches;
    Sint16 x;
    Sint16 y;
    Sint16 faster;
    double vit=1.0;
    Sint16 status = -1;
    if(SDL_Init(SDL_INIT_VIDEO) == -1){
        printf("Unable to init SDL: %s", SDL_GetError());
    }
    else{
        FPSmanager FPSmanager;
        SDL_initFramerate(&FPSmanager);
        SDL_setFramerate(&FPSmanager,15);
        Sint16 quit = 0;
        ecran = SDL_SetVideoMode(640, 480, 24, SDL_HWSURFACE|SDL_DOUBLEBUF);
        // Contient les voitures, les têtes des joueurs, tout ça...
        if((sprites = SDL_LoadBMP("generalsprites.bmp"))!=NULL)
            SDL_SetColorKey(sprites, SDL_SRCCOLORKEY,sprites->format->Bmask|sprites->format->Rmask);
        else
            return -1;
        SDL_MapRGB(sprites->format, 186, 254, 202);
        // L'arrière-plan (vue de dessus).
        if((decor = SDL_LoadBMP("deco.bmp"))==NULL)
            return -1;
        x = decor->w/2;
        y = decor->h/2;
        touches = SDL_GetKeyState(NULL);
        SDL_Rect rcDeco;
        SDL_Rect rcVoiture={12, 176, 25, 25};
        while(!quit){
            //Boucle pour gérer les touches/événements (crade, mais c'est plus simple).
            while(SDL_PollEvent(&event)){
                quit = (event.type == SDL_QUIT);
            }
            if(!quit){
                faster=0;
                Sint16 savex=x;Sint16 savey=y;
                vit=(touches[SDLK_SPACE]) ? vit - (vit*0.4) : vit;
                if(vit<1){ //vitesse <1 = bugs
                        vit=1.0;
                }

                x = (touches[SDLK_RIGHT]) ? x +(Sint16)vit : x;
                x = (touches[SDLK_LEFT]) ? x - (Sint16)vit : x;
                if(x<320 || x>640)
                    x=savex;

                y = (touches[SDLK_DOWN]) ? y + (Sint16)vit : y;
                y = (touches[SDLK_UP]) ? y - (Sint16)vit : y;
                if(y<240 || y>900)
                    y=savey;

                if(x<savex&&savey==y){ //left
                    faster=1;
                    rcVoiture=(SDL_Rect){501,180,25,25};
                }
                else if(x>savex&&savey==y){ //right
                    faster=1;
                    rcVoiture=(SDL_Rect){137,180, 25, 25};
                }
                else if(y<savey&&savex==x){ //up
                    faster=1;
                    rcVoiture=(SDL_Rect){12,176,25,25};
                }
                else if(y>savey&&savex==x){ //down
                    faster=1;
                    rcVoiture=(SDL_Rect){268,177,25,25};
                }
                else if(y<savey&&x<savex){ //upleft
                    faster=1;
                    rcVoiture=(SDL_Rect){202,120,25,25};
                }
                else if(y<savey&&x>savex){ //upright
                    faster=1;
                    rcVoiture=(SDL_Rect){73,177,25,25};
                }
                else if(y>savey&&x<savex){ //downleft
                    faster=1;
                    rcVoiture=(SDL_Rect){203,150,25,25};
                }
                else if(y>savey&&x>savex){ //downright
                    faster=1;
                    rcVoiture=(SDL_Rect){201,176,25,25};
                }

                if(faster&&vit<10.0){
                    vit=vit+0.2;
                }
                if(!faster&&vit>1.0){
                    vit=1.0;
                }

                rcDeco.y = (y - 240);
                rcDeco.x = (x - 320);
                rcDeco.w = 640;
                rcDeco.h = 480;

                SDL_BlitSurface(decor, &rcDeco, ecran, NULL);
                SDL_BlitSurface(sprites, &rcVoiture, ecran, &rcDeco);
                SDL_Flip(ecran);
                // Pour y voir quelque chose au lieu de calculer le framerate, tout ça (c'est ce que j'ai compris)
                //SDL_Delay(20);
            }
            SDL_framerateDelay(&FPSmanager);
        }
        status = 0;
        SDL_Quit();
    }
    return status;
}

(oui sans timer, c'est un peu optimiste..)
(et le code est un peu crade )

BN;
PS : Le C ça fait un bien fou après l'Action Script.... X-)

Dernière modification par The Uploader (Le 16/01/2011, à 00:29)

helly · Le 16/01/2011, à 00:37

grim7reaper a écrit :

Sinon, tu as commencé le CLFB (ne serait-ce qu'un peu) ?
J'ai l'impression d'être un peu le seul à avoir produit un embryon de truc ^^

Un tout petit peu, mais juste en C++, et 'jai dit que finalement j'allais le faire en haskell.

grim7reaper · Le 16/01/2011, à 00:52

The Uploader a écrit :

PS : Le C ça fait un bien fou après l'Action Script.... X-)

Ouais, sauf que là c'est du C++, pas du C…

@helly : oki

Dernière modification par grim7reaper (Le 16/01/2011, à 01:11)

gnuuat · Le 16/01/2011, à 01:01

Pyrfesseur thistman, pourriez vous, s'il vous plait, avoir l'amabilité de gentiment nous explique pourquoi, en Python, dans chaque méthode on doit passer en premier paramètre le pointeur sur l'objet (conventionnellement appelé self) ?
Je vois bien que c'est ce que fait en arrière plan le C++, mais c'est invisible pour le développeur...
Alors pourquoi dans un langage sensé être plus accessible comme le python on le met en avant plan ?

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

grim7reaper a écrit :

The Uploader a écrit :
PS : Le C ça fait un bien fou après l'Action Script.... X-)
Ouais, sauf que là c'est du C++, pas du C…
[…]

Tu dis ça pour trois commentaires qui traîne ?
(En plus, je crois que c'est OK en C99.)

gnuuat a écrit :

Pyrfesseur thistman, pourriez vous, s'il vous plait, avoir l'amabilité de gentiment nous explique pourquoi, en Python, dans chaque méthode on doit passer en premier paramètre le pointeur sur l'objet (conventionnellement appelé self) ?
Je vois bien que c'est ce que fait en arrière plan le C++, mais c'est invisible pour le développeur...
Alors pourquoi dans un langage sensé être plus accessible comme le python on le met en avant plan ?

Explicit is better than implicit.

Elzen · Le 16/01/2011, à 02:00

gnuuat a écrit :

Alors pourquoi dans un langage sensé être plus accessible comme le python on le met en avant plan ?

Je ne suis pas le « Pyrfesseur thistman », mais je pense que c'est par construction : les méthodes sont d'abord liées à la classe, et donc il faut préciser à quel objet on les applique.

Ça permet par exemple, en cas d'héritage, à indiquer de façon explicite à quelle classe on fait appel pour exécuter une méthode donnée (notamment l'initialisation par ClasseMere.__init__(self)). Si on ne passait pas le pointeur, on ne pourrait pas appeler la méthode depuis le nom de la classe, et donc on aurait besoin d'un autre mécanisme pour remonter au parent.

Et puis comme tu l'as dit, le choix de « self » est conventionnel, on peut très bien l'appeler autrement si on a envie, et ça, c'est fun (Même si on l'appelle tout le temps self quand même, le fait de pouvoir changer est amusant en soi)

Rolinh · Le 16/01/2011, à 02:14

Pylade a écrit :

grim7reaper a écrit :
The Uploader a écrit :
PS : Le C ça fait un bien fou après l'Action Script.... X-)
Ouais, sauf que là c'est du C++, pas du C…
[…]
Tu dis ça pour trois commentaires qui traîne ?
(En plus, je crois que c'est OK en C99.)

Peut-être à cause de ça? (en tout cas, c'est pas très beau)

int main()

samυncle · Le 16/01/2011, à 02:17

Pylades · Le 16/01/2011, à 02:30

Ouais, aussi.
C'est horrible, mes fautes d'orthographe…

Кຼزດ · Le 16/01/2011, à 03:04

Plop

samυncle · Le 16/01/2011, à 03:06

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1201 Le 15/01/2011, à 13:34

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

#1202 Le 15/01/2011, à 13:51

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

#1203 Le 15/01/2011, à 14:29

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

#1204 Le 15/01/2011, à 14:53

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

#1205 Le 15/01/2011, à 15:03

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

#1206 Le 15/01/2011, à 23:47

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

#1207 Le 15/01/2011, à 23:52

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

#1208 Le 15/01/2011, à 23:56

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

#1209 Le 16/01/2011, à 00:01

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

#1210 Le 16/01/2011, à 00:05

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

#1211 Le 16/01/2011, à 00:09

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

#1212 Le 16/01/2011, à 00:12

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

#1213 Le 16/01/2011, à 00:14

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

#1214 Le 16/01/2011, à 00:24

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

#1215 Le 16/01/2011, à 00:24

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

#1216 Le 16/01/2011, à 00:37

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

#1217 Le 16/01/2011, à 00:52

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

#1218 Le 16/01/2011, à 01:01

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

#1219 Le 16/01/2011, à 01:44

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

#1220 Le 16/01/2011, à 02:00

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

#1221 Le 16/01/2011, à 02:14

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

#1222 Le 16/01/2011, à 02:17

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

#1223 Le 16/01/2011, à 02:30

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

#1224 Le 16/01/2011, à 03:04

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

#1225 Le 16/01/2011, à 03:06

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

Pied de page des forums