Smartmatch und andere experimentelle Perl-Features

Begonnen von betateilchen, 04 April 2024, 23:50:54

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: rudolfkoenig am 04 April 2024, 23:37:17Off-Topic: mein perl 5.38 beschwert sich: Smartmatch is deprecated at FHEM/TimeSeries.pm line 113.

Auch offtopic: bei switch ist es ähnlich. Diese Experimente sollen wohl ab 5.42 komplett entfernt werden.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

Ich habe den Beitrag von Udo abgeteilt und hierher gestellt, damit wir uns mit dem Schicksal von Smartmatch, given, when, switch und was weiß ich noch für experimentellen Features von Perl befassen und für den FHEM-Code darauf reagieren.

Interessant (habe mich aber nicht weiter damit auseinandergesetzt): Perl 5.20 and the fate of smart matching and given-when.

Ich liebe ~~ für die Prüfung, ob ein Element in einem Array steht.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

CoolTux

Na toll. Da darf ich ja dann einiges umschreiben.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: CoolTux am 05 April 2024, 13:30:07Na toll. Da darf ich ja dann einiges umschreiben.
So neu ist das ja eigentlich sich nicht... In der Perl-Ecke gibt es dazu einige "Warnungen" - die sind mehrere Jahre alt...

Smartmatch z.B. müßte relativ einfach mit einem grep zu fixen sein. (Muss ggf. mal suchen.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#4
Zitat von: CoolTux am 05 April 2024, 13:30:07Na toll. Da darf ich ja dann einiges umschreiben.

Zitat von: Beta-User am 05 April 2024, 13:37:13So neu ist das ja eigentlich sich nicht...

Stimmt, die smartmatch Problematik ist seit 5.18 bekannt und deshalb sind die darauf basierenden features (z.B. switch/given) seither als "experimental" gekennzeichnet. Dass die irgendwann wegfallen, ist nicht überraschend, inzwischen weiß man halt auch, wann das passieren wird.

Meine drei aktiven Module, die davon betroffen sind, habe ich heute umgebaut. Dabei habe ich given/when einfach durch if/elsif/else ersetzt. Das war die einfachste Lösung, die versionsunabhängig und ohne weitere Modul-Abhängigkeiten funktioniert.

Zitat von: Dr. Boris Neubert am 05 April 2024, 09:24:15Ich liebe ~~ für die Prüfung, ob ein Element in einem Array steht.

Zitat von: Beta-User am 05 April 2024, 13:37:13Smartmatch z.B. müßte relativ einfach mit einem grep zu fixen sein.

if (grep(regex, @array)) {}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 05 April 2024, 13:53:01if grep(regex, @array) {}

Meine mich erinnern zu können, dass das perlcritics in dieser Fassung nicht optimal findet und die block-Variante vorschlägt. Mobil, ungetestet so:
if (grep m{regex} @array) {}
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

ja, ich hatte auf die Schnelle beim Tippen die Klammern vergessen.

Ansonsten bleibe ich aber bei dieser Variante:

if (grep(regex, @array)) {}
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Hatte nicht behauptet, dass es in der Komma-separierten Variante nicht funktioniert.

Wollte nur anregen, bei einer Überarbeitung der Module ggf. schlicht das online-tool oä. zu nutzen und bei der Gelegenheit gleich die (afair) "bessere" Variante zu wählen. That's all...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hier noch ein (funktionierendes und hoffentlich verständliches) Beispiel, wie das z.B. in "98_monitoring.pm" nach der perlcritic-Optimierung aussieht (unter Ignorierung der "postfix-if"-critic...):
return if @blacklist && grep { m{\A${name}\z}x } @blacklist;
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

#9
Zitat von: Beta-User am 05 April 2024, 15:23:38Hier noch ein ... Beispiel, wie das z.B. in "98_monitoring.pm" nach der perlcritic-Optimierung aussieht (unter Ignorierung der "postfix-if"-critic...)

Entschuldigung, aber das ist doch Käse.

Entweder, Du willst es (im Sinne von perlcritic) richtig machen, dann mach es aber auch komplett richtig.
Aber doch bitte nicht den einen (perlcritic)-Mangel beseitigen und den anderen bewusst ignorieren.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 05 April 2024, 15:47:41Entweder, Du willst es (im Sinne von perlcritic) richtig machen, dann mach es aber auch komplett richtig.
Aber doch bitte nicht den einen (perlcritic)-Mangel beseitigen und den anderen bewusst ignorieren.
Schön, dass du das highlightest :) .
Auch Perlcritic kennt mehrere Stufen, und macht Unterschiede. Das "grep"-Thema liegt (aus dem Kopf) auf Level 4, postfix-if dürfte "cruel" sein.
In der Regel würde ich Level 4+5 beseitigen wollen, ausgenommen manche Dinge, die im FHEM-Kontext wenig sinnvoll sind oder im konkreten Fall einfach überzogen, bei Level 3 kann man vermutlich so oder so votieren.
"Meine" Codes laufen (mit wenigen Pflastern) in der Regel bei bis Level-3-Checks (einschließlich) ohne Meckern durch, und die Dinge, die ich über diesen Weg gefunden hatte, waren praktisch alle ziemlich valide.

 Bei postfix-if geht es eigentlich v.a. um Lesbarkeit, und wenn da vorne ein "return" steht, macht mein Editor ein schönes Syntax-highlighting und es ist direkt sichtbar, dass hier eine "Ausgangstür" ist - Ziel (anders) voll erreicht. Darf ich ja entscheiden... 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dr. Boris Neubert

https://forum.fhem.de/index.php?topic=139688

#####################################
#
# smartmatch replacement
#
#####################################

# use contains_<type>($scalar, @array) instead of $scalar ~~ @array
# requires List:Util
# see https://www.perlmonks.org/?node_id=1067462

sub contains_numeric($@) {
  my ($scalar, @array) = @_;
  return any { $_ == $scalar } @array;
}

sub contains_string($@) {
  my ($scalar, @array) = @_;
  return any { $_ eq $scalar } @array;
}
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

JoWiemann

Hallo,

möchte dafür plädieren contains_numeric und contains_string in die 99_Utils zu übernehmen.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Beta-User

Frage dazu:

Bringt die Unterscheidung in "numeric" und "string" irgend einen (performance-) Vorteil?

Bei "numeric" besteht sonst immer das Riskio, dass jemand gemischte Daten reinwirft (also kein rein numerisches Vergleichsarray) und man am Ende dann eine Ladung Fehlermeldungen hat...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dr. Boris Neubert

Zitat von: Beta-User am 01 November 2024, 17:28:32Bringt die Unterscheidung in "numeric" und "string" irgend einen (performance-) Vorteil?

Es ist die Frage, welcher Vergleichsoperator ausgewählt werden soll, == oder eq.

Die Performance kommt von any statt grep.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Beta-User

any ist einleuchtend.

eq klappt halt auch mit Zahlen, aber == wirft einen Fehler bei jedem nicht-numerischen Element im Array.
Daher die Frage, ob nicht eine Funktion (mit eq) ausreichend wäre.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dr. Boris Neubert

Die Funktion wäre ja dann contains_string()

An sich fände ich es gut, wenn beide Funktionen oder was noch besseres nach 99_Utils.pm oder nach fhem.pl käme. Liest Rudi hier mit?
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

ZitatLiest Rudi hier mit?
Ja, ich warte nur die Ende der Diskussion und eine klare Ansage ab :)

erwin

Nachdem any nur ein true/false als Resultat liefert, wäre ich für "eq" - und nur eine function - am besten in fhem.pl
Gibts Nachteile/Pitfalls wenn man Zahlen mit eq vergleicht?
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Dr. Boris Neubert

Zitat von: erwin am 10 November 2024, 19:18:46Gibts Nachteile/Pitfalls wenn man Zahlen mit eq vergleicht?

Ich habe ChatGPT gefragt. Hier der relevante Schnipsel aus der Antwort:

Zitat... kann unerwartetes Verhalten verursachen, weil eq die Werte als Strings interpretiert. In den meisten Fällen funktioniert es zufällig, wenn die Zahlen ähnlich formatiert sind, aber sobald z.B. führende Nullen oder unterschiedliche Formate vorhanden sind, könnte das Ergebnis falsch sein.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

betateilchen

Bei einer Abstimmung wäre ich auch dafür, BEIDE Funktionen zu implementieren. Und zwar sicherheitshalber in der fhem.pl, denn es gibt doch den einen oder anderen user, der seine 99_Utils.pm verhunzt.

Als Entwickler sollte man sich aber bei solchen grundlegenden Funktionen darauf verlassen können, dass sie auch wirklich vorhanden sind.

Es wird nach der Umstellung vermutlich ohnehin den einen oder anderen Supportfall geben, wenn Anwender ihr update nur unvollständig ausführen, weil sie beispielsweise mit exclude_from_update arbeiten. Aber man kann und sollte nicht jede Dummheit abfangen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

Zitat von: Dr. Boris Neubert am 01 November 2024, 14:29:00https://forum.fhem.de/index.php?topic=139688

#####################################
#
# smartmatch replacement
#
#####################################

# use contains_<type>($scalar, @array) instead of $scalar ~~ @array
# requires List:Util
# see https://www.perlmonks.org/?node_id=1067462

sub contains_numeric($@) {
  my ($scalar, @array) = @_;
  return any { $_ == $scalar } @array;
}

sub contains_string($@) {
  my ($scalar, @array) = @_;
  return any { $_ eq $scalar } @array;
}

Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen
use List::Util qw(any);

betateilchen

Hallo Rudi,

würdest Du bitte die beiden neuen Funktionen noch in die Liste der "Forward declarations" am Anfang der fhem.pl aufnehmen? Diese Liste benutze ich gerne beim Suchen von passenden Funktionen :)

Danke!
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig


betateilchen

Zitat von: rudolfkoenig am 01 Dezember 2024, 11:32:02Erledigt.

Danke.

Zitat von: rudolfkoenig am 30 November 2024, 19:55:15mit etwas Bauchschmerzen wegen
use List::Util qw(any);

Inzwischen habe ich das Paket libscalar-list-utils-perl in die dependencies für das Debian-Paket von FHEM aufgenommen, damit sollte es zumindest bei Neuinstallation unter Debian und Derivaten keine Probleme geben.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: rudolfkoenig am 30 November 2024, 19:55:15Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen
use List::Util qw(any);
Sollte kein allzu großes Problem mehr sein, jedenfalls wenn ich das richtig zusammengefieselt habe:
{ Module::CoreList->first_release('List::Util', 1.33) }=>
5.019005
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Dr. Boris Neubert am 30 November 2024, 12:50:00Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.
Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Dr. Boris Neubert

Zitat von: Beta-User am 04 Dezember 2024, 10:04:51
Zitat von: Dr. Boris Neubert am 30 November 2024, 12:50:00Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.
Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?
getan
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!