Cython sous windows

Salut à tous,

Je développe un soft qui utilise cython (avec OpenMP).
Sous linux, nickel. Mon module binaire à comme dépendances:
ldd /usr/lib/python2.6/dist-packages/pyFAI/histogram.so
	linux-vdso.so.1 =>  (0x00007fff1f5ff000)
	libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f7493762000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7493546000)
	libc.so.6 => /lib/libc.so.6 (0x00007f74931e4000)
	librt.so.1 => /lib/librt.so.1 (0x00007f7492fdc000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7493bb2000

Sous windows, je ne suis pas à l'aise mais j'ai des beta-testeurs, ils utilisent pythonXY et compilent
avec mingw le module binaire.
Tout se passe bien à la compilation sous windows mais à l'import (import pyFAI.histogram), python se
plaint d'une DLL manquante (sans que je sache laquelle)

Quelqu'un avec des connaissances pythoniques sous windows a-t-il une idée d'où vient le probleme ?
LD_LIBRARY_PATH de libgomp ou libpthread ? comment on «regle» cela sous windows ???

Voila ce n'est finalement pas très pythonique comme question :/

Merci d'avance à ceux qui ont des idées sur la cause du bug.

--

-- 
Jérôme Kieffer

PS: Le code source est là:
svn co http://forge.epn-campus.eu/svn/azimuthal/pyFAI
Il y a un script build-msi.bat qui construit l'installeur windows qu'il faut executer (il est dans le

Re: Cython sous windows

On Tue, 4 Oct 2011 20:07:56 +0200
Jérôme Kieffer <jerome.kieffer <at> crans.org> wrote:

> Merci d'avance à ceux qui ont des idées sur la cause du bug.

en googlant mieux j'ai trouvé

http://comments.gmane.org/gmane.comp.python.cython.user/4169

mais je ne sais pas encore si cela marche.
-- 
Jérôme Kieffer <jerome.kieffer <at> crans.org>

--

-- 
Gerez vos abonnements aux listes de diffusion : http://listes.aful.org

Urllib2 hang up

Bonjour,

J'essaie de coder un client automatique qui doit tester sur le site de
mon client des milliers de numéro chaque ligne. Depuis quelques jours
(probablement en raison de coupure internet qui se sont intensifiés -
je suis au Sénégal), j'ai un hang up sur urllib2.

Je lance 25 threads du code ci-dessous simultanément, mais pour
reproduire l'erreur je dois même aller plus haut (genre 60 threads ou
quelque chose comme ça la nuit). En journée, vu que la bande passante
internet est utilisé, même 10 threads ont de bonnes chance de
provoqués l'erreur.

Je sais que le hangup se situe sur les lignes with
contextlib.closing(client.open('<url_client_1>', ...) pas toujours les
mêmes (la présence des LOG.debug me le confirme)

Comment éviter ce problème sachant qu'il n'est à priori pas stable de
killer les threads de façon extérieure d'après mes recherches, mais si
c'est la seule solution comment le faire le moins salement possible,
sinon que faire. Je précise que j'ai bien un
socket.setdefaulttimeout(10) au démarrage de mon application, et que
la variable timeout qui est passé dans chaque appel est aussi
positionnée sur 10 secondes. Pourtant cette nuit il est resté bloqué
plusieurs heures. Parfois ça débloque, parfois non ...

Autre question, malgré le contextlib.closing, j'ai 75 CLOSE_WAIT
restant avant de kill le process

Voilà le code :

Problème encodage avec rpclib et MySQL

Bonjour la liste,

Je crois bien que c'est mon premier poste alors je vous salue respectueusement.

Je suis en train de coder un serveur de web service SOAP avec rpclib,
en Python 2.7
J'attaque une base MySQL ainsi configurée :
| character_set_client | utf8       |
| character_set_connection | utf8       |
| character_set_database | latin1     |
| character_set_filesystem | binary     |
| character_set_results | utf8       |
| character_set_server | latin1     |
| character_set_system | utf8       |

quelque soit la façon dont j'instancie mon moteur SQLAlchemy :
myengine = create_engine(mysqlURL, echo=True)
myengine = create_engine(mysqlURL, encoding='latin1', echo=True)
myengine = create_engine(mysqlURL, encoding='utf8', echo=True)

je récupére la même erreur ;
  File "C:\Python27\lib\site-packages\rpclib-2.4.4_beta-py2.7.egg\rpclib\protocol\xml\model\_base.py",
line 79, in base_to_parent_element
    elt.text = cls.to_string(value)
  File "lxml.etree.pyx", line 916, in lxml.etree._Element.text.__set__
(src/lxml/lxml.etree.c:36134)
  File "apihelpers.pxi", line 721, in lxml.etree._setNodeText
(src/lxml/lxml.etree.c:17141)
  File "apihelpers.pxi", line 1366, in lxml.etree._utf8
(src/lxml/lxml.etree.c:22211)

Re: Cython sous windows

Salut,

Maintenant cela fonctionne presque ... il suffit de fournir la DLL qui va bien.
J'ai un setup.py (en piece jointe) qui essaye de le faire si on est sous windows:

installDir = os.path.join(get_python_lib(), "pyFAI")
if sys.platform == "win32":
    data_files = [(installDir, [os.path.join("dll", "pthreadGC2.dll")])]
else:
    data_files = []

Cela fonctionne bien si je fais un "python setup.py install" mais pas si je construis un paquet avec
"python setup.py build_msi" la DLL n'est pas incluse et forcément cela marche moins bien.

J'en appelle donc aux développeurs python sous windows qui doivent être habitués à ce genre de
tracasseries, non ?

Merci de vos tuyaux
-- 
Jérôme Kieffer <jerome.kieffer <at> terre-adelie.org>

--

-- 
Gerez vos abonnements aux listes de diffusion : http://listes.aful.org

pylint

Bonjour la liste,

J'aimerais savoir comment décrypter le message :

Exception RuntimeError: 'maximum recursion depth exceeded in
__subclasscheck__' in <type 'exceptions.AttributeError'> ignored

et comment remonter jusqu'au code qui le déclenche.

Il y a quelque part des imports circulaires [?] que je devrais ou
pourrais éviter ?

rb

--

-- 
Gerez vos abonnements aux listes de diffusion : http://listes.aful.org

Inscription

Je souhaiterais m'inscrire à cette liste.

Cordialement

-- 
André Hetzel

https://sites.google.com/site/andrehetzel/

--

-- 
Gerez vos abonnements aux listes de diffusion : http://listes.aful.org

Re: Inscription

Re: Inscription

python-mpd / socket NAT timeout

Bonjour à tous,

Je rencontre un problème dans l'écriture d'un client pour le lecteur MPD [0]
Je m'appuie sur python-mpd [1] pour écrire ce client.

J'utilise la commande idle [2] pour scruter les changements d'état de MPD.

Cependant je bute sur un problème quand je me connecte à travers un NAT.
Il me semble que la connexion est détruite par le NAT au bout d'une heure (en
cas d'inactivité sur le socket, MPD sur "stop" par exemple).
Dans ce cas le client derrière le NAT continue de scruter la socket en vain.
J'ai contrôlé l'hypothèse de timeout du NAT en modifiant la valeur de
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established (routeur linux).

J'ai conscience que je suis peut être hors sujet. Mais je ne sais pas trop
dans quelle direction regarder pour régler ce problème.

Je me pose deux questions :
0°) L'hypothèse du NAT est elle correcte ?
1°) Si oui, dans quelle direction dois je regarder pour trouver une solution ?

Ci dessous le bout de code que j'ai utilisé pour cerner le problème.
J'ai par ailleurs essayé de de scruter la socket avec select.select() et
select.poll() comme suggérer dans la doc en ligne de python-mpd sans plus de
succès.

Merci à vous,
	Geoff

[O] http://www.musicpd.org/
[1] http://jatreuman.indefero.net/p/python-mpd/
[2] http://www.musicpd.org/doc/protocol/ch03.html#id461284

---------------------------8<-----------------------------------
#!/usr/bin/env python
# -*- coding: utf-8 -*-

import datetime
import mpd

from select import select

def main():
    cli = mpd.MPDClient()
    cli.connect('exemple.org', 6600)
    while 42:
        try:
            cli.send_idle()
            print datetime.datetime.today()
            print cli.fetch_idle()
        except KeyboardInterrupt:
            cli.disconnect()
            break

if __name__ == '__main__':
    main()
--------------------------->8-----------------------------------

--

-- 
Gerez vos abonnements aux listes de diffusion : http://listes.aful.org