Fehler mit perl v5.24.1: Experimental each on scalar is now forbidden

[kaihs]

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.

Code Auswählen Erweitern


File      Rev   Last Change

02_RSS.pm 10849 2016-02-14 19:08:31Z borisneubert


[doesel]

Gibt es schon eine Lösung? Auch Infopanel funktioniert unter dieser perl-Version nicht.
Doesel

[betateilchen]

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.

[doesel]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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.

[betateilchen]

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.

[doesel]

Leider sind immer noch Fehlermeldungen im Log, nur aus anderen Zeilen:

Code Auswählen Erweitern

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

[betateilchen]

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?

[herrmannj]

der hash muss nur de-refernziert werden

foreach my $key (keys %$hash)

vg
joerg

[betateilchen]

fast richtig...

Code Auswählen Erweitern

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.

[kaihs]

Und hier der Patch um das Problem in 02_RSS.pm zu beheben:

Code Auswählen Erweitern


--- 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};


[doesel]

@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...

[betateilchen]

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.

[Dr. Boris Neubert]

Und hier der Patch um das Problem in 02_RSS.pm zu beheben:

Code Auswählen Erweitern


--- 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.

[doesel]

Ich 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

[betateilchen]

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.

[herrmannj]

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

[betateilchen]

Für viele Ausnahmen (refs, redefine etc) gibt es ja durchaus legitime Gründe.

jepp

(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).

[herrmannj]

naja, idr kann der Autor dort ja genauso gut die Ursache der Warnung entfernen (undefined zb: $var||'' )

[Dr. Boris Neubert]

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

[herrmannj]

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

[justme1968]

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

[herrmannj]

wenn $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

[Dr. Boris Neubert]

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.

[betateilchen]

Ich nutze sehr gerne den ~~-Operator - ist ein sehr nützliches Ding.

Aber für die perl-Performance eine absolute Katastrophe.

[Dr. Boris Neubert]

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

[justme1968]

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