06:44 <xcombelle> feth de tuteurs pour quoi ?
06:50 <NelleV> pour des présentateurs pour pyconfr
07:43 <xcombelle> merci NelleV
07:43 <xcombelle> je vais peut etre venir à la pyconfr
09:21 <mdk> matin
11:26 <mathieui> https://bugs.python.org/issue17636 d’un côté j’aime bien que ça marche mieux, de l’autre c’est un peu chiant d’écrire du code qui marche sous python 3.5 et découvrir que c’est pêté en 3.4 :|
11:26 <mathieui> (et devoir aller fouiller dans le changelog de python 3.5 alpha1 pour ça)
11:28 <feth> ça m'a surpris d'apprendre que plein de gens ont un Python 3.4 sous la main mais ne peuvent pas installer 3.5 facilement
11:28 <feth> encore la semaine dernière
11:28 <feth> genre fedora, ubtunu
11:29 <mathieui> debian
11:29 <mathieui> ubuntu 16.04 a 3.5 par défaut, il me semble
11:29 <feth> j'ai une debian et 3.5 depuis longtemps
11:30 <mathieui> debian stable, si tu veux
11:31 <misc> bah, j'ai une fedora stable et 3.5 :)
11:31 <feth> les gens qui tournent debian stable n'ont pas besoin de nouveaux logiciels, si ? je pense qu'ils ont qualifié debian stable pour leur cible fonctionnelle
11:32 <mathieui> feth, tu serais surpris
11:33 <mathieui> (déjà le nombre de gens qui se plaignent de devoir compiler 3.4 à la main parce que le logiciel marche pas en 3.3…)
11:33 <mathieui> (ça va que python est léger)
11:34 <feth> Bah après c'est comme une voiture homologuée, tu peux mettre des spoilers, des jantes larges etc
11:34 <feth> mais à la base, le truc que tu avais faisait ce que tu voulais qu'il fît
11:41 <mathieui> (mais les gens sont pas contents d’avoir des bugs après)
11:41 <mathieui> (pourtant c’est censé fit)
11:41 <feth> bah ça fait partie de debian stable qu'il y a des corrections de bug quand même
11:42 <misc> y a des corrections de bug backportés ?
11:42 <mathieui> feth, bof
11:42 <mathieui> c’est vraiment que pour les logiciels majeurs
11:43 <feth> ou pour la sécu
11:43 <misc> et les bugs majeurs
11:43 <misc> feth: tout est backporté pour la secu ?
11:43 <mathieui> en général ils trackent assez bien les CVE, oui
11:43 <feth> misc: c'est la politique, je crois.
11:44 <feth> misc: lance "debsecan", il y a des options "with upgrade available only"
11:44 <misc> (parce que sur RHEL, on explique que les failles mineurs moisis sont parfois pas backportés)
11:45 <feth> debian n'est pas vendue contre un engagement financier, en même temps
11:46 <feth> https://www.debian.org/security/faq#handling
11:46 <misc> non, mais la contrainte d'avoir des ressources qui ne suffisent pas s'applique aussi
11:46 <feth> A: Security breakage in the stable distribution warrants a package on security.debian.org. Anything else does not.
11:48 <mathieui> ce que je préfère ce sont les packages qui ont besoin d’être mis à jour mais qui ne le sont pas, par policy
11:49 <mathieui> genre youtube-dl
11:49 <mathieui> qui a besoin d’une mise à jour par mois au moins
11:50 <feth> ben en même temps, c'est assez clair quand tu lis la policy que le besoin fonctionnel ne peut pas être couvert par debian stable
11:50 <misc> la policy date d'avant ce genre de probléme
11:50 <misc> y a debian volatile pour ça
11:50 <misc> ou des trucs genre debian backports
11:51 <feth> ouip
11:51 <feth> debian volatile c'était pour les signatures d'AV, vraiment orienté données
11:58 <feth> une solution pour youtube-dl serait d'arriver à séparer la logique et la config (et ok, on sait que c'est la même chose depuis turing, mais bon)
11:59 <feth> et ça a des limites
12:00 <feth> après, c'est pareil pour libreoffice : si microsoft dégaine une variation de format de données bizarre, il faut la nouvelle version
12:00 <feth> et debian stable ne peut pas la fournir
12:06 <misc> la différence est que si microsoft sort une version bizzare, lo ne va pas rajouter le support immédiatement
12:09 <feth> donc youtube-dl est comparable à un antivirus
12:10 <misc> je sais pas
12:10 <misc> un antivirus, tu peux mettre les données séparés
12:10 <misc> la, c'est du code avec des dependances distantes
13:57 <xcombelle> feth depuis quand la logique et la config sont la meme chose ?
14:24 <feth> xcombelle: depuis les machines de turing ?
14:26 <xcombelle> ben non justement à la limite tu pourrais parler de l'architecture de Von Neuman ou les données et les programmes sont stocqués de la meme manière mais certainement pas des machines de turing feth
14:27 <xcombelle> et ce n'est pas parce qu'ils sont stoqués de la meme manière que c'est la meme chose
14:28 <feth> j'entends bien
14:28 <xcombelle> alors pourquoi tu affirme le contraire feth ?
14:28 <feth> après, la config, si elle dépasse un certain niveau de complexité -comme permis par json et yaml maintenant, xml avant- rend le comportement d'un programme complètement imprévisible
14:29 <xcombelle> json n'est pas turing complet
14:30 <feth> hm, on peut pas représenter un AST en json ? me semble que si
14:30 <tshirtman> ça dépends de ce qui le lit, j'ai envie de dire
14:30 <haypo> feth: le module ast fournit beaucoup d'outils pour explorer l'AST. tu dois pouvoir facilement convertir de l'AST en ce que tu veux
14:30 <tshirtman> si tu décide d'implémenter une vm qui lit son programme dans un fichier json, pourquoi pas?
14:30 <haypo> feth: faut juste aimer la récursivité :)
14:30 <tshirtman> (à part toutes les bonnes raisons du monde de ne pas le faire)
14:31 <tshirtman> d'un coté, le code, ce n'est qu'une façon avancée de configurer du hardware
14:33 <mathieui> (sinon il y a redbaron qui est peut-être plus sympa qu’ast)
14:58 <gordon`> wiiiii !
19:06 <jpcw_> grenoya: bah fais la propale, comme ça elle sera dans le pipe, c'est très dur de rajouter des trucs à côté
19:06 <jpcw_> grenoya: déolé pour le lag
19:06 <jpcw_> 3 jours ans irc