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

Begonnen von kaihs, 12 Oktober 2016, 23:32:27

Vorheriges Thema - Nächstes Thema

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.


File      Rev   Last Change

02_RSS.pm 10849 2016-02-14 19:08:31Z borisneubert
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

doesel

Gibt es schon eine Lösung? Auch Infopanel funktioniert unter dieser perl-Version nicht.
Doesel
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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:
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.
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

doesel

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
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

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?
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

der hash muss nur de-refernziert werden

foreach my $key (keys %$hash)

vg
joerg


betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

kaihs

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};
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

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...
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

doesel

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
(FHEM auf Cubietruck mit Igor-Image, 64GB SSD), seit März 19 FHEM auf NUC im Proxmox-Container, 240GB SSD, div. Homematic, Max Fensterkontakte, Onewire über Firmata und FHEM2FHEM auf Raspberrys, MySensors, Jeelink-Clone mit GSD-Modul, CUL, SDM220Modbus, Logo!8, WS980WiFi

betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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

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).
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

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

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

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.
-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968