From gerald at sedrati-dinet.net Sat Dec 1 01:03:15 2018 From: gerald at sedrati-dinet.net (=?UTF-8?Q?G=c3=a9rald_S=c3=89DRATI-DINET?=) Date: Sat, 1 Dec 2018 01:03:15 +0100 Subject: [Perl] UTF8 hash key downgraded when assigned Message-ID: <55dd4c7d-545b-1434-70e2-c403e37b48af@sedrati-dinet.net> Salut les Mongueurs! Ça faisait longtemps que je n'avais pas posté ici, mais maintenant que j'ai la joie de retravailler en Perl, j'ai aussi celle de partager à nouveau de vos lumières :) Je suis tombé sur un étrange comportement, sur toutes les versions de Perl que j'ai pu testées (entre la 5.16 et la 5.26). Il y a une question sur stack overflow (https://stackoverflow.com/questions/8418496/hash-keys-encoding-why-do-i-get-here-with-develpeekdump-two-different-resul) qui date de quelques années mais sans réponse s'il s'agit ou non d'un bug d'optimisation ou d'un comportement normal. Le problème et que si vous initialisez un hash avec une clé ayant des caractères non-ascii (par ex. du iso-8859-1), la clé est correctement encodée en UTF8 (avec le flag UTF8 positionné). Mais si vous assignez ensuite une valeur à l'élément du hash correspondant à cette clé, celle-ci est déclassée (comme avec un utf8::downgrade, probablement encodée en iso-8859-1). Je vous laisse imaginer les conséquences si vous avez à manipuler cette clé pour une raison ou pour une autre, en vous attendant à ce qu'elle soit encodée en UTF8? Voilà un script montrant le problème: #!/usr/bin/perl use strict; use warnings; use utf8; use Devel::Peek; use Data::Dumper; $Data::Dumper::Useqq = 1; my %hash = ( 'clé' => 0, ); my $key = (keys %hash)[0]; Dump($key); print Dumper($key); $hash{'clé'} = 1; $key = (keys %hash)[0]; Dump($key); print Dumper($key); utf8::upgrade($key); Dump($key); print Dumper($key); [download] avec le résultat suivant: SV = PV(0x555ed17dfe60) at 0x555ed1809710 REFCNT = 1 FLAGS = (POK,pPOK,UTF8) PV = 0x555ed1993ed0 "cl\303\251"\0 [UTF8 "cl\x{e9}"] CUR = 4 LEN = 5 $VAR1 = "cl\x{e9}"; SV = PV(0x555ed17dfe60) at 0x555ed1809710 REFCNT = 1 FLAGS = (POK,IsCOW,pPOK) PV = 0x555ed1909b10 "cl\351" CUR = 3 LEN = 0 $VAR1 = "cl\351"; SV = PV(0x555ed17dfe60) at 0x555ed1809710 REFCNT = 1 FLAGS = (POK,pPOK,UTF8) PV = 0x555ed1825350 "cl\303\251"\0 [UTF8 "cl\x{e9}"] CUR = 4 LEN = 10 $VAR1 = "cl\x{e9}"; [download] Comme dans ce code, on peut résoudre le problème en surclassant en UTF8 (utf8::upgrade) la clé. Mais j'aurais jamais imaginé devoir faire ça avant de tomber sur le problème. J'ai rien lu dans perldoc qui explique ce comportement. Vous avez une idée d'explication, si c'est ou non voulu ? Merci! -- Gérald Sédrati-Dinet https://pascontent.sedrati-dinet.net https://www.april.org https://www.unitary-patent.eu https://laquadrature.net -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: signature.asc Type: application/pgp-signature Taille: 195 octets Desc: OpenPGP digital signature URL: From kai.carver at gmail.com Sat Dec 1 08:14:15 2018 From: kai.carver at gmail.com (Kai Carver) Date: Sat, 1 Dec 2018 08:14:15 +0100 Subject: [Perl] UTF8 hash key downgraded when assigned In-Reply-To: <55dd4c7d-545b-1434-70e2-c403e37b48af@sedrati-dinet.net> References: <55dd4c7d-545b-1434-70e2-c403e37b48af@sedrati-dinet.net> Message-ID: hello Gérard curieux... j'ai vu ceci: "It appears to be a bug the optimisation of constant hash keys. The constant key string in $h{'Góry'} is being downgraded from utf8, whereas if you write my $g = 'Góry'; $h{$g} = 1; it works ok." https://www.perlmonks.org/index.pl?node_id=1197369 et effectivement le bug ne se produit pas si au lieu d'utiliser 'clé' tu utilises une variable $cle = 'clé' #!/usr/bin/perl use strict; use warnings; use utf8; use Devel::Peek; use Data::Dumper; $Data::Dumper::Useqq = 1; my $cle = 'clé'; my %hash = ( $cle => 0, ); my $key = (keys %hash)[0]; Dump($key); print Dumper($key); $hash{$cle} = 1; $key = (keys %hash)[0]; Dump($key); print Dumper($key); utf8::upgrade($key); Dump($key); print Dumper($key); On Sat, Dec 1, 2018 at 1:03 AM Gérald SÉDRATI-DINET < gerald at sedrati-dinet.net> wrote: > Salut les Mongueurs! > > Ça faisait longtemps que je n'avais pas posté ici, mais maintenant que > j'ai la joie de retravailler en Perl, j'ai aussi celle de partager à > nouveau de vos lumières :) > > Je suis tombé sur un étrange comportement, sur toutes les versions de > Perl que j'ai pu testées (entre la 5.16 et la 5.26). > > Il y a une question sur stack overflow > ( > https://stackoverflow.com/questions/8418496/hash-keys-encoding-why-do-i-get-here-with-develpeekdump-two-different-resul > ) > qui date de quelques années mais sans réponse s'il s'agit ou non d'un > bug d'optimisation ou d'un comportement normal. > > Le problème et que si vous initialisez un hash avec une clé ayant des > caractères non-ascii (par ex. du iso-8859-1), la clé est correctement > encodée en UTF8 (avec le flag UTF8 positionné). Mais si vous assignez > ensuite une valeur à l'élément du hash correspondant à cette clé, > celle-ci est déclassée (comme avec un utf8::downgrade, probablement > encodée en iso-8859-1). Je vous laisse imaginer les conséquences si vous > avez à manipuler cette clé pour une raison ou pour une autre, en vous > attendant à ce qu'elle soit encodée en UTF8? > > Voilà un script montrant le problème: > > #!/usr/bin/perl > > use strict; > use warnings; > use utf8; > use Devel::Peek; > use Data::Dumper; > $Data::Dumper::Useqq = 1; > > my %hash = ( > 'clé' => 0, > ); > my $key = (keys %hash)[0]; > Dump($key); > print Dumper($key); > > $hash{'clé'} = 1; > $key = (keys %hash)[0]; > > Dump($key); > print Dumper($key); > > utf8::upgrade($key); > Dump($key); > print Dumper($key); > [download] > > avec le résultat suivant: > > SV = PV(0x555ed17dfe60) at 0x555ed1809710 > REFCNT = 1 > FLAGS = (POK,pPOK,UTF8) > PV = 0x555ed1993ed0 "cl\303\251"\0 [UTF8 "cl\x{e9}"] > CUR = 4 > LEN = 5 > $VAR1 = "cl\x{e9}"; > SV = PV(0x555ed17dfe60) at 0x555ed1809710 > REFCNT = 1 > FLAGS = (POK,IsCOW,pPOK) > PV = 0x555ed1909b10 "cl\351" > CUR = 3 > LEN = 0 > $VAR1 = "cl\351"; > SV = PV(0x555ed17dfe60) at 0x555ed1809710 > REFCNT = 1 > FLAGS = (POK,pPOK,UTF8) > PV = 0x555ed1825350 "cl\303\251"\0 [UTF8 "cl\x{e9}"] > CUR = 4 > LEN = 10 > $VAR1 = "cl\x{e9}"; > [download] > > Comme dans ce code, on peut résoudre le problème en surclassant en UTF8 > (utf8::upgrade) la clé. Mais j'aurais jamais imaginé devoir faire ça > avant de tomber sur le problème. J'ai rien lu dans perldoc qui explique > ce comportement. > > Vous avez une idée d'explication, si c'est ou non voulu ? > > Merci! > -- > Gérald Sédrati-Dinet > https://pascontent.sedrati-dinet.net https://www.april.org > https://www.unitary-patent.eu https://laquadrature.net > > _______________________________________________ > Perl mailing list > Perl at mongueurs.net > http://listes.mongueurs.net/mailman/listinfo/perl > Attention, les archives sont publiques -------------- section suivante -------------- Une pièce jointe HTML a été nettoyée... URL: From gerald at sedrati-dinet.net Sat Dec 1 11:51:03 2018 From: gerald at sedrati-dinet.net (=?UTF-8?Q?G=c3=a9rald_S=c3=89DRATI-DINET?=) Date: Sat, 1 Dec 2018 11:51:03 +0100 Subject: [Perl] UTF8 hash key downgraded when assigned In-Reply-To: References: <55dd4c7d-545b-1434-70e2-c403e37b48af@sedrati-dinet.net> Message-ID: <9125e9a3-1715-b48c-b360-13ebbc29950a@sedrati-dinet.net> Le 01/12/2018 à 08:14, Kai Carver a écrit : > hello Gérard Gérald en fait, ou Gibus c'est plus simple, Gérard c'est celui qui fume du hackick avec les beatnicks https://www.youtube.com/watch?v=w8Oa70HmXVU ;) > > curieux... > > j'ai vu ceci: > > "It appears to be a bug the optimisation of constant hash keys. The > constant key string in $h{'Góry'} is being downgraded from utf8, whereas > if you write my $g = 'Góry'; $h{$g} = 1; it works ok." > https://www.perlmonks.org/index.pl?node_id=1197369 > > et effectivement le bug ne se produit pas si au lieu d'utiliser 'clé' tu > utilises une variable $cle = 'clé' Yeah merci Kai, c'est exactement ça: faut savoir que l'optimisation des constantes comme clé de hash peut générer des problèmes. -- Gérald Sédrati-Dinet https://pascontent.sedrati-dinet.net https://www.april.org https://www.unitary-patent.eu https://laquadrature.net -------------- section suivante -------------- Une pièce jointe autre que texte a été nettoyée... Nom: signature.asc Type: application/pgp-signature Taille: 195 octets Desc: OpenPGP digital signature URL: From eiro at phear.org Thu Dec 13 17:24:10 2018 From: eiro at phear.org (Marc Chantreux) Date: Thu, 13 Dec 2018 17:24:10 +0100 Subject: [Perl] dist.ini homepage ? Message-ID: <20181213162410.GA4006@prometheus.u-strasbg.fr> salut à tous, j'utilise maintenant dzil pour maintenir le module Sympatic (celui dont j'avais parlé aux JP) et je fais la connaissance du block MetaResources https://github.com/sympa-community/p5-sympatic/blob/master/dist.ini#L46 [MetaResources] homepage = http://sympa.org/ me parrait fort sympatique ... sauf que [DZ] building distribution under .build/4xnjQwGyUb for installation [DZ] beginning to build sympatic [DZ] guessing dist's main_module is lib/Sympatic.pm [VersionFromModule] dist version 0.2 (from lib/Sympatic.pm) Can't merge attribute resources.homepage: 'https://github.com/sympa-community/p5-sympatic' does not equal 'http://sympa.org/' at /usr/share/perl5/Dist/Zilla.pm line 595. l'erreur est vague ): je ne sais pas encore ou il trouve l'information de la homepage ... je vais continuer à investiguer mais si quelqu'un a une piste, votre aide me serait précieuse. a+ marc From khatar at phear.org Fri Dec 14 08:17:00 2018 From: khatar at phear.org (Marc Chantreux) Date: Fri, 14 Dec 2018 08:17:00 +0100 Subject: [Perl] dist.ini homepage ? In-Reply-To: <20181213162410.GA4006@prometheus.u-strasbg.fr> References: <20181213162410.GA4006@prometheus.u-strasbg.fr> Message-ID: <20181214071700.GA28755@prometheus.u-strasbg.fr> salut, Réponse à moi-même > [MetaResources] > homepage = http://sympa.org/ [GithubMeta] part du principe que la "homepage" est la page du projet github, il faut donc surcharger cette info dans la section GithubMeta et la laisser vide dans MetaResources. donc [GithubMeta] [MetaResources] homepage = http://sympa.org/ devient [GithubMeta] homepage = http://sympa.org/ [MetaResources] voilà ... merci et bon we à tous marc