Debian Bullseye Perl 5.32 FHEM wird Ende des Jahres crachen

Begonnen von CoolTux, 28 Februar 2021, 19:15:25

Vorheriges Thema - Nächstes Thema

CoolTux

Provokante Überschriften erregen Aufmerksamkeit. Und ich denke die ist auch nötig und angebracht.
Ende des Jahres wird Debian Bullseye, aktuell noch testing, als stable erscheinen und unsere User werden nach und nach updaten.
Das stellt laut aktuellen Codeanalysen FHEM vor einem großen Problem. Denn entweder wird es crachen oder besten Falls in einem eval böse Fehlermeldungen werfen.
Grund ist Perl in der Version 5.32. Schon ab Version 5.30 wurden viele "Deprecations" als "Incompatible Changes" makiert.


  • Assigning non-zero to $[ is fatal
  • Delimiters must now be graphemes
  • Some formerly deprecated uses of an unescaped left brace "{" in regular expression patterns are now illegal
  • Previously deprecated sysread()/syswrite() on :utf8 handles is now fatal
  • my() in false conditional prohibited
  • Fatalize $* and $#
  • Fatalize unqualified use of dump()
  • Remove File::Glob::glob()
  • pack() no longer can return malformed UTF-8
  • Any set of digits in the Common script are legal in a script run of another script
  • JSON::PP enables allow_nonref by default

Wir als Entwickler haben also noch genau 10 Monate um unsere Module einen Codereview zu unterziehen und zu schauen ob unsere Module von diesen Änderungen betroffen sind.

Nur mal zur Verdeutlichung
Zitat
my() in false conditional prohibited

Declarations such as my $x if 0 are no longer permitted.
Dieses  my $x if 0  ist im übrigen etwas wovor uns einige Entwickler bereits vor Monaten gewarnt hatten. Allen vorweg Richard. Siehe aktuell https://forum.fhem.de/index.php/topic,117934.0.html

Ein weiteres Thema sollte "unescaped left brace "{" in regular expression patterns" sein, ich denke es wäre gut, sofern noch nicht geschehen, eine Prüfung diesbezüglich in perlSyntaxCheck() ein zu bauen.



Grüße
Marko
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

rudolfkoenig

ZitatDenn entweder wird es crachen oder besten Falls in einem eval böse Fehlermeldungen werfen.
Hast Du Details?
Ich teste seit einem halben Jahr mit 5.32 (vorrangig meine Module), bisher ohne Warnungen oder gar einem Crash.

Christoph Morrison

Zitat von: rudolfkoenig am 01 März 2021, 09:04:26
Hast Du Details?
Ich teste seit einem halben Jahr mit 5.32 (vorrangig meine Module), bisher ohne Warnungen oder gar einem Crash.

Testest du mit einem "reinen" Perl oder mit einem von Debian gepatchten?

CoolTux

Zitat von: rudolfkoenig am 01 März 2021, 09:04:26
Hast Du Details?
Ich teste seit einem halben Jahr mit 5.32 (vorrangig meine Module), bisher ohne Warnungen oder gar einem Crash.

Aktuell habe ich nur die Changelogs der entsprechenden Perl Versionen ab 5.30. Ich bin dabei ein Testsystem auf zu setzen. Das wird aber noch etwas dauern. Meine Aussagen beziehen sich also auf die Changelogs und sind somit rein theoretischer Natur. Ich wollte es dennoch mehr in den Fokus rücken.


Grüße
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

rudolfkoenig

ZitatTestest du mit einem "reinen" Perl oder mit einem von Debian gepatchten?
Soweit ich sehe, ist das ein "reiner" Perl.

Dr. Boris Neubert

Gibt es noch die Aktivitäten zur stärkeren Modularisierung der FHEM-Module und der Ermöglichung von Unit-Tests?

Marco, wenn Du ein Testsystem aufsetzt: so etwas wäre doch grundsätzlich sinnvoll für regelmäßige Integrationstests. Man lässt FHEM einmal mit einer cleveren Konfiguration durchlaufen und sieht ggf. Fehler in Modul A durch Änderungen in Modul B, fhem.pl oder den Libs.

Clevere Konfiguration: für einen Teil der Module kann man Konfigurationen mitliefern zum Test ohne dass es eines physischen Gerätes bedarf (siehe demo.cfg). Für meine Module würde ich sowas mal zusammenhacken können.

Für den Rest könnte man mal über einen generischen Device-Emulator nachdenken, der fest in FHEM verbaut ist. Der müsste dann anhand einer simplen Spec spontan Datagramme senden sowie Request/Response-Paare bearbeiten können. Nicht, dass ich dafür Zeit hätte. Ist halt so eine Idee.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

ZitatGibt es noch die Aktivitäten zur [...] Ermöglichung von Unit-Tests?
Unit-Tests koennen mW auch jetzt schon gebaut werden, siehe .../t/README

ZitatFür den Rest könnte man mal über einen generischen Device-Emulator nachdenken, der fest in FHEM verbaut ist.
Ich habe vor ca vier Jahren contrib/CULsim.pl eingecheckt.
Das ist zwar nicht generisch, simuliert aber ein CUL und ein SCC, da ich Letzteres nie gesehen habe.

CoolTux

Zitat von: Dr. Boris Neubert am 10 März 2021, 14:07:05
Gibt es noch die Aktivitäten zur stärkeren Modularisierung der FHEM-Module und der Ermöglichung von Unit-Tests?

Marco, wenn Du ein Testsystem aufsetzt: so etwas wäre doch grundsätzlich sinnvoll für regelmäßige Integrationstests. Man lässt FHEM einmal mit einer cleveren Konfiguration durchlaufen und sieht ggf. Fehler in Modul A durch Änderungen in Modul B, fhem.pl oder den Libs.

Clevere Konfiguration: für einen Teil der Module kann man Konfigurationen mitliefern zum Test ohne dass es eines physischen Gerätes bedarf (siehe demo.cfg). Für meine Module würde ich sowas mal zusammenhacken können.

Für den Rest könnte man mal über einen generischen Device-Emulator nachdenken, der fest in FHEM verbaut ist. Der müsste dann anhand einer simplen Spec spontan Datagramme senden sowie Request/Response-Paare bearbeiten können. Nicht, dass ich dafür Zeit hätte. Ist halt so eine Idee.

Hallo Boris,

Es gibt Aktivitäten dies bezüglich. Einige Entwickler bauen Ihre Module entsprechend um oder bauen neue Module gleich entsprechend auf. Auch Tests werden fleißig verwendet wenn ich das richtig sehe. Es müsste natürlich prominent im Developer Guide angepriesen und auch Dokumentiert werden. Aber ich glaube das wollte Rudi nicht unbedingt so sehr anpinnen damit es neue Entwickler welche einsteigen nicht zu sehr abschreckt. Kann ich auch irgendwie verstehen. Aber vielleicht wäre es dennoch gut da gleich mal in die richtige Richtung zu lenken.

Ich habe vor 2-3 Jahren ein kleinen TCP Server gebaut welcher mir entsprechende Respons gibt je nach Anfrage. Habe damit damals das Tesla Powerwall Modul entwickelt da ich ja keine TeslaPowerwall hatte.
Das könnte ich mal versuchen flott zu machen. Aber leider habe ich aktuell null Zeit.
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

klaus.schauer

Zitat von: CoolTux am 10 März 2021, 16:21:17
Ich habe vor 2-3 Jahren ein kleinen TCP Server gebaut welcher mir entsprechende Respons gibt je nach Anfrage. Habe damit damals das Tesla Powerwall Modul entwickelt da ich ja keine TeslaPowerwall hatte.
Das könnte ich mal versuchen flott zu machen. Aber leider habe ich aktuell null Zeit.
Etwas abseits vom Thema: Was kann dieser TCP Server? Ich suche nach einem Einstieg für einen HTTP-Server in Fhem, der Anfragen zu Device-Stati über xml-Dateien beantwortet, konkret des SMA Home Managers.

Christoph Morrison

#9
Zitat von: CoolTux am 10 März 2021, 16:21:17
Ich habe vor 2-3 Jahren ein kleinen TCP Server gebaut welcher mir entsprechende Respons gibt je nach Anfrage. Habe damit damals das Tesla Powerwall Modul entwickelt da ich ja keine TeslaPowerwall hatte.
Das könnte ich mal versuchen flott zu machen. Aber leider habe ich aktuell null Zeit.

Naja im Prinzip sind das ja oft wirklich nur Server die irgendwas über HTTP ausliefern, heute meist JSON. Für meine Buienradar-Entwicklung habe ich mir einfach einen Apache-Docker-Container genommen, der auf verschiedenen URLs statisch verschiedene JSON-Dokumente zurückliefert.

ZitatGibt es noch die Aktivitäten zur stärkeren Modularisierung der FHEM-Module und der Ermöglichung von Unit-Tests?

Ich schreibe z.B. gerade an einer TDD-Version des BR-Moduls und im FHEM-Github gibt es von Sidey auch ein Template-Modul, das bereits einige best practices unterstützt. Ich habe mal an einem Tool gearbeitet, mit dem man Module vorkonfiguriert anlegen kann - ist aber eher Alpha-Version.