Ayant donne la chance a python (contre l'avis de la direction... :p) il
s'avere que j'ai eu raison ... Nous avons d'excellents resultats en terme de
dev, de vitesse (c'etait la principale crainte) et il tient ses promesses:
on peut utiliser le meme code sur PC X86 comme sur le materiel embedded,
qu'il soit en SH3 ou en ARM ... La classe! :)
Maintenant, une question : la gestion des erreurs. Quand ca plante quelque
part, il indique l'erreur etcetc, le module qui a plante ne tourne plus,
mais le reste si, ce qui donne une impression que le soft tourne toujours
mais avec une partie en moins.. Pas pratique.
Je me suis dit qu'il devait y avoir un parametre a passer a python pour
qu'il sorte (ou relance) automatiquement a la moindre erreur, stype
python -onerrorrestart xxx.pyc, vous voyez le genre .. et la, dans la doc,
horreur, je trouve rien...
Donc, comme il est impossible de tout prevoir, et que je ne peux pas mettre
de try catch partout, existe-t-il un moyen de dire a python de fermer ou
relancer le soft des qu'une erreur (grave ou non) apparait ?
Donc, comme il est impossible de tout prevoir, et que je ne peux pas mettre de try catch partout
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible. J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Nicolas
Donc, comme il est impossible de tout prevoir, et que je ne peux pas mettre
de try catch partout
Là, je ne suis pas d'accord.
Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Donc, comme il est impossible de tout prevoir, et que je ne peux pas mettre de try catch partout
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible. J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Nicolas
ian
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les ressouces sont limitees, mais le pire pour moi c'est que mes ptites bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou datas), par modem, par wifi ... bref, TRES communicante, et si un des appareils autour m'envoi des conneries, tout le reste peut partir en live Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
Là, je ne suis pas d'accord.
Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut
considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources
sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la
programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est
beaucoup plus lourd de gérer les erreurs correctement mais on c'est
nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de
gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les
ressouces sont limitees, mais le pire pour moi c'est que mes ptites
bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou
datas), par modem, par wifi ... bref, TRES communicante, et si un des
appareils autour m'envoi des conneries, tout le reste peut partir en live
Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les ressouces sont limitees, mais le pire pour moi c'est que mes ptites bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou datas), par modem, par wifi ... bref, TRES communicante, et si un des appareils autour m'envoi des conneries, tout le reste peut partir en live Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
NicolasP
Maintenant, sous ARM, faut faire sans ... :)
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu de mots minable mais on se rapproche de vendredi)
Tu peux très bien créer un thread de surveillance des autres threads. Chaque thread actif envoie un signal récurrent avec une périodicité donnée. Si l'un d'eux manque à l'appel, action. Et comme on est dans un environnement objet, la création et la destruction des thread passe par une classe qui référence les threads actifs au fur et à mesure de leur création/destruction.
Nicolas
Maintenant, sous ARM, faut faire sans ... :)
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu de mots minable mais on se rapproche de vendredi)
Tu peux très bien créer un thread de surveillance des autres threads.
Chaque thread actif envoie un signal récurrent avec une périodicité donnée. Si l'un d'eux manque à l'appel, action.
Et comme on est dans un environnement objet, la création et la destruction des thread passe par une classe qui référence les threads actifs au fur et à mesure de leur création/destruction.
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu de mots minable mais on se rapproche de vendredi)
Tu peux très bien créer un thread de surveillance des autres threads. Chaque thread actif envoie un signal récurrent avec une périodicité donnée. Si l'un d'eux manque à l'appel, action. Et comme on est dans un environnement objet, la création et la destruction des thread passe par une classe qui référence les threads actifs au fur et à mesure de leur création/destruction.
Nicolas
ian
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu de mots minable mais on se rapproche de vendredi)
si seulement on etait vendredi soir ... :)
Tu peux très bien créer un thread de surveillance des autres threads. Chaque thread actif envoie un signal récurrent avec une périodicité donnée. Si l'un d'eux manque à l'appel, action.
Et comme on est dans un environnement objet, la création et la destruction des thread passe par une classe qui référence les threads actifs au fur et à
mesure de leur création/destruction.
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees) on echange des infos entre les threads via des events ? si oui comment faire ? sinon peut etre utiliser un systeme de queue qui est cense etre thread safe ...
+++
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu
de mots minable mais on se rapproche de vendredi)
si seulement on etait vendredi soir ... :)
Tu peux très bien créer un thread de surveillance des autres threads.
Chaque thread actif envoie un signal récurrent avec une périodicité
donnée. Si l'un d'eux manque à l'appel, action.
Et comme on est dans un environnement objet, la création et la destruction
des thread passe par une classe qui référence les threads actifs au fur et à
mesure de leur création/destruction.
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees)
on echange des infos entre les threads via des events ? si oui comment faire
?
sinon peut etre utiliser un systeme de queue qui est cense etre thread safe
...
Et un watchdog soft c'est pas fait pour les chiens... (Désolé pour le jeu de mots minable mais on se rapproche de vendredi)
si seulement on etait vendredi soir ... :)
Tu peux très bien créer un thread de surveillance des autres threads. Chaque thread actif envoie un signal récurrent avec une périodicité donnée. Si l'un d'eux manque à l'appel, action.
Et comme on est dans un environnement objet, la création et la destruction des thread passe par une classe qui référence les threads actifs au fur et à
mesure de leur création/destruction.
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees) on echange des infos entre les threads via des events ? si oui comment faire ? sinon peut etre utiliser un systeme de queue qui est cense etre thread safe ...
+++
NicolasP
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les ressouces sont limitees, mais le pire pour moi c'est que mes ptites bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou datas), par modem, par wifi ... bref, TRES communicante, et si un des appareils autour m'envoi des conneries, tout le reste peut partir en live Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement pas avec des gros try et des except sans condition comme dans un de mes posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup améliorer la stabilité du système. Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x. Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un moment ou un autre... Evidemment, il est impossible de penser à toutes les sources d'erreurs possibles.
Nicolas
Là, je ne suis pas d'accord.
Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut
considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources
sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la
programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est
beaucoup plus lourd de gérer les erreurs correctement mais on c'est
nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de
gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les
ressouces sont limitees, mais le pire pour moi c'est que mes ptites
bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou
datas), par modem, par wifi ... bref, TRES communicante, et si un des
appareils autour m'envoi des conneries, tout le reste peut partir en live
Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement pas avec des gros try et des except sans condition comme dans un de mes posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup améliorer la stabilité du système.
Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x. Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un moment ou un autre...
Evidemment, il est impossible de penser à toutes les sources d'erreurs possibles.
Là, je ne suis pas d'accord. Je programme quasiment que sur de l'embarqué. Et en embarqué, il faut considérer que rien n'est acquis. Par exemple, c'est pas parce qu'un fichier
s'est ouvert que l'on pourra le lire ou l'écrire à volonté. Les ressources sont limitées, l'environnement hostile et l'utilisateur imprévisible.
J'ai du mal à faire passer le message aux informaticiens habitués à la programmation sur PC où ils considèrent que presque tout est possible sans
gestion d'erreur. Et ça pose de vrais problèmes. C'est vrai que c'est beaucoup plus lourd de gérer les erreurs correctement mais on c'est nécessaire ET indispensable.
Je suis d'accord, mais pas d'accord sur le fait qu'on regle tout a coup de gros try catch partout histoire de dire que c'est ok ... Comme tu dis, les ressouces sont limitees, mais le pire pour moi c'est que mes ptites bestioles recoivent de partout des donnees, par ethernet, par gsm (sms ou datas), par modem, par wifi ... bref, TRES communicante, et si un des appareils autour m'envoi des conneries, tout le reste peut partir en live Evidemment si j'ai pas le choix jvais try catcher tout ca, mais bon
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement pas avec des gros try et des except sans condition comme dans un de mes posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup améliorer la stabilité du système. Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x. Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un moment ou un autre... Evidemment, il est impossible de penser à toutes les sources d'erreurs possibles.
Nicolas
ian
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement pas avec des gros try et des except sans condition comme dans un de mes
posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup améliorer la stabilité du système.
Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x.
Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un moment ou un autre...
Evidemment, il est impossible de penser à toutes les sources d'erreurs possibles.
Justement non, il y a par exemple des lecteur de badges qui m'envoient des trames, et qui ne sont absolument pas concus par nous ... rien ne me dit qu'un pour il vont pas faire une modif dans le protocole qui fera tout foirer ... quand a tester la trame, sur toute la trame que je recois j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
+++
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement
pas avec des gros try et des except sans condition comme dans un de mes
posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup
améliorer la stabilité du système.
Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme
tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x.
Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la
trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un
moment ou un autre...
Evidemment, il est impossible de penser à toutes les sources d'erreurs
possibles.
Justement non, il y a par exemple des lecteur de badges qui m'envoient des
trames, et qui ne sont absolument pas concus par nous ... rien ne me dit
qu'un pour il vont pas faire une modif dans le protocole qui fera tout
foirer ... quand a tester la trame, sur toute la trame que je recois
j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est
une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
Les problèmes ne se règlent pas forcément à coup de try/except et sûrement pas avec des gros try et des except sans condition comme dans un de mes
posts précédents (ce qu'il faut absolument éviter).
Des simples tests pour valider une valeur de variable peuvent beaucoup améliorer la stabilité du système.
Du genre, tu reçois une trame d'un autre appareil que tu as conçu. Comme tu as conçu l'émetteur et le récepteur tu sais que la trame as une taille x.
Dans le récepteur, tu programmes tout avec cette taille sans vérifier que la trame reçue as bien la bonne taille. Erreur. La loi de Murphy dit qu'à un moment ou un autre...
Evidemment, il est impossible de penser à toutes les sources d'erreurs possibles.
Justement non, il y a par exemple des lecteur de badges qui m'envoient des trames, et qui ne sont absolument pas concus par nous ... rien ne me dit qu'un pour il vont pas faire une modif dans le protocole qui fera tout foirer ... quand a tester la trame, sur toute la trame que je recois j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
+++
NicolasP
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees) on echange des infos entre les threads via des events ? si oui comment faire ?
Je vois ça plutôt à sens unique. Les threads à surveiller envoient un signal au thread de surveillance de façon périodique. Le thread de surveillance peut alors savoir si un thread manque à l'appel lors de l'absence de signalisation.
sinon peut etre utiliser un systeme de queue qui est cense etre thread safe ...
Là, je ne sais pas ce qui est le mieux.
Nicolas
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees)
on echange des infos entre les threads via des events ? si oui comment faire
?
Je vois ça plutôt à sens unique. Les threads à surveiller envoient un signal au thread de surveillance de façon périodique. Le thread de surveillance peut alors savoir si un thread manque à l'appel lors de l'absence de signalisation.
sinon peut etre utiliser un systeme de queue qui est cense etre thread safe
...
Bonne idee aussi ca (c'est bien pour ca que je suis la, glaner les idees) on echange des infos entre les threads via des events ? si oui comment faire ?
Je vois ça plutôt à sens unique. Les threads à surveiller envoient un signal au thread de surveillance de façon périodique. Le thread de surveillance peut alors savoir si un thread manque à l'appel lors de l'absence de signalisation.
sinon peut etre utiliser un systeme de queue qui est cense etre thread safe ...
Là, je ne sais pas ce qui est le mieux.
Nicolas
NicolasP
Bon apparement on peut le savoir avec IsAlive() mais ca implique de devoir faire une boucle de test pour chaques threads :(
Dans un de mes softs j'avais commencé à faire ce qui suit avant de trouvé une meilleure solution :
def MyExceptHook(exctype, value, traceback): _oldexcepthook (exctype, value, traceback) # affichage de la trace # Faire ce qu'il y a à faire
Justement non, il y a par exemple des lecteur de badges qui m'envoient des trames, et qui ne sont absolument pas concus par nous ... rien ne me dit qu'un pour il vont pas faire une modif dans le protocole qui fera tout foirer ... quand a tester la trame, sur toute la trame que je recois j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
Ce n'était qu'un exemple pour dire qu'il faut se méfier de tout.
Nicolas
Justement non, il y a par exemple des lecteur de badges qui m'envoient des
trames, et qui ne sont absolument pas concus par nous ... rien ne me dit
qu'un pour il vont pas faire une modif dans le protocole qui fera tout
foirer ... quand a tester la trame, sur toute la trame que je recois
j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est
une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
Ce n'était qu'un exemple pour dire qu'il faut se méfier de tout.
Justement non, il y a par exemple des lecteur de badges qui m'envoient des trames, et qui ne sont absolument pas concus par nous ... rien ne me dit qu'un pour il vont pas faire une modif dans le protocole qui fera tout foirer ... quand a tester la trame, sur toute la trame que je recois j'extraits des valeurs.. impossible pour moi de verifier ces valeurs, c'est une suite de valeurs hexa, y'a rien a tester la dedans...
Bref, j'ai assez d'elements en main pour voir ce que je peux en faire
Ce n'était qu'un exemple pour dire qu'il faut se méfier de tout.
Nicolas
Mihamina (R12y) Rakotomandimby
ian wrote:
rien ne me dit qu'un pour il vont pas faire une modif dans le protocole qui fera tout foirer
Ben c'est leur faute, hein! Un badge est un élément de sécurité, qui, si il n'envoie pas les bonnes données: biiiiiiiiiiiiip.
ian wrote:
rien ne me dit
qu'un pour il vont pas faire une modif dans le protocole qui fera tout
foirer
Ben c'est leur faute, hein!
Un badge est un élément de sécurité, qui, si il n'envoie pas les bonnes
données: biiiiiiiiiiiiip.
