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

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
fhem.pl: lustiger Namespace-Bug
« am: 23 März 2020, 20:03:46 »
Also, dass der main Namespace in FHEM ja ziemlich überfüllt ist, muss ich ja wohl nicht extra weiter breittreten.

Und über die daraus resultierende grenzwertige Wartbarkeit haben wir schon an anderer Stelle gesprochen, aber irgendwie blieb das ja alles im theoretischen Bereich. Nun - hier was Konkretes:

sub
restoreDir_saveFile($$)
{
  my($restoreDir, $fName) = @_;

  return if(!$restoreDir || !$fName);

  my $root = $attr{global}{modpath};
  restoreDir_mkDir($root, "$restoreDir/$fName", 1);
  if(!copy($fName, "$root/$restoreDir/$fName")) {
    log 1, "copy $fName $root/$restoreDir/$fName failed:$!";
  }
}

Finde den Fehler.

Bevor die schnelle Auflösung kommt, sage ich wie ich ihn gefunden habe. Ich lese natürlich viel und gerne und irgendwie war mir POSIX zu allem Namespace-Überfluss dann doch zuviel des Guten. Ich zitiere aus https://perldoc.perl.org/POSIX.html

Zitat
Everything is exported by default (with a handful of exceptions). This is an unfortunate backwards compatibility feature and its use is strongly discouraged. You should either prevent the exporting (by saying use POSIX (); , as usual) and then use fully qualified names (e.g. POSIX::SEEK_END ), or give an explicit import list.

Da ich natürlich mehr mache, als ein "paar Greps und viel tamtam", habe ich mir gedacht, ich beisse in meinem Repo in den sauren Apfel und binde POSIX richtig ein - also mit minimalem Namespace Impakt.

Gesagt, use POSIX qw(); getan.

Und siehe da,

$ perl -c hobo.pl
Useless use of string in void context at hobo.pl line 6116.


Tja line 6116 in hobo.pl ist

    log 1, "copy $fName $root/$restoreDir/$fName failed:$!";
und ich bin mir jetzt relativ sicher, dass man da nicht den Logarithmus berechnen will. Aus der POSIX Doku:

Zitat
log
This is identical to Perl's builtin log() function, returning the natural (e-based) logarithm of the numerical argument, see log.

Der Witz ist also, dass man nicht nur ein falsches Keyword erwischt hat, man hat eine "einfach mal so importierte" POSIX Funktion erwischt, die sich noch nicht einmal beschwert, wenn das zweite Argument ein String ist. Sobald man das eliminiert, beschwert sich dann der vormals übertünchte Perl log()-builtin.

use warnings; sei dank.


Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #1 am: 23 März 2020, 20:17:26 »
Das ist eventuell nur ein Typo.
Sollte bestimmt Log heißen
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
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5616
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #2 am: 23 März 2020, 20:27:28 »
Jo, wobei Richard mit POSIX schon Recht hat. Das sind imho einige hundert Funktionen.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #3 am: 23 März 2020, 20:48:45 »
Den Tippfehler habe ich behoben.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #4 am: 23 März 2020, 21:22:54 »
"nur ein Typo" verkennt die eigentliche Tiefe des Problems. Aber ich bin ja froh maximal zur Qualitätssteigerung beigetragen zu haben.

edit:

mit lediglich

use POSIX                     qw(getuid setuid
                                 strftime
                                 EAGAIN EINVAL EWOULDBLOCK );

bekomme ich den Server ans Laufen. Und man hat ein use POSIX einmal oben (diese uses mitten im Code sind ja eh die Pest).

Ein grep auf den Source fördert (ganz ohne tamtam) aber gar schröckliches zu Tage: "use POSIX;" soweit das Auge reicht.

« Letzte Änderung: 23 März 2020, 22:11:02 von RichardCZ »

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3562
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #5 am: 24 März 2020, 08:13:18 »
"use POSIX;" soweit das Auge reicht.
Wenn das so verwerflich ist , kann dann mal jemand das Problem in ein Beispiel fassen damit auch ein Kreissklassen Modulautor der eigentlich nur vom abschreiben bei anderen lebt das auch "richtig" umsetzen kann ?

Wie ich es bis jetzt verstanden habe :
1. man wirft in seinem Modulen ersteinmal am Anfang das use POSIX ganz raus.
2. man schaut wo es anschliessend Gemecker gibt, zb. bei my $test = hanswilli('blablub');hanswilli ist nun unbekannt, also ersetze ich den Aufruf durch
$test = POSIX::hanswilli('blablub'); ?
3. wenn ich viele solcher Stellen im Modul habe bleibe ich bei der alten Form ersetze aber das einfache use POSIX am Anfang durch use POSIX qw(hanswilli wasauchimmer ); ?   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10834
  • eigentlich eher "user" wie "developer"
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #6 am: 24 März 2020, 09:02:49 »
...würde mich auch interessieren, habe grade mal geschaut, ob ich den WeekdayTimer "verbessern" kann (so das denn Sinn macht (?))...

ABER: Soweit mein begrenztes Verständnis reicht, ist das nicht ganz so einfach, weil ja der Namespace gerade nicht irgendwie gekapselt wird. Es reicht doch aus, wenn ein Modul, (das nicht einen eigenen Namespace eröffnet) irgendwo das "allgemeine" use POSIX verwendet (also auch fhem.pl selbst), dann kann man es "überall" verwenden, oder nicht? Aber selbst wenn man es in fhem.pl begrenzen würde: 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 (?). 
Andererseits: auch der POSIX::-Aufruf setzt voraus, dass das Modul geladen ist (?)...

Und: wären wir andersrum auch davor gefeit, dass plötzlich Module Probleme verursachen, die bisher ohne Mucken liefen, wenn man jetzt POSIX-Funktionen in fhem.pl begrenzt?

Ergo: _Wenn_ es Sinn macht, da was zu tun, und das obige auch nur halbwegs sachlich richtig ist, wird das sehr lange noch "Nachwirkungen" haben, wenn wir das nicht gründlichst machen..., 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}

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #7 am: 24 März 2020, 09:06:59 »
Deswegen bin ich ja schon seit Monaten dabei Euch zu bitten mit packages zu arbeiten. Einige Entwickler mit neuen Modulen konnte ich schon dazu anregen.
 ;D


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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #8 am: 24 März 2020, 09:16:02 »
Zitat
mit lediglich ... bekomme ich den Server ans Laufen
Das ist nicht sehr aussagekraeftig, um sicher zu sein muessen alle Module und alle Codeschnipsel in notify/at/DOIF/etc geprueft werden. Ich will damit nicht sagen, dass ich froh ueber "use POSIX" bin, aber ich nehme z.Zt. kein akutes Problem wahr, und bin zuversichtlich konkrete Probleme zu verursachen, wenn ich was aendere.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3562
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #9 am: 24 März 2020, 09:27:10 »
Deswegen bin ich ja schon seit Monaten dabei Euch zu bitten mit packages zu arbeiten.
aber da stellt sich doch die gleiche Frage , wie man POSIX einsetzt ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #10 am: 24 März 2020, 09:33:06 »
Wie ich es bis jetzt verstanden habe :
1. man wirft in seinem Modulen ersteinmal am Anfang das use POSIX ganz raus.
2. man schaut wo es anschliessend Gemecker gibt, zb. bei my $test = hanswilli('blablub');hanswilli ist nun unbekannt, also ersetze ich den Aufruf durch
$test = POSIX::hanswilli('blablub'); ?
3. wenn ich viele solcher Stellen im Modul habe bleibe ich bei der alten Form ersetze aber das einfache use POSIX am Anfang durch use POSIX qw(hanswilli wasauchimmer ); ?   

Ja, anders habe ich es auch nicht gemacht. Wobei ich dann diese POSIX::xxx eben durch use POSIX qw(xxx) ersetzt habe.
Aber ehrlich gesagt ist da der explizite Aufruf vermutlich sogar noch besser wenn sich die Anzahl der POSIX AUfrufe pro File in Grenzen hält.

@Rudolf: Das übliche "wenn ich was ändere fliegt mir alles um die Ohren" Argument kenne ich ja jetzt, ich stimme sogar (aus eigener Erfahrung) zu, aber das ist ein Korsett, das Dich früher oder später erdrücken wird.  Ich gehe jetzt in meinem Repo den Extremweg: Ultra-progressiv, im Zweifelsfall interessieren mich alte Zöpfe nicht.

Da kann ich mir das erlauben, der einzige Nutzer bin ja wohl ich.

Ich sehe aber schon relativ deutlich (und hatte eigentlich die Hoffnung Du auch), dass ich auf diesem Weg Probleme aufdecke, die "euch" verborgen bleiben. Und so ist es doch auch. Diese

"so lange es kein aktues Problem gibt"
"ist nur ein Typo"

Aussagen sind - sorry - Selbstbetrug. FHEM hat akute Probleme, nur will man das nicht sehen.

"Ach deswegen habe ich so unerklärliches Verhalten..." (HMCCU min/max)

Im Grunde genommen habe ich den Eindruck, man sagt "So lange der Server läuft ist nix akut".
Wenn ich dann sage "Mein Server läuft", dann heißt es aber plötzlich "das sagt noch lange nix". Ist doch Schizo.  ???

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #11 am: 24 März 2020, 09:44:01 »
Zitat
...der main Namespace in FHEM ja ziemlich überfüllt ist...
Ich habe keine belastbare Ursachenstatisktiken parat, aber in den 13 Jahren Support fuer FHEM erinnere ich mich an genau ein Problem, dessen Ursache namespace-collision war, und das Problem hat weniger als eine Stunde Aufwand fuer alle zusammen gekostet.

Zitat
Und über die daraus resultierende grenzwertige Wartbarkeit...
Da ich davon ausgehe, dass deine Erfahrung mit FHEM-Support begrenzter ist, halte ich diese Aussage fuer polemisch.

Ich will damit nicht sagen, dass ich keine Probleme behebe, aber Aufwand/Nutzen muss im Rahmen bleiben. Ich kenne das Gefuehl, einen grossen, nicht selbstgebauten Software vor sich zu haben, und alles besser machen zu wollen, weil man gute Gruende dafuer hat. Aber ich kann inzwischen die Position der anderen Seite verstehen.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3562
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #12 am: 24 März 2020, 09:45:39 »
Wenn man hier ne Weile dabei ist und schon so manchen Teufelskreis live miterlebt hat kann ich Rudis Haltung gut nachvollziehen.
( Ich habe selbst Schiss meine MAX Beta Module via commit auf alle lozulassen :) )
@RichardCZ, ist es nicht einfacher statt von oben nach unten das Problem von unten nach oben anzugehen ?
Sprich zuerst kommen die Modulautoren, die kennen ihre Module und können i.d.R. auch sehr gut testen ( z.B. weil die Hardware vorhanden ist )
   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher
Zustimmung Zustimmung x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #13 am: 24 März 2020, 09:59:46 »
Ich habe keine belastbare Ursachenstatisktiken parat, aber in den 13 Jahren Support fuer FHEM erinnere ich mich an genau ein Problem, dessen Ursache namespace-collision war, und das Problem hat weniger als eine Stunde Aufwand fuer alle zusammen gekostet.

Das ist interessant, denn in den letzten 7 Tagen habe ich 2 NS-collisions aufgezeigt. (min/max & log). Ob man die nun "typo" oder "hach ich dachte das ist was anderes" nennt ist egal.

Zitat
Da ich davon ausgehe, dass deine Erfahrung mit FHEM-Support begrenzter ist, halte ich diese Aussage fuer polemisch.

Meine Erfahrung mit FHEM Support ist nicht vorhanden. Es ist jetzt aber nicht so, dass ich keine Erfahrung mit Systemen hätte die eine breite Installationsbasis in der Produktion haben. Überleg' Dir mal was es für eine Linux Distribution bedeutet wenn "plötzlich" 500 000 Leute updaten.

Hunderte neuere Versionen von Applikationen, Readmes, etc. Hobbyanwender klopfen das irgendwie hin, "Profi-Umgebungen" haben ihre Admins
die sich vorab informieren, testen und kümmern.

* Development: stable (release tag) und progressive (trunk) branches, für die ganz wilden Cowboys auch mal ne experimental-branch
* Deployment: /opt/fhem

$ ll
total 16
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 6.0
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 7.1
lrwxrwxrwx 1 fhem fhem    3 Mar 24 09:55 active -> 7.1
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 r25744
drwxr-xr-x 2 fhem fhem 4096 Mar 24 09:54 r27833


/opt/fhem/active wäre das neue Zuhause, bei Bedarf schaltet man mal um, sieht was einem im Xicht explodiert und schaltet wieder zurück.
Ach so, vielleicht geht das in Windows nicht/anders. Nicht mein Problem.  ;)

Ne - ehrlich, ist denn irgendwo definiert was man sich alles "antun will"? Ich lese "bei all den OS, Perl, MOdul"-Kombinationen. Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16352
  • s/fhem\.cfg/configDB/g
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #14 am: 24 März 2020, 10:21:27 »
so langsam nervt mich diese Klugscheißerei...
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #15 am: 24 März 2020, 10:25:07 »
so langsam nervt mich diese Klugscheißerei...

Das ist schon in Ordnung. Da wir beide echte Männer sind, wirst Du mit der Klugscheißerei genauso gut zurechtkommen wie ich mit der Ignoranz.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5616
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #16 am: 24 März 2020, 10:34:30 »
...
Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?
...
Kann ich für mich beantworten: ich versuche das zu supporten was bei den usern vorhanden ist - soweit das möglich ist.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #17 am: 24 März 2020, 10:42:45 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.
Ich würde aber auch erstmal den Weg gehen die Modulautoren an zu sprechen. Eben von unten nach oben arbeiten.
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
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16352
  • s/fhem\.cfg/configDB/g
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #18 am: 24 März 2020, 10:51:38 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.

Das finde ich auch grundsätzlich gut.

Aber bitte nicht auf die hier praktizierte Art und Weise, dass man einer großen Gemeinschaft von Entwicklern versucht einzureden, sie hätten in den vergangenen 13 Jahren alles falsch gemacht, was falschzumachen ging. Und genau so empfinde ich das im Moment.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #19 am: 24 März 2020, 11:05:44 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.
Ich würde aber auch erstmal den Weg gehen die Modulautoren an zu sprechen. Eben von unten nach oben arbeiten.

Klar - warum nicht? Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".

Aber dann muss man sich auch über Folgendes im Klaren sein:

Das gegenwärtige Entwicklungsmodell "jeder Modulautor/Maintainer ist für sein Modul verantwortlich" ist auf der einen Seite verständlich - wer will schon Support/Verantwortung für ein Modul übernehmen wenn ihm einer von der Seite reingrätscht - es bürdet aber auch den Modulautoren eine größere Last auf, denn dann ist eigentlich jeder für den gesamten vertikalen Stack des Moduls (Funktionalität, Fehlerfreiheit, Support, Security, ...) verantwortlich. Das ist wesentlich mehr als üblich ist.

Auf der anderen Seite blockiert man dann "Leute wie mich" die horizontal über den Code gehen (Für alle Module: xxx). Für jemanden, der z.B. Security, oder coding Guidelines oder Effizienz auf der Fahne hat, ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".

Ergo: Bottom-Up Vorgehensweise über die Modulautoren, bin ich dafür, aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".

Dann kann man gleich ein Board "Security" und "Effizienz" aufmachen. Bei Effizienz kann ich auch noch ein wenig mitreden, bei Security gibt es definitiv bessere Spinner als mich.

Und ja, @betateilchen:

Es wurde definitiv nicht alles falsch gemacht in den letzten 13 Jahren. FHEM funktioniert ja.
Aber es gibt viele Probleme und nach 13 Jahren, 500 Modulen und xxx Autoren ist man vor so Dingen wie "Projektblindheit" nicht nur nich gefeit, man ist dafür geradezu anfällig.

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1203
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #20 am: 24 März 2020, 11:14:57 »
Ne - ehrlich, ist denn irgendwo definiert was man sich alles "antun will"? Ich lese "bei all den OS, Perl, MOdul"-Kombinationen. Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?
Laut Statistik gibt es noch Perl-Installationen bis runter zu 5.10, wobei das gerade mal je 5 Installationen mit 5.10 und 5.12 sind.

Da gibt es wohl auch noch etliche Raspis, die seit Jahren unverändert mit alten OS laufen:
  • Wheezy: 5.14 (299 Installationen)
  • Jessie: 5.20 (894)
  • Stretch: 5.24 (2139)
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #21 am: 24 März 2020, 11:25:13 »
Klar - warum nicht? Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".

Aber dann muss man sich auch über Folgendes im Klaren sein:

Das gegenwärtige Entwicklungsmodell "jeder Modulautor/Maintainer ist für sein Modul verantwortlich" ist auf der einen Seite verständlich - wer will schon Support/Verantwortung für ein Modul übernehmen wenn ihm einer von der Seite reingrätscht - es bürdet aber auch den Modulautoren eine größere Last auf, denn dann ist eigentlich jeder für den gesamten vertikalen Stack des Moduls (Funktionalität, Fehlerfreiheit, Support, Security, ...) verantwortlich. Das ist wesentlich mehr als üblich ist.

Auf der anderen Seite blockiert man dann "Leute wie mich" die horizontal über den Code gehen (Für alle Module: xxx). Für jemanden, der z.B. Security, oder coding Guidelines oder Effizienz auf der Fahne hat, ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".

Ergo: Bottom-Up Vorgehensweise über die Modulautoren, bin ich dafür, aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".

Dann kann man gleich ein Board "Security" und "Effizienz" aufmachen. Bei Effizienz kann ich auch noch ein wenig mitreden, bei Security gibt es definitiv bessere Spinner als mich.

Und ja, @betateilchen:

Es wurde definitiv nicht alles falsch gemacht in den letzten 13 Jahren. FHEM funktioniert ja.
Aber es gibt viele Probleme und nach 13 Jahren, 500 Modulen und xxx Autoren ist man vor so Dingen wie "Projektblindheit" nicht nur nich gefeit, man ist dafür geradezu anfällig.

Ich denke mal was Deine Arbeit in Form von Empfehlungen an geht ist klar das da keine diffs nötig sind. Du musst aber auch damit leben das einige Autoren sagen werden interessiert mich nicht. Ist dann halt so.
Ansonsten liegt es an jedem Autor selbst Deine Empfehlungen um zu setzen.
Die Idee mit dem zusätzlichen Board finde ich gut. Das ständige PM schreiben ist anstrengend und nicht sehr transparent für die anderen.



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://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #22 am: 24 März 2020, 11:32:39 »
Zitat
Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".
Ich habe damit kein Problem, will aber nicht ganz alleine entscheiden => bitte kommentieren.
Ich bin auf die Reaktion der Autoren auf die Aenderungen gespannt, und noch skeptisch.

Das gegenwertige Entwicklungsmodell ist das Resultat von (schiefgelaufenen) Experimenten, wie alles ein Kompromiss, nicht problemlos, aber ich will auch nichts daran aendern: mir ist ein potentieller Fehler im Modul lieber, als ein verwaistes Modul. Keine Regel ohne Ausnahme: z.Bsp. habe ich bestimmte Code-Tags in der Doku nach angemessene Wartezeit selbst korrigiert.

@mahowi: die Zahlen aus den Statistiken sind nach meiner Erfahrung etwa mit 4 zu multiplizieren, um die Gesamtzahl zu erhalten. Die Fehlerrate ist bei kleinen Werten hoch, und was Gesamtzahl bedeutet (installiert aber brauche ich nicht mehr oder mein Leben haengt davon ab) ist schwammig.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #23 am: 24 März 2020, 11:34:05 »
Kann ich für mich beantworten: ich versuche das zu supporten was bei den usern vorhanden ist - soweit das möglich ist.

Das ist natürlich eine geradezu übermenschliche Serviceeinstellung.

Aber da auch Deine Resourcen nicht unendlich sind... siehe die Statistiken auf die mahowi erinnert hat:

Über 99% (99,08%) der Installationen sind Linux. Wegen dem 1% sollte man sich nicht zurückhalten lassen.
Und das tut man, wenn man das in die Kombinatorik (alle Kombinationen von OS, Perl, Modulversion, ...) einfliessen lässt

Wenn man ein wenig flexibel ist, kann man auch noch die MacOS und *BSD Leute in Boot nehmen.
Die 0.5% Windows User... Sorry. 6.x last version for you.

Perl Version. 5.10+ ... na wenigstens etwas. defined-or und named captures. Hurra!
Ab 5.24 wurde Perl erheblich schneller
Ab 5.28.1 gibt es - derzeit - keine bekannten Security Bugs.

edit:

Für Windows user schlage ich folgende Migrationspfade vor:

1) https://docs.microsoft.com/en-us/windows/wsl/install-win10

"Windows Subsystem for Linux". Das ist praktisch ein Linux - aus Programmsicht sowieso. Mit ganz ganz wenigen Einschränkungen. Man kann z.B. nicht direkt die GPU aus WSL ansprechen (PCI-pass through) und ähnliche Speckwürfel. Für FHEM sind die Einschränkungen irrelevant.

2) Cygwin (https://www.cygwin.com/)

Ähnlich, aber älter. Ich lese gerade die Perldeltas im Detail durch und sehe, dass Cygwin support mindestens in Perl 5.16 nochmal auf Vordermann gebracht wurde.

=> Selbst die paar wenigen Unglücklichen, die Windows haben und behalten wollen, müssen nicht komplett im Regen stehengelassen werden.
« Letzte Änderung: 24 März 2020, 15:04:58 von RichardCZ »

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3970
    • Meine Seite im fhemwiki
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #24 am: 24 März 2020, 16:39:35 »
Das ist natürlich eine geradezu übermenschliche Serviceeinstellung.

Aber da auch Deine Resourcen nicht unendlich sind... siehe die Statistiken auf die mahowi erinnert hat:

Über 99% (99,08%) der Installationen sind Linux. Wegen dem 1% sollte man sich nicht zurückhalten lassen.
Und das tut man, wenn man das in die Kombinatorik (alle Kombinationen von OS, Perl, Modulversion, ...) einfliessen lässt

Wenn man ein wenig flexibel ist, kann man auch noch die MacOS und *BSD Leute in Boot nehmen.
Die 0.5% Windows User... Sorry. 6.x last version for you.


Nö!

Ich bin ganz bei herrmannj - wenn ich helfen kann frage ich nur nach der perl- oder os-version um mehr Infos zu bekommen, ich will ohne zwingenden Grund niemanden zum Update oder gar zum Umstieg (!) überreden. 1% Benutzer anderer OS plötzlich auszugrenzen (warum eigentlich ?) wäre für mich komplett die falsche Richtung. Wenn jemand es auf CP/M zum laufen bekommen wollte, mach doch, oder auch zLinux - los doch.

Auf der anderen Seite wäre es wichtig zu modernisieren und auch kritische Stellen anzupacken - aber bitte nicht unter der Prämisse andere abzuschrecken oder auszugrenzen!
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3562
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #25 am: 24 März 2020, 16:48:37 »
ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".
--- snipp ---
aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".
a. erwarte ich gar, ich denke den meisten reicht eine einfache Info / Beschreibung wie jetzt hier bei POSIX
b. ich habe kein Problem damit irgendwo etwas abzuholen, dafür muß ich aber erst einmal wissen das es überhaupt etwas zum Abholen gibt.
Ob es dann in einem meiner Fällel zutrifft sehe ich dann ja schon, d.h. bringen muß mir niemand etwas, sondern lediglich einigermaßen verständlich das Problem schildern. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #26 am: 24 März 2020, 18:01:05 »
Nö!

Ich bin ganz bei herrmannj - wenn ich helfen kann frage ich nur nach der perl- oder os-version um mehr Infos zu bekommen, ich will ohne zwingenden Grund niemanden zum Update oder gar zum Umstieg (!) überreden. 1% Benutzer anderer OS plötzlich auszugrenzen (warum eigentlich ?) wäre für mich komplett die falsche Richtung. Wenn jemand es auf CP/M zum laufen bekommen wollte, mach doch, oder auch zLinux - los doch.

Versuch' es doch mal andersherum zu sehen. Du bremst 99% der Leute aus, weil Du das 1% Minderheit "nicht enttäuschen willst".
Man kann es noch heftiger sehen. Angenommen man fühlt sich ihnen verpflichtet und sie wissen das, dann sind diese 1% lethargischen Updatemuffel eigentlich Egoisten, die an Entwicklerkapazitäten und "verpasstem Fortschritt für den Rest" schmarotzen.

Ich formuliere es bewusst wenig diplomatisch um auch mal ne andere Sichtweise zu präsentieren.

Und für dieses 1% hast Du dann 20% Aufwand.  Gefühlt (hallo Herrmann) eher mehr, weil Du den Aufwand gar nicht realisiert bekommst (Du bekommst von dem 1% auch nicht die Tests etc.)

Die Frage "warum eigentlich?" bestimmten Support fallenzulassen zeugt von Unkenntnis der ganzen Diskussion der letzten 4 von mir geöffneten Threads - oder von schlechtem Gedächtnis.

Es gibt hier weder die Kapazitäten, noch die Skills, noch den Willen CP/M, zOS, BeOS, Hurd, etc. Support zu realisieren. Ist komplett illusorisch. Ich sagte ja, ich lese mir gerade im Detail die perldeltas durch. Da steht bei 5.16 z.B.

Platforms with no supporting programmers
These platforms will probably have their special build support removed during the 5.17.0 development series.

BeOS
djgpp
dgux
EPOC
MPE/iX
Rhapsody
UTS
VM/ESA


Bada Bum. Das ist ganz normal Leute. Früher gab es bei Supercomputern auch noch Windows, Schaut euch die Top500 Liste heute an. Support wird auch in Open Source Umgebungen fallengelassen - nicht nur in kommerziellen Umgebungen - wenn Kosten/Nutzen jenseits von gut und böse sind..

Und dieses "da bin ich ganz bei Herrmann". Hermann ist derjenige, der ziemlich schnell zur Stelle ist wenn es darum geht zu zeigen wie aufwändig doch jede Codeänderung ist, weil das ja einen irre Rattenschwanz an Tests und Validierungen in allen möglichen Umgebungen nach sich zieht. Ziehen würde. Den man ja nicht mal so eben hinbekommt. Also macht man am besten nix.

Zitat
Auf der anderen Seite wäre es wichtig zu modernisieren und auch kritische Stellen anzupacken - aber bitte nicht unter der Prämisse andere abzuschrecken oder auszugrenzen!

Das ist das "wasch mich aber mach mich nicht nass", was ich schon recht zu Beginn mal hier fallengelassen habe.


Deine empfundene richtige Richtung "los doch, mach doch" geht nur unter der Prämisse, dass die FHEM Community plötzlich 20-30 perlporter-cracks aus dem Hut zaubert. Leute, die es einfach nicht real-existierend gibt.

Der Unterschied besteht offensichtlich darin, was man als "zwingenden Grund" sieht. Keiner wird zur Modernisierung seiner Infra gezwungen. Aber keiner kann doch erwarten, dass seine ungewartete Uralt-Infra bis zum St. Nimmerleinstag supported wird.

Wer halt noch ein Windows mit Perl 5.10 betreibt - fein - aber dann ist für den halt eine FHEM 6.x die letzte Version. Er muss ja nicht updaten - er kriegt halt dann nix neueres mehr.

---

Aber ok, diese ganze Diskussion geht komplett am eigentlichen Thema vorbei, Momentan würde es mir ja schon reichen, wenn ich helfen könnte den Perl code von FHEM vom Niveau "Jahrtausendwende" aufs Niveau 2007 zu hieven. Das Abschneiden alter Zöpfe war eigentlich nur ein Vorschlag um den Entwicklern die Füße von ein paar Ketten mit Eisenkugeln dran freizumachen.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5616
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #27 am: 24 März 2020, 18:13:41 »
Zitat
Gefühlt (hallo Herrmann) eher mehr
Hallo Richard :)

Nein, eigentlich nicht. Ich versuche(!) beim Design bereits darauf zu achten dass ich keine Abhängigkeiten habe und das ich Konstrukte vermeide von denen ich annehmen kann das sie systemspezifisch sind.

Dogmatisch geht das sowieso nicht: bei einem aktuellen Modul "muss" ich 5.18 voraussetzen. Warum? Ich habe zu spät gemerkt das "lexical sub" erst ab 5.18 funktionieren. Hätte ich es früher erkannt dann hätte ich das anders geschrieben und "nu isses eben so" :)

Dann kommen trotzdem die Perl-Versionsspezifischen-Sonderlocken: https://forum.fhem.de/index.php/topic,109413.msg1034136.html#msg1034136

Problem? Nö. Hab's gefixt. Hätte natürlich auch einfach 5.24 vorschrieben können - aber warum sollte ich ? So sind alle happy.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #28 am: 24 März 2020, 18:38:26 »
Problem? Nö. Hab's gefixt. Hätte natürlich auch einfach 5.24 vorschrieben können - aber warum sollte ich ? So sind alle happy.

Naja. Ich bin so happy mit dem Code nicht. Ein bedingtes Morphium-Pflaster sehe ich jetzt nicht als "Fix".

Aber kein Problem - ich werde damit psychisch schon irgendwie fertig.  ;)

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5616
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #29 am: 24 März 2020, 18:52:20 »
Naja. Ich bin so happy mit dem Code nicht. Ein bedingtes Morphium-Pflaster sehe ich jetzt nicht als "Fix".
Wenn man das besser machen kann (ohne Einschränkungen zu produzieren;)) bin ich für alles offen.
Zitat
Aber kein Problem - ich werde damit psychisch schon irgendwie fertig.  ;)
so siehts aus ;)
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
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
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
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: 22522
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: 16352
  • 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.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
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?

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3388
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: 16352
  • 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.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
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
  • Full Member
  • ****
  • Beiträge: 109
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
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
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
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
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: 10834
  • 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}

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
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
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #45 am: 25 März 2020, 12:28:38 »
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.

FHEM läuft, es gibt keine Bugmeldungen und wir sitzen fast alle zu Hause. Wenn nicht jetzt wann dann  :)
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
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #46 am: 25 März 2020, 13:49:59 »
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.

Wenn Du ein Hausdach mit 3500 Dachziegeln bedecken musst, dann gilt für Dachzeigel D1 bis Dachziegel D3500 die folgende Regel:

Es regnet nicht ins Haus <=> D1 && D2 && D3 ... && D3500 korrekt auf dem Dach liegen.

Wenn Du jetzt der Ansicht bist, das Legen von jedem einzelnen Dachziegel sei eine NOP, dann kannste ja bei Dir auf dem Dach einige wegmachen...  ::)


Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3970
    • Meine Seite im fhemwiki
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #47 am: 25 März 2020, 20:20:06 »
Ich formuliere es bewusst wenig diplomatisch um auch mal ne andere Sichtweise zu präsentieren.


Ja und ich muss zugeben, das stört mich zu sehr - deshalb lasse ich die anderen Punkte mal unerwidert ohne damit Akzeptanz auszudrücken

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können