Bon j'ai fait mon application python client/serveur en TCP/IP et ça
marche très bien. Mais je voulais cacher le client car la fenêtre est
très gênante quand je travail surtout quand je transfert 100mo ;).
Le problème est que quand je passe en pyw (sans console) et bien
l'application reste 3 à 4secondes et se referme automatiquement.
Le problème c'est que je ne peux pas voir le message d'erreur et que sur
le serveur (comme je n'ai pas mis de try et except) un message d'erreur
apparaît: (..., "Software caused connection abort"). Comment faire pour
que pyw ne s'arrête pas ? Y a-t-il une limite avec l'utilisation de
python sans console à propos des sockets ?
J'utilise Eclipse comme environnement de développement avec pydev comme plugin. Quand tu exécutes l'appli, elle est lancée dans un nouveau processus. Avec la solution 3, Eclipse récupère toutes les traces et les affiche dans sa console. Dans le cas d'une exception, tu peux cliquer sur la trace pour t'amener directement sur la ligne qui a généré l'erreur. Et si ton appli est plantée (ou pas), tu peux tuer le processus directement depuis éclipse.
Pour info, le même comportement est obtenu avec Boa, avec un debugger disponible en plus.
Bonjour,
J'utilise Eclipse comme environnement de développement avec pydev comme
plugin.
Quand tu exécutes l'appli, elle est lancée dans un nouveau processus.
Avec la solution 3, Eclipse récupère toutes les traces et les affiche
dans sa console. Dans le cas d'une exception, tu peux cliquer sur la
trace pour t'amener directement sur la ligne qui a généré l'erreur. Et
si ton appli est plantée (ou pas), tu peux tuer le processus directement
depuis éclipse.
Pour info, le même comportement est obtenu avec Boa, avec un debugger
disponible en plus.
J'utilise Eclipse comme environnement de développement avec pydev comme plugin. Quand tu exécutes l'appli, elle est lancée dans un nouveau processus. Avec la solution 3, Eclipse récupère toutes les traces et les affiche dans sa console. Dans le cas d'une exception, tu peux cliquer sur la trace pour t'amener directement sur la ligne qui a généré l'erreur. Et si ton appli est plantée (ou pas), tu peux tuer le processus directement depuis éclipse.
Pour info, le même comportement est obtenu avec Boa, avec un debugger disponible en plus.
Yves Lange
Le problème c'est que je ne peux pas voir le message d'erreur et que sur le serveur (comme je n'ai pas mis de try et except) un message d'erreur apparaît: (..., "Software caused connection abort"). Comment faire pour que pyw ne s'arrête pas ? Y a-t-il une limite avec l'utilisation de python sans console à propos des sockets ?
Merci utiliser try/except serait une bonne idée.
Et logging pour enregistrer l'erreur ;-) !
Par parenthèse, quand on génère une application utilisant wx avec
py2exe, les éventuels messages sont enregistrés automatiquement dans un fichier nom_du_point_exe.log. C'est pratique une fois que l'application est déployée si l'on a pas prévu d'autre moyen d'enregistrer les erreurs.
Par contre je ne sais pas si ça vient de py2exe ou de wx...
A+ jm Merci pour toutes vos réponses. Ma solution a été d'enlever les parties
print répétitif (dans la boucle while). Depuis, plus aucun problème. Je pense que Python limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine... enfin ce n'est qu'une hypothèse.
Merci encore.
PS: je trouve que try et except n'est pas vraiment la solution car elle ne me permettront pas de comprendre mon erreur ^^
Le problème c'est que je ne peux pas voir le message d'erreur et que
sur
le serveur (comme je n'ai pas mis de try et except) un message d'erreur
apparaît: (..., "Software caused connection abort"). Comment faire pour
que pyw ne s'arrête pas ? Y a-t-il une limite avec l'utilisation de
python sans console à propos des sockets ?
Merci
utiliser try/except serait une bonne idée.
Et logging pour enregistrer l'erreur ;-) !
Par parenthèse, quand on génère une application utilisant wx avec
py2exe, les éventuels messages sont enregistrés automatiquement dans un
fichier nom_du_point_exe.log.
C'est pratique une fois que l'application est déployée si l'on a pas
prévu d'autre moyen d'enregistrer les erreurs.
Par contre je ne sais pas si ça vient de py2exe ou de wx...
A+
jm
Merci pour toutes vos réponses. Ma solution a été d'enlever les parties
print répétitif (dans la boucle while). Depuis, plus aucun problème. Je
pense que Python limite les boucles avec des prints pour empêcher qu'un
application dévore l'intégralité des ressources de la machine... enfin
ce n'est qu'une hypothèse.
Merci encore.
PS: je trouve que try et except n'est pas vraiment la solution car elle
ne me permettront pas de comprendre mon erreur ^^
Le problème c'est que je ne peux pas voir le message d'erreur et que sur le serveur (comme je n'ai pas mis de try et except) un message d'erreur apparaît: (..., "Software caused connection abort"). Comment faire pour que pyw ne s'arrête pas ? Y a-t-il une limite avec l'utilisation de python sans console à propos des sockets ?
Merci utiliser try/except serait une bonne idée.
Et logging pour enregistrer l'erreur ;-) !
Par parenthèse, quand on génère une application utilisant wx avec
py2exe, les éventuels messages sont enregistrés automatiquement dans un fichier nom_du_point_exe.log. C'est pratique une fois que l'application est déployée si l'on a pas prévu d'autre moyen d'enregistrer les erreurs.
Par contre je ne sais pas si ça vient de py2exe ou de wx...
A+ jm Merci pour toutes vos réponses. Ma solution a été d'enlever les parties
print répétitif (dans la boucle while). Depuis, plus aucun problème. Je pense que Python limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine... enfin ce n'est qu'une hypothèse.
Merci encore.
PS: je trouve que try et except n'est pas vraiment la solution car elle ne me permettront pas de comprendre mon erreur ^^
NicolasP
NicolasP wrote:
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte que l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une application. Il ne faut pas perdre de vue qu'un print est lent, voire très lent. La notion de lenteur est très subjective et dépend du contexte.
Il est fort probable que le dialogue avec une carte à puce ne s'accommode pas de lenteurs dans le protocole. On peut penser que pour des raisons de sécurité, la carte à puce coupe la communication si le PC n'a pas répondu dans un temps donné (réponse trop lente = tentative de piratage). Donc méfiance sur des analyses trop rapides du genre "limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine" ce qui n'est, pour ma part, pas exact.
Nicolas
NicolasP wrote:
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu
édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte que
l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une
boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son
dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une application. Il ne faut pas perdre de vue qu'un print est lent, voire très lent. La notion de lenteur est très subjective et dépend du contexte.
Il est fort probable que le dialogue avec une carte à puce ne s'accommode pas de lenteurs dans le protocole. On peut penser que pour des raisons de sécurité, la carte à puce coupe la communication si le PC n'a pas répondu dans un temps donné (réponse trop lente = tentative de piratage).
Donc méfiance sur des analyses trop rapides du genre "limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine" ce qui n'est, pour ma part, pas exact.
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte que l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une application. Il ne faut pas perdre de vue qu'un print est lent, voire très lent. La notion de lenteur est très subjective et dépend du contexte.
Il est fort probable que le dialogue avec une carte à puce ne s'accommode pas de lenteurs dans le protocole. On peut penser que pour des raisons de sécurité, la carte à puce coupe la communication si le PC n'a pas répondu dans un temps donné (réponse trop lente = tentative de piratage). Donc méfiance sur des analyses trop rapides du genre "limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine" ce qui n'est, pour ma part, pas exact.
Nicolas
hg
NicolasP wrote:
NicolasP wrote:
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte que l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une
application. Il ne faut pas perdre de vue qu'un print est lent, voire très lent. La notion de lenteur est très subjective et dépend du contexte. Il est fort probable que le dialogue avec une carte à puce ne s'accommode pas de lenteurs dans le protocole. On peut penser que pour des raisons de sécurité, la carte à puce coupe la communication si le PC n'a pas répondu dans un temps donné (réponse trop lente = tentative de piratage). Donc méfiance sur des analyses trop rapides du genre "limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine" ce qui n'est, pour ma part, pas exact.
Nicolas
Pas possible: les appels aux cartes sont synchrones et l'appli en question n'était pas multi-thread. Mais je suis d'accord '...l faut toujours savoir ce que l'on fait ...' ;-)
hg
NicolasP wrote:
NicolasP wrote:
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu
édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte
que l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une
boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son
dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une
application. Il ne faut pas perdre de vue qu'un print est lent, voire très
lent. La notion de lenteur est très subjective et dépend du contexte. Il
est fort probable que le dialogue avec une carte à puce ne s'accommode pas
de lenteurs dans le protocole. On peut penser que pour des raisons de
sécurité, la carte à puce coupe la communication si le PC n'a pas répondu
dans un temps donné (réponse trop lente = tentative de piratage). Donc
méfiance sur des analyses trop rapides du genre "limite les boucles avec
des prints pour empêcher qu'un application dévore l'intégralité des
ressources de la machine" ce qui n'est, pour ma part, pas exact.
Nicolas
Pas possible: les appels aux cartes sont synchrones et l'appli en question
n'était pas multi-thread. Mais je suis d'accord '...l faut toujours savoir
ce que l'on fait ...' ;-)
Pas avec wxPython. En tout cas, j'ai jamais eu de problèmes. Sauf si tu édites ton appli avec IDLE. IDLE lance ton appli dans le même contexte que l'éditeur. Du coup, si tu plantes ton appli, tu plantes IDLE. Et une boucle infinie, c'est comme planter l'appli.
En fait ça ne plantait pas l'appli mais semblait avoir un impact sur son dialogue avec une carte à puce
Il faut toujours savoir ce que l'on fait. Surtout quand on debug une
application. Il ne faut pas perdre de vue qu'un print est lent, voire très lent. La notion de lenteur est très subjective et dépend du contexte. Il est fort probable que le dialogue avec une carte à puce ne s'accommode pas de lenteurs dans le protocole. On peut penser que pour des raisons de sécurité, la carte à puce coupe la communication si le PC n'a pas répondu dans un temps donné (réponse trop lente = tentative de piratage). Donc méfiance sur des analyses trop rapides du genre "limite les boucles avec des prints pour empêcher qu'un application dévore l'intégralité des ressources de la machine" ce qui n'est, pour ma part, pas exact.
Nicolas
Pas possible: les appels aux cartes sont synchrones et l'appli en question n'était pas multi-thread. Mais je suis d'accord '...l faut toujours savoir ce que l'on fait ...' ;-)
