[Vienna-pm] utf8 string als hash-key

[max]

>>> Was tut:
>>> %hash=map { utf8::upgrade(my $k=$_); $k => $hash{$_} } keys %hash;
>>> $rdb->mget(\%hash);               # Verliert utf8-Flag
>>> %hash=map { _utf8_on(my $k=$_); $k => $hash{$_0} } keys %hash;
>> bleibt haengen... geiches passiert bei "normalen" utf8 strings  
>> (wohlgemerkt nur unter perl5.10)
>
> Bei welcher Zeile?

kann ich nicht sagen. das TokyoTyrant modul ist nicht von mir, und es  
bleibt in dem modul haengen! vielleicht kommt bei der client-server  
verbindung das protokoll mit den utf8 zeichen durcheinander... k.a.

> Abgesehen von perl5.10 Seltsamkeiten verwurschtelt dein Modul
> definitiv das utf8-Flag. Also mal ein Fehler des Moduls!
> Wenn es denn nicht gebe, wärst Du mit den perl5.10 Problemen
> nicht in Kontakt gekommen.

das stimmt, aber andererseits verwurschtelt das TokyoTyrant modul  
definitv auch das flag, und darum hab ich erst zum wurschteln  
angefangen :)

>> die use bytes directive ist fuer das ganze TokyoTyrant package  
>> eingeschalten, und darin wird dann extrem viel mit pack, unpack usw  
>> gemacht. das ist mir irgendwie zu heiss, da was anzufassen.
>
> Na ja, man könnte auch innerhalb von mget "no bytes;" einfügen.
> Aber das ist trotzdem Glückssache wegen xs.
>
> # Oder im eigen Modul dies einfügen (untestet)
> { package TokyoTyrant; # oder wie auch immer es heißt.
>  my $org_mget=\&TokyoTyrant::mget;
>  no warnings 'redefine';
>  sub mget : method { no bytes; shift()->$org_mget(@_) };
> }

w.g. es klappt mit encode("UTF-8", ...) jetzt eh, und darum werd ich  
das fremde modul das fremde modul bleiben lassen.

> Oder es gibt ohnehin eine neuere Version dieses Moduls‽

nein.. leider nicht.

thx u. lg. max.