Mit perl v5.24.1 lässt sich 02_RSS.pm nicht mehr laden, die Fehlermeldung ist:
Experimental each on scalar is now forbidden at ./FHEM/02_RSS.pm line 693.
File Rev Last Change
02_RSS.pm 10849 2016-02-14 19:08:31Z borisneubert
Gibt es schon eine Lösung? Auch Infopanel funktioniert unter dieser perl-Version nicht.
Doesel
Zitat von: doesel am 04 November 2016, 13:43:57
Auch Infopanel funktioniert unter dieser perl-Version nicht.
Ich habe gerade eine InfoPanel Version eingecheckt, die das Problem lösen sollte. Kommt morgen per Update und kann jetzt schon aus svn gezogen werden.
Da ich nirgends perl 5.24 im Einsatz habe, bin ich auf Rückmeldungen von betroffenen Anwendern angewiesen.
Danke.
Hallo betateilchen,
erstmal Danke für die schnelle Hilfe. Leider bleibt es bei der Meldung "Cannot load module InfoPanel".
Hier der betreffende Auszug aus dem Log:
2016.11.05 16:14:49 1: reload: Error:Modul 55_InfoPanel deactivated:
Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 228.
2016.11.05 16:14:49 0: Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 228.
Gruß Doesel
Ein erneuter Versuch (ohne etwas zu ändern) brachte folgende Log-Meldung:
2016.11.05 16:46:57 1: PERL WARNING: Subroutine InfoPanel_Initialize redefined at ./FHEM/55_InfoPanel.pm line 130.
2016.11.05 16:46:57 1: PERL WARNING: Subroutine btIP_Define redefined at ./FHEM/55_InfoPanel.pm line 152.
2016.11.05 16:46:57 1: PERL WARNING: Subroutine btIP_Undef redefined at ./FHEM/55_InfoPanel.pm line 170.
2016.11.05 16:46:57 1: PERL WARNING: Subroutine btIP_Set redefined at ./FHEM/55_InfoPanel.pm line 178.
2016.11.05 16:46:57 1: reload: Error:Modul 55_InfoPanel deactivated:
Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 228.
2016.11.05 16:46:57 0: Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 228.
Zitat von: doesel am 05 November 2016, 16:18:57
Ein erneuter Versuch (ohne etwas zu ändern) brachte folgende Log-Meldung:
Naja, das ist ja letztendlich zweimal die gleiche Fehlermeldung (aus Zeile 228)
Habe eben eine neue Version eingecheckt und hoffe, dass die Meldung jetzt verschwindet.
Diese Version stellt "get ... override" (derzeit) nicht zur Verfügung, aber damit kann ich gut leben. Die war eh mehr oder weniger experimentell.
Leider sind immer noch Fehlermeldungen im Log, nur aus anderen Zeilen:
2016.11.05 20:48:46 1: PERL WARNING: Subroutine InfoPanel_Initialize redefined at ./FHEM/55_InfoPanel.pm line 130.
2016.11.05 20:48:46 1: PERL WARNING: Subroutine btIP_Define redefined at ./FHEM/55_InfoPanel.pm line 152.
2016.11.05 20:48:46 1: PERL WARNING: Subroutine btIP_Undef redefined at ./FHEM/55_InfoPanel.pm line 170.
2016.11.05 20:48:46 1: PERL WARNING: Subroutine btIP_Set redefined at ./FHEM/55_InfoPanel.pm line 178.
2016.11.05 20:48:46 1: reload: Error:Modul 55_InfoPanel deactivated:
Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 1163.
2016.11.05 20:48:46 0: Experimental keys on scalar is now forbidden at ./FHEM/55_InfoPanel.pm line 1163.
Auch "Cannot load module InfoPanel" kommt weiterhin,
Gruß Doesel
ok, dann muss ich mir mal irgendein System aufsetzen, auf dem dann perl 5.24 läuft.
Auf welcher Plattform läuft denn Dein fhem, damit da 5.24 installiert wird?
der hash muss nur de-refernziert werden
foreach my $key (keys %$hash)
vg
joerg
fast richtig...
foreach my $key ( keys %{$hash} )
Damit klappts.
Habe inzwischen eine EC2 Instanz aufgesetzt, auf der perl 5.24.1 installiert ist.
Die eben eingecheckte Version des InfoPanel Moduls läßt sich darauf problemlos laden und liefert die InfoPanels korrekt aus.
Und hier der Patch um das Problem in 02_RSS.pm zu beheben:
--- FHEM/02_RSS.pm 2016-11-06 16:19:16.098942402 +0100
+++ 02_RSS.pm 2016-11-06 17:24:06.000000000 +0100
@@ -690,7 +690,7 @@
}
} elsif($cmd eq "pop") {
return unless $pstackcount;
- while ( my ($key, $value) = each($pstack{$pstackcount}) ) {
+ while ( my ($key, $value) = each(%{$pstack{$pstackcount}}) ) {
$params{$key} = $value;
}
delete $pstack{$pstackcount};
@betateilchen:
Bin begeistert, Infopanel läuft mit der neuen Version. Nun werde ich noch das 02_RSS.pm testen, dann kann ich mich wieder den unwichtigen Dingen widmen.
Doesel
P.S.: Mein System ist eigentlich ein Debian Jessie, durch einen dummen Fehler teilweise auf Debian Stretch upgedatet...
Zitat von: doesel am 06 November 2016, 17:40:19
eigentlich ein Debian Jessie, durch einen dummen Fehler teilweise auf Debian Stretch upgedatet...
Meine neue EC2 Instanz ist auch ein stretch, da war dann perl 5.24.1 mit dabei und ich konnte testen.
Zitat von: kaihs am 06 November 2016, 17:32:59
Und hier der Patch um das Problem in 02_RSS.pm zu beheben:
--- FHEM/02_RSS.pm 2016-11-06 16:19:16.098942402 +0100
+++ 02_RSS.pm 2016-11-06 17:24:06.000000000 +0100
@@ -690,7 +690,7 @@
}
} elsif($cmd eq "pop") {
return unless $pstackcount;
- while ( my ($key, $value) = each($pstack{$pstackcount}) ) {
+ while ( my ($key, $value) = each(%{$pstack{$pstackcount}}) ) {
$params{$key} = $value;
}
delete $pstack{$pstackcount};
Eingecheckt.
Ich denke, dass wir in Zukunft noch über mehr Kodestellen mit impliziten Referenzen auf Hashes und Arrays stolpern werden.
ZitatIch denke, dass wir in Zukunft noch über mehr Kodestellen mit impliziten Referenzen auf Hashes und Arrays stolpern werden.
Genau, auch die JSONREADINGS funktionieren unter dieser Perl-Version leider ebenfalls nicht.
Doesel
Zitat von: Dr. Boris Neubert am 08 November 2016, 16:03:24
Ich denke, dass wir in Zukunft noch über mehr Kodestellen mit impliziten Referenzen auf Hashes und Arrays stolpern werden.
Vielleicht würde es Sinn machen die "no ... warnings" Zeilen aus allen Modulen zu entfernen und dann die auftauchenden Warnungen im Log bereits im Vorfeld aufzulösen, bevor ein Modul nach einem Perl-upgrade plötzlich gar nicht mehr funktioniert.
nun ja - am Ende muss das jeder Autor für sich entscheiden. Die Meldungen "experimental" und "depraced" gibt es dazu lange genug.
Ein Autor sollte wissen wann und warum er "no warnings" einsetzt und wenn er das tut dann hat er vermutlich eine Grund. Für viele Ausnahmen (refs, redefine etc) gibt es ja durchaus legitime Gründe. (für warnings fällt mir keiner ein)
vg
joerg
Zitat von: herrmannj am 08 November 2016, 20:52:31
Für viele Ausnahmen (refs, redefine etc) gibt es ja durchaus legitime Gründe.
jepp :)
Zitat von: herrmannj am 08 November 2016, 20:52:31
(für warnings fällt mir keiner ein)
mir schon: unbedarfte fhem user, die bei jeder WARNING in ihrem Logfile sofort in Panik geraten und das Forum mit "Fehler-Threads" überschwemmen, weil sie eine Warnung nicht von einem Fehler unterscheiden können (oder wollen).
naja, idr kann der Autor dort ja genauso gut die Ursache der Warnung entfernen (undefined zb: $var||'' )
Ich achte mittlerweile tunlichst darauf, keine Warnungen zu erzeugen, um keine Anfragen von verunsicherten Usern zu bekommen. Aber ich sehe nicht jeden Anwendungsfall voraus und die meisten Warnungen kommen bei meinen Modulen aus der Konkatenation mit undef.
Bewusst schalte ich nur experimental aus. Habe ich irgendwo überlesen, dass experimentelle Sprachfeatures wieder entfernt werden? Ich nutze sehr gerne den ~~-Operator - ist ein sehr nützliches Ding. Aber ich will nicht jeden Monat einen Beitrag lesen, was die Warnung im Log denn bedeute.
Viele Grüße
Boris
ich kann die Quelle nicht mehr benennen, aber ja:
experimental wird gekennzeichnet weil die Konstrukte nicht vollständig auf Nebenwirkungen getestet sind und weil nicht sicher ist das die features Bestand haben. Die Liste der wieder abgeschalteten features ist sogar beachtlich lang.
Für mich zb ein Grund smartmatches (so schön die auch sind) nicht zu verwenden und bei bei each verwende ich deswegen die (minimal) umständlichere de-referenzierte Variante. Bzgl der warning bin ich allerdings auch sehr pedantisch veranlagt, Daher verwende ich auf das $var||'' construct an Stellen wo ein undef (Beispiel log) vorkommen kann. In Summe empfinde ich das auch sehr gut. Es kommt durchaus vor das ich im log über eine warning stolpere und dadurch eigene Fehler (idr Logik) identifiziere
vg
joerg
achtung: mit $var|| das macht nicht immer was du möchtest da die linke seite nicht auf defined geprüft wird sondern auf true. d.h. wenn $var 0 oder '' ist ist die rechte seite das ergebniss. das kann, muss aber nicht das beabsichtigte sein.
um auf defined zu prüfen gibt es $var//. aber leider nicht in äderten perl versionen.
zu den experimental features: ja. es sind einige schon mal wieder rausgeflogen oder haben sich (was noch schlimmer ist) in ihrer logik/funktion/verhalten geändert.
gruss
andre
Zitatwenn $var 0 oder '' ist ist die rechte seite das ergebniss.
ja absolut, Danke. Vergesse manchmal das solche threads als Orientierung dienen.
Die komplette Kette besteht aus der Überlegung ob ich eine Zahl oder einen Text erwarte:
numerisch: $var||0
string: $var||'' (führt bei string $var = '0' zur einer Abweichung)
Alternativ (etwas umständlicher) kann man unklare Fälle so behandeln:
$var = defined($var)?$var:'hier könnte ihre Werbung stehen'; # ggf anderer Text ;)
vg
joerg
Zitat von: herrmannj am 09 November 2016, 23:31:08
Für mich zb ein Grund smartmatches (so schön die auch sind) nicht zu verwenden und bei bei each verwende ich deswegen die (minimal) umständlichere de-referenzierte Variante.
Was meinst Du bzw. wie geht das?
Ich verwende smartmatch ausschließlich zur Prüfung, ob ein Skalar in einem Array aufgeführt ist.
Zitat von: Dr. Boris Neubert am 09 November 2016, 20:42:55
Ich nutze sehr gerne den ~~-Operator - ist ein sehr nützliches Ding.
Aber für die perl-Performance eine absolute Katastrophe.
Zitat von: betateilchen am 12 November 2016, 11:27:54
Aber für die perl-Performance eine absolute Katastrophe.
Wie würdest Du effizient (knackiger, performanter Code) prüfen, ob ein Skalar in einem Array enthalten ist?
Viele Grüße
Boris
das hängt doch vom kontext ab.
- wenn es oft vorkommt und sich das array selten/nicht ändert -> besser (zusätzlich) hash statt array verwenden und darüber suchen
- wenn man das array sortieren kann -> binäre (oder andere) suche
- sonst einfach mit grep -> if( grep {$_ eq $var} @array ) {...}
gruss
andre