From domm at cpan.org Tue Sep 1 00:47:59 2009 From: domm at cpan.org (Thomas Klausner) Date: Tue, 1 Sep 2009 09:47:59 +0200 Subject: [Vienna-pm] =?utf-8?q?Themen_f=C3=BCr_2009-09-01?= In-Reply-To: <200908261329.33736.daxim@cpan.org> References: <200908261329.33736.daxim@cpan.org> Message-ID: <20090901074759.GC3878@dedomm.validad.net> Hi! On Wed, Aug 26, 2009 at 01:29:22PM +0200, Lars D?????? ??? wrote: > * Perl 5.10.1 is out - what's new & how to compile for development environment > * The Hacker's Diet Ich kann heut leider nicht kommen, wuensche aber dem Rest viel Spass! -- #!/usr/bin/perl http://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From jozef at kutej.net Tue Sep 1 08:12:47 2009 From: jozef at kutej.net (Jozef Kutej) Date: Tue, 01 Sep 2009 17:12:47 +0200 Subject: [Vienna-pm] =?utf-8?q?Themen_f=C3=BCr_2009-09-01?= In-Reply-To: <200908261329.33736.daxim@cpan.org> References: <200908261329.33736.daxim@cpan.org> Message-ID: <4A9D39EF.8060701@kutej.net> Lars D?????? ??? wrote: > * Perl 5.10.1 is out - what's new & how to compile for development environment > * The Hacker's Diet i can do a lightning talk about my fresh new go-home-notification script :-) j From jozef at kutej.net Wed Sep 2 00:53:47 2009 From: jozef at kutej.net (Jozef Kutej) Date: Wed, 02 Sep 2009 09:53:47 +0200 Subject: [Vienna-pm] =?utf-8?q?Themen_f=C3=BCr_2009-09-01?= In-Reply-To: <4A9D39EF.8060701@kutej.net> References: <200908261329.33736.daxim@cpan.org> <4A9D39EF.8060701@kutej.net> Message-ID: <4A9E248B.8080907@kutej.net> Jozef Kutej wrote: > Lars D?????? ??? wrote: >> * Perl 5.10.1 is out - what's new & how to compile for development environment >> * The Hacker's Diet > > i can do a lightning talk about my fresh new go-home-notification script :-) http://github.com/jozef/jozef-bin/blob/5c1c99605d3a97a0269997ffa0695f44dbd802da/script/go-home-notification j From christoph.jokubonis at univie.ac.at Wed Sep 2 01:02:28 2009 From: christoph.jokubonis at univie.ac.at (Christoph Jokubonis) Date: Wed, 02 Sep 2009 10:02:28 +0200 Subject: [Vienna-pm] =?utf-8?q?Themen_f=C3=BCr_2009-09-01?= In-Reply-To: <4A9E248B.8080907@kutej.net> References: <200908261329.33736.daxim@cpan.org> <4A9D39EF.8060701@kutej.net> <4A9E248B.8080907@kutej.net> Message-ID: <4A9E2694.7020305@univie.ac.at> Hello! Jozef Kutej wrote: > Jozef Kutej wrote: >> Lars D?????? ??? wrote: >>> * Perl 5.10.1 is out - what's new & how to compile for development environment >>> * The Hacker's Diet >> i can do a lightning talk about my fresh new go-home-notification script :-) > > http://github.com/jozef/jozef-bin/blob/5c1c99605d3a97a0269997ffa0695f44dbd802da/script/go-home-notification You might want to include http://search.cpan.org/dist/Date-Holidays/ by creating Date::Holidays::Adapter::AT ;) regards, Christoph > > j > > > > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm From e9427749 at stud4.tuwien.ac.at Wed Sep 2 10:52:27 2009 From: e9427749 at stud4.tuwien.ac.at (josef schmid) Date: Wed, 02 Sep 2009 19:52:27 +0200 Subject: [Vienna-pm] export enviroment vars Message-ID: <4A9EB0DB.9090401@stud4.tuwien.ac.at> Hallo, allerseits! Mir ist da (zumindest f?r mich) seltsames aufgefallen. perl -e '$ENV{foo}=q{bla}; exec q{echo $foo >&2};'??? bla # was ich erwarte perl -e 'local %ENV;$ENV{foo}=q{bla}; exec q{echo $foo >&2};' bla # was ich auch erwarte perl -e 'local *ENV;$ENV{foo}=q{bla}; exec q{echo $foo >&2};' # b?ng, nix. pfiateng, Josef ad 1) Voraussetzung man hat ein Derivat einer Bourne?Shell als Standard Shell. ad 2) das selbe gilt f?r system(?), open(?,'|?'), sowohl unter 5.8.8 als auch 5.10.0 From e9427749 at stud4.tuwien.ac.at Thu Sep 3 08:56:05 2009 From: e9427749 at stud4.tuwien.ac.at (josef schmid) Date: Thu, 03 Sep 2009 17:56:05 +0200 Subject: [Vienna-pm] export enviroment vars In-Reply-To: <4A9EB0DB.9090401@stud4.tuwien.ac.at> References: <4A9EB0DB.9090401@stud4.tuwien.ac.at> Message-ID: <4A9FE715.7080908@stud4.tuwien.ac.at> josef schmid schrieb: > > Hallo, allerseits! > > > Mir ist da (zumindest f?r mich) seltsames aufgefallen. > > perl -e '$ENV{foo}=q{bla}; exec q{echo $foo >&2};'??? > bla # was ich erwarte > > perl -e 'local %ENV;$ENV{foo}=q{bla}; exec q{echo $foo >&2};' > bla # was ich auch erwarte > > perl -e 'local *ENV;$ENV{foo}=q{bla}; exec q{echo $foo >&2};' > # b?ng, nix. > Das gilt nat?rlich auch f?r: local %ENV=(foo => 'bla'); [OK] local *ENV={foo => 'bla'}; [zumindest vorerst irritativ] Nun ja offensichtlich verliert %ENV sein magisches Verhalten, wenn ?ber glob lokalisiert wird. Irgendwann zu 5.6.x Zeiten hatte ich den umgekehrten Fall das Lokalisieren mittels glob verhindert das eine Spezialvariable ihre Besonderheit verliert. Regeln ala "Vermeide dies" kann ich gut leben, aber Regeln ala "Wenn es so nicht geht, dann versuche es andersrum" sind eher unangenehm. Aber gottseidank^W*gl?cklicherweise* scheint Perl trotzdem hier einer Regel zu folgen. Wenn mittels glob, dann wird der Sonderstatus von der rechten Seite ?bernommen. D.h.: { local *e=\%ENV; $e{foo}='bla'; system 'echo $foo' }; ? tut, und eben auch { local %ENV; $ENV{foo}='bla'; ? } Irgendwie habe ich es geschafft, all die Jahre nicht dar?ber zu stolpern. ;-] (Oder es hat sich doch mal umgedreht?) (Damit geht local %ENV; *ENV=? eben nicht. Und local %ENV; *ENV{HASH}=? ist nicht erlaubt. Gibt es eine M?glichkeit den Status von links und die Referenz von rechts zu bekommen, also statt den Daten den Status zu kopieren? Oder denke ich blo? zu kompliziert? ) Nun zu etwas komplett anderem. Etwas f?r die ?sthetizisten unter euch. Was ist am wenigsten h?sslich: a) local %ENV=%$newenv if $newenv; readonly_something? Kurz & tut was es soll. Aber seltsam & gew?hnungsbed?rftig. b) local %ENV=$newenv ? %$newenv : %ENV; readonly_something? Etwas verwirrend und macht ?wahrscheinlich? eine unn?tige Kopie falls $newenv nicht vorhanden. b2) local %ENV=%{ $newenv ? $newenv : \%ENV }; readonly_something? c) my $inner=sub { readonly_something? }; if ($newenv) { local %ENV=%$newenv; &$inner } else { &$inner } Halt relativ explizit d) POSIX::exec?e(?); Nur in sehr speziellen F?llen, und erwartet die Parameter wahrscheinlich ohnehin unperlisch. e) Oder?? pfiateng, Josef PS: Zum Ausgleich l?sst sich^W^Wist das Env Modul nicht verwirrend: use Env "bla"; { local %ENV=(bla=>2); print "$bla\n" } From oliver.baier at lotterien.at Fri Sep 4 00:31:06 2009 From: oliver.baier at lotterien.at (Baier Oliver) Date: Fri, 4 Sep 2009 09:31:06 +0200 Subject: [Vienna-pm] export enviroment vars In-Reply-To: <4A9FE715.7080908@stud4.tuwien.ac.at> References: <4A9EB0DB.9090401@stud4.tuwien.ac.at> <4A9FE715.7080908@stud4.tuwien.ac.at> Message-ID: <69E5AEF30B927F4E9ACE54092B904BB803A181CA1B@EXCHCLU1.office.lottery.co.at> $a++; finde (a) gar nicht gew?hnungsbed?rftig; eher im Gegenteil. (b) ist ineffizient wegen Kopie und (c) einfach zu umst?ndlich. *meine Meinung* lg Oliver > -----Urspr?ngliche Nachricht----- > Von: vienna-pm-bounces+oliver.baier=lotterien.at at pm.org > [mailto:vienna-pm-bounces+oliver.baier=lotterien.at at pm.org] > Im Auftrag von josef schmid > Gesendet: Donnerstag, 03. September 2009 17:56 > An: vienna-pm at pm.org > Betreff: Re: [Vienna-pm] export enviroment vars > > Nun zu etwas komplett anderem. > Etwas f?r die ?sthetizisten unter euch. > Was ist am wenigsten h?sslich: > > a) local %ENV=%$newenv if $newenv; readonly_something. > Kurz & tut was es soll. Aber seltsam & gew?hnungsbed?rftig. > > b) local %ENV=$newenv ? %$newenv : %ENV; readonly_something. > Etwas verwirrend und macht ?wahrscheinlich? eine unn?tige > Kopie falls $newenv nicht vorhanden. > > b2) local %ENV=%{ $newenv ? $newenv : \%ENV }; readonly_something. > > c) my $inner=sub { readonly_something. }; > if ($newenv) { local %ENV=%$newenv; &$inner } else { &$inner } > Halt relativ explizit > > d) POSIX::exec.e(.); > Nur in sehr speziellen F?llen, > und erwartet die Parameter wahrscheinlich ohnehin unperlisch. > > e) Oder?? > ?sterreichische Lotterien Ges.m.b.H., Rennweg 44, A-1038 Wien FN 54472 g, Handelsgericht Wien, DVR-Nr.: 0476706, UID ATU 15666508 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3634 bytes Desc: not available URL: From e9427749 at stud4.tuwien.ac.at Tue Sep 8 09:13:36 2009 From: e9427749 at stud4.tuwien.ac.at (Josef) Date: Tue, 08 Sep 2009 18:13:36 +0200 Subject: [Vienna-pm] export enviroment vars In-Reply-To: <4A9FE715.7080908@stud4.tuwien.ac.at> References: <4A9EB0DB.9090401@stud4.tuwien.ac.at> <4A9FE715.7080908@stud4.tuwien.ac.at> Message-ID: <4AA682B0.4000509@stud4.tuwien.ac.at> Nochmals hi! ich schrieb: >> Mir ist da (zumindest f?r mich) seltsames aufgefallen. >> >> $ENV{foo}='bla'; exec q{echo $foo}; >> bla # was ich erwarte >> local %ENV;$ENV{foo}='bla'; exec q{echo $foo}; >> bla # was ich auch erwarte >> local *ENV;$ENV{foo}='bla'; exec q{echo $foo}; >> # b?ng, nix. > > Das gilt nat?rlich auch f?r: > local %ENV=(foo => 'bla'); [OK] > local *ENV={foo => 'bla'}; [zumindest vorerst irritativ] > Nun ja offensichtlich verliert %ENV sein magisches Verhalten, wenn > ?ber glob lokalisiert wird. > [?] > Aber gottseidank^W*gl?cklicherweise* scheint Perl trotzdem > hier einer Regel zu folgen. Wenn mittels glob, > dann wird der Sonderstatus von der rechten Seite ?bernommen. > D.h.: { local *e=\%ENV; $e{foo}='bla'; system 'echo $foo' }; ? > tut, und eben auch > { local %ENV; $ENV{foo}='bla'; ? } > [?] Aber das erlaubt so seltsame Dinge wie: (*SIG, *ENV)=(\%ENV,\%SIG); $SIG{foo}='bla'; exec 'echo $foo'; Perl-Obsfuscation lebe 3x hoch. DWIMerisch ist das ihmo ? gerade. Speziell bei den Spezialvariablen erwartet man wahrscheinlich doch das die Magie am Namen haftet(/oder nachl?uft). Sonst wohl eher ?? Um die Sache dann doch wieder verwirrend zu machen, f?r andere spezielle (aber nicht zauberhaften?) Perl-Variablen, gehen wieder beide Varianten: z.B.: local *_=\$x und local $_=$x; Hingegen: local *STDERR{IO}=...; geht (wiederum) nicht. (v5.10) Hier muss es local *STDERR=\...; sein Meinungen? ? oder gar einfache Regeln daf?r? > [?] > Gibt es eine M?glichkeit den Status von links und die Referenz > von rechts zu bekommen, also statt den Daten den Status zu kopieren? Zumindest Variable::Magic erlaubt nur eigene Zaubereien hinzuzuf?gen. pfiateng, Josef From prozessor13 at gmx.net Sun Sep 20 11:39:20 2009 From: prozessor13 at gmx.net (max) Date: Sun, 20 Sep 2009 20:39:20 +0200 Subject: [Vienna-pm] utf8 string als hash-key Message-ID: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> hallo.. ich hab mich jetzt die letzten stunden rumgeaergert, weil ein programm auf dem test-system funktioniert hat, und am live nicht. das test-system ist unter os x perl 5.8.9 (installiert mit macports) am live-system ist es debian-etch perl 5.10.0 hier das test-programm. schaut ziehmlich unsinnig aus, aber es ist halt nur das minimal-set.. die logik fehlt klarerweise.. ------------------------------------------------------ package X; use strict; use Encode qw( _utf8_off _utf8_on ); sub x { my %hash = map { my $k = $_; _utf8_off($k); # so sollten dann doch einfach die bytes verwendet werden $k => 'ok'; } @_; # hier braucht irgendeine logic einen hash mit keinen utf8-keys # (es kommt sonnst in einer 3rd party lib zu einem fehler) foreach (keys %hash) { my $k = $_; _utf8_on($k); # und jetzt machen wir wieder utf8-strings daraus $hash{$k} = delete $hash{$_}; } # der return-hash soll wieder die originalen keys drinnen haben return \%hash; } package main; use strict; use utf8; use Data::Dumper; binmode STDOUT, 'utf8'; my $x = '???'; my $h = X::x($x); print Dumper($h); print "\n\ntest: " . $h->{$x} . "\n"; ---------------------------------------------------------- der output ist am test-system: $VAR1 = { "\x{f6}\x{e4}\x{fc}" => 'ok' }; test: ok und am live-system: $VAR1 = { "\x{f6}\x{e4}\x{fc}" => 'ok', }; test: jetzt gibt es fuer mich ein paar unbekannte: * rechnet perl 5.10.0 richtig * rechnet perl 5.8.9 richtig * wieso schreibt Data::Dumper ueberhaupt \x{f6}\x{e4}\x{fc} und nicht ??? ... \x{f6} ist doch ein latin1 zeichen?? * wie kann ich das loesen bitte helft mir. thx. max. From pagaltzis at gmx.de Sun Sep 20 14:05:05 2009 From: pagaltzis at gmx.de (Aristoteles Pagaltzis) Date: Sun, 20 Sep 2009 23:05:05 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> Message-ID: <20090920210505.GB18011@klangraum.plasmasturm.org> * max [2009-09-20 20:40]: > use Encode qw( _utf8_off _utf8_on ); Du machst mit ann?hernd 100%er Wahrscheinlichtkeit etwas falsch. Du verstehst auch mit ?hnlicher Wahrscheinlichtkeit nicht, was du damit tats?chlich anstellst. (Das ist nicht pers?nlich gemeint: es ist etwas, was nur wenige richtig verstehen. Sogar die Perl- Doku selbst ist streckenweise verwirrt.) > # (es kommt sonnst in einer 3rd party lib zu einem fehler) Wie w?r?s, wenn du dein eigentliches Problem schilderst? Gru?, -- Aristoteles Pagaltzis // From e9427749 at stud4.tuwien.ac.at Sun Sep 20 14:29:58 2009 From: e9427749 at stud4.tuwien.ac.at (Josef) Date: Sun, 20 Sep 2009 23:29:58 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> Message-ID: <4AB69ED6.3080807@stud4.tuwien.ac.at> Hallo, Max! _utf8_{on,off} setzen nur das interne Flag um! Und ?ndern nichts an den Daten. Wenn Flag zuerst an, dann schaltest Du aus und wieder an, geht alles _zuf?lligerweise_! Wenn aber das Flag aus ist, weil nur Latin1 Zeichen drin; Und Du schaltest aus (nop) un dann ein, dann h?lt er deinen String (der immer noch iso-8859-1 ist, f?lschlicherweise f?r utf-8. Ausgeben tuts Du in utf-8, also meint er nichts zu tun zu haben. => Problemo no uno. Zweitens ist die Bytefolge \x{f6}\x{e4}\x{fc} Latin1 bzw. utf8 nicht das selbe, somit findet er denn Wert korrekter- weise nicht. Wenn externes mit ausgemachten Hashkeys zugreift, brauchst Du ohnehin encode("iso-8859-1",$s) & decode("iso-8859-1",$s). (Sonst reicht u.U. ein use bytes an der richtigen Stelle.) Die Doku vom Encode-Modul mag verwirrend sein, aber lesen kann trotzdem nicht Schaden. Meist lohnender als per zufallsmethode Funktionen einer Lib einzusetzen, und hoffen das es tut was man will (trotz DWIMery ;-). ciao, Josef max schrieb: > [...] sub x { > my %hash = map { > my $k = $_; > _utf8_off($k); # so sollten dann doch einfach die bytes > verwendet werden > $k => 'ok'; > } @_; > # hier braucht irgendeine logic einen hash mit keinen utf8-keys > # (es kommt sonnst in einer 3rd party lib zu einem fehler) > foreach (keys %hash) { > my $k = $_; > _utf8_on($k); # und jetzt machen wir wieder utf8-strings daraus > $hash{$k} = delete $hash{$_}; > } > # der return-hash soll wieder die originalen keys drinnen haben > return \%hash; > } > > package main; > > use strict; > use utf8; > use Data::Dumper; > binmode STDOUT, 'utf8'; > > my $x = '???'; > my $h = X::x($x); > print Dumper($h); > print "\n\ntest: " . $h->{$x} . "\n"; > ---------------------------------------------------------- > > der output ist am test-system: > > $VAR1 = { > "\x{f6}\x{e4}\x{fc}" => 'ok' > }; > > test: ok > > und am live-system: > > $VAR1 = { > "\x{f6}\x{e4}\x{fc}" => 'ok', > }; > > test: > > jetzt gibt es fuer mich ein paar unbekannte: > > * rechnet perl 5.10.0 richtig > * rechnet perl 5.8.9 richtig > * wieso schreibt Data::Dumper ueberhaupt \x{f6}\x{e4}\x{fc} und nicht > ??? ... \x{f6} ist doch ein latin1 zeichen?? > * wie kann ich das loesen From prozessor13 at gmx.net Mon Sep 21 01:22:50 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 10:22:50 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <20090920210505.GB18011@klangraum.plasmasturm.org> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <20090920210505.GB18011@klangraum.plasmasturm.org> Message-ID: <1D4A3B00-E1D5-442A-93A9-7B639625BDA8@gmx.net> On Sep 20, 2009, at 11:05 PM, Aristoteles Pagaltzis wrote: > * max [2009-09-20 20:40]: >> use Encode qw( _utf8_off _utf8_on ); > > Du machst mit ann?hernd 100%er Wahrscheinlichtkeit etwas falsch. > Du verstehst auch mit ?hnlicher Wahrscheinlichtkeit nicht, was du > damit tats?chlich anstellst. (Das ist nicht pers?nlich gemeint: > es ist etwas, was nur wenige richtig verstehen. Sogar die Perl- > Doku selbst ist streckenweise verwirrt.) ja.. das seh ich auch so, wollte eben nur wissen was ich falsch mach > >> # (es kommt sonnst in einer 3rd party lib zu einem fehler) > > Wie w?r?s, wenn du dein eigentliches Problem schilderst? ich brauch die methode $rdb->mget(\%hash) von Tokyo Tyrant (http://1978th.net/tokyotyrant/perldoc/). nur bin ich grad draufgekommen, dass diese eh gar nicht das problem ist. peinlich. hab mich aber leider so darauf festgefahren, dass ichs erst wem erzaehlen hab muessen, um das selber zu checken. das problem tritt einfach schon viel frueher auf (irgendwo erstell ich einen nicht validen utf8-string). d.h. die richtige methode schaut so aus! sub x { my %hash = map { $_ => undef } @_; $rdb->mget(\%hash); return \%hash; } vielen dank mal. > > Gru?, > -- > Aristoteles Pagaltzis // > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm -------------- next part -------------- An HTML attachment was scrubbed... URL: From prozessor13 at gmx.net Mon Sep 21 01:33:30 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 10:33:30 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <4AB69ED6.3080807@stud4.tuwien.ac.at> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> Message-ID: On Sep 20, 2009, at 11:29 PM, Josef wrote: > Hallo, Max! > > _utf8_{on,off} setzen nur das interne Flag um! > Und ?ndern nichts an den Daten. ja das weiss ich, das war auch genau meine absicht. ich wollt einfach den strings als bytes ansehen, ohne der utf8-logik > Wenn Flag zuerst an, dann schaltest Du aus und wieder an, > geht alles _zuf?lligerweise_! > Wenn aber das Flag aus ist, weil nur Latin1 Zeichen drin; > Und Du schaltest aus (nop) un dann ein, dann h?lt er deinen > String (der immer noch iso-8859-1 ist, f?lschlicherweise > f?r utf-8. Ausgeben tuts Du in utf-8, also meint er nichts > zu tun zu haben. => Problemo no uno. es kommen immer utf8-strings daher, darum auch diese annahme (was jetzt programmiertechnisch sicher nicht 1A ist ;) > Zweitens ist die Bytefolge \x{f6}\x{e4}\x{fc} Latin1 bzw. > utf8 nicht das selbe, somit findet er denn Wert korrekter- > weise nicht. ja und nein, denn in perl5.8.9 funktioniert es ja. das ist ja das komische! > Wenn externes mit ausgemachten Hashkeys zugreift, brauchst > Du ohnehin encode("iso-8859-1",$s) & decode("iso-8859-1",$s). > (Sonst reicht u.U. ein use bytes an der richtigen Stelle.) ja waere besser gewesen. hab halt gedacht, ich kann perl mit dem utf8 flag austricksen... falsch gedacht > Die Doku vom Encode-Modul mag verwirrend sein, aber lesen > kann trotzdem nicht Schaden. Meist lohnender als per > zufallsmethode Funktionen einer Lib einzusetzen, und > hoffen das es tut was man will (trotz DWIMery ;-). was ist DWIMery? :) das Encode-Modul hab ich schon gelesen -> es was schon volle absicht _utf8_off/on einzusetzen. also fuer mich war der code ja auch mehr als komisch programmiert, vorallem weil ich, wie ich jetzt weiss einen folgefehler zum ausbessern versucht hab. vergessen wirs.. hab den code schon geloescht. ich dank euch fuer die hilfe, denn oft ist einfach nur ein wenig beistand schon des problems loesung. max. > > ciao, > Josef > > max schrieb: >> [...] sub x { >> my %hash = map { >> my $k = $_; >> _utf8_off($k); # so sollten dann doch einfach die bytes >> verwendet werden >> $k => 'ok'; >> } @_; >> # hier braucht irgendeine logic einen hash mit keinen utf8-keys >> # (es kommt sonnst in einer 3rd party lib zu einem fehler) >> foreach (keys %hash) { >> my $k = $_; >> _utf8_on($k); # und jetzt machen wir wieder utf8-strings >> daraus >> $hash{$k} = delete $hash{$_}; >> } >> # der return-hash soll wieder die originalen keys drinnen haben >> return \%hash; >> } >> package main; >> use strict; >> use utf8; >> use Data::Dumper; >> binmode STDOUT, 'utf8'; >> my $x = '???'; >> my $h = X::x($x); >> print Dumper($h); >> print "\n\ntest: " . $h->{$x} . "\n"; >> ---------------------------------------------------------- >> der output ist am test-system: >> $VAR1 = { >> "\x{f6}\x{e4}\x{fc}" => 'ok' >> }; >> test: ok >> und am live-system: >> $VAR1 = { >> "\x{f6}\x{e4}\x{fc}" => 'ok', >> }; >> test: >> jetzt gibt es fuer mich ein paar unbekannte: >> * rechnet perl 5.10.0 richtig >> * rechnet perl 5.8.9 richtig >> * wieso schreibt Data::Dumper ueberhaupt \x{f6}\x{e4}\x{fc} und >> nicht ??? ... \x{f6} ist doch ein latin1 zeichen?? >> * wie kann ich das loesen From nine at detonation.org Mon Sep 21 01:48:30 2009 From: nine at detonation.org (Stefan Seifert) Date: Mon, 21 Sep 2009 10:48:30 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> Message-ID: <200909211048.34741.nine@detonation.org> On Monday 21 September 2009 10:33:30 max wrote: > On Sep 20, 2009, at 11:29 PM, Josef wrote: > > Hallo, Max! > > > > _utf8_{on,off} setzen nur das interne Flag um! > > Und ?ndern nichts an den Daten. > > ja das weiss ich, das war auch genau meine absicht. ich wollt einfach > den strings als bytes ansehen, ohne der utf8-logik Dazu gibt es auch einen vorgesehenen Weg: ? utf8::encode($string) Converts in-place the character sequence to the corresponding octet sequence in UTF-X. The UTF8 flag is turned off, so that after this operation, the string is a byte string. Returns nothing. Danach hast du einen Byte-String mit deinen UTF-8 codierten Zeichen und Perl kennt sich auch aus. F?r den umgekehrten Weg vom Bytestring zu einer Perl-Zeichenkette gibts utf8::decode. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From prozessor13 at gmx.net Mon Sep 21 03:00:12 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 12:00:12 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <200909211048.34741.nine@detonation.org> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> Message-ID: <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> bins schonwieder. > Dazu gibt es auch einen vorgesehenen Weg: > > ? utf8::encode($string) ok. das hab ich jetzt verwendet, und unter perl 5.8.9 funkt das auch (wie auch schon das _utf8_off/on) aber leider gehts immer noch nicht, und ich hab noch folgendes rausgefunden: die TokyoTyrant mget methode macht definitv was komisches: sub x { my %hash = map { $_ => 'ko' } @_; print "1: " . join(",", keys %hash) . "\n"; $rdb->mget(\%hash); print "2: " . join(",", keys %hash) . "\n"; foreach (keys %hash) { my $k = $_; utf8::decode($k); $hash{$k} = $hash{$_}; } print "3: " . join(",", keys %hash) . "\n"; return \%hash; } liefert die ausgabe in perl 5.8.9: 1: ??? 2: ?????? 3: ??????,??? soweit sogut, mget macht was mit dem hash, aber man kann es reparieren, aber: unter 5.10 bleibt die methode mget haengen. d.h. ich muss ein utf8::encode dranmachen. my %hash = map { $_ => 'ko' } @_; wird zu my %hash = map { utf8::encode($_); $_ => 'ko' } @_; der output ist: 1: ?????? 2: ?????? 3: ???,?????? schaut auch richtig aus.. aber jetzt kommts: wenn ich sowas schreib my %hash = map { my $k = $_;utf8::encode($k); $k => 'ko' } @_; dann kommt zwar der gleiche output, aber die HASH->FETCH methode liefert nix mehr: d.h. ich bau: foreach my $k (keys %hash) { print "k: $k -> $hash{$k}\n"; } irgendwo ein und bekomm: k: ??? -> k: ?????? -> ok obwohl Data::Dumper: $VAR1 = { "\x{f6}\x{e4}\x{fc}" => 'ok', '??????' => 'ok' }; liefert. also fuer mich ist das eindeutig ein perl5.10 bug!! lg. From prozessor13 at gmx.net Mon Sep 21 03:30:16 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 12:30:16 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> Message-ID: <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> so und nochmal. jetzt hab ich das beweis-script: use strict; use utf8; use Data::Dumper; binmode STDOUT, 'utf8'; sub x { my %hash = map { my $k = $_; utf8::encode($k); $k => 'bytes' } @_; foreach (keys %hash) { my $k = $_; utf8::decode($k); $hash{$k} = 'utf8'; } return \%hash; } my $x = '???'; my $h = x($x); print Data::Dumper->Dumpperl([$h]); print Data::Dumper->Dump([$h]); liefert unter perl5.8.9 korrekterweise: $VAR1 = { '??????' => 'bytes', '???' => 'utf8' }; $VAR1 = { '??????' => 'bytes', "\x{f6}\x{e4}\x{fc}" => 'utf8' }; und unter perl 5.10 falscherweise: $VAR1 = { '???' => undef, '??????' => 'bytes', '???' => ${\$VAR1->{'???'}} }; $VAR1 = { "\x{f6}\x{e4}\x{fc}" => 'utf8', '??????' => 'bytes', "\x{f6}\x{e4}\x{fc}" => undef }; k.a. wieso da 3 keys drinnen sind, und zusaetzlich verliert der perl- varante im gegensatz zur xs variante auch noch eine hash-value. grrr... ich weiss nicht, ob ich hier eine loesung schaffen kann... From bernd at firmix.at Mon Sep 21 04:29:18 2009 From: bernd at firmix.at (Bernd Petrovitsch) Date: Mon, 21 Sep 2009 13:29:18 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> Message-ID: <1253532558.8674.5.camel@tara.firmix.at> On Mon, 2009-09-21 at 12:30 +0200, max wrote: [...] > grrr... ich weiss nicht, ob ich hier eine loesung schaffen kann... Die Weicheier-L?sung ist wohl, den bin?ren Byte-String base64 (o.?.) encoden bevor man ihn als Key ben?tzt und zur?ck konvertieren, wenn man ihn ausliest. "UTF-8 vs Latin-1" l?st das nat?rlich nicht - falls das ein Problem ist. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From prozessor13 at gmx.net Mon Sep 21 04:46:57 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 13:46:57 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <1253532558.8674.5.camel@tara.firmix.at> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1253532558.8674.5.camel@tara.firmix.at> Message-ID: <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> On Sep 21, 2009, at 1:29 PM, Bernd Petrovitsch wrote: > On Mon, 2009-09-21 at 12:30 +0200, max wrote: > [...] >> grrr... ich weiss nicht, ob ich hier eine loesung schaffen kann... > > Die Weicheier-L?sung ist wohl, den bin?ren Byte-String base64 (o.?.) keine schleche idee!, aber Wolfgang Laun hat mir grad eben schon den entscheidenden tip gegeben. naemlich use Encode qw( encode decode ); sub x { my %hash = map { my $k = encode("UTF-8", $_ ); $k => 'bytes' } @_; foreach (keys %hash) { my $k = decode( "UTF-8", $_ ); $hash{$k} = 'utf8'; } return \%hash; } irgendwie scheint es, dass utf8::encode/decode _utf8_on/off irgendwie zu wenig machen, und perl5.10 durcheinanderkommt. lg. max. > encoden bevor man ihn als Key ben?tzt und zur?ck konvertieren, wenn > man > ihn ausliest. > "UTF-8 vs Latin-1" l?st das nat?rlich nicht - falls das ein Problem > ist. > > Bernd > -- > Firmix Software GmbH http://www.firmix.at/ > mobil: +43 664 4416156 fax: +43 1 7890849-55 > Embedded Linux Development and Services > > > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm From e9427749 at stud4.tuwien.ac.at Mon Sep 21 06:34:16 2009 From: e9427749 at stud4.tuwien.ac.at (Josef) Date: Mon, 21 Sep 2009 15:34:16 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1253532558.8674.5.camel@tara.firmix.at> <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> Message-ID: <4AB780D8.6080109@stud4.tuwien.ac.at> Hi, allerseits! max schrieb: > keine schleche idee!, aber Wolfgang Laun hat mir grad eben schon den > entscheidenden tip gegeben. naemlich Nun ja, da h?ttest Du auch mein Posting lesen k?nnen. ;-/ (Latin1 w?re wichtig gewesen, wenn die andere Lib selber auf Werte mit bestimmten Schl?sseln zugreift. Diesbez?gl. hattest Du Dich noch nicht ge?u?ert gehabt. UTF-8 hat den Vorteil das alle Zeichen drin Platz haben.) Zu Deinem Ausgangspunkt noch ein paar Fragen. 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; Und was tut: %hash=map { encode('iso-8859-1',$_) => $hash{$_} } keys %hash; # ^- nur Latin1, kein Flag $rdb->mget(\%hash); # solange nur latin1-Zeichen sollte es passen. Und drittens: Falls deine Lib reines Perl ist, schau ob dort irgendwo "use bytes;" steht und kommentier das mal testweise aus. Vielleicht er?brigt sich dann Dein Workaround, um den Workaround der Bibl. f?r ?ltere Perls. Noch ein paar Fragen: - Taintmode? - PERL_UNICODE Umgebungsvariable? - Insbesondere Unterschiede zw. den Systemen? ciao, Josef PS: utf8::upgrade($_) for keys %hash; geht f?r values aber nicht f?r keys. From prozessor13 at gmx.net Mon Sep 21 07:46:21 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 16:46:21 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <4AB780D8.6080109@stud4.tuwien.ac.at> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1253532558.8674.5.camel@tara.firmix.at> <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> <4AB780D8.6080109@stud4.tuwien.ac.at> Message-ID: <17999915-4E73-4524-A8FF-5351237CC7FB@gmx.net> hallo > max schrieb: >> keine schleche idee!, aber Wolfgang Laun hat mir grad eben schon >> den entscheidenden tip gegeben. naemlich > > Nun ja, da h?ttest Du auch mein Posting lesen k?nnen. ;-/ > (Latin1 w?re wichtig gewesen, wenn die andere Lib selber auf Werte > mit bestimmten Schl?sseln zugreift. Diesbez?gl. hattest Du Dich > noch nicht ge?u?ert gehabt. UTF-8 hat den Vorteil das alle Zeichen > drin Platz haben.) das stimmt schon, aber ich habs zu dem zeitpunkt noch nicht einsehen wollen, dass es nicht anders geht. vorallem hab ich gedacht mit latin1 verliere ich im schlechtesten fall informationen, und mit base64 waere das nicht der fall, darum spontan die bessere alternative fuer mich. > Zu Deinem Ausgangspunkt noch ein paar Fragen. > > 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) > Und was tut: > %hash=map { encode('iso-8859-1',$_) => $hash{$_} } keys %hash; > # ^- nur Latin1, kein Flag > $rdb->mget(\%hash); > # solange nur latin1-Zeichen sollte es passen. das klappt komischerweise. versteh ich ueberhaupt nicht! kann sogar mit dem 6byte langam '???' string den hash-accessen (wo ja eigentlich nur 3byte keys drinnen sein sollten). oder macht hier perl dann automatisch die konvertierung?? falls ja, dann kann das aber, wie du eh schon sagst mit chinesischen zeichen nicht funken. > Und drittens: > Falls deine Lib reines Perl ist, schau ob dort irgendwo > "use bytes;" steht und kommentier das mal testweise aus. > Vielleicht er?brigt sich dann Dein Workaround, um den > Workaround der Bibl. f?r ?ltere Perls. das modul ist perl/xs, und das problem ist nicht in aelteren perls sondern in perl5.10. 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. > Noch ein paar Fragen: > - Taintmode? nein > - PERL_UNICODE Umgebungsvariable? nein > - Insbesondere Unterschiede zw. den Systemen? ich denke nicht, os x und debian halt, und perl5.8.9 und perl5.10.0. alles mit den defaultconfigs installiert danke wiedermal. max. > > ciao, > Josef > > PS: utf8::upgrade($_) for keys %hash; > geht f?r values aber nicht f?r keys. hmm. das versteh ich irgendwie nicht... was du da meinst? From e9427749 at stud4.tuwien.ac.at Mon Sep 21 08:41:40 2009 From: e9427749 at stud4.tuwien.ac.at (Josef) Date: Mon, 21 Sep 2009 17:41:40 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <17999915-4E73-4524-A8FF-5351237CC7FB@gmx.net> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1253532558.8674.5.camel@tara.firmix.at> <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> <4AB780D8.6080109@stud4.tuwien.ac.at> <17999915-4E73-4524-A8FF-5351237CC7FB@gmx.net> Message-ID: <4AB79EB4.1050209@stud4.tuwien.ac.at> Hi, again! max schrieb: [?] >> Zu Deinem Ausgangspunkt noch ein paar Fragen. >> >> 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? (Falls Deine Behauptung stimmt, das alle Texte utf-8 sind, kannst Du die erste Zeile auch auskommentieren.) >> Und was tut: >> %hash=map { encode('iso-8859-1',$_) => $hash{$_} } keys %hash; >> # ^- nur Latin1, kein Flag >> $rdb->mget(\%hash); >> # solange nur latin1-Zeichen sollte es passen. > > das klappt komischerweise. versteh ich ueberhaupt nicht! kann sogar mit > dem 6byte langam '???' string den hash-accessen (wo ja eigentlich nur > 3byte keys drinnen sein sollten). oder macht hier perl dann automatisch > die konvertierung?? falls ja, dann kann das aber, wie du eh schon sagst > mit chinesischen zeichen nicht funken. > >> Und drittens: >> Falls deine Lib reines Perl ist, schau ob dort irgendwo >> "use bytes;" steht und kommentier das mal testweise aus. >> Vielleicht er?brigt sich dann Dein Workaround, um den >> Workaround der Bibl. f?r ?ltere Perls. > > das modul ist perl/xs, und das problem ist nicht in aelteren perls > sondern in perl5.10. 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. ?lterer xs-Code ist oft nicht utf8-aware. > 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(@_) }; } Oder es gibt ohnehin eine neuere Version dieses Moduls? ciao, Josef >> PS: utf8::upgrade($_) for keys %hash; >> geht f?r values aber nicht f?r keys. > > hmm. das versteh ich irgendwie nicht... was du da meinst? Macht nix, war ohnehin an andere Mitleser adressiert? From pagaltzis at gmx.de Mon Sep 21 09:37:56 2009 From: pagaltzis at gmx.de (Aristoteles Pagaltzis) Date: Mon, 21 Sep 2009 18:37:56 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <4AB79EB4.1050209@stud4.tuwien.ac.at> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1D4A3B00-E1D5-442A-93A9-7B639625BDA8@gmx.net> Message-ID: <20090921163756.GA11296@klangraum.plasmasturm.org> * max [2009-09-21 10:25]: > On Sep 20, 2009, at 11:05 PM, Aristoteles Pagaltzis wrote: > >Du machst mit ann?hernd 100%er Wahrscheinlichtkeit etwas > >falsch. Du verstehst auch mit ?hnlicher Wahrscheinlichtkeit > >nicht, was du damit tats?chlich anstellst. (Das ist nicht > >pers?nlich gemeint: es ist etwas, was nur wenige richtig > >verstehen. Sogar die Perl- Doku selbst ist streckenweise > >verwirrt.) > > ja.. das seh ich auch so, wollte eben nur wissen was ich falsch > mach Du fummelst mit der internen Repr?sentation von Strings herum. Das willst du in 99.9999% der F?lle *nicht* machen. > nur bin ich grad draufgekommen, dass diese eh gar nicht das > problem ist. peinlich. hab mich aber leider so darauf > festgefahren, dass ichs erst wem erzaehlen hab muessen, um das > selber zu checken. Mach dir nichts draus, das ist normal. :-) Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed ?Never mind, I see what?s wrong. Sorry to bother you.? This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor. ?Kernighan & Pike, _The Practice of Programming_, Kap. 1 * max [2009-09-21 10:35]: > On Sep 20, 2009, at 11:29 PM, Josef wrote: > >_utf8_{on,off} setzen nur das interne Flag um! Und ?ndern > >nichts an den Daten. > > ja das weiss ich, das war auch genau meine absicht. ich wollt > einfach den strings als bytes ansehen, ohne der utf8-logik Das willst du nicht. ??? kann abh?ngig vom Flag wahlweise als Byte DF oder als Bytefolge C3 9F dargestellt und BEDEUTET DASSELBE in beiden F?llen. Du willst die Zeichenkette encoden, nicht einfach an irgendwelchen Perl-Eingeweiden herumfummeln, soda? aus einem ??? immer dasselbe Ergebnis wird, nicht mal so und mal so. > es kommen immer utf8-strings daher, darum auch diese annahme > (was jetzt programmiertechnisch sicher nicht 1A ist ;) Gew?hn dir das ab. Denk nicht ?ber das UTF-8-Flag nach. > ja und nein, denn in perl5.8.9 funktioniert es ja. das ist ja > das komische! Das ist Programming by Coincidence. Wenn du es falsch machst, und es funktioniert zuf?lligerweise trotzdem, hei?t das nicht, da? du es richtig gemacht hast. * max [2009-09-21 12:30]: > so und nochmal. > > jetzt hab ich das beweis-script: > > use strict; > use utf8; > use Data::Dumper; > binmode STDOUT, 'utf8'; > > sub x { > my %hash = map { > my $k = $_; > utf8::encode($k); > $k => 'bytes' > } @_; > foreach (keys %hash) { > my $k = $_; > utf8::decode($k); > $hash{$k} = 'utf8'; > } > return \%hash; > } > > my $x = '???'; > my $h = x($x); > print Data::Dumper->Dumpperl([$h]); > print Data::Dumper->Dump([$h]); > > liefert unter perl5.8.9 korrekterweise: > > $VAR1 = { > '??????' => 'bytes', > '???' => 'utf8' > }; > $VAR1 = { > '??????' => 'bytes', > "\x{f6}\x{e4}\x{fc}" => 'utf8' > }; > > und unter perl 5.10 falscherweise: > > $VAR1 = { > '???' => undef, > '??????' => 'bytes', > '???' => ${\$VAR1->{'???'}} > }; > $VAR1 = { > "\x{f6}\x{e4}\x{fc}" => 'utf8', > '??????' => 'bytes', > "\x{f6}\x{e4}\x{fc}" => undef > }; Hier ist das Gegenbeweis-Skript: use strict; use utf8; use Data::Dumper; use Encode; binmode STDOUT, ':encoding(UTF-8)'; sub x { my %hash = map { my $k = $_; encode('UTF-8', $k) => 'bytes'; } @_; foreach (keys %hash) { my $k = $_; $hash{decode('UTF-8', $k)} = 'utf8'; } return \%hash; } my $x = '???'; my $h = x($x); print Data::Dumper->Dumpperl([$h]); print Data::Dumper->Dump([$h]); Das liefert bei mir die erwartete Ausgabe. Ein paar Punkte zum Mitschreiben: ? Niemals den `:utf8` binmode verwenden, denn der macht effektiv nur `_utf8_on`/`_utf8_off` statt den Input/Output tats?chlich zu de-/enkodieren. ? Aus `utf8` nur `upgrade`/`downgrade` verwenden, und dann auch nur falls man mit kaputten XS-Modulen zu tun hat und die Daten in Latin-1 passen. ? Sonst IMMER `decode`/`encode` aus Encode nehmen. ? Das Encoding immer ?UTF-8? schreiben, nicht ?utf8?; letzteres pr?ft nur minimalst auf G?ltigkeit. (Das kann bis hin zu Sicherheitsl?cken f?hren, weil das Programm dann evlt. dazu zu bringen ist, Output zu erzeugen, der von andere Programmen falsch interpretiert wird.) ? perlunitut und perlunifaq lesen. * Josef [2009-09-21 17:45]: > 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. > > ?lterer xs-Code ist oft nicht utf8-aware. Stimme zu. Gru?, -- Aristoteles Pagaltzis // From prozessor13 at gmx.net Mon Sep 21 10:25:21 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 19:25:21 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <4AB79EB4.1050209@stud4.tuwien.ac.at> References: <95C8DDE3-ACBC-4FF1-B82A-F67824572697@gmx.net> <4AB69ED6.3080807@stud4.tuwien.ac.at> <200909211048.34741.nine@detonation.org> <12F1E1D8-8118-477A-A881-D62A24B267DC@gmx.net> <3E58360C-1A2B-4C45-98F6-2CC441682C67@gmx.net> <1253532558.8674.5.camel@tara.firmix.at> <86E27EF3-C66B-458C-A89F-484423EC1A75@gmx.net> <4AB780D8.6080109@stud4.tuwien.ac.at> <17999915-4E73-4524-A8FF-5351237CC7FB@gmx.net> <4AB79EB4.1050209@stud4.tuwien.ac.at> Message-ID: <5E4D115A-BBFD-42B8-9C26-F7B2B7E2D2B4@gmx.net> >>> 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. From prozessor13 at gmx.net Mon Sep 21 10:37:04 2009 From: prozessor13 at gmx.net (max) Date: Mon, 21 Sep 2009 19:37:04 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <20090921163756.GA11296@klangraum.plasmasturm.org> References: <20090921163756.GA11296@klangraum.plasmasturm.org> Message-ID: <082D038A-D66A-4BA9-81CE-340D27F77CEF@gmx.net> > Du fummelst mit der internen Repr?sentation von Strings herum. > Das willst du in 99.9999% der F?lle *nicht* machen. :) nein will ich nicht, werd jetzt alle meine _utf8_on/off sachen aus dem code raushaun > Das willst du nicht. ??? kann abh?ngig vom Flag wahlweise als > Byte DF oder als Bytefolge C3 9F dargestellt und BEDEUTET > DASSELBE in beiden F?llen. Du willst die Zeichenkette encoden, > nicht einfach an irgendwelchen Perl-Eingeweiden herumfummeln, > soda? aus einem ??? immer dasselbe Ergebnis wird, nicht mal so > und mal so. yep, will ich! >> es kommen immer utf8-strings daher, darum auch diese annahme >> (was jetzt programmiertechnisch sicher nicht 1A ist ;) > > Gew?hn dir das ab. Denk nicht ?ber das UTF-8-Flag nach. > >> ja und nein, denn in perl5.8.9 funktioniert es ja. das ist ja >> das komische! > > Das ist Programming by Coincidence. Wenn du es falsch machst, und > es funktioniert zuf?lligerweise trotzdem, hei?t das nicht, da? du > es richtig gemacht hast. ich will nochmal betonen, dass ich "nur" einen folgefehler gemacht hab. wenn das modul gleich richtig hinhaut, dann komm ich nicht in die versuchung so zu tricksen... und dafuer hab ich jetzt ja euch gefragt, gelernt und alles richtig gemacht. > Hier ist das Gegenbeweis-Skript: > > use strict; > use utf8; > use Data::Dumper; > use Encode; > binmode STDOUT, ':encoding(UTF-8)'; > > sub x { > my %hash = map { > my $k = $_; > encode('UTF-8', $k) => 'bytes'; > } @_; > foreach (keys %hash) { > my $k = $_; > $hash{decode('UTF-8', $k)} = 'utf8'; > } > return \%hash; > } genau dieses hat mir der Wolfgang Laun auch schon gesagt, und seit nachmittag funkt endlich alles. aber auch nochmal danke! > Ein paar Punkte zum Mitschreiben: > > ? Niemals den `:utf8` binmode verwenden, denn der macht effektiv > nur `_utf8_on`/`_utf8_off` statt den Input/Output tats?chlich > zu de-/enkodieren. > > ? Aus `utf8` nur `upgrade`/`downgrade` verwenden, und dann auch > nur falls man mit kaputten XS-Modulen zu tun hat und die Daten > in Latin-1 passen. > > ? Sonst IMMER `decode`/`encode` aus Encode nehmen. > > ? Das Encoding immer ?UTF-8? schreiben, nicht ?utf8?; letzteres > pr?ft nur minimalst auf G?ltigkeit. (Das kann bis hin zu > Sicherheitsl?cken f?hren, weil das Programm dann evlt. dazu zu > bringen ist, Output zu erzeugen, der von andere Programmen > falsch interpretiert wird.) > > ? perlunitut und perlunifaq lesen. NOTIERT! unicode ist echt kein leichtes thema.. nicht nur in perl, sondern ueberall. ich hab ja seinerzeit gehofft (vor 10 jahren), dass mit dem endgueltigen durchbruch vom internet nur noch A-Za-z0-9 und ein paar sonderzeichen ueberleben. naja... thx. u. auf bald. max. From pagaltzis at gmx.de Mon Sep 21 14:01:50 2009 From: pagaltzis at gmx.de (Aristoteles Pagaltzis) Date: Mon, 21 Sep 2009 23:01:50 +0200 Subject: [Vienna-pm] utf8 string als hash-key In-Reply-To: <082D038A-D66A-4BA9-81CE-340D27F77CEF@gmx.net> References: <20090921163756.GA11296@klangraum.plasmasturm.org> <082D038A-D66A-4BA9-81CE-340D27F77CEF@gmx.net> Message-ID: <20090921210150.GA15004@klangraum.plasmasturm.org> * max [2009-09-21 19:40]: > >>ja und nein, denn in perl5.8.9 funktioniert es ja. das ist ja > >>das komische! > > > >Das ist Programming by Coincidence. Wenn du es falsch machst, > >und es funktioniert zuf?lligerweise trotzdem, hei?t das nicht, > >da? du es richtig gemacht hast. > > ich will nochmal betonen, dass ich "nur" einen folgefehler > gemacht hab. wenn das modul gleich richtig hinhaut, dann komm > ich nicht in die versuchung so zu tricksen... > und dafuer hab ich jetzt ja euch gefragt, gelernt und alles > richtig gemacht. Ist auch OK. :-) Ich meinte das nicht als Kritik, sondern als Erkl?rung/Aufkl?rung. > unicode ist echt kein leichtes thema.. nicht nur in perl, > sondern ueberall. Stimme v?llig zu. Ich musste erst auf eine YAPC gehen wo ich mal ein netto wohl so zweist?ndiges Gespr?ch zu dem Thema mit Juerd gef?hrt habe, bevor ich wirklich begriffen haben, wie in Perl der Hase l?uft? > ich hab ja seinerzeit gehofft (vor 10 jahren), dass mit dem > endgueltigen durchbruch vom internet nur noch A-Za-z0-9 und ein > paar sonderzeichen ueberleben. naja... *g* Gru?, -- Aristoteles Pagaltzis //