Matthias Scharwies: Wiki: Perl-Bereich depubliziert

747

Wiki: Perl-Bereich depubliziert

  1. 0
  2. 0
    1. 1
      1. 0
        1. 1
    2. 0
      1. 0
        1. 2
          1. 0
          2. 0
  3. 0
  4. 0

    Wiki: Fehler auf der Regex-Seite

    1. 2
      1. 0
        1. 1
          1. -3
            1. -1

              Beitragsbewertung

            2. 2
              1. -1
                1. 2
                  1. 0
                    1. 0
                      1. 0
                        1. 0
                          1. 0
                            1. 1
                              1. 0
                            2. 1
                              1. 0
                                1. 0
                              2. 0
                  2. 0
                    1. -1
            3. 0
              1. 0
                1. 0
                  1. 0
          2. -2
        2. 2
          1. 0
    2. 0
      1. 0
        1. 0
          1. 0
            1. 3
  5. 1

    Perl und Unicode

problematische Seite

Servus!

wie hier und hier schon angeklungen, haben wir den Perl-Bereich im Wiki depubliziert.

Die Inhalte sind auf webarchive.org (und in den Versionsgeschichten der Wiki-Seiten) einsehbar.

Noch vorhanden ist:

Das sollte in den Glossar-Eintrag Regulärer Ausdruck integriert werden.

Auch wenn ich die Depublizierung rational nachvollziehen kann, brennt doch meine Seele. Das wir hier in einem Nicht-Kernthema nicht weiterarbeiten, heißt ja nicht zwangsläufig, dass in unseren Kernthemen mehr passiert. Eigentlich wäre es Zeit für einen Wiki-Push, unsere Baustellen abzuarbeiten.

Herzliche Grüße

Matthias Scharwies

-- Es gibt viel zu tun: ToDo-Liste

Folgende Nachrichten verweisen auf diesen Beitrag:

  1. problematische Seite

    Hallo Matthias Scharwies,

    brennt doch meine Seele.

    Teufel noch eins.

    Bis demnächst
    Matthias

    -- Rosen sind rot.
  2. problematische Seite

    Hallo Matthias,

    Noch vorhanden ist:

    Das sollte in den Glossar-Eintrag Regulärer Ausdruck integriert werden.

    Falls du reguläre Ausdrücke im Perl-Stil in dem Umfang erklären willst, in dem das bisher passiert, würde das den Umfang eines Glossar-Artikels sprengen. Außerdem müsste die Anleitung „Entperlt“ werden (allgemein ist es schlecht, eine solche Technik von einer Programmiersprache abhängig zu erklären), hier kann vielleicht auf Dienste wie Regex101 oder ein JavaScript in Frickl zurückgegriffen werden (benutzt JavaScript eigentlich die gleiche Regex-Syntax wie Perl?).

    Gruß
    Julius

    -- Verallgemeinerungen sind immer schlecht!
    1. problematische Seite

      Servus!

      Hallo Matthias,

      Noch vorhanden ist:

      Das sollte in den Glossar-Eintrag Regulärer Ausdruck integriert werden.

      Falls du reguläre Ausdrücke im Perl-Stil in dem Umfang erklären willst, in dem das bisher passiert, würde das den Umfang eines Glossar-Artikels sprengen.

      Ja, im HTTP-Bereich haben wir Glossar, Referenz und normalen Artikel einfach unter HTTP zusammengefasst.

      Das stell' ich mir hier auch so vor. Regulärer Ausdruck als kurzen Glossar-Eintrag und die Zeichenklassen und Listen als Unterseiten. Wir verlinken im Augenblick extern, dass können wir auch intern.

      Außerdem müsste die Anleitung „Entperlt“ werden (allgemein ist es schlecht, eine solche Technik von einer Programmiersprache abhängig zu erklären),

      Deshalb hab' ich auch ein ToDo reingesetzt, anstatt es selbst zu machen.

      (benutzt JavaScript eigentlich die gleiche Regex-Syntax wie Perl?).

      Ja, deshalb ist es imho unbedingt erhaltenswert.

      Herzliche Grüße

      Matthias Scharwies

      -- Es gibt viel zu tun: ToDo-Liste
      1. problematische Seite

        Hallo Matthias,

        Außerdem müsste die Anleitung „Entperlt“ werden (allgemein ist es schlecht, eine solche Technik von einer Programmiersprache abhängig zu erklären),

        Deshalb hab' ich auch ein ToDo reingesetzt, anstatt es selbst zu machen.

        Ist dieses angefangene Tutorial im Benutzernamensraum vielleicht auch noch relevant (ist mir zufällig über den Weg gelaufen)? Dessen Qualität kann ich nicht einschätzen, weil ich von Regex keine Ahnung habe...

        Gruß
        Julius

        1. problematische Seite

          Tach!

          Ist dieses angefangene Tutorial im Benutzernamensraum vielleicht auch noch relevant (ist mir zufällig über den Weg gelaufen)? Dessen Qualität kann ich nicht einschätzen, weil ich von Regex keine Ahnung habe...

          Lies es einmal und beurteile dann, ob du nun wenigstens etwas Ahnung bekommen hast.

          Für mich - ich bilde mir ein, das Wesen von RegExp verstanden zu haben - ist schon in der Einleitung eine Menge Geschwafel drin. "Bisher" ist das erste Wort, und es wäre richtig, wenn wir uns gerade in den 90ern befänden. Und Sätze à la "ist einfacher als es aussieht" helfen niemandem in fachlicher Hinsicht weiter. Pädagogisch vielleicht, aber das müssten unsere Lehrer besser wissen.

          Ich bin bis zum Beispiel mit der Mutter gekommen. Ein gober Schnitzer ist, die Ziffern 123456 als Zahl zu interpretieren. Das Suchmuster ist eine Zeichenkette. Nichts darin wird als Zahl interpretiert, solange wir nicht einen Quantifier wie {2,5} notieren. Die Ziffern werden genauso als Zeichen interpretiert wie Buchstaben und andere Zeichen, mit Ausnahme der syntaktisch relevanten Zeichen.

          Auch wenn ich es nicht bis zum Ende gelesen habe, der Rotstift hat da sicher einiges zu tun.

          dedlfix.

    2. problematische Seite

      Lieber Julius,

      Außerdem müsste die Anleitung „Entperlt“ werden [...] hier kann vielleicht auf Dienste wie Regex101 oder ein JavaScript in Frickl zurückgegriffen werden

      mein Tipp: www.regular-expressions.info.

      (benutzt JavaScript eigentlich die gleiche Regex-Syntax wie Perl?).

      Nicht ganz, aber ziemlich.

      Liebe Grüße,

      Felix Riesterer.

      1. problematische Seite

        Hallo Felix,

        (benutzt JavaScript eigentlich die gleiche Regex-Syntax wie Perl?).

        Nicht ganz, aber ziemlich.

        Dann wäre ein Blick auf die Unterschiede zwischen JS-Regex und PCRE sehr interessant. Was ist eigentlich mit dem pattern-Attribut in HTML5, verwendet das dann die gleiche Syntax wie die JavaScript-Regexe?

        Gruß
        Julius

        -- Verallgemeinerungen sind immer schlecht!
        1. problematische Seite

          Servus!

          Hallo Felix,

          (benutzt JavaScript eigentlich die gleiche Regex-Syntax wie Perl?).

          Nicht ganz, aber ziemlich.

          Dann wäre ein Blick auf die Unterschiede zwischen JS-Regex und PCRE sehr interessant. Was ist eigentlich mit dem pattern-Attribut in HTML5, verwendet das dann die gleiche Syntax wie die JavaScript-Regexe?

          Zitat aus JavaSCript: The Definite guide:

          JavaScript regular expressions are strongly based on the regular expression facilities of the Perl programming language. Roughly speaking, we can say that JavaScript 1.2 implements Perl 4 regular expressions, and JavaScript 1.5 implements a large subset of Perl 5 regular expressions.

          Da die Artikel ja auf dem Stand von Perl 4 steckengeblieben sind, sollte das wohl kein größeres Problem darstellen. (Oder hab ich mich jetzt total blamiert?)

          Herzliche Grüße

          Matthias Scharwies

          -- Es gibt viel zu tun: ToDo-Liste
          1. problematische Seite

            Aloha ;)

            Da die Artikel ja auf dem Stand von Perl 4 steckengeblieben sind, sollte das wohl kein größeres Problem darstellen. (Oder hab ich mich jetzt total blamiert?)

            Nein, ich denke du hast da schon den richtigen Riecher.

            Grüße,

            RIDER

            -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

            # Twitter # Steam # YouTube # Self-Wiki #

            Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          2. problematische Seite

            Hallo Matthias,

            Dann wäre ein Blick auf die Unterschiede zwischen JS-Regex und PCRE sehr interessant. Was ist eigentlich mit dem pattern-Attribut in HTML5, verwendet das dann die gleiche Syntax wie die JavaScript-Regexe?

            Zitat aus JavaSCript: The Definite guide:

            JavaScript regular expressions are strongly based on the regular expression facilities of the Perl programming language. Roughly speaking, we can say that JavaScript 1.2 implements Perl 4 regular expressions, and JavaScript 1.5 implements a large subset of Perl 5 regular expressions.

            Und im Falle des pattern-Attributs verweist man auf JavaScript.

            Gruß
            Julius

            -- Verallgemeinerungen sind immer schlecht!
  3. problematische Seite

    Hallo Matthias Scharwies,

    haben wir den Perl-Bereich im Wiki depubliziert.

    Dankeschön.

    Ich habe dann auch alle innerwiki-Links auf Perl-Seiten entfernt sowie die Unterseiten vor Bearbeitung geschützt.

    Bis demnächst
    Matthias

    -- Rosen sind rot.
  4. problematische Seite

    Das Beispiel beginnt nach dem üblichen Einbinden von strict und warnings mit dem Laden des utf8-Moduls, das einzig dem Zweck dient, Perl mitzuteilen, dass der Sourcecode in utf-8 geschrieben ist.

    Das ist nicht richtig. utf8 ist ein Pragma was bewirkt, dass der Interpreter die im Script notierten Literale als "utf-8-kodierte Zeichenketten" betrachtet und nicht als Bytesequenzen.

    Die folgende Zeile binmode STDOUT, ":utf8" sorgt dafür, dass auch die Ausgabe in utf-8 erfolgt. Ohne diese Zeile könnten Umlaute als Fragezeichen oder ähnliches ausgegeben werden.

    Auch falsch. Diese Zeile sorgt dafür, dass eben keine utf-8-kodierte Zeichenketten nach STDOUT geschickt werden sondern Bytesequenzen.

    Siehe auch:

    use utf8; print 'Ä' =~ /ä/i;

    ==> das Match ergibt sich nur, wenn pragma utf8 gesetzt ist. D.h., der Modifier /i tut nur dann erwartungsgemäß, wenn er zeichnorientiert arbeitet.

    MfG

    1. problematische Seite

      Tach!

      Das Beispiel beginnt nach dem üblichen Einbinden von strict und warnings mit dem Laden des utf8-Moduls, das einzig dem Zweck dient, Perl mitzuteilen, dass der Sourcecode in utf-8 geschrieben ist.

      Das ist nicht richtig. utf8 ist ein Pragma was bewirkt, dass der Interpreter die im Script notierten Literale als "utf-8-kodierte Zeichenketten" betrachtet und nicht als Bytesequenzen.

      "The use utf8 pragma tells the Perl parser to allow UTF-8 in the program text in the current lexical scope. The no utf8 pragma tells Perl to switch back to treating the source text as literal bytes in the current lexical scope. [...] Do not use this pragma for anything else than telling Perl that your script is written in UTF-8." sagt Perldoc. Und weiterhin:

      "Bytes in the source text that are not in the ASCII character set will be treated as being part of a literal UTF-8 sequence. This includes most literals such as identifier names, string constants, and constant regular expression patterns."

      Ich kann nicht erkennen, warum der oben zitierte Satz nicht richtig sein soll - größtenteils jedenfalls. Geht es lediglich darum, dass das Wort Modul falsch ist? Ist er mit dem Ändern in die Formulierung "mit dem Setzen des utf8-Pragmas" korrekter?

      Die folgende Zeile binmode STDOUT, ":utf8" sorgt dafür, dass auch die Ausgabe in utf-8 erfolgt. Ohne diese Zeile könnten Umlaute als Fragezeichen oder ähnliches ausgegeben werden.

      Auch falsch. Diese Zeile sorgt dafür, dass eben keine utf-8-kodierte Zeichenketten nach STDOUT geschickt werden sondern Bytesequenzen.

      Verstehe ich nicht den Einwurf.

      "To output UTF-8, use the :encoding or :utf8 output layer. Prepending binmode(STDOUT, ":utf8"); to this sample program ensures that the output is completely UTF-8, and removes the program's warning." sagt Perldoc.

      Was wird denn für ein "häh?" ausgegeben, wenn nicht 68 c3 a4 68 3f? Verstehst du unter "utf-8-kodierte Zeichenketten" etwas anderes als die gemäß UTF-8-Kodierungsvorschrift in Bytes umgewandelten Unicode-Codepoints der jeweiligen Zeichen?

      dedlfix.

      1. problematische Seite

        Du brauchst mir die Doku nicht abzutippen, lesen kann ich selber.

        Ist er mit dem Ändern in die Formulierung "mit dem Setzen des utf8-Pragmas" korrekter?

        Nein. use utf8 bewirkt, dass der Interpreter die in der Script-Datei notierten Literale als "utf-8-kodierte Zeichenketten" betrachtet und nicht als Bytesequenzen -- Das ist das Wesentliche und das gibt die Doku nicht her.

        Ansonsten kann man ein Perl-Script in beliebigen Kodierungen abspeichern ohne dieses Pragma setzen zu müssen. use utf8 wird nur gebraucht, wenn mit den im Script notierten Literalen Operationen ausgeführt werden sollen, die zeichenorientiert arbeiten, Stringfunktionen und z.B. auch reg.Expr.

        Verstehst du unter "utf-8-kodierte Zeichenketten" etwas anderes als die gemäß UTF-8-Kodierungsvorschrift in Bytes umgewandelten Unicode-Codepoints der jeweiligen Zeichen?

        Perl unterscheidet seit Version 5 (2001) zwischen UTF-8-kodierten Zeichenketten und Bytesequenzen. Wenn utf-8-kodierte Zeichenketten nach STDOUT ausgegeben werden, quittiert das der Interpreter mit einer Fehlermeldung "wide character in print...". Deswegen muss vor jeder Ausgabe dafür gesorgt werden dass keine utf-8-kodierten Zeichenketten ausgegeben werden sondern Oktetten (Bytesequenzen). Dabei ist die Bekanntmachung der Kodierung direkt am Layer auch nur eine von mehreren Möglichkeiten. Siehe auch Encode.pm

        MfG

        1. problematische Seite

          Tach!

          Du brauchst mir die Doku nicht abzutippen, lesen kann ich selber.

          Ach, wirklich? Ich tippte aber nicht ab, ich zitierte die Stellen, auf die ich mich bezog. Als Alternative hätte ich auch im Stil von Gesetzestexten darauf verweisen können. Paragraph, Absatz, Satz, Nummer. Leider ist die Perl-Dokumentation nicht so aufgebaut und Kopieren war einfacher als den Weg zu beschreiben. Und das ist sicherlich auch für die interessieren Mitlesenden besser.</menschelei>

          Ist er mit dem Ändern in die Formulierung "mit dem Setzen des utf8-Pragmas" korrekter?

          Nein. use utf8 bewirkt, dass der Interpreter die in der Script-Datei notierten Literale als "utf-8-kodierte Zeichenketten" betrachtet und nicht als Bytesequenzen -- Das ist das Wesentliche und das gibt die Doku nicht her.

          Ich hatte auch erst gedacht, dass du mit Literale die String-Literale meinst, aber die Dokumentation sieht das anders und bezeichnet auch die im Code für die Keywords verwendeten Literale als solche.

          Ansonsten kann man ein Perl-Script in beliebigen Kodierungen abspeichern ohne dieses Pragma setzen zu müssen. use utf8 wird nur gebraucht, wenn mit den im Script notierten Literalen Operationen ausgeführt werden sollen, die zeichenorientiert arbeiten, Stringfunktionen und z.B. auch reg.Expr.

          Die Perldoc nimmt den Literalbegriff auch für Bezeichner wie Variablennamen. Die müssen aber selten stringverarbeitet werden, und es reicht, wenn gleich gemeinte Namen auch als gleich erkannt werden. Ob das auf Zeichen- oder Byte-Ebene passiert ist dabei nebensächlich.

          Deine Aussage jedenfalls bezieht sich viel mehr auf die Weiterverarbeitung dessen, was da in den Code-Dateien steht. Ist das denn für die Wiki-Stelle relevant, außer dass die Anweisungen da der Vollständigkeit halber angeführt sind und wenigstens grob deren Bedeutung erklärt wird?

          Deiner Meinung nach schaltet also (entgegen der Perldoc-Aussage) das use utf8 nur die interne Verarbeitung um. Wie bringt man dem Perl nun aber bei, dass es die Quellcode-Datei als UTF-8 interpretieren soll, wenn nicht über das in der Perldoc aufgeführte use utf8. Ist dann nur noch die ebenfalls genannte Möglichkeit der UTF-8-BOM verfügbar? Oder was genau ist der Weg? Formulier doch mal den von dir beanstandeten Satz richtig, aber dem Kontext angemessen. Es soll da ja auch keine Abhandlung über Perls Unicode-Handling stehen.

          Verstehst du unter "utf-8-kodierte Zeichenketten" etwas anderes als die gemäß UTF-8-Kodierungsvorschrift in Bytes umgewandelten Unicode-Codepoints der jeweiligen Zeichen?

          Perl unterscheidet seit Version 5 (2001) zwischen UTF-8-kodierten Zeichenketten und Bytesequenzen. Wenn utf-8-kodierte Zeichenketten nach STDOUT ausgegeben werden, quittiert das der Interpreter mit einer Fehlermeldung "wide character in print...". Deswegen muss vor jeder Ausgabe dafür gesorgt werden dass keine utf-8-kodierten Zeichenketten ausgegeben werden sondern Oktetten (Bytesequenzen).

          Also, ich würde schon sagen, dass UTF-8-kodierte Zeichenketten ausgegeben werden (sollen), denn es muss an einem in UTF-8-kodierten String nichts mehr umkodiert werden, sondern lediglich die bereits vorhandenen Bytes 1:1 ausgegeben werden. Dem Perl muss man mit dieser Anweisung nur sagen, dass es da nichts weiter herumzuinterpretieren hat. Am Ende erreicht man doch aber genau das, was da im Wiki steht/stand, nämlich dass UTF-8 in der Ausgabe landet. Und das halte ich für den dortigen Kontext für ausreichend. Es ist ja kein Artikel über die Interna von Perls Unicode-Handhabung (sagte ich ja schon).

          dedlfix.

          1. problematische Seite

            Du hast überhaupt nichts verstanden. Wie willst Du einen Wiki schreiben über etwas was Du nicht verstehst!?

            Zum Nachvollziehen dessen was ich Dir schrieb:

            use utf8; say "Ä" =~ /ä/i ? "passt" : "passt nicht "; # passt no utf8; say "Ä" =~ /ä/i ? "passt" : "passt nicht "; # passt nicht use utf8; say "€ 2.50"; # wide character in say use bytes; say "€ 2.50";

            Und lies bitte auch die POD zu Encode.pm.

            MfG

            PS: Und lies bitte noch einmal meine bisherigen Posts. Und ja, Theorie und Praxis bilden eine Einheit, sonst wird das nix mit Dir.

            1. problematische Seite

              Es geht um Euren Wiki, ist Euch das eigentlich klar!?

            2. problematische Seite

              Tach!

              Du hast überhaupt nichts verstanden. Wie willst Du einen Wiki schreiben über etwas was Du nicht verstehst!?

              Danke für die Blumen. "Überhaupt nichts verstanden" ist natürlich keine Grundlage für ein weiteres Vorgehen. Ich beende das dann hier, der Artikel soll sowieso auch noch gestrichen/umgearbeitet werden. In ihm geht es sozusagen nur noch um Regex und das Perl ist da nur ein historischer Aspekt.

              dedlfix.

              1. problematische Seite

                Danke für die Blumen. "Überhaupt nichts verstanden" ist natürlich keine Grundlage für ein weiteres Vorgehen.

                Doch ist es. Zumal ich Dir hier mehr als nur einmal und mehr als ausführlich die Zusammenhänge erklärt habe, zeigen Deine Reaktionen ja dass Du es nicht verstanden hast. Von einem Wiki-Author erwartet der Leser jedoch einen kompetenten Fachmann, der auch praktische Erfahrungen hat. Wenn Letzteres bei Euch in Sachen Perl nicht zutrifft, dann solltet Ihr auch die richtigen Konsequenzen ziehen was den Artikel betrifft.

                Es ist Eure Entscheidung was Ihr mit meinen konstruktiven Hinweisen zum Wiki macht, aber Eure Diskussion hier ist der eines kompetenten Fachmannes nicht würdig!

                MfG

                1. problematische Seite

                  Hallo pl,

                  Das ist nun aber wirklich ein *g* zum Wochenende. Es fällt mir schwer, darauf chartagemäß zu antworten. Vielleicht wäre es Verantwortlicher für Wiki und Forum besser, diese Antwort zu unterlassen. Aber ich musste wirklich laut auflachen und dann den Kopf schütteln, wem du hier die totale Inkomptenz unterstellst. Wenn du das mir unterstelltest, lägest du damit um Längen richtiger.

                  Bis demnächst
                  Matthias

                  -- Rosen sind rot.
                  1. problematische Seite

                    @@Matthias Apsel

                    Das ist nun aber wirklich ein *g* zum Wochenende. Es fällt mir schwer, darauf chartagemäß zu antworten.

                    Die Charta muss weg! n00bs lesen sie eh nicht und für unsereiner ist sie ein einziges Hindernis. *duckundweg*

                    LLAP 🖖

                    -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                    1. problematische Seite

                      Hallo Gunnar,

                      …lesen sie eh nicht…

                      das liegt vielleicht auch daran, daß der Hinweis unglücklich plaziert ist, nämlich im Wiki und der Begriff "Charta", so man ihn denn entdeckt hat, nicht unbedingt für alle Besucher sprechend ist.

                      Grüße, Martl

                      1. problematische Seite

                        Hallo Martl,

                        das liegt vielleicht auch daran, daß der Hinweis unglücklich plaziert ist, nämlich im Wiki und der Begriff "Charta", so man ihn denn entdeckt hat, nicht unbedingt für alle Besucher sprechend ist.

                        Allerdings ist ein Link auf die Charta beim Absendebutton platziert.

                        „Formulieren Sie bitte höflich und wertschätzend.“

                        Bis demnächst
                        Matthias

                        -- Rosen sind rot.
                        1. problematische Seite

                          @@Matthias Apsel

                          „Formulieren Sie bitte höflich und wertschätzend.“

                          Der Hinweis ist irreführend. Es muss heißen „Formuliere bitte …“

                          Wenn ein n00b den Hinweis so wie er jetzt ist befolgt, ist das erste, was er als Antwort zu hören bekommt, dass hier im Forum generell geduzt wird. Tolle UX. Nicht.

                          LLAP 🖖

                          -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                          1. problematische Seite

                            Hallo Gunnar Bittersmann,

                            Wenn ein n00b den Hinweis so wie er jetzt ist befolgt, ist das erste, was er als Antwort zu hören bekommt, dass hier im Forum generell geduzt wird. Tolle UX. Nicht.

                            Wir duzen einander, nicht die Software uns.

                            Bis demnächst
                            Matthias

                            -- Rosen sind rot.
                            1. problematische Seite

                              @@Matthias Apsel

                              Wenn ein n00b den Hinweis so wie er jetzt ist befolgt, ist das erste, was er als Antwort zu hören bekommt, dass hier im Forum generell geduzt wird. Tolle UX. Nicht.

                              Wir duzen einander, nicht die Software uns.

                              Abgesehen davon, dass ich diese Unterscheidung unsinnig finde, hilft das dem n00b nicht im Geringsten. Er/sie wird gesiezt und aufgefordert, höflich und wertschätzend zu formulieren. Da drängt sich geradezu die Vermutung auf, er/sie solle im Forum höflich und wertschätzend siezen.

                              LLAP 🖖

                              -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                              1. problematische Seite

                                Hallo Gunnar & Matthias,

                                da ist sie wieder, die berühmte selfDynamic!

                                Vorschlag: Wir treffen uns am Untersberg zu Streit um des Kaisers Bart :)

                                Grüße, Martl

                            2. problematische Seite

                              Aloha ;)

                              Wenn ein n00b den Hinweis so wie er jetzt ist befolgt, ist das erste, was er als Antwort zu hören bekommt, dass hier im Forum generell geduzt wird. Tolle UX. Nicht.

                              Wir duzen einander, nicht die Software uns.

                              Ich hätte allerdings auch kein Problem damit, von der Software geduzt zu werden. Immerhin ist sie die einzige, die auch wirklich alle meine Postings gelesen hat und auch immer als einzige alles versteht was ich meine!!!1!!

                              Nein, Scherz beiseite. Ich verstehe was du meinst - will aber ausdrücklich dazusagen, dass ich es bei Ikea auch voll okay finde, von den Plakaten an der Wand geduzt zu werden. Ich finde das eher positiv als negativ.

                              Grüße,

                              RIDER

                              -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

                              # Twitter # Steam # YouTube # Self-Wiki #

                              Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                              1. problematische Seite

                                Hallo,

                                Ich hätte allerdings auch kein Problem damit, von der Software geduzt zu werden.

                                Ist es denn überhaupt so, dass man sich „von der Software angeredet“ fühlt? Ich denke, es wird klar, dass das von einem Verantwortlichen stammt. Und wenn hier generell geduzt wird, dann doch auch in diesem Fall…

                                Gruß
                                Kalk

                                1. problematische Seite

                                  Hi,

                                  Ich hätte allerdings auch kein Problem damit, von der Software geduzt zu werden.

                                  Ist es denn überhaupt so, dass man sich „von der Software angeredet“ fühlt? Ich denke, es wird klar, dass das von einem Verantwortlichen stammt. Und wenn hier generell geduzt wird, dann doch auch in diesem Fall…

                                  "Sind Sie sicher?" geht ja in die gleiche Richtung. Ich find's auch eher ungewöhnlich, daß hier überall geduzt wird, aber an diesen Stellen nicht.

                                  cu,
                                  Andreas a/k/a MudGuard

                              2. problematische Seite

                                Ich hätte allerdings auch kein Problem damit, von der Software geduzt zu werden.

                                Mein iPhone duzt mich auch ungefragt, finde ich absolut ok. Bin da bei Gunnar, hier im Forum wäre das aus konsitenzgründen schon angebracht.

                  2. problematische Seite

                    Tach!

                    Das ist nun aber wirklich ein *g* zum Wochenende. Es fällt mir schwer darauf, chartagemäß zu antworten.

                    Mein Anliegen hier war eigentlich nur, mit einer kleine Korrektur die als falsch deklarierten Sätze zu berichtigen. Das Vorhaben ist misslungen. Entweder hat Perl da eine viel zu komplexe Herangehensweise an das Thema und man kann das nicht abhaken mit einem "Für UTF-8-Handling schreib mal die drei Anweisungen hin", mit einem impliziten: "Alles andere ist grad nicht Thema dieser Regexp-Seite und muss anderswo geklärt werden." Oder aber die Erklärungsversuche sind schlecht nachvollziehbar. Da ich aber attestierterweise immer noch am Nullpunkt bin und es nichts bringt, ein obszoleszentes Thema mit einem derartigen Aufwand zu klären, lass ich das wie es ist und schau mal lieber, wie man die Seite auf Javascript umschreiben kann. Aber vorerst hab ich noch was anderes zu tun.

                    dedlfix.

                    1. problematische Seite

                      Entweder hat Perl da eine viel zu komplexe Herangehensweise an das Thema

                      Nein. Das kann man alles lernen und Du kannst das auch. Gerne noch einmal:

                      binmode STDOUT, ":utf8"; schaltet die Kodierung nicht ein sondern aus.

                      Oder aber die Erklärungsversuche sind schlecht nachvollziehbar.

                      Das auch nicht, ganz im Gegenteil: Meine Code-Beispiele kannst auch Du kopieren und ausführen, somit also nachvollziehbar. Die untrennbare Einheit von Theorie und Praxis halt und das ist auch keine Erfindung von mir. Nur, man muss es halt mal machen und sich selbst bemühen!

                      MfG

            3. problematische Seite

              Hallo pl,

              Du hast überhaupt nichts verstanden. Wie willst Du einen Wiki schreiben über etwas was Du nicht verstehst!?

              PS: Und lies bitte noch einmal meine bisherigen Posts. Und ja, Theorie und Praxis bilden eine Einheit, sonst wird das nix mit Dir.

              Könnte es auch sein, dass die Theorie nicht zu deiner Praxis passt? Mit dedlfix habe ich jedenfalls schon praktisch zusammengearbeitet. Ich weiß, dass er ordentliche Produkte liefert. Von dir weiß ich das nicht. Und obwohl ich mir oft wirklich Mühe gebe, deine Beiträge und die Artikel auf deiner Seite zu verstehen, gelingt mir das häufig nicht. Und Antworten auf Nachfragen blieben oft aus oder beschäftigten sich mit etwas ganz anderem.

              Ich wollte dir schon beinahe dein eigenes Tag spendieren, aber ich denke, dass das einem Mobbing gleichkäme.

              Bis demnächst
              Matthias

              -- Rosen sind rot.

              Folgende Nachrichten verweisen auf diesen Beitrag:

              1. problematische Seite

                Könnte es auch sein, dass die Theorie nicht zu deiner Praxis passt?

                Nein. Die von mir gezeigten Code-Beispiele sind aus einer Praxis die sehr wohl zur Theorie passt. Beim Ausführen der Codebeispiele zeigt sich doch, dass die von mir vermittelte Theorie richtig ist.

                Und gerne noch einmal: Euer Wiki möchte die theoretischen Grundlagen vermitteln, das ist Euer Anspruch und absolut legitim. Die Praxis hingegen muss sich jeder selbst erarbeiten und spätestens da zeigt sich, ob die Theorie richtig ist. Die Aussage dass binmode STDOUT, ":utf8"; notwendig ist UTF-8-kodierte Zeichen auszugeben ist in mehrfacher Hinsicht falsch, weil:

                1. Handle wie STDOUT bzw. Bytesequenzen gar keine Kodierung kennen,
                2. der Layer damit die Kodierung ab- und nicht einschaltet,
                3. andernfalls praktisch die Ausgabe zwar korrekt aber mit einer Fehlermeldung "wide character in print ..." verbunden ist.

                Deswegen passt die Theorie in Eurem Wiki nicht zur Praxis.

                MfG

                1. problematische Seite

                  Aloha ;)

                  Und gerne noch einmal: Euer Wiki möchte die theoretischen Grundlagen vermitteln, das ist Euer Anspruch und absolut legitim.

                  Nein, da musst du was echt falsch verstanden haben. Genau genommen will unser Wiki zu Perl gar nichts mehr vermitteln.

                  Und wenn ich mir die Diskussion hier ansehe ist das vielleicht auch wirklich gut so.

                  Grüße,

                  RIDER

                  -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

                  # Twitter # Steam # YouTube # Self-Wiki #

                  Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                  1. problematische Seite

                    @@Camping_RIDER

                    Nein, da musst du was echt falsch verstanden haben. Genau genommen will unser Wiki zu Perl gar nichts mehr vermitteln.

                    Was gäbe es zu Perl auch zu sagen außer dass es da ein Framework gibt, dass einfach alles kann?

                    LLAP 🖖

                    -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
          2. problematische Seite

            Am Ende erreicht man doch aber genau das, was da im Wiki steht/stand, nämlich dass UTF-8 in der Ausgabe landet.

            Der Ausgabekanal ist ein Handle, STDOUT. Da gibt es keine Kodierung sondern nur Bytesequenzen. Genauso wie es in Dateien und Dateihandles nur Bytesequenzen gibt. Bytesequenzen kennen keine Kodierung aber Perl kann mit Kodierungen umgehen. Deswegen muss vor der Ausgabe in ein Handle die Kodierung ausgeschaltet werden. Erst ein Gerät, was Bytesequenzen lesbar darstellen soll (Konsole, Browser, Texteditor...) muss die Kodierung wieder kennen.

            Perl lädt im Hintergrund die Moduldatei bytes.pm und arbeitet per Default bytesemantisch. So kann man die Bytesemantic mit use bytes und no bytes explizit ein- und wieder ausschalten. Diesen Zusammenhang zu kennen ist wichtig, wenn Operationen mit Zeichenketten vorliegen, also sämtliche Stringoperationen und auch die Anwendung regulärer Ausdrücke.

            use utf8; binmode STDOUT, ":utf8"; print "€€€";

            ist unsinnig, weil es unnötig ist die interne Kodierung ein- und wieder auszuschalten wenn das Literal nur ausgegeben werden soll. Außerdem hat use utf8 überhaupt keine Auswirkung auf Bytesequenzen, die NICHT als Literal im Script selbst notiert sind sondern beispielsweise von STDIN oder Sockets oder anderen Handles oder auch über die CGI-Schnittstelle (Serverumgebung) gelesen werden, dafür gibt es Encode.

            MfG

        2. problematische Seite

          Hallo pl,

          Du brauchst mir die Doku nicht abzutippen, lesen kann ich selber.

          Dann tu das auch!

          Ist er mit dem Ändern in die Formulierung "mit dem Setzen des utf8-Pragmas" korrekter?

          Nein. use utf8 bewirkt, dass der Interpreter die in der Script-Datei notierten Literale als "utf-8-kodierte Zeichenketten" betrachtet und nicht als Bytesequenzen -- Das ist das Wesentliche und das gibt die Doku nicht her.

          Das ist Unsinn. Das ut8-Pragma bewirkt, dass der gesamte Quelltext als UTF-8 interpretiert wird. Kleines Beispiel gefällig?

          #!/usr/bin/perl -w use strict; my $äöü = 1; print $äöü, "\n";

          Dieses Programm sagt bei der Ausführung:

          Can't use global $� in "my" at test.pl line 6, near "my $�" Unrecognized character \xA4; marked by <-- HERE after my $�<-- HERE near column 6 at test.pl line 6.

          Dagegen dieses Programm:

          #!/usr/bin/perl -w use strict; use utf8; my $äöü = 1; print $äöü, "\n";

          gibt erfolgreich 1 aus. Was du vermutlich meinst ist use feature "unicode_strings", dass dem Compiler sagt, es soll Unicode-Regeln auf alle Strings und Regexe im aktuellen Scope anwenden. Das Gegenstück dazu ist dann use bytes (von dessen Verwendung abgeraten wird).

          Auch das Beispiel aus deinem vorherigen Code ist falsch, es ist durchaus möglich ohne use utf8 zu matchen:

          use strict; print 'Ä' =~ /ä/ui;

          gibt erwartungsgemäß 1 aus. Und nein, use utf8 ist nicht das gleiche wie /u.

          Ansonsten kann man ein Perl-Script in beliebigen Kodierungen abspeichern ohne dieses Pragma setzen zu müssen.

          Gnhahahahaha. Dann erkläre mir bitte, wie du dieses Programm ausführen willst:

          #!/usr/bin/perl -w use strict; my $äöü = 1; print $äöü, "\n";

          Und -C-Flags zählen nicht!

          Für den Rest bin ich jetzt zu müde.

          LG,
          CK

          -- https://wwwtech.de/about
          1. problematische Seite

            Ja, wenn Du unbedingt UTF-8-Zeichen in der Symboltabelle haben willst, dann kannst Du das selbstverständlich so machen. Ansonsten:

            print "1.50 €€€";

            braucht kein use utf8; Literale konntest Du schon immer in beliebigen Kodierungen speichern, also die gesamte Script-Datei. Im Übrigen funktionieren Umlaute in Variablennamen nur mit Utf-8-Kodierung. Ab Version 5.8 jedoch kann Perl mit beliebigen Kodierungen umgehen, seit Encode im Core ist, wird sogar empfohlen auf das Pragma utf8 zu verzichten.

            Und wie ich bereits gestern schrieb, gibt es mehrere Möglichkeiten zum richtigen Umgang mit UTF-8 und anderen Zeichenkodierungen. Welche der Möglichkeiten zum Einsatz kommt, ist stets eine praktische Frage und weniger eine Frage der Willkür -- Insbesondere in Teamarbeit. MfG

    2. problematische Seite

      Hallo pl,

      Das ist irgendwie im falschen Thread gelandet.

      Bis demnächst
      Matthias

      -- Rosen sind rot.
      1. problematische Seite

        Tach!

        Hallo pl,

        Das ist irgendwie im falschen Thread gelandet.

        Es bezieht sich auf die verlinkte noch erhalten gebliebene Regexp-Seite. Ich habe mir erlaubt, den Zweig wieder zu öffnen, aber den Betreff zu ändern. Bei Bedarf kann man den Teil ja auch abtrennen.

        dedlfix.

        1. problematische Seite

          Hallo dedlfix,

          Es bezieht sich auf die verlinkte noch erhalten gebliebene Regexp-Seite.

          Ah.

          Ich hab dann mal die problematischen Seiten korrigiert.

          Bis demnächst
          Matthias

          -- Rosen sind rot.
          1. problematische Seite

            Freu Dich doch einfach, wenn Du ein Feedback bekommst! Über ein Dankeschön würde ich mich auch freuen. MfG

            1. problematische Seite

              Hallo pl,

              Freu Dich doch einfach, wenn Du ein Feedback bekommst!

              Ja, da hast du recht. Ich dachte jedoch, dass sich dein Beitrag auf die Geschichte mit dem Kontaktformular von der IP da halt bezieht. Da passt es inhaltlich hin und deine zitierten Stellen sind im Vorposting nicht auffindbar.

              Über ein Dankeschön würde ich mich auch freuen. MfG

              Jederzeit, wenn du doch endlich mal etwas konstruktives zum Wiki beitragen würdest. Stattdessen bindest du hier Zeit von Leuten, die sich wirklich auskennen, die deine manchmal wirren Vorstellungen korrigieren müssen und jedesmal, wenn du nicht weiterweist, kommst du mit deinem Totschlagargument „Ich habe die Praxiserfahrung, du nicht“. Dass aber drei der Leute, deren Zeit du bindest, sehr erfolgreich in diesem Bereich unterwegs sind, scheinst du nicht wahrhaben zu wollen.

              Bis demnächst
              Matthias

              -- Rosen sind rot.

              Folgende Nachrichten verweisen auf diesen Beitrag:

  5. problematische Seite

    Die Geschichte von SELFHTML ist auch meine Geschichte. Deswegen hier der Link zu einem neuen Artikel Perl und Unicode zum besseren Verständnis.

    Schönen Sonntag!