01:36 <alain_afpy> ERROR www(2) timed out
01:39 <alain_afpy> INFO www fixed
04:06 <alain_afpy> ERROR www(2) timed out
04:09 <alain_afpy> INFO www fixed
05:30 <alain_afpy> ERROR www(2) timed out
05:33 <alain_afpy> INFO www fixed
16:48 <alain_afpy> ERROR logs(2) timed out
16:51 <alain_afpy> INFO logs fixed
17:13 <gawel_> GMLudo: ping
20:16 <GMLudo> gawel: oui ?
20:30 <GMLudo> gawel: Ce dont je te parlais sur Twitter: https://github.com/Eyepea/panoramisk/commit/e503884114fcc11a111e49cd31c5b1a63040f275
20:31 <GMLudo> gawel: il y a encore deux tests qui cassent, aucune idée pour les réparer
20:33 <GMLudo> gawel: et en bons track, dans la class Message, il y avait deux noms pour la même chose: text et content, j'ai tout mis avec content
20:55 <GMLudo> -bons +bonus
21:30 <gawel> GMLudo: ama tu perds tout l'asynchrone, la. je vois pas trop comment ça va marcher
21:31 <gawel> l'idée de stocker les réponses dans un dict ça me va moyen
21:34 <gawel> ca me semble pas viable en tout cas. je me trompe peut-être
21:42 <foxmask> Debnet: merci je vais voir ca
21:45 <GMLudo> gawel: justement, je stocke des futures dedans, le dict sert juste à retrouver la bonne future
21:46 <gawel> je vois
21:46 <gawel> pourquoi pas
21:46 <GMLudo> gawel: en tout cas, tu as des + gros problèmes de blocages synchrones en utilisant requests qu'en passant par un dict ;-)
21:46 <gawel> clairement
21:46 <GMLudo> gawel: si tu as une meilleure suggestion, je suis preneur
21:47 <GMLudo> mais ce qui est sûr, c'est que j'ai eu des désynchros entre les actions et les réponses dès que j'oubliais de consommer une réponse dans la queue
21:47 <GMLudo> c'est comme ça que je suis tombé dessus
21:48 <GMLudo> c'est pour cette raison que tu passes par arawman pour les actions ?
21:49 <gawel> non, c'est pour être compatible python2
21:50 <GMLudo> je ne comprends pas, c'est quoi le stress d'envoyer les actions en AMI avec python2 ?
21:50 <gawel> faut utiliser yield from
21:51 <GMLudo> y'a pas non plus les futures ?
21:51 <gawel> si
21:52 <GMLudo> c'est ce que j'ai fait dans le send_action_via_manager(), j'utilise une future, comme ça, tu peux utiliser yield from ou les callbacks
21:52 <GMLudo> j'ai mis un exemple dans le docstring de la méthode
21:53 <gawel> ok
21:53 <GMLudo> et pour info, y'a longtemps, en Asterisk 1.4, j'avais utilisé AJAM (arawman) sur un projet avec bcp d'actions à faire, le serveur HTTP dans Asterisk, il n'était pas vraiment scalable par rapport à AMI
21:54 <GMLudo> tiens, par contre, pourquoi tu tiens à une compatibilité avec Python 2 ?
21:55 <gawel> parceque c'est pas si mal
21:56 <gawel> et que le serveur ou je l'utilise a que python 2
21:56 <gawel> mais je m'en fou un peu, en fait. suffit de dire qu'a telle version c'est plus compatible
21:57 <GMLudo> bah, pas de stress, mais de mon point de vue, si j'étais obligé à faire du Python 2 en prod, j'utiliserais plutôt pyst2 ou starpy en fonction du contexte
21:58 <GMLudo> en tout cas, si j'ai choisi ta lib plutôt qu'obelus, c'est que je comprenais comment elle fonctionnait à peu prêt dès le début
21:59 <GMLudo> je ne suis peut-etre pas très malin, mais dans obelus, vu que ça supporte tous les frameworks asynchrones en python, avec toutes les abstractions, je ne comprend pas ce qui se passe
21:59 <GMLudo> même si en théorie, obelus fait + de trucs
22:00 <gawel> je connaissais pas
22:03 <alain_afpy> ERROR membres(2) HTTPConnectionPool(host='www.afpy.org', port=80): Request timed out. (timeout=10)
22:06 <alain_afpy> INFO membres fixed
22:08 <GMLudo> gawel: pour send_action_via_http(), j'aurais envie de l'enlever du manager, pour qu'il soit pur AMI
22:08 <GMLudo> et pourquoi avoir le support d'AJAM dans un fichier séparé
22:09 <GMLudo> -pourquoi +pourquoi pas
22:15 <gawel> fais toi plaisir
22:18 <GMLudo> gawel: Ok. Je te ferais une pull request dans la semaine. Par contre, je crois que j'aurais besoin de tes lumières, pour fixer les tests.
22:21 <gawel> ok