XML::Simple

[RichardCZ]

https://metacpan.org/pod/distribution/XML-Simple/lib/XML/Simple/FAQ.pod#Basics

What should I use XML::Simple for?

Nothing!

It's as simple as that.

$ grep -r XML::Simple FHEM | wc -l
45



Dank FHEM bin ich für 20% des Umsatzes der Papiertaschentuch-Industrie verantwortlich.
Will jemand wissen wie man XML::Simple in senem Code ersetzt oder ist das wurst?

[herrmannj]

a) guter Beitrag, hoffe auf Anfragen der "Betroffenen"
b) jetzt weiß ich endlich warum es kein Klopapier mehr gibt. Das ist nicht die Apokalypse - die Papierindustrie hat sich auf Dich und Deine Taschentücher eingestellt 

[CoolTux]

Ich bin leider betroffen. Auch wenn ich UWZ nur geerbt habe.

Bin also interessiert.

[RichardCZ]

Also prinzipiell ist es natürlich so, dass der Autor von der Verwendung dieses Moduls in neuem Code dringend abrät.

https://metacpan.org/pod/XML::Simple#STATUS-OF-THIS-MODULE

The use of this module in new code is strongly discouraged.

Nun ist natürlich klar, dass wir es mit Legacy code zu tun haben, aber hey - wenn der weiter (und lange) leben soll, und ggf. schneller, besser zukunftsträchtiger werden soll... Auf der anderen Seite ... hier ist ein dokumentierter Migrationspfad aus dem Jahr 2005 https://www.perlmonks.org/?node_id=490846 - also dem Geburtsjahr von FHEM. Also hätte Fahradkette man die Designentscheidung auch damals... Egal.

XML::Simple war mal als einfaches Frontend zu anderen XML Parsern gedacht, es läuft also auch heute nicht ohne ein entsprechendes Backend. Vermutlich (= bin mir nicht 100% sicher), verwenden 90% der User ohnehin libxml als Backend.

libxml2 ist auch standardmäßig auf dem RasPi verfügbar auf den x86/amd64 distris ohnehin, da sollte es also keine Probleme geben.

Der XML::Simle Autor empfiehlt denn auch XML::LibXML (und das macht so auch ziemlich jeder andere)
auch mit dem Verweis auf ein "XML::LibXML by example": http://grantm.github.io/perl-libxml-by-example/

Der gute alte Michael Schilli hat ebenfalls 2005 einen XML-Parser "Vergleichsartikel" geschrieben
https://www.linux-magazin.de/ausgaben/2005/08/datenfischer/ und empfiehlt dort XML::Simple als "einfachste Lösung".
kann sein, dass man sich das 2005 zu Herzen genommen hat. 
Der Artikel ist aber auch als Migrationspfad gut, weil dort - auf Deutsch - auch LibXML Beispiele benannt werden.

Da die TL;DR Fraktion ohnehin schon ausgestiegen ist, verweise ich hiermit für die Verbliebenen auf

https://metacpan.org/pod/XML::LibXML::Simple

Von Mark Overmeer - neueste Version jetzt März 2020

Man beachte aber https://metacpan.org/pod/XML::LibXML::Simple#Differences-to-XML::Simple
-> nur XMLin wird unterstützt.



Und damit kommen wir fliessend zum nächsten Mysterium der FHEM Codebasis:

Wir haben zwar 45 x use XML::Simple
aber nur 27 x XMLin
und nur 4 x XMLout

Das ist ein Fall für Akte-X.

[rudolfkoenig]

auch mit dem Verweis auf ein "XML::LibXML by example": http://grantm.github.io/perl-libxml-by-example/

Ich finde es bezeichnend, dass keiner da von dispose redet, und ich kriege Aerger, weil Fork "no more memory" meldet.
Gibt es eigentlich keine XML-Bibliothek zu empfehlen, was ohne dispose auskommt?

[RichardCZ]

Ich finde es bezeichnend, dass keiner da von dispose redet, und ich kriege Aerger, weil Fork "no more memory" meldet.
Gibt es eigentlich keine XML-Bibliothek zu empfehlen, was ohne dispose auskommt?

Alle modernen XML Bibliotheken sind im Gegensatz zu XML::Simple mit Iteratoren gebaut, sprich die hangeln sich durch XML Code on demand und schlucken und spucken nicht alles auf einmal. Ich würde meinen, diese gehen mit dem Speicher wesentlich sparsamer um - gerade bei grossen XML Dokumenten.

[mahowi]

Und damit kommen wir fliessend zum nächsten Mysterium der FHEM Codebasis:

Wir haben zwar 45 x use XML::Simple
aber nur 27 x XMLin
und nur 4 x XMLout

Das ist ein Fall für Akte-X.

Ganz so ominös ist es dann doch nicht. 

Dein grep zeigt sämtliche Vorkommnisse der Zeichenkette "XML::Simple", das aber dann auch mehrfach in einigen Modulen (inkl. Kommentaren).

Code Auswählen Erweitern

grep -r -l XML::Simple FHEM|wc -l
20

Und da waren es nur noch 20. 

Und zwar:

• FHEM/30_ENECSYSGW.pm
• FHEM/37_fakeRoku.pm
• FHEM/77_UWZ.pm
• FHEM/60_allergy.pm
• FHEM/98_livetracking.pm
• FHEM/70_DENON_AVR.pm
• FHEM/98_BOSEST.pm
• FHEM/88_ALL4000T.pm
• FHEM/98_DLNARenderer.pm
• FHEM/70_ENIGMA2.pm
• FHEM/10_EnOcean.pm
• FHEM/70_BRAVIA.pm
• FHEM/88_WEBCOUNT.pm
• FHEM/34_SWAP.pm
• FHEM/70_ONKYO_AVR.pm
• FHEM/37_plex.pm
• FHEM/70_OctoPrint.pm
• FHEM/70_NEUTRINO.pm
• FHEM/37_harmony.pm
• FHEM/98_rssFeed.pm

[RichardCZ]

Ganz so ominös ist es dann doch nicht. 
...
Und da waren es nur noch 20. 

Ich wusste es: Die Wahrheit ist da draussen.

Ist es eigentlich nicht schrecklich unkooperativ von Modulen, wenn einige

eval { require XML::Simple; };

und andere

use XML::Simple qw(:strict);

machen? Ich meine, da ja ein use zur Compilezeit passiert und das meiste eh in main:: landet, reicht ja ein einziger "harter" use und alle eval Liebesmüh' ist für die Katz.

Also das jetzt auch mal stellvertretend für alle anderen uses/requires gefragt.



Oder mal weitergedacht:

FHEM gibt sich sehr viel Mühe nicht abzusemmeln, wenn mal ein Modul putt ist. Denn der Require eines FHEM Moduls erfolgt ja schon im eval block.
Ich formuliere dann meine Frage um: "Ist es nicht schrecklich ineffizient - wenn das schon Rudolf an zentraler Stelle gemacht hat - dass jedes FHEM Modul irgendwie für sich versucht robust zu sein?"

[herrmannj]

erstens: historisch gewachsen.
zweitens: wie oft wird denn so ein modul bei einer uptime von, sagen wir einem Monat, geladen und welchen prozentualen Geschwindigkeitszuwachs dürfte man erwarten ? 

[rudolfkoenig]

Alle modernen XML Bibliotheken sind im Gegensatz zu XML::Simple mit Iteratoren gebaut, sprich die hangeln sich durch XML Code on demand und schlucken und spucken nicht alles auf einmal.

Netter Versuch das primitive XML-SAX zu verkaufen, das kam mW aber vor DOM. SAX verursacht Kopfschmerzen beim Programmieren, sobald das XML etwas aufwendiger wird: ich habe deswegen schon selbst einen DOM-Parser gebaut.

Also das jetzt auch mal stellvertretend für alle anderen uses/requires gefragt.

Bei fehlenden/fehlerhaften Datei wird mit use ein Modul gar nicht geladen, und die Fehlermeldung versteht nicht jeder Benutzer.
Bei eval/require kann man die Fehlermeldung netter verpacken, oder gar auf eine alternative Methode ausweichen, z.Bsp. unterstuetzt FHEMWEB bei fehlenden gzip keine Komprimierung, oder bei fehlenden SHA kein websocket.
Das heisst nicht, dass ich fuer require bin, nur als Argument, dass man require nicht von vornherein verteufeln sollte.

[RichardCZ]

Netter Versuch das primitive XML-SAX zu verkaufen,

XML::SAX ... da nage ich mir lieber vorher das Bein ab. Schon festgestellt, dass wenn man XML::Simple via CPAN installiert, dass dasn XML::SAX als Default XML Parser installiert wird? Ne - ich bin tatsächlich für XML::LibXML.

Und da auch nicht einmal aus sonderlich technischen Überlegungen, sondern "weil's jeder macht".

Das heisst nicht, dass ich fuer require bin, nur als Argument, dass man require nicht von vornherein verteufeln sollte.

Ich verteufle require auch nicht, nur finde ich, dass es auch da häufig zu Cargo Cult kommt.

Ein { eval require } macht z.B. pro Modul Sinn, wenn eine - optionale - Funktionalität erprobt wird. Und wenn nicht da, zuckt das FHEM Modul mit der Schulter und nimmt entweder was anderes her, oder eine Teilfunktionalität ist nicht verfügbar.

Aber leider kommt es doch eher häufiger vor, dass ein eval require gemacht wird und wenn der fehlschlägt, dann kommt eine return "Nicht mit mir." Grätsche.
Hier stelle ich die Sinnfrage.

[KernSani]

Ein { eval require } macht z.B. pro Modul Sinn, wenn eine - optionale - Funktionalität erprobt wird. Und wenn nicht da, zuckt das FHEM Modul mit der Schulter und nimmt entweder was anderes her, oder eine Teilfunktionalität ist nicht verfügbar.

Aber leider kommt es doch eher häufiger vor, dass ein eval require gemacht wird und wenn der fehlschlägt, dann kommt eine return "Nicht mit mir." Grätsche.
Hier stelle ich die Sinnfrage.

Im praktischen Betrieb sieht das Ganze doch so aus: Anwender will ein neues Modul ausprobieren, liest natürlich die commandref nicht ordentlich und/oder weiß eh nicht, welche CPAN Module er installiert hat. Also tippt Anwender "define meinSchaf MowModule  xyz" in die Kommandozeile. Dann ist es doch schön, wenn er statt "Module could not be loaded" eine schöne Meldung "MOW::ROBOT::WHATEVER not found. Please install it via CPAN or apt-get install libMowRobot."   bekommt, oder?

[RichardCZ]

erstens: historisch gewachsen.
zweitens: wie oft wird denn so ein modul bei einer uptime von, sagen wir einem Monat, geladen und welchen prozentualen Geschwindigkeitszuwachs dürfte man erwarten ? 

Geht ja nicht um die Speed. Geht ja darum, dass (normalerweise, wenn man nicht im eval-lala-land wohnt) ein "use <modul>" - auch wenn nur einmal vorhanden - bei Nichtvorhandensein den Compile-Vorgang abbricht, da können sich alle anderen noch so sehr anstrengen.

Wie schon geschrieben, bei den FHEM Modulen sorgt fhem.pl dafür, dass auch ein fehlgeschlagenes use nicht den Weltuntergang bedeutet.
Dann aber sind FHEM-modulprivate evals, wenn man ohnehin den Dienst ganz (und nicht nur eine Teilfunktionalität) quittiert vollkommen sinnlos.



Aber um mal zu XML::Simple zurückzukommen. Es geht immer besser:

60_allergy.pm

26:  use XML::Simple;
...
100:    my $req = eval {
101:        require XML::Simple;


Doppelt hält vmtl. besser.

[RichardCZ]

Wollte mal schauen was so insgesamt geholt wird - ist ja dann doch eine ganze Menge.

Da sind jetzt alle drin, sowohl die FHEM-Internen, wie auch externe.

Sind ganz schöne Hämmer dabei. Ich kann unendlich viele Fässer aufmachen...

Beispiel:

use bignum;

holy sh!t. https://perldoc.perl.org/bignum.html

If you do use bignum; at the top of your script, Math::BigFloat and Math::BigInt will be loaded and any constant number will be converted to an object (Math::BigFloat for floats like 3.1415 and Math::BigInt for integers like 1234).

Man kann dann natürlich bis hin zu einer bazzillion rechnen, aber alle Rechenoperationen werden ungefähr um den Faktor 100 langsamer. Alle, weil die natürlich automatisch overloaded werden. Deswegen will man ja auch use bignum in einem eingeschränkten Namespace / block verwenden. Schaumermal:

77_SMAEM.pm

package main;

use strict;
use warnings;
use bignum;
... # ab hier nuklearer Holocaust für main::


Also wer 77_SMAEM verwendet, darf sich nicht wundern wenn alles u.U. zäh wird.

[DS_Starter]

Also wer 77_SMAEM verwendet, darf sich nicht wundern wenn alles u.U. zäh wird.

Nö, eines der unauffällgst laufenden Module. 
Aber ich nehme das trotzdem mal raus, weiß nicht mehr aus welchem Grund wir das dort platziert hatten... Läuft schon gut drei Jahre ...

[RichardCZ]

Nö, eines der unauffällgst laufenden Module. 
Aber ich nehme das trotzdem mal raus, weiß nicht mehr aus welchem Grund wir das dort platziert hatten... Läuft schon gut drei Jahre ...

Ja klar! Wie kann es auch anders sein. Ich bin aber mehr ein Fan von "messen wir nach" als "Die Legende besagt":

$ bignum.pl
Benchmark: timing 10000 iterations of comp, comp_big...
      comp:  0 wallclock secs ( 0.23 usr +  0.00 sys =  0.23 CPU) @ 43478.26/s (n=10000)
  comp_big: 243 wallclock secs (242.48 usr +  0.02 sys = 242.50 CPU) @ 41.24/s (n=10000)


Also das nur für diejenigen, die glauben ich sei hysterisch wenn ich sage "100 mal langsamer".  Es ist mind. 1000 mal langsamer
Vermutlich merkt man in FHEM nix, weil FHEM auch großartig nix macht. 

Kann jeder für sich nachmessen:

Code Auswählen Erweitern

use strict;
use warnings;

use Data::Dumper;
use Benchmark;

sub compute_big {
    use bignum;
    my $num = 3.14;

    for my $sum (1..1000) {
        $num *= 2;
    }
}

sub compute {
    my $num = 3.14;

    for my $sum (1..1000) {
        $num *= 2;
    }
}

timethese(10000, {
                  'comp_big'  => \&compute_big,
                  'comp'  => \&compute,
                 });

[DS_Starter]

Vermutlich merkt man in FHEM nix, weil FHEM auch großartig nix macht. 

Jo, außer Haussteuerung ... 

Jedenfalls hab ich das rausgenommen und läuft bei mir nach wie vor. Ich stelle das geänderte Modul zum Nutzertest und requeste den Change beim Maintainer.
Danke für den Hinweis !

Grüße,
Heiko