Autor Thema: fhem.pl: lustiger Namespace-Bug  (Gelesen 1526 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21953
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #30 am: 24 März 2020, 19:07:03 »
Zitat
Er 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. :)

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #31 am: 24 März 2020, 19:33:07 »
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.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21953
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #32 am: 24 März 2020, 19:46:49 »
Zitat
Deswegen 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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16164
  • s/fhem\.cfg/configDB/g
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #33 am: 24 März 2020, 19:51:16 »
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)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #34 am: 24 März 2020, 20:28:24 »
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?

Online KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3201
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #35 am: 24 März 2020, 20:39:28 »
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, ...
Zustimmung Zustimmung x 4 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16164
  • s/fhem\.cfg/configDB/g
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #36 am: 24 März 2020, 23:40:12 »
Ich finde das PingPong ja ganz amüsant

Ich nicht.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #37 am: 25 März 2020, 09:06:45 »
Hey Betateilchen!

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.

Offline SCMP77

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 90
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #38 am: 25 März 2020, 09:34:47 »
Hallo,

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

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.

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



« Letzte Änderung: 25 März 2020, 09:38:22 von SCMP77 »
Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht
Zustimmung Zustimmung x 2 Liste anzeigen

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #39 am: 25 März 2020, 10:23:48 »
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.

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 24242
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #40 am: 25 März 2020, 10:28: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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
Mein Dokuwiki:
https://tuxnetwiki-tuxnet.ddns.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21953
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #41 am: 25 März 2020, 10:33:54 »
Ich habe die Ecke eingerichtet.
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9765
  • eigentlich eher "user" wie "developer"
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #42 am: 25 März 2020, 12:02:51 »
Nochmal zurück zum Kritikpunkt im ersten Beitrag hier, "use POSIX;" ohne "qw()".
Ist denn das hier zutreffend?
Aber 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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 24242
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #43 am: 25 März 2020, 12:14:58 »
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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
Mein Dokuwiki:
https://tuxnetwiki-tuxnet.ddns.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21953
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #44 am: 25 März 2020, 12:25:08 »
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.

 

decade-submarginal