08:22 <cyp:#afpy> plop
09:02 <Llew:#afpy> plop
09:04 <jpcw:#afpy> matin café
10:03 <glickind:#afpy> bonjour
10:05 <glickind:#afpy> A qui faut-il signaler l'erreur "une erreur est survenue pendant le trzaitement de votre requête" sur l'onglet Informations de pycon.fr ?
10:05 <NelleV:#afpy> Salut !
10:05 <NelleV:#afpy> On a un bug tracker quelque part. Deux sec
10:06 <yota:#afpy> étonnant
10:07 <NelleV:#afpy> *https://hg.io/marmoute/pyconfr/issues?status=new&status=open
10:07 <glickind:#afpy> erreur vue à FireFox 6.0 mais pas sur Internet Explorer 7.0 :(
10:08 <NelleV:#afpy> mmh, c'est pas la premiere fois
10:08 <NelleV:#afpy> c'est un problème de javascript ça encore
10:10 <glickind:#afpy> je vais compléter l'issue #8
10:11 <NelleV:#afpy> glickind: merci !
10:43 <jrx:#afpy> Bonjour
10:44 <jrx:#afpy> je vois que les inscriptions à la pyconfr sont fermées, est-ce qu'il y aura une publication de slides ou de vidéos des présentations de la pyconfr quelquepart ?
10:45 <NelleV:#afpy> jrx: en fait, on fait du surbooking si tu veux venir ;)
10:46 <Exirel:#afpy> NelleV: on fait toujours d'ailleurs ?
10:46 <NelleV:#afpy> on a 134 inscrits
10:46 <NelleV:#afpy> on a dit jusqu'à 150, non ?
10:46 <Exirel:#afpy> aucune idée, je sais pas de qui ça vient :x
10:46 <NelleV:#afpy> moi non plus :]
10:47 <jrx:#afpy> en fait, j'peux pas venir les 2 jours entiers...
10:47 <Exirel:#afpy> sinon oui il devrait y avoir les slides sur le site après
10:47 <Exirel:#afpy> (on devrait même les avoir avant)
10:47 <Exirel:#afpy> et la Cantine Numérique de Rennes veut les slides des présentations aussi
10:47 <NelleV:#afpy> (on ne les aura pas avant)
10:48 <Exirel:#afpy> (je sais :p )
10:48 <Exirel:#afpy> (c'est parfaitement illusoire de les vouloir avant)
10:48 <NelleV:#afpy> (les slides, ça se fait pendant la présentation d'avant)
10:49 <jrx:#afpy> je ne connaissais pas les imprimantes 3d open source (type Reprap)
10:49 <jrx:#afpy> ça à l'air sympa
10:50 <haypo:#afpy> ça a l'air lent, et l'objet est pas super bien fini je trouve
10:50 <haypo:#afpy> mais sur le concept, c'est très sympa :)
10:50 <jrx:#afpy> sur le site de reprap, ça a l'air de faire des objets assez correct...
10:50 <NelleV:#afpy> moi j'ai utilisé des imprimantes 3D non opensource
10:50 <NelleV:#afpy> c'est lent aussi
10:50 <haypo:#afpy> NelleV: ha ha, oui
10:51 <NelleV:#afpy> par contre, ça déchire à mort *__*
10:51 <NelleV:#afpy> c'était mon apport philosophique de la journée
10:52 <jrx:#afpy> c'est un peu comme une machine outil à commande numérique non ? http://fr.wikipedia.org/wiki/Machine-outil_%C3%A0_commande_num%C3%A9rique
10:52 <haypo:#afpy> http://en.wikipedia.org/wiki/File:3D_scanning_and_printing.jpg ah ouais, c'est mieux que ce que j'avais vu
10:52 <jrx:#afpy> haypo : ah oui, c'est sympa en effet
10:52 <haypo:#afpy> "RepRap version 2.0" ah, y'a plusieurs versions :)
10:54 <haypo:#afpy> jrx: oh, l'image vienet de wikipédia, pas sûr que ça soit fait avec reprap
10:54 <haypo:#afpy> ah voilà, moi j'avais plutôt vu des trucs genre http://reprap.org/wiki/File:Shoe-closed.jpg
10:54 <haypo:#afpy> la semelle n'est pas très nette, ça bave un peu
10:56 <jrx:#afpy> y'aura une machine reprap à la pyconfr ?
10:58 <jrx:#afpy> en tout cas le dragon est sous MeshLab http://meshlab.sourceforge.net/
11:01 <natim:#afpy> benoitc, Tu m'avais dit que tu avais fait un petit module pour générer des flashcodes en utilisant la PIL, pourrais-tu me redonner le lien stp ?
12:06 <benoitc:#afpy> flash code ? qr code ?
12:06 <alexis:#afpy> natim: c'est pas ça : https://github.com/benoitc/qrurl ?
12:18 <yota:#afpy> machine outil a commande numérique, ca me rappelle mon bac :)
12:58 <natim:#afpy> benoitc, Oui c'est les qrcode
12:59 <natim:#afpy> alexis, Si ça doit être ça
12:59 <natim:#afpy> merci
14:01 <natim:#afpy> benoitc, alexis encore une question, lorsque j'essaye de compiler le qrencode.pyx avec Cython il me mets un message d'erreur disant qu'il ne trouve pas le fichier qrencode.h quel est la manipulation à faire pour le compiler ?
14:01 <natim:#afpy> merci
14:07 <Maddingue:#afpy> peut-être installer la lib correspondante ?
14:07 <Maddingue:#afpy> par exemple, libqrencode, http://fukuchi.org/works/qrencode/index.en.html
14:09 <natim:#afpy> genre libqrencode-dev
14:09 <natim:#afpy> Oui c'est le fait qu'il y ai un qrencode.c qui m'a troublé
14:09 <natim:#afpy> Merci Maddingue
14:10 <Maddingue:#afpy> de rien
14:18 <yota:#afpy> apt-file est la vie
14:18 <yota:#afpy> (sur debian bien sur)
14:18 <yota:#afpy> (ou alors http://packages.debian.org)
14:42 <natim:#afpy> Vous trouvez qu'il faut que j'appelle la lib pyqrencode ou pyqr ?
14:57 <cyp:#afpy> natim: pourquoi t'encombrer du py ?
14:57 <natim:#afpy> Bonne question ,pour moi c'est pour signifier qu'il s'agit d'un binding
14:58 <Maddingue:#afpy> o_O
14:58 <cyp:#afpy> mouais
14:58 <natim:#afpy> T'as pas l'air d'accord Maddingue
14:59 <natim:#afpy> ça pose pas de problème d'appeler le module comme le nom du fichier cython ? Genre d'avoir du qrencode.qrencode
14:59 <natim:#afpy> Moi je trouve qu'on perds en lisibilité
14:59 <feth:#afpy> le "py" est inutile et redondant
15:00 <feth:#afpy> je trouve
15:00 <brutasse:#afpy> oui
15:00 <natim:#afpy> sinon je l'appelle qrimage
15:01 <feth:#afpy> natim: pouvoir faire le lien avec la lib originale par contre est utile :)
15:02 <natim:#afpy> Ok
15:02 <Maddingue:#afpy> natim: vu que 95% des logiciels en Python contiennent "py" dans le nom, ça n'en fera jamais qu'un de plus, mais c'est presque drole de lire la justification "pour indiquer que c'est un binding"
15:02 <natim:#afpy> Donc pyqr c'est bien alors QRCode en python
15:04 <Maddingue:#afpy> à mon avis, un nom comme qrcode ou qrimage va très bien
15:05 <feth:#afpy> En effet, c'est dommage que pyqt ne s'appelle pas simplement Qt. Mais il avait peut-être pas le droit.
15:05 <feth:#afpy> (ça aurait bien *** pyside)
15:05 <haypo:#afpy> j'trouve que python est mal traité dans Python
15:06 <haypo:#afpy> pourquoi les paquets des programmes Python s'appelle python-xxx au lieu de xxx ?
15:06 <haypo:#afpy> le paquet firefox c'est firefox, et pas firefox-c++-javascript-et-un-peu-de-xml
15:06 <haypo:#afpy> je parle des programmes, pas des bibliothèques
15:07 <haypo:#afpy> genre sphinx => python-sphinx
15:07 <misc:#afpy> le tarball s'appelle comme ça, ou le paquet d'une distro ?
15:07 <misc:#afpy> ( car je peux répondre au 2eme )
15:07 <brutasse:#afpy> le paquet de la distro
15:08 <misc:#afpy> en general, c'est pour éviter de faire conflit avec un paquet ruby-sphinx
15:08 <Maddingue:#afpy> haypo: le problème, c'est que les paquets python, dans Debian, s'appellent python-xxx au lieu de libxxx-python
15:09 <misc:#afpy> sphinx.i686 : Free open-source SQL full-text search engine
15:09 <misc:#afpy> ou effectivement, un autre paquet sui s'appelle deja sphinx
15:09 <haypo:#afpy> misc: ah ok. en même temps, pour le programme "meld" : c'est le paquet "meld"
15:10 <haypo:#afpy> je suis peut-être mauvaise langue
15:10 <natim:#afpy> Bizarement cython ne s'appelle pas python-cython
15:10 <Maddingue:#afpy> comme quand git est apparu, et qu'on a (re)découvert qu'il y avait déjà un logiciel qui s'appelait git
15:11 <haypo:#afpy> Maddingue: c'était quoi l'ancien "gi" ?
15:11 <feth:#afpy> le fait que l'identifiant d'un paquet doive être unique c'est un peu comme si on empêchait deux personnes de s'appeler bernard
15:11 <haypo:#afpy> git
15:11 <Maddingue:#afpy> haypo: un logiciel de statistiques si j'ai bonne mémoire
15:11 <haypo:#afpy> feth: perso j'ai voté contre le fait que ma fille s'appelle "clara" car il y avait déjà une autre "clara"
15:14 <misc:#afpy> on devrait prefixer les noms des gens par un nom de domaine
15:14 <Exirel:#afpy> misc > on appelle ça le nom de famille
15:14 <haypo:#afpy> on utilise des UUID
15:15 <haypo:#afpy> utiliser*
15:16 <Maddingue:#afpy> à moins que je ne confonde avec http://packages.debian.org/lenny/gnuit
15:16 <misc:#afpy> Exirel: mais le nom de domaine est unique :)
15:16 <Exirel:#afpy> misc > les gens ne sont pas des numéros
15:16 <Exirel:#afpy> y a qu'en Corée où il faut donner son KSSN pour jouer à des MMO
15:16 <haypo:#afpy> ça serait le bizzare le squattage de nom de domaine de famille
15:17 <haypo:#afpy> Exirel: KSSN ?
15:17 <Exirel:#afpy> de mémoire, Korean Social Security Number
15:17 <Exirel:#afpy> (de mémoire)
15:17 <misc:#afpy> Exirel: blizzard a aussi proposé une politique d'utiliser son vrai nom
15:17 <misc:#afpy> tout comme g+ et facebook, d'ailleurs
15:17 <misc:#afpy> ( même si fb fait moins de buit sur ça )
15:17 <Maddingue:#afpy> misc: c'était l'an dernier
15:17 <Maddingue:#afpy> ils sont revenus en arrière depuis
15:18 <misc:#afpy> oui
15:18 <Maddingue:#afpy> le lobbying féminin (principalement) a été suffisament efficace pour leur faire comprendre leur erreur
15:21 <feth:#afpy> Et si on change de patronyme
15:22 <feth:#afpy> genre mariage, ou changement de prénom, ou reconnaissance d'un nom d'usage
15:22 <Maddingue:#afpy> ou ceux qui changent de sexe
15:22 <feth:#afpy> tu peux déjà changer de sexe sur google +
15:23 <misc:#afpy> on parle de wow
15:23 <misc:#afpy> les gens se marient pas /o\
15:23 <feth:#afpy> haha :)
15:23 <mike_perdide:#afpy> on peut pas se marier sur wow ?
15:24 <natim:#afpy> Comment on fait pour utiliser cython sans distutils ?
15:24 <natim:#afpy> Je croyais qu'il fallait utiliser setuptools non ?
15:25 <natim:#afpy> J'ai une vieille erreur : http://friendpaste.com/3fehlNmg5WjapC7hZE294T
15:26 <natim:#afpy> Lorsque je fais python setup.py register
15:28 <brutasse:#afpy> il y a pas un accent dans ton nom ?
15:31 <natim:#afpy> Si mais il y en a aussi un dans celui de Benoît
15:31 <natim:#afpy> Visiblement distutils aime pas les accents dans le README.rst
15:31 <natim:#afpy> :(
15:31 <natim:#afpy> Pourquoi une telle discrimination
15:31 <haypo:#afpy> natim: c'est encodé en UTF-8?
15:32 <brutasse:#afpy> un petit decode('utf-8') dans le setup.py peut-être
15:33 <Exirel:#afpy> natim: un problème avec les accents ? ôo
15:33 <Exirel:#afpy> (ah zut j'ai lu "docutils" à la place de "distutils", dsl)
15:55 <haypo:#afpy> natim: tu passes le contenu de README.rst comme une chaîne d'octets ou de caractères ?
16:04 <natim:#afpy> brutasse, à oui c'est une bonne idée
16:04 <natim:#afpy> https://bitbucket.org/natim/qrimage/src/3bcb69bc6875/setup.py
16:05 <natim:#afpy> haypo, j'ai repris le setup.py de qrurl mais le bug vient de la lecture du README.rst
16:06 <natim:#afpy> il faudrait utiliser codecs
16:12 <natim:#afpy> Bon ben voilà un nouveau module sur pypi
16:20 <haypo:#afpy> ouais, codecs.open('README.rst', encoding='utf-8').read() devrait faire l'affaire
16:20 <haypo:#afpy> pas contre, codecs ne gère pas les fins de ligne universelles
16:48 <haypo:#afpy> benoitc: tu n'aimes pas qu'on réutilise ton code ? met le sous une licence bien chiante
16:48 <benoitc:#afpy> ceci est illegal : https://bitbucket.org/natim/qrimage/src/823b184d96ee/LICENSE
16:48 <haypo:#afpy> "si vous recopiez mon code, vous devrez faire 10 pompes" par exemple
16:49 <benoitc:#afpy> https://github.com/benoitc/qrurl/blob/master/LICENSE#L12
16:49 <haypo:#afpy> benoitc: qu'est-ce qui est illégal ? les accents dans un fichier de licence ?
16:49 <benoitc:#afpy> haypo: non oublier le copyright
16:49 <benoitc:#afpy> convention de berne tt ça
16:49 <benoitc:#afpy> ne pas suivre la license aussi
16:49 <benoitc:#afpy> aussi simple qu'elle soit.
16:50 <natim:#afpy> désolé j'ai essayé de mettre ton nom partout
16:50 <natim:#afpy> Dis moi comment je dois faire s'il te plait
16:50 <haypo:#afpy> benoitc: "The above copyright notice ... shall be included in all copies or substantial portions of the Software." ?
16:50 <haypo:#afpy> natim: commence par faire 10 pompes
16:50 <natim:#afpy> haypo, C'est en cours
16:50 <benoitc:#afpy> natim: tu aurais pu ommencer par demander déjà
16:51 <benoitc:#afpy> ensuite metrte la notice ainsi que mon copyright .
16:51 <benoitc:#afpy> ceci etant dit si tu m'avais demandé je l'aurais externalisé ...
16:52 <natim:#afpy> Hum je peux toujours le supprimer de pypi et te laisser le faire si tu veux
16:52 <natim:#afpy> La notice que j'ai mis n'est pas la bonne ?
16:53 <haypo:#afpy> natim: déjà que tu embêtes les papy !
16:53 <natim:#afpy> hum
16:54 <natim:#afpy> benoitc, j'ai pensé bien faire le faisant et puis j'ai découvert des trucs
16:55 <natim:#afpy> Si tu veux me faire une push request en corrigeant ce qui te semble illégal je l'accepterais volontier
16:56 <haypo:#afpy> benoitc: y'a pas besoin de te demander pour réutiliser ton code, vu la licence que tu as choisie
16:57 <benoitc:#afpy> je ne mets pas en doute le fait que tu aies cru bien faire. mais je ne trouve pas tres correct de rajouter une license quand il ne s'agit que de packaging
16:57 <natim:#afpy> Si tenté qu'on considère le packaging comme un travail
16:58 <benoitc:#afpy> haypo: simple correction?
16:58 <haypo:#afpy> benoitc: quoi ?
16:59 <benoitc:#afpy> """Qualité de quelqu'un, de son comportement qui est correct, respecte les bienséances, la morale : Agir avec correction.""""
16:59 <haypo:#afpy> benoitc: faut pas en vouloir à natim, il s'est juste trompé
16:59 <haypo:#afpy> il voulait bien faire
17:00 <benoitc:#afpy> je ne lui en veux pas. je met les choses au point.
17:00 <natim:#afpy> Ce qui te déplait c'est que j'ai mis mon nom dans la LICENCE et la NOTICE ? Ou il y a autre chose ?
17:00 <natim:#afpy> Tout ce que j'ai fait est supprimable
17:00 <haypo:#afpy> natim: non, il faut mettre celui de benoitc , le tien tu peux le laisser
17:00 <natim:#afpy> Donc si tu veux bien m'expliquer ce que je dois faire pour que ce soit correct, je suis tout ouïe
17:01 <haypo:#afpy> natim: la licence indique que tu DOIS garder la mention de copyright
17:01 <natim:#afpy> Et dans la notice aussi ?
17:01 <haypo:#afpy> c'est une des seules exigences de cette licence communiste
17:01 <benoitc:#afpy> natim: oui
17:01 <haypo:#afpy> quelle notice ?
17:02 <benoitc:#afpy> plus de lecture http://en.wikipedia.org/wiki/Fair_use & http://en.wikipedia.org/wiki/Copyright
17:02 <haypo:#afpy> j'comprend pas : qrimage contient des bouts de code de qrurl ? lesquels ?
17:03 <benoitc:#afpy> haypo: bah qrencode.pyx et qrimage.py
17:03 <natim:#afpy> Le bindings
17:03 <natim:#afpy> En gros tout le code du package
17:03 <haypo:#afpy> natim: tu as repris tout le code et dans setup.py tu dis que tu l'as écrit ?
17:04 <natim:#afpy> C'est une autre erreur alors
17:04 <natim:#afpy> Comment je fais pour le packager et le mettre sur pypi avec les bons droits ?
17:04 <natim:#afpy> Sinon, ce qui est encore plus simple
17:05 <natim:#afpy> C'est que je le retire de Pypi et benoitc tu le package et tu le mets avec ton compte ?
17:05 <natim:#afpy> Non ?
17:05 <haypo:#afpy> natim: tu peux ajouter ton nom à la limite si tu estimes que tu as participé au projet
17:05 <haypo:#afpy> mais virer Benoit pour mettre uniquemetn ton nom, c'est très mal vu
17:05 <haypo:#afpy> ça laisse penser que tu te contrefous du droit d'auteur et du travail de Benoit, en essayant de te l'approprier
17:06 <haypo:#afpy> je ne dis pas que c'était ton intention, mais c'est ce que ça laisse entendre :)
17:06 <haypo:#afpy> c'est plus clair pour toi ?
17:06 <natim:#afpy> Oui carrément
17:06 <natim:#afpy> Je comprends bien le ressenti
17:06 <natim:#afpy> Mais c'est pas du tout l'intention
17:06 <haypo:#afpy> natim: sous DEbian, y'a un champ clairement identifié pour indiqué le *packageur*
17:07 <natim:#afpy> Ce que je voulais faire c'est le packager et dire que le code venait de qrurl
17:07 <haypo:#afpy> avec setup.py, c'est mal foutu, ça suppose que celui qui upload est l'auteur du projet
17:07 <haypo:#afpy> (pour indiquer*)
17:07 <natim:#afpy> benoitc, je l'ai retirer de pypi, tu veux bien le packager et le mettre ?
17:08 <alexis:#afpy> haypo: il y a les notions de mainteneur et d'auteur, mais celui qui upload est effectivement recensé sur pypi comme auteur
17:08 <haypo:#afpy> "benoitc> natim: tu aurais pu ommencer par demander déjà" je comprends mieux maintenant :)
17:08 <alexis:#afpy> c'est un bug dans distutils, cf un mail que j'ai envvoyé sur catalog-sig y'a peu de temps
17:08 <haypo:#afpy> alexis: mainteneur != packageur
17:08 <natim:#afpy> Après tu peux être l'auteur du package :s
17:08 <alexis:#afpy> ah, ya pas de notion de packageur alors
17:08 <haypo:#afpy> alexis: auteur, mainteneur, packageur peuvent être 3 personnes différentes
17:09 <alexis:#afpy> je mettais les deux ensemble (mainteneur et packageur)
17:09 <alexis:#afpy> donc auteur c'est l'auteur initial
17:09 <benoitc:#afpy> natim: donne moi 30mn
17:09 <haypo:#afpy> perso je me débrouille pour être la même personne pour les 3 champs :)
17:09 <alexis:#afpy> et mainteneur c'est le mec qui continue de le maintenir ?
17:09 <natim:#afpy> benoitc, merci
17:09 <alexis:#afpy> ouais ça semble logique en fait
17:09 <benoitc:#afpy> code stupide du jour https://github.com/benoitc/fserve
17:09 <haypo:#afpy> les subtilités peuvent être notées dans le fichier AUTHORS
17:09 <natim:#afpy> alexis, haypo author dans setup.py est considéré comme quoi ? L'auteur du code ? L'auteur du package ?
17:10 <haypo:#afpy> alexis: tiens, c'est nul : pour le projet IPy, je me suis indiqué comme mainteneur et Maximillian Dornseif comme auteur : http://pypi.python.org/pypi/IPy m'indique comme auteur, sans mentionner Maximillian
17:10 <haypo:#afpy> c'est atroce comme bug
17:10 <haypo:#afpy> natim: plutôt l'auteur du code
17:11 <haypo:#afpy> j'ai repris le projet IPy, Maximillian est l'auteur initial, il a abandonné le projet
17:11 <alexis:#afpy> haypo: yep c'est le problème en question
17:11 <natim:#afpy> ce serait plus logique d'avoir une liste de personne ayant participé au projets et la personne ayant lancé le projet
17:12 <alexis:#afpy> haypo: on dirait que l'auteur est pas cherché dans les metadonnées mais en fonction de qui à uploadé la distribution
17:12 <alexis:#afpy> j'ai pas regardé plus mais ça semble anormal
17:12 <haypo:#afpy> natim: je ne sais pas s'il y a une convention, mais dans le champ authors j'essaye de mettre les gens qui ont passé le plus de temps sur le projet
17:12 <haypo:#afpy> natim: dans AUTHORS je cite tous les contributeurs avec un micro description
17:13 <haypo:#afpy> natim: je pense que tu as passé 10x moins de temps que benoitc sur le projet, donc tu ne devrais pas mettre ton nom dans setup.py, mais tu peux le mettre autres part (AUTHORS ?)
17:16 <haypo:#afpy> natim: maintenant tu peux décider de mettre tout le monde sur un pied d'égalité et mettre tout le monde dans le champ author de setup.py, mais la liste sera illisible si elle est trop longue
17:18 <haypo:#afpy> natim: je sais pas si je suis clair. tu vois l'idée ?
17:18 <natim:#afpy> Moi ce qui me semble important c'est que les gens sachent que c'est Benoit qui est à la base de la fonctionnalité
17:19 <natim:#afpy> après le reste m'importe peu
17:23 <yota:#afpy> le plus important amha est le mainteneur actuel
17:23 <yota:#afpy> pas celui a qui eu l'idée :)
17:28 <jpcw:#afpy> pour éviter toute ambiguité un champ creator indiquerait le créateur initial
17:28 <jpcw:#afpy> et autho pourrait -être celui qui release à un instant T
17:29 <Maddingue:#afpy> benoitc: "\r\n" ? j'imagine que la portabilité n'est probalement pas utile mais c'est quand même laid
17:29 <jpcw:#afpy> quoi que maintener pour ça est bien
17:34 <yota:#afpy> splitlines() ?
17:35 <haypo:#afpy> benoitc, natim : pour se détendre, rien de mieux que de jouer à Monsterz :-) http://sam.zoy.org/blog/2007-05-26-bitten-by-michael-j-hardy
17:36 <natim:#afpy> haypo, lol
17:37 <haypo:#afpy> "[Mike Hardy] thought that the GNU General Public License (GPL) gave him free reign to use the source code of others and claim their work as his own."
17:37 <haypo:#afpy> http://youfailit.net/?p=49
17:39 <benoitc:#afpy> Maddingue: \r\n ?
17:39 <haypo:#afpy> ? ?
17:39 <benoitc:#afpy> dasn fserve ?
17:39 <benoitc:#afpy> c juste la spec http hein
17:41 <haypo:#afpy> faut patcher HTTP, il est nul ce protocole !
17:42 <Maddingue:#afpy> benoitc: heu non, la spec dit CR LF
17:42 <natim:#afpy> Maddingue, et \r\n c'est pas CR LF ?
17:43 <Maddingue:#afpy> non
17:43 <natim:#afpy> :o
17:43 <haypo:#afpy> Maddingue: c'est quoi alors ?
17:43 <Maddingue:#afpy> \r est le retour à la ligne de l'OS, \n le saut de ligne de l'OS
17:43 <Maddingue:#afpy> les valeurs réelles de \r et \n changent en fonction des OS, voire en fonction du mode du flux en cours
17:44 <haypo:#afpy> "les valeurs réelles de \r et \n changent en fonction des OS" hein ?
17:44 <benoitc:#afpy> http c'est \r\n .
17:45 <benoitc:#afpy> les valeurs ne changent pas
17:45 <benoitc:#afpy> ça a tjrs ete ça
17:45 <haypo:#afpy> en python "\r" c'est la même chose que "\x0d" ou chr(13)
17:45 <haypo:#afpy> Maddingue: python s'en fout de l'OS pour "\r"
17:46 <Maddingue:#afpy> est-ce garanti ?
17:46 <haypo:#afpy> oui
17:46 <Maddingue:#afpy> parce que sauf erreur de ma part, ce serait le seul langage que je connaisse qui fasse cela
17:46 <jpcw:#afpy> Maddingue: oui
17:46 <jpcw:#afpy> Maddingue: ce qui change c'est le retour à la ligne suivant l'os
17:46 <jpcw:#afpy> pas suivant le langage
17:47 <haypo:#afpy> Maddingue: tu veux dire qu'en C, selon le compilateur "\n" et "\r" peuvent avoir des valeurs différentes ?
17:47 <Maddingue:#afpy> haypo: oui
17:47 <haypo:#afpy> j'ai jamais entendu ça
17:47 <Maddingue:#afpy> je viens du monde Mac, j'ai bossé sur Windows et Unix
17:47 <Maddingue:#afpy> on se rends très vite compte de cela
17:47 <haypo:#afpy> j'ai toujours vu '\n' == 10 et '\r' == 13
17:47 <Maddingue:#afpy> c'est très loin d'etre nouveau
17:47 <Maddingue:#afpy> benoitc: je fais aussi du HTTP depuis longtemps
17:47 <haypo:#afpy> Maddingue: sous Mac, la fin de ligne c'est "\r"
17:48 <haypo:#afpy> mais "\r" désigne le code 13 sous Windows, Mac et Linux
17:48 <jpcw:#afpy> haypo: jusqu'a os-x
17:48 <natim:#afpy> Ce qui est loin d'être nouveau c'est que les fins de ligne sous mac c'est \n et il fut un temps c'était \r sous linux c'est \n et sous Windows \r\n
17:48 <natim:#afpy> Ceci dit pour le protocole HTTP c'est \r\n et le code de \r \n ne change pas selon l'os
17:48 <natim:#afpy> Ils sont dans la table ascii qui est la même tout le temps partout
17:48 <jpcw:#afpy> oui
17:49 <Maddingue:#afpy> http://www.ietf.org/rfc/rfc2616.txt Section 2.2 Basic Rules: HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body
17:49 <natim:#afpy> Oui mais les codes de CR et LF sont dans la table ASCII
17:49 <Maddingue:#afpy> oui
17:50 <natim:#afpy> Et en python ils s'écrivent \r et \n
17:50 <Maddingue:#afpy> mais tu n'as aucune garantie que \r veuille dire CR ni que \n veuille dire LF
17:50 <Maddingue:#afpy> non, en python, comme dans à la plupart des langages, on a l'écrire d'une manière portable, par exemple \015 \012
17:52 <haypo:#afpy> Maddingue: je suis très étonné parce que tu dis
17:52 <haypo:#afpy> Maddingue: j'ai jamais rien entendu de tel
17:52 <natim:#afpy> Je suis d'accord que '\015' == '\r' et '\012' == '\n' mais j'aimerais bien un exemple où ce n'est pas vrai
17:56 <benoitc:#afpy> Maddingue:
17:56 <benoitc:#afpy> CR = <ASCII CR, carriage return> ; ( 15, 13.)
17:56 <benoitc:#afpy> LF = <ASCII LF, linefeed> ; ( 12, 10.)
17:56 <benoitc:#afpy> http://www.ietf.org/rfc/rfc0822.txt
17:56 <benoitc:#afpy> anyway
17:57 <benoitc:#afpy> et c cette rfc qui est utilisé pour le format des messages
17:57 <Maddingue:#afpy> désolé, appel téléphonique
17:58 <benoitc:#afpy> us ascii je connais pas d'autres valeurs que \r \n ceci dit et leur traduction par le langage
17:58 <Maddingue:#afpy> donc, comme j'allais l'expliquer, sous Windows, "\n" est convertit en CR LF (deux caractères), quand le flux est en mode texte, et en LF quand le flux est en mode binaire
17:58 <benoitc:#afpy> bon ils ont rangé ou les livs
17:58 <anhj:#afpy> http://docs.python.org/reference/lexical_analysis.html
17:59 <Maddingue:#afpy> sous Mac OS Classic, "\n" valait CR et "\r" LF
17:59 <anhj:#afpy> tableau des escape sequences au milieur
17:59 <anhj:#afpy> en python, \r ASCII Carriage Return (CR)
17:59 <anhj:#afpy> \n ASCII linefeed (LF)
17:59 <anhj:#afpy> indépendant de l'OS
18:00 <Maddingue:#afpy> sous VMS, "\n" est aussi convertit en CR LF si j'ai bonne mémoire
18:04 <Maddingue:#afpy> enfin bon, vous n'êtes pas obligé de me croire après tout, mais si je mentais j'imagine qu'on n'aurait écrit des programmes de conversion de fin de lignes comme dos2unix
18:04 <haypo:#afpy> Maddingue: je pense que "\n" vaut toujours 10 et "\r" toujours 13 en Python
18:05 <haypo:#afpy> Maddingue: pour les autres langages, je n'en sais rien, mais ça m'étonnerait quand même que ça soit variable
18:05 <anhj:#afpy> dos2unix n'a RIEN à voir avec ce que tu dis, mais avec le fait que suivant l'OS, les lignes se terminent par \r, \n, ou les deux
18:06 <Maddingue:#afpy> anhj: parce que tu crois que les gens sous Windows s'embetent à explicitement écrire "\r\n" ?
18:06 <anhj:#afpy> ok j'abandonne
18:06 <benoitc:#afpy> ceci dit donc http-parser fonctionne sur bsds*, solaris, macosx, linux* et windows
18:06 <Maddingue:#afpy> et encore une fois, je viens de Mac OS Classic, où \n == CR et \r == LF
18:07 <benoitc:#afpy> donc bon ct ptete vrai
18:07 <benoitc:#afpy> ça ne l'est plus
18:07 <Maddingue:#afpy> benoitc: tu as cité 4 Unix et Windows
18:07 <Maddingue:#afpy> les Unix sont tous équivalents de ce point de vue
18:07 <Maddingue:#afpy> le coup du \r\n marche par chance sous Windows
18:08 <benoitc:#afpy> je n'appellerais pas ça de la chance mais bon ....
18:08 <Maddingue:#afpy> alors en effet, Mac OS Classic n'existe plus
18:08 <haypo:#afpy> Maddingue: sous Windows, si tu écris dans un fichier ouvert en mode texte, certains caractères peuvent être remplacés entre ton appel à fwrite / write, et l'écriture sur disque
18:09 <haypo:#afpy> Maddingue: par contre, dans ton programme, "\n" c'est 10
18:09 <Maddingue:#afpy> mais utiliser \r\n dans u ncontexte réseau reste quand même loin d'être propore
18:09 <Maddingue:#afpy> propre
18:12 <feth:#afpy> haypo: est-ce qu'il y a un intérêt à ouvrir un fichier en mode texte ?
18:13 <haypo:#afpy> feth: je suppose que ça permet d'écrire printf("bla\n"); et que ça marche magiquement
18:13 <feth:#afpy> est-ce que 'w' ne devrait pas être un alias pour 'wb dans open(..., 'w') ?
18:13 <feth:#afpy> ça marche pas sinon ?
18:13 <haypo:#afpy> (ou fprint(fichier, "bla\n");)
18:13 <haypo:#afpy> feth: bah windows s'attend à avoir \r\n
18:13 <feth:#afpy> toutes les applis windows savent lire \n seulement
18:14 <haypo:#afpy> python 3.2 n'utilise plus ces saloperies de fichier en mode texte
18:14 <feth:#afpy> disons toutes celles écrites après 2005
18:14 <haypo:#afpy> ça foutait le bordel en CGI
18:14 <haypo:#afpy> python cache les spécificité des OS, et c'est bien agréable !
18:17 <benoitc:#afpy> Maddingue: patch are welcome comme on dit ;)
18:17 <benoitc:#afpy> patches
18:27 <natim:#afpy> benoitc, tu pourras me faire un petit twitt pour me dire que qrimage est sur pypi ? thx
18:34 <benoitc:#afpy> https://github.com/benoitc/qrkit
18:34 <benoitc:#afpy> ah parti
18:35 <benoitc:#afpy> c quoi ces gens qui se deconnectent
18:39 <Maddingue:#afpy> ok, now I have proof
18:41 <haypo:#afpy> Maddingue: une proof de quoi ?
18:43 <Maddingue:#afpy> deux sec, je nopaste
18:43 <Maddingue:#afpy> http://nopaste.snit.ch/74151
18:44 <Maddingue:#afpy> la preuve que Python se comporte comme les autres langages de programmation, et que \n n'a pas la même valeur sur Win32 que sur Unix
18:44 <Maddingue:#afpy> là, il faut se souvenir de lire les paires d'octets à l'envers, puisque c'est sur du x86
18:45 <misc:#afpy> et si tu mets \n directement ?
18:46 <Maddingue:#afpy> hmm, peux pas le faire en uniligne
18:47 <misc:#afpy> python -c 'print "\n"' ?
18:47 <Maddingue:#afpy> pas dans un shell Win32
18:47 <Maddingue:#afpy> il faut utilise " comme quotes
18:49 <haypo:#afpy> Maddingue: ton exemple est complètement bidon, vu que tu n'utilises pas \n
18:49 <anhj:#afpy> ...
18:49 <benoitc:#afpy> print "\\n"
18:50 <benoitc:#afpy> ou pas
18:50 <benoitc:#afpy> enfin bon windows quoi
18:50 <haypo:#afpy> Maddingue: print "bla" appelle sys.stdout.write("bla"); sys.stdout.write("\n");
18:50 <Maddingue:#afpy> je suis en train de le faire
18:50 <Maddingue:#afpy> deux secondes
18:50 <misc:#afpy> haypo: donc c'est bon, non ?
18:50 <haypo:#afpy> Maddingue: et Python remplace "\n" par "\r\n"
18:51 <haypo:#afpy> car Python est gentil !
18:51 <Maddingue:#afpy> haypo: non, il remplace \n par CR LF
18:52 <Maddingue:#afpy> parce que c'est ce que fait la libc
18:52 <misc:#afpy> sur windows ?
18:52 <anhj:#afpy> hahaha il est énorme
18:52 <anhj:#afpy> bon, /me va faire une salade de tomate
18:53 <haypo:#afpy> bon attendez, je lis le source de python 3, ça m'embrouille
18:53 <Maddingue:#afpy> http://nopaste.snit.ch/74154
18:53 <anhj:#afpy> de tomates, en fait, une ne suffira pas
18:53 <benoitc:#afpy> anhj: depends
18:53 <benoitc:#afpy> tu peux la couper en plusieurs morceaux
18:53 <benoitc:#afpy> :)
18:54 <Maddingue:#afpy> par contre, comme on pouvait s'y attendre, \r renvoie \0d dans les deux cas
18:54 <benoitc:#afpy> mais ce sera une salade de morceaux de tomates
18:54 <anhj:#afpy> même, ça ne suffira pas
18:54 <anhj:#afpy> :)
18:54 <haypo:#afpy> Maddingue: écrire dans un fichier c'est une chose
18:54 <haypo:#afpy> Maddingue: une chaîne de caractère "bla\n" c'est une autre chose
18:54 <Maddingue:#afpy> haypo: je n'ai pas écris dans un fichier
18:54 <haypo:#afpy> Maddingue: quand tu écris dans un fichier, la chaîne est transformée
18:55 <haypo:#afpy> Maddingue: quand tu écris "bla\n" dans stdout, ça écrit en fait "bla\r\n"
18:55 <misc:#afpy> mais un socket, ç'est pareil ou pas ?
18:55 <haypo:#afpy> avec python 3, c'est python qui remplace "\n" par "\r\n" lors de l'écriture, dans Python 2 je sais plus si c'est fwrite() ou Python qui le fait
18:55 <haypo:#afpy> misc: une socket c'est un fichier, mais souvent un fichier binaire
18:55 <haypo:#afpy> misc: pour un fichier binaire, y'a pas de conversion de fin de ligne
18:56 <Maddingue:#afpy> haypo: non. c'est ce que j'essaye de vous expliquer depuis le début. le fait d'utiliser \r et \n à tort et à travers ne vous permet même pas de comprendre que ce sont des notations flottantes, dont la valeur varie
18:56 <haypo:#afpy> Maddingue: c'est quoi une notation flottante ?
18:56 <misc:#afpy> un truc pas cool
18:56 <misc:#afpy> car si ça coule, ça flotte pas
18:57 <haypo:#afpy> ce que j'ai compris de ton discour, c'est quoi "\r" c'est pas le caractère 13, c'est parfois autre chose
18:57 <Maddingue:#afpy> au sens que \o015 par exemple, vaut toujours CR, alors que \n peut valoir CR ou CR LF
18:57 <haypo:#afpy> Maddingue: tu parles d'une chaîne python, ou tu parles d'une console là ?
18:57 <Maddingue:#afpy> je parle d'I/O
18:57 <haypo:#afpy> ("Maddingue> haypo: je n'ai pas écris dans un fichier" : bah si, print ça écrit dans stdout qui est un fichier)
18:57 <misc:#afpy> Maddingue: mais si tu fait print \o015 sur windows, ça va pas être remplacé par print ?
18:58 <haypo:#afpy> Maddingue: je suis maintenant sûr d'une chose, tu n'es pas clair :)
18:58 <Maddingue:#afpy> misc: ce n'est pas print() qui est magique
18:58 <haypo:#afpy> Maddingue: une socket réseau, c'est un flux binaire, y'a pas de conversion de fin de ligne
18:58 <Maddingue:#afpy> là j'ai utilisé write() justement pour avoir une fonction qui ne fasse rien de plus
18:58 <haypo:#afpy> Maddingue: donc "\r" reste "\r" et c'est toujours chr(13)
18:58 <misc:#afpy> Maddingue: nan mais si tu refait les 2 scritps, avec \o015 à la place de \n, ça fait quoi ?
18:59 <haypo:#afpy> après si tu lis un flux HTTP depuis sys.stdout sous Windows avec Python< 3.3, bon là tu risques d'avoir des surprises
18:59 <haypo:#afpy> mais le code de ton parseur devrait toujours utiliser "\r\n"
19:00 <Maddingue:#afpy> misc: ça affiche 0d dans les deux cas
19:00 <haypo:#afpy> misc: en python, "\n", "\o015" et "\x0a" c'est la même chose
19:00 <Maddingue:#afpy> haypo: ok, j'ai compris, vous avez décidé de ne pas me croire. pas grave.
19:00 <haypo:#afpy> mais print n'est pas le bon outil pour s'en assurer
19:00 <misc:#afpy> moi, ce que je pige pas, c'est quand est ce que \n change de valeur
19:00 <haypo:#afpy> Maddingue: tu mélanges plusieurs choses différentes, t'es pas clair du tout
19:01 <Maddingue:#afpy> j'ai du mal à voir en quoi mon dernier nopaste n'est pas clair
19:01 <benoitc:#afpy> juste en c
19:01 <benoitc:#afpy> \n (new line) Moves the active position to the initial
19:01 <benoitc:#afpy> position of the next line.
19:01 <benoitc:#afpy> \r (carriage return) Moves the active position to the
19:01 <benoitc:#afpy> initial position of the current line.
19:01 <misc:#afpy> si c'est pas print qui le fait, est ce que chr doit pas montre que la valeur est différente ?
19:01 <benoitc:#afpy> alors anyway tt ce qui nous interesse c un cariage return et un saut de ligne en http
19:02 <benoitc:#afpy> jamais vu de client gerant les choses differement en http.
19:02 <haypo:#afpy> Maddingue: http://nopaste.snit.ch/74154 : tu écris \n dans stdout, stdout remplace \n par \r\n
19:03 <haypo:#afpy> Maddingue: la conversion est faite quand tu écris dans stdout
19:03 <haypo:#afpy> si tu remplaces sys.stdout.write("\n") par sys.stdout.write("code=%u" % (ord("\n")) ça t'affichera 10 sur tous les OS
19:04 <haypo:#afpy> Maddingue: le stdout windows est spécial, si tu le passes en mode binaire, il ne fait plus de magie
19:07 <haypo:#afpy> c'est http://bugs.python.org/issue10841 qui a passé stdout en mode binaire sous Windosw
19:09 <benoitc:#afpy> meme si c wikipedia http://en.wikipedia.org/wiki/Newline