Bugproblematik bei 10_CUL_HM.pm

[CoolTux]

https://forum.fhem.de/index.php/topic,79858.0.html

Wie kann man hier am besten verfahren? Martin wurde wohl bereits informiert, dennoch tut sich nichts trotz einer Kleinigkeit.
Welche möglichkeiten, ausser Patch bei Martin einreichen, haben die anderen Developer um die User zu unterstützen?



Grüße

[rudolfkoenig]

Mir faellt ein:
- Immer wieder auf das Problem hinweisen und warten.
- Alternativmodul schreiben.

Selbst sein Modul zu Patchen ist keine Option.

[CoolTux]

Danke Dir Rudi

[Hauswart]

Selbst sein Modul zu Patchen ist keine Option.

Du sprichst hier von Patchen und via SVN verteilen? Gegen Patchen und via Thread verteilen ist in Ordnung? Siehe: https://forum.fhem.de/index.php/topic,79858.msg720176.html#msg720176

[CoolTux]

Du sprichst hier von Patchen und via SVN verteilen? Gegen Patchen und via Thread verteilen ist in Ordnung? Siehe: https://forum.fhem.de/index.php/topic,79858.msg720176.html#msg720176

Meine Meinung. Ich finde es ok. Das Problem ist das ich finde das das (man eine Menge das) File nach Bereinigung des Problemes wieder entfernt werden sollte.

[Thorsten Pferdekaemper]

Hi,
erst einmal vorweg: Ich bin ein Verfechter des "strengen Code-Ownership". D.h. für jedes Stückchen Coding gibt es einen "Oberboss", der im Endeffekt das Sagen hat.
Aaaaber:
Es kann gut sein, dass derjenige mal krank ist, vom Auto überfahren wird oder ohne Handy im australischen Outback wandert. In dem Fall finde ich es auch nicht ganz richtig, wenn man das ganze Modul neu schreiben müsste. Da sollten wir schon, zumindest bei Sachen, die ganz klar ein Fehler sind (wie hier), auch in "fremdem" Coding einen Fix einbauen können. Es ist mir auch klar, dass jemand anders nicht immer wissen kann, was eigentlich die Intention des betreffenden Codings war, aber ein erfahrener Entwickler wird trotzdem in den meisten Fallen etwas machen können.
Natürlich muss darüber der eigentliche Maintainer immer so gut es geht informiert werden und das sollte auch nicht leichtfertig gemacht werden. Andererseits ist aber auch blöd, wenn man bei einem so wichtigen Modul wie 10_CUL_HM.pm irgendwelche Umgehungslösungen braucht, damit es überhaupt läuft.

Längerfristig könnte ich mir vorstellen, dass jeder Maintainer einen "Vize-Maintainer" ernennt.

Gruß,
    Thorsten 

[herrmannj]

Vorschlag:

Jemand (namentlich) übernimmt die Prozess und macht:

- Info am Martin, PM und Mail
- letzte funktionierende version im SVN wieder herstellen.

- Martin macht das dann heil sobald er die Chance dazu hat.

Wir haben alle ein rl !

[betateilchen]

Da ich im Homematic-Thread die Lösung ja schon identifiziert habe, kann ich das gerne übernehmen:

• martin anschreiben
• funktionierendes Modul mit bugfix des aktuellen Problems als interims-Lösung einchecken, bis martin das selbst korrigiert hat

[herrmannj]

perfekt. Danke.

[Thorsten Pferdekaemper]

Da ich im Thread die Lösung ja schon identifiziert habe, kann ich das gerne übernehmen:

Ich bin auch dafür.
Gruß,
   Thorsten

[betateilchen]

kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...

[CoolTux]

Vorschlag:

Jemand (namentlich) übernimmt die Prozess und macht:

- Info am Martin, PM und Mail
- letzte funktionierende version im SVN wieder herstellen.

- Martin macht das dann heil sobald er die Chance dazu hat.

Wir haben alle ein rl !

In diesem Fall wäre ein Roolback etwas suboptimal. Laut dem Comment waren einige wichtige Bugfixes dabei. Daher würde hier wohl ein fix, zu mal es nur um ein Wort geht, besser angebracht.

Ich kann mich an Martin per PN wenden (Mail ist aktuell mir nicht bekannt, kann aber mal schauen) und einen fix im SVN bereit stellen.

Meinungen dazu?

Sorry hat Udo seinen Post übersehen.

[CoolTux]

kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...

Vielleicht erstmal ne kleine Mahnung in Worte einbringen das man sich doch bitte am Thema halten soll.

[herrmannj]

kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...

done

[betateilchen]

Danke.

Der bugfix ist eingecheckt. Falls Rudi Lust und Zeit findet, könnte er vielleicht heute nochmal ein update generieren, damit den Anwendern schnell geholfen werden kann.

[Hauswart]

• martin anschreiben
• funktionierendes Modul mit bugfix des aktuellen Problems als interims-Lösung einchecken, bis martin das selbst korrigiert hat

Ist das nun die offizielle Herangehensweise?

[betateilchen]

Wir reden hier über eine Ausnahmesituation.
Die beiden Punkte sind inzwischen beide erledigt.

[dev0]

Ist das nun die offizielle Herangehensweise?

Ich würde nicht versuchen das zu generalisieren, es kommt einfach auf den Einzelfall an. Aber _ich_ würde mich darüber freuen, wenn Kollegen eingreifen, wenn ein Problem auftritt und ich nicht "erreichbar" bin.

[herrmannj]

Ich würde nicht versuchen das zu generalisieren, es kommt einfach auf den Einzelfall an. Aber _ich_ würde mich darüber freuen, wenn Kollegen eingreifen, wenn ich ein Problem auftritt und ich nicht "erreichbar" bin.

dito

[rudolfkoenig]

Es kann gut sein, dass derjenige mal krank ist, vom Auto überfahren wird oder ohne Handy im australischen Outback wandert.

Klar, und sowas haben wir laufend. Im ersten und im letzten Fall apelliere ich an die Geduld der Benutzer.
Fuer den zweiten Fall gibt es den Regel: Autor anschreiben, und falls nach 3 Wochen keine Antowrt, dann ist das Modul verweist, ich verwalte es kommissarisch solange, bis jemand "hier" schreit, danach ist dieser der neue Maintainer. Wer vor hat laenger als 3 Wochen krank zu sein, oder im australischen Outback rumzuwandern, der sollte einen Stellvertreter ernennen oder einfach darauf Hinweisen, damit wir geduldiger sind.

Der bugfix ist eingecheckt.

Ich hoffe das bleibt eine einmalige Ausnahme. Sonst sehe ich die Gefahr von Leuten, die es gut meinen, aber den Code oder die Absichten des Autors nicht ganz verstehen, und durch die Aenderung nur die Arbeit des Autors erschweren.

Falls Rudi Lust und Zeit findet, könnte er vielleicht heute nochmal ein update generieren, damit den Anwendern schnell geholfen werden kann.

Das habe ich gemacht.

Zum Problem: ich verstehe die Aufregung noch nicht: soweit ich es sehe, geht es um eine Warnung, und nicht mehr.

[betateilchen]

Zum Problem: ich verstehe die Aufregung noch nicht: soweit ich es sehe, geht es um eine Warnung, und nicht mehr.

Nein, es geht nicht um eine Warnung, es geht um einen harten Abbruch, der das Laden des Moduls verhindert. Damit funktionieren keinerlei Homematic Komponenten mehr.

Ich hoffe das bleibt eine einmalige Ausnahme.

Keine Sorge, in der Zeit, die ich jetzt mit FHEM zu tun habe, habe ich sowas zum zweiten Mal gemacht. Und ich mache sowas nicht leichtfertig, sondern nur, wenn ich wirklich genau verstanden habe, was das Problem ist und ich auch genau weiß, dass die Änderung das tut, was beabsichtigt ist. Im vorliegenden Fall eine Änderung im Verhalten von perl, die auf perldoc genau beschrieben ist - inklusive der neuen Vorgehensweise als Lösung.

Aber ich wollte nicht drei Wochen warten, da die Anzahl der Problemmeldungen immer größer wurde

[Thorsten Pferdekaemper]

Nein, es geht nicht um eine Warnung, es geht um einen harten Abbruch, der das Laden des Moduls verhindert. Damit funktionieren keinerlei Homematic Komponenten mehr.

Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.
Gruß,
   Thorsten

[betateilchen]

Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.

Das hatte ich ja bereits an anderer Stelle genau so beschrieben

[Thorsten Pferdekaemper]

Das hatte ich ja bereits an anderer Stelle genau so beschrieben

Das ist mir durchaus bekannt, ich war nur zu faul, es herauszusuchen.
Gruß,
   Thorsten

[herrmannj]

Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.
Gruß,
   Thorsten

Bei aktuellen perl Versionen knallt es.

Das bedeutet(e) konkret:
wenn ein user mit aktueller perl version ein von uns ausdrücklich empfohlenes, regelmaßiges fhem update macht funktionieren danach HM Komponenten nicht mehr.

https://perldoc.perl.org/functions/defined.html

Use of defined on aggregates (hashes and arrays) is no longer supported. It used to report whether memory for that aggregate had ever been allocated. You should instead use a simple test for size:

Das stellt deutlich mehr als nur eine Warnung dar.

edit: soweit ich sehe lässt sich "aktuell" auf >= 5.12 legen. Wenn  das stimmt wäre das 2010

[Thorsten Pferdekaemper]

ein von uns ausdrücklich empfohlenes, regelmaßiges fhem update

Echt? Wo wird das empfohlen? Ich mache auf meinem Produktivsystem etwa einmal im Jahr (höchstens) ein FHEM update. Das wäre auch meine Empfehlung bei einem ansonsten gut laufenden System.
Gruß,
   Thorsten

[herrmannj]

Echt? Wo wird das empfohlen? Ich mache auf meinem Produktivsystem etwa einmal im Jahr (höchstens) ein FHEM update. Das wäre auch meine Empfehlung bei einem ansonsten gut laufenden System.
Gruß,
   Thorsten

Naja, jeder der im forum um Hilfe bittet der wird recht zügig darauf angesprochen: System aktuell, update gemacht ?

[CoolTux]

Macht ja auch Sinn. Ich würde selbst mein Produktivsystem nicht 365 Tage alt lassen. Einmal im Monat kommt ein Update. Dafür wird vorher im Forum gestöbert und auf einem Testsystem die groben Dinge durchlaufen welche man testen kann.

[betateilchen]

Geht jetzt hier die gleiche sinnlose Diskussion los wie im ursprünglichen Problem-Thread?

[betateilchen]

edit: soweit ich sehe lässt sich "aktuell" auf >= 5.12 legen. Wenn  das stimmt wäre das 2010

Ich habe hier eine produktive FHEM Installation mit perl 5.20.2 die völlig problemlos läuft und bei der es NICHT knallt.

[Thorsten Pferdekaemper]

Naja, jeder der im forum um Hilfe bittet der wird recht zügig darauf angesprochen: System aktuell, update gemacht ?

Ok, wenn was nicht klappt, dann sollte man natürlich erst einmal sicher stellen, dass man nicht auf einen alten Fehler gerannt ist. Das ist klar.

Macht ja auch Sinn. Ich würde selbst mein Produktivsystem nicht 365 Tage alt lassen. Einmal im Monat kommt ein Update. Dafür wird vorher im Forum gestöbert und auf einem Testsystem die groben Dinge durchlaufen welche man testen kann.

Ich mache das eher umgekehrt. So lange alles stabil läuft lasse ich es so, wie es ist. Im Forum gestöbert wird eh ständig und wenn mal was wichtiges hochkommt (z.B. sicherheitsrelevant), dann kommt ein update.

Geht jetzt hier die gleiche sinnlose Diskussion los wie im ursprünglichen Problem-Thread?

Wieso sinnlos? Off-topic vielleicht, aber meiner Meinung nach nicht sinnlos.

Ich habe hier eine produktive FHEM Installation mit perl 5.20.2 die völlig problemlos läuft und bei der es NICHT knallt.

Hier zwar nicht produktiv, aber Perl v5.22.1 und es knallt. 10_CUL_HM.pm wird überhaupt nicht geladen. Wenn ich mir das Coding aber scharf anschaue, kann ich mir vorstellen, dass das vom "expert" Attribut abhängt. Wenn man niemals irgendwas mit einem gesetzten Bit 3 (etwa 8, 12, 251) hat, dann knallt es wohl eh nicht.

Gruß,
   Thorsten

[betateilchen]

Hier zwar nicht produktiv, aber Perl v5.22.1 und es knallt. 10_CUL_HM.pm wird überhaupt nicht geladen. Wenn ich mir das Coding aber scharf anschaue, kann ich mir vorstellen, dass das vom "expert" Attribut abhängt.

Das wäre aber ein anderes Problem als das, worum es im aktuellen Fall ging. Die betroffene und gestern angepasste Stelle hatte was mit templates zu tun, nicht mit Attributen.

[Thorsten Pferdekaemper]

Das wäre aber ein anderes Problem als das, worum es im aktuellen Fall ging. Die betroffene und gestern angepasste Stelle hatte was mit templates zu tun, nicht mit Attributen.

Beides, würde ich sagen. Wenn Bit 3 des Attributs expert gesetzt ist, dann passiert irgendwas mit Templates, soweit ich das verstehe.
Gruß,
   Thorsten

[betateilchen]

ok, dann habe ich Deinen vorletzten Beitrag falsch interpretiert. Das Bit3 selbst ist nicht das Problem, sondern das, was passiert, wenn Bit3 gesetzt ist Dann passt ja alles wieder.

Das gestern eingecheckte Modul sollte sich aber auch bei Dir laden lassen, selbst wenn Bit3 gesetzt ist.

[Thorsten Pferdekaemper]

Das gestern eingecheckte Modul sollte sich aber auch bei Dir laden lassen, selbst wenn Bit3 gesetzt ist.

Ja, das funktioniert.
...zumindest an der Stelle. Dummerweise erzeugen die BlockingCalls unter Windows Probleme, aber das interessiert nicht wirklich sooo sehr, da das für mich nur ein Spielsystem ist.
Gruß,
   Thorsten

[betateilchen]

Martin hat heute eine neue Modulversion eingecheckt, die neben der gestrigen ad-hoc Lösung auch noch weitere Änderungen enthält.

Insofern dürfte das Thema nun auch "offiziell" erledigt sein.