fhem.pl: lustiger Namespace-Bug

Begonnen von RichardCZ, 23 März 2020, 20:03:46

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatEr muss ja nicht updaten - er kriegt halt dann nix neueres mehr.
Und wenn er das doch tut, dann bleibt sein FHEM halt stehen => Bevor jemand auf die Idee kommt, ab sofort nur eine neuere Perl Version zu unterstuetzen, bitte mit mir Ruecksprache halten, damit wir das "er kriegt nix neueres mehr" in update auch implementieren. Das gilt nicht fuer neue Module, da ist die Ueberraschung geringer, wenn es nicht tut.

Komplett Off-Topic: Ich wuesste gerne, wozu man perl auf EPOC (vmtl. ist damit EPOC/32 gemeint) benoetigt hat. :)

RichardCZ

Zitat von: rudolfkoenig am 24 März 2020, 19:07:03
Und wenn er das doch tut, dann bleibt sein FHEM halt stehen => Bevor jemand auf die Idee kommt, ab sofort nur eine neuere Perl Version zu unterstuetzen, bitte mit mir Ruecksprache halten, damit wir das "er kriegt nix neueres mehr" in update auch implementieren. Das gilt nicht fuer neue Module, da ist die Ueberraschung geringer, wenn es nicht tut.

Komplett Off-Topic: Ich wuesste gerne, wozu man perl auf EPOC (vmtl. ist damit EPOC/32 gemeint) benoetigt hat. :)

Deswegen sprach ich in meinem Vorschlag auch von FHEM 6.x als letzte Version und nicht 6.0

Natürlich muss man die Update-Handbremse erstmal reinmachen bevor man den Zopf abschneidet. Also bitte: Ich möchte jetzt nicht in die userfeindliche Ecke geschoben werden. Mir liegt sehr wohl was daran, dass keine "running Systems" grundlos kaputt gemacht werden.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

rudolfkoenig

ZitatDeswegen sprach ich in meinem Vorschlag auch von FHEM 6.x als letzte Version und nicht 6.0
Mir leuchtet noch nicht ein, wo das prinzipielle Unterschied zwischen 6.X und 6.0 ist.
Ich kann auch auf einem 5.6 FHEM update eintippen, und danach habe ich die aktuelle Version.

betateilchen

Zitat von: RichardCZ am 24 März 2020, 19:33:07
Ich möchte jetzt nicht in die userfeindliche Ecke geschoben werden.

Im Moment sehe ich Dich eher in der entwicklerfeindlichen Ecke.

(mein ganz persönliches Empfinden)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

RichardCZ

Zitat von: rudolfkoenig am 24 März 2020, 19:46:49
Mir leuchtet noch nicht ein, wo das prinzipielle Unterschied zwischen 6.X und 6.0 ist.
Ich kann auch auf einem 5.6 FHEM update eintippen, und danach habe ich die aktuelle Version.

Weil sich ein FHEM 6.1 alle Updates von einer leicht geänderten URL holt für die alle FHEM < 6.1 "blind" sind?
Alle FHEMs < 6.1 updaten eben up bis 6.1 und 6.1 hat die "Welche Version und welches OS fährst Du?" Handbremse.

Also das wäre zumindest meine naive Vorgehensweise.


@betateilchen: Das täuscht. Ich mag Entwickler. Aber Du bist jetzt auf meiner schwarzen Liste.  ;)
Kleiner Scherz. Ich bevorzuge Verbesserungen am Code. Für interpersonelles Drama habe ich weder die Zeit noch die Lust. Ok?
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

KernSani

Ich finde das PingPong ja ganz amüsant... Aber wenn auf der einen Seite weniger Brechstange käme und auf der anderen Seite etwas mehr Bereitschaft über Änderungen nachzudenken, könnte vielleicht eine sinnvolle und konstruktive Diskussion zu Stande kommen und damit vielleicht auch verwertbare Ergebnisse...


Gesendet von iPhone mit Tapatalk
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

betateilchen

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

RichardCZ

Hey Betateilchen!

Zitat von: betateilchen am 24 März 2020, 23:40:12
Ich nicht.

Ich finde jetzt so langsam reicht's. Diese Emo-Rülpser gehören nicht in Development. Bitte doch Rudolf, dass er ein FHEM/Psychology aufmacht, wo Du deine Feefeees äußern kannst. So auf einer Skala von 1-10 wie Du Dich fühlst.

Kein Mensch hat Dich angegriffen und wenn Du Dich nicht mit persönlichen und nichts zur Sache beitragenden Äußerungen in den Thread gezwängt hättest, dann wärste derzeit noch nicht einmal auf dem Radar. So war ich gezwungen mir mal Deinen Code anzusehen.

Die Versuchung ist natürlich groß, den Code auseinanderzunehmen. Aber das wäre (hochgradig) unprofessionell und vor allem würde es die durchaus verständliche (und in der gegenwärtigen Situation richtige) Politik von Rudolf unterwandern: "Mir ist ein Modul mit potentiellen Fehlern lieber als ein Modul ohne Maintainer".

Da habe ich mal ne Nacht drüber geschlafen und bin aufgewacht mit der Erkenntnis, dass ich da 100% zustimme.

Deswegen habe ich bei ConfigDB et al. einen "pull"-Schalter umgelegt. Ich werde mich da (außer ich finde echte kritische Bugs) gar nicht dazu äußern und Dir was "reindrücken" (push), sondern Du kommst zu mir - wenn gewünscht - und fragst was dort knirscht. Oder auch nicht.

Allerdings - für den Fall, Du solltest einer derer sein, die sich viel und gerne aufregen wie sich zwei andere Parteien unterhalten:

Fremde Dinge.
Eigene Nase.
Nicht reinstecken.

Danke.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

SCMP77

#38
Hallo,

Zitat von: KernSani am 24 März 2020, 20:39:28Ich finde das PingPong ja ganz amüsant... Aber wenn auf der einen Seite weniger Brechstange käme und auf der anderen Seite etwas mehr Bereitschaft über Änderungen nachzudenken, könnte vielleicht eine sinnvolle und konstruktive Diskussion zu Stande kommen und damit vielleicht auch verwertbare Ergebnisse...

Weniger amüsant, aber trotzdem wichtig, solange die DevelopmentModuleIntro keine Empfehlungen in dieser Art beinhaltet. So eine Diskussion sollte man immer auch als Denkanstoß sehen.

Zitat von: Wzut am 24 März 2020, 16:48:37
b. ich habe kein Problem damit irgendwo etwas abzuholen, dafür muß ich aber erst einmal wissen das es überhaupt etwas zum Abholen gibt.

Eben Und hier liegt eigentlich die Wurzel des Übels. Man diskutiert etwas, meint, dass es so oder so vielleicht besser gehen könnte, aber diese Überlegungen müssten dann in die DevelopmentModuleIntro o.ä. eingehen.

Eine solche Diskussion bewirkt schon, dass derjenige, welcher mitliest, mal über den eigenen Code nachdenkt. Ich bin hier kein großartiger Modulentwickler, weil ich auf der Basis Perl einfach nicht ausreichend effektiv programmieren kann. Ein sehr umfangreiches Modul habe ich daher in Java ausgelagert und ich bezweifel, dasss man das überhaupt in FHEM in der herkömmlichen Weise ausreichend sicher hinbekommen hätte. Das nur am Rande.

Sauberer ist es aber auf jeden Fall für jedes FHEM-Modul ein einzelnes Package zu definieren. Das hat den Vorteil, dass man nicht immer den Modulnamen vor Funktionen und Variablen schreiben muss (man liest nunmal von links nach rechts). Dadurch wird der Code übersichtlicher und daher auch weniger anfällig für Bugs. Sicher ist ein gewisses Umdenken notwendig, man muss die einzelnen FHEM-Module, welche man nutzen will mit use oder über GP_Import bekannt machen. Das hat dann aber wieder den Vorteil, dass man jederzeit einen Überblick besitzt, welche FHEM-Methoden man überhaupt benutzt.

Ich habe bisher auch quasi mittels copy/paste aus dem DevelopmentModuleIntro meine Module erstellt und dabe nicht wirklich nachgedacht. Daher hatte ich bisher auf die Packages auch verzichtet (obgleich ich es besser wissen müsste). Diese Diskussion hat mich dazu angeregt, mein aktuelles Modul (SolvisClient) die Namespace-Möglichkeit von Perl zu nutzen. Auch habe ich dabei auch FHEM::Meta eingebaut. Das ganze hat mich vielleicht 2h gekostet und der Code sieht jetzt deutlich übersichlicher aus. Als Anhaltspunkt habe ich dafür das Modul "73_AutoShuttersControl.pm" verwendet.

Und eine Empfehlung, dass man immer nur das "use" nur für daie Methoden nutzt, die man wirklich benötigt (der eigentliche Grund für die vorliegende Diskussion), wäre auch nicht schlecht.

Das Ziel solcher Diskussionen sollte sein, dass man dann das Ergebnis auch in die entsprechende Fhem-Doku zu übertragen.

Aber ja, die Änderung zu einem übersichtleren System hin, kann  bei einem laufenden System nur von unten nach oben erfolgen, andernfalls müsste man von einem Tag zum anderen die vielen Module bearbeiten, ich denke, das ist klar.


Viele Grüße
     Stefan



Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht

RichardCZ

Zitat von: SCMP77 am 25 März 2020, 09:34:47
Eben Und hier liegt eigentlich die Wurzel des Übels. Man diskutiert etwas, meint, dass es so oder so vielleicht besser gehen könnte, aber diese Überlegungen müssten dann in die DevelopmentModuleIntro o.ä. eingehen.

100%. Aber bevor man das in https://wiki.fhem.de/wiki/DevelopmentModuleIntro in destillierter Form giessen kann, muss das Destillat erstmal kollektiv erarbeitet werden. Ansonsten haste Wiki-Vandalismus und change/revert Krieg. ;-)

Daher ja mein Vorschlag mit der "Perl Ecke" im Forum, wo ich gerne mögliche Wege aus dem Dickicht aufzeige - und auch gerne L3 Support für die Modulautoren spiele. Rudolf bat um eine Diskussion diesbezüglich - bislang Fehlanzeige.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

CoolTux

Zitat von: RichardCZ am 25 März 2020, 10:23:48
100%. Aber bevor man das in https://wiki.fhem.de/wiki/DevelopmentModuleIntro in destillierter Form giessen kann, muss das Destillat erstmal kollektiv erarbeitet werden. Ansonsten haste Wiki-Vandalismus und change/revert Krieg. ;-)

Daher ja mein Vorschlag mit der "Perl Ecke" im Forum, wo ich gerne mögliche Wege aus dem Dickicht aufzeige - und auch gerne L3 Support für die Modulautoren spiele. Rudolf bat um eine Diskussion diesbezüglich - bislang Fehlanzeige.

Ich hatte ja schon erwähnt das ich für so eine Ecke wäre.
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


Beta-User

Nochmal zurück zum Kritikpunkt im ersten Beitrag hier, "use POSIX;" ohne "qw()".
Ist denn das hier zutreffend?
Zitat von: Beta-User am 24 März 2020, 09:02:49Aber selbst wenn man es bereits eine myUtils-Datei (entsprechend dem template geschrieben) würde ausreichen, um für alle Module keine Fehlfunktionen beim Aufruf entsprechender Funktionen mehr zu verursachen (?). 

Dann sollte man doch - unterstellt, dass die Kritik an sich betr. den Umgang mit POSIX korrekt ist - das myUtils-Template asap ändern, oder?
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

CoolTux

Stellt sich die Frage ob das überhaupt nötig ist das das "use" in der myUtils steht. Einmal sauber geladen in der main und dann sollte das doch ausreichend sein. Es sei denn der User will aus POSIX eine andere Funktion verwenden als die welche in der main per qw geladen wurde.
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

Habe "use POSIX;" aus myUtilsTemplate.pm, 95_holiday.pm, 98_JsonList2.pm und 98_XmlList.pm entfernt. Bleiben noch 75 weitere Module, die auch "use POSIX;" haben, sinnlos, weil fhem.pl das eh schon tut. Ich frage mich, ob wir die naechsten Monate mit solchen "NOP" Aufgaben beschaeftigt sind.