Autor Thema: Perl Readonly / Debian  (Gelesen 8608 mal)

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4501
Perl Readonly / Debian
« am: 30 April 2020, 19:55:04 »
Readonly wird vermutlich bei dem meisten direkt verfügbar sein, trotzdem gibt es für Debian/Raspbian noch ein extra Paket :
Zitat
libconst-fast-perl

facility for creating read-only scalars, arrays, and hashes

Const::Fast is a perl module for creating read-only scalars, arrays, and hashes. It enables you to set a variable to the given value and subsequently make it readonly. Arrays and hashes will be made deeply readonly.
This module uses the builtin readonly feature of perl, making access to the variables just as fast as any normal variable without the weird side-effects of ties.

Vllt kann ja Richard was Genaues zu "weird side-effects of ties" sagen. IMHO hatte ich da gestern auch einen Abschnitt in deutsch der darauf Bezug nahm, finde ihn nun leider nicht mehr.
« Letzte Änderung: 30 April 2020, 19:57:04 von Wzut »
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1207
Antw:Perl Readonly / Debian
« Antwort #1 am: 30 April 2020, 22:03:01 »
Readonly gehört übrigens leider auch nicht zum Core, wie ich eigentlich vermutet hatte. Für Debian muß man das Paket libreadonly-perl installieren.
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

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #2 am: 30 April 2020, 22:08:23 »
Readonly wird vermutlich bei dem meisten direkt verfügbar sein, trotzdem gibt es für Debian/Raspbian noch ein extra Paket :
Vllt kann ja Richard was Genaues zu "weird side-effects of ties" sagen. IMHO hatte ich da gestern auch einen Abschnitt in deutsch der darauf Bezug nahm, finde ihn nun leider nicht mehr.

Richard würde Readonly nehmen und "weird side-effects of ties" in einer Doku, die 2013 das letzte Mal aktualisiert wurde, nicht so viel Gewicht beimessen.
Das bedeutet nicht, dass Richard keinen Respekt vor Leon Timmermans hätte und den gemeinsam getrunkenen Mengen an Bier kein Gewicht beimessen würde.

Es ist natürlich im FHEM-Kontext ein ziemlich häretisches Konzept, aber 2013 ist jetzt auch schon ne Weile her.

Readonly mit installiertem Readonly::XS ist die beste Lösung AFAIK, wobei man mit dem Pure-Perl Readonly zwar langsamer fährt (*) aber für den Code ist das transparent (man macht immer nur "use Readonly;"). Jetzt noch ein Fass mit einem anderen Modul aufmachen fände ich kontraproduktiv.

Die Tatsache, dass aber Readonly/Readonly::XS nicht zum CORE gehört ist allerdings sehr bitter.

(*) für FHEM-Belange immer noch mehr als schnell genug.

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #3 am: 30 April 2020, 23:27:42 »
Die Tatsache, dass aber Readonly/Readonly::XS nicht zum CORE gehört ist allerdings sehr bitter.

Weil das debian Paket für readonly nicht als Anbängigkeit im FHEM Paket enthalten ist, scheue ich mich noch ein wenig vor dem Einsatz.
 

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3532
Antw:Perl Readonly / Debian
« Antwort #4 am: 01 Mai 2020, 00:40:51 »
Weil das debian Paket für readonly nicht als Anbängigkeit im FHEM Paket enthalten ist, scheue ich mich noch ein wenig vor dem Einsatz.
 

Grüße Sidey
Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #5 am: 01 Mai 2020, 09:15:47 »
Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...

Das sind schon interessante Entscheidungsprozesse hier...

Hätte man da nicht einfach betateilchen, oder wer auch immer für die Debian-Pakete verantwortlich ist, fragen können?
Also ich bin zumindest gewohnt, dass man in einem Team zusammenarbeitet und nicht nebeneinander her.

Ok, ich knicke Debian-Paketierung für HoBo ohnehin komplett
https://gl.petatech.eu/root/HomeBot/-/commit/3495444f06b3587b00fcba0dd26c51c5641bb701
-> https://appimage.org/

Aber in meinem 1-Mann Team reicht es ja wenn ich Selbstgespräche führe.

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3750
    • HMCCU
Antw:Perl Readonly / Debian
« Antwort #6 am: 01 Mai 2020, 10:02:38 »
Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...

Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.

Es soll ja Leute geben, die FHEM auf Nicht-Debian-Systemen betreiben (andere Linux Derivate, MacOS oder sogar Windows). Als FHEM Nutzer sollte man wissen, wie man eventuell fehlende Module nachinstalliert.

Auch unter Debian kann man z.B. cpan verwenden, um Module zu installieren. Es muss also nicht zwingend das lib/deb Paket sein.
« Letzte Änderung: 01 Mai 2020, 10:09:11 von zap »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #7 am: 01 Mai 2020, 10:09:34 »
Hi RichardCZ,

Du hast schon Recht, ich könnte fragen.
Dafür ist es aber sicher interessant, ob das dann auch mehrere nutzen oder ob ich der einzigste bin.

Bei dem Update Vorgehen bringt das aber der installierten Basis leider recht wenig, denn die machen ja ein Fhem Update mit dem Ergebnis, dass das Modul bestenfalls eine Meldung im Log hinterlässt, wieso es jetzt nicht mehr funktioniert und dass man doch bitte das Readonly Modul installiert.

Möchte man seine Anwender nicht mehr strapazieren, als unbedingt nötig, kann man auch erst einmal nur diese Warnung ausgeben und alles so belassen wie es ist.

Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.

Ich bin der Meinung, wenn jemand das Debian Paket installiert, dann sollten alle Abhängigkeiten die für die Funktion notwendig sind auch mit installiert werden.
Alle die auf anderen Wegen installieren, die haben ohnehin viel Handarbeit dir durch die META Daten etwas durchsichtiger werden :)

Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #8 am: 01 Mai 2020, 10:39:34 »
Möchte man seine Anwender nicht mehr strapazieren, als unbedingt nötig, kann man auch erst einmal nur diese Warnung ausgeben und alles so belassen wie es ist.

Weisst Du eigentlich warum so ein Steak aus Argentinien oder Uruguay so gut ist?
Weil da hinter der Herde Rindviecher unermüdlich ein paar Gauchos herreiten und diese vor sich treiben.

Man kann natürlich immer "alles so belassen wie es ist", aber dann muss man auch mit Kommentaren wie diesem hier leben

https://blindfuchs.de/smarthome/91-openhab2-smarthome-findungsphase

Zitat
FHEM war leider ein ähnlich negatives Erlebnis. Während die Verbindung mit den Komponenten problemlos funktionierte und eine Übersicht über diese einfach und zielführend geboten wurde, fehlten mir die interessanten weiteren Möglichkeiten. Die Basis von FHEM war deutlich in die Jahre gekommen, die Unterstützung für weitere Komponenten nur schwach, eine schicke Bedienoberfläche suchte man vergebens und - und das ist der entscheidende Teil - die Möglichkeiten komplexere Automatisierungsregeln zu definieren, waren bescheiden. Kurz gesagt, FHEM konnte meine Anforderungen nicht erfüllen.

Und das war 2017 (eine Situation aus 2014 beschreibend). Nun könnte natürlich der FHEM e.V. eine Sonderkommission gründen, die das mal ausdiskutiert und zu dem Schluss kommt, dass das ja alles nicht stimmt (oder man lässt den asdasd-Geheimagenten auf die Kommentare los), aber mir dünkt, dass davon FHEM nicht besser wird.

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3532
Antw:Perl Readonly / Debian
« Antwort #9 am: 01 Mai 2020, 10:51:40 »
Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.
Habe mich falsch ausgedrückt. Mir ging es generell um die Nachinstallation. Egal ob lib oder cpan. Ich persönlich halte den Nutzen von Readonly für eher überschaubar und es gibt Alternativen im Core.


Kurz, weil mobil....
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24130
Antw:Perl Readonly / Debian
« Antwort #10 am: 01 Mai 2020, 11:05:20 »
Verstehe ich den Vergleich richtig: Die Programmierer (als Gauchos) muessen die Benutzer (als Rindviecher) unermuedlich vor sich hertreiben, damit sie richtig gut werden?

Vermutlich sehe ich noch nicht das grosse Bild, deswegen interessiert mich, welche der o.g. Kritikpunkte das Zwingen des Benutzers zum Nachinstallieren dieses Perl-Moduls loest.


Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #11 am: 01 Mai 2020, 11:53:57 »
Verstehe ich den Vergleich richtig: Die Programmierer (als Gauchos) muessen die Benutzer (als Rindviecher) unermuedlich vor sich hertreiben, damit sie richtig gut werden?

Das kann man so verstehen. Ich hätte natürlich auch den Vergleich mit dem Kobe-Steak bringen können, bei denen sich Phasen von Aktivität mit Phasen von Faulheit abwechseln und so für eine Fleisch/Fett Marmorierung sorgen, die auch ganz gut ist - Geschmacksfrage. Man könnte es auch in der ersten Ableitung so verstehen, dass ich der Gaucho bin und das Blut der Entwickler in Wallung bringe.  ;)

Unterm Schlussstrich bleibt die Erkenntnis, dass ein Open-Source Projekt auf Userseite nicht nur ein Nehmen, sondern auch ein Geben sein sollte.
Was hat ein OSS Projekt von Usern, die nur kostenlos nehmen, am besten nix (oder so wenig wie möglich) machen wollen und maulen ("muuuh") wenn
sie mal ein wenig traben sollen? Oder maulen ("muuuh!"), wenn das veralternde Projekt bestimmte Features nicht bietet?
Das ist doch - für die Entwickler! - wieder so eine schachmatt Situation. In der ist FHEM - derzeit - immer noch.

Zitat
Vermutlich sehe ich noch nicht das grosse Bild, deswegen interessiert mich, welche der o.g. Kritikpunkte das Zwingen des Benutzers zum Nachinstallieren dieses Perl-Moduls loest.

Ja, die Abstraktionsfähigkeit könnte besser sein, dann würde man
  • sich von dieser konkreten Situation mit diesem konkreten Perl Modul lösen und darüber nachdenken wie man beim Update ein Modul zum User bekommt
  • allgemein die Denke "da ist eine Mauer da kann ich nicht durch oder muss irgendwie aussen rum" durch "muss da die Mauer sein?" ersetzen

Ich bin tatsächlich der Ansicht, dass sich die Geschwindigkeit der Herde nicht den Langsamsten, sondern der Mehrheit anzupassen hat. Die Langsamsten beissen bekanntlich die Hunde bzw. fressen die Löwen. Ein bischen Schwund ist immer. Im Gegenzug schliessen sich starke Individuen auch lieber einer gesunden Herde als einer tristen Population an - sagt National Geographic.

Ich bringe solche Sachen nur deswegen derart süffisant (und nehme in Kauf, dass das jemanden nervt), weil mich dieses "welche der o.g. Kritikpunkte ... loest das konkret?" ebenfalls stark nervt. Genauso gut könnte man auch fragen "Welchen Schalter müssen wir konkret umlegen um das Sonnensystem zu besiedeln?". Da schwingt für mich eine Menge Kurzsichtigkeit mit.

@Rudolf: Präsentier' doch mal - spaßeshalber - ne Roadmap für FHEM.



Und damit wir mal wieder zum Konkreten zurückkehren: Readonly ist ein Perl-only Modul

https://metacpan.org/source/SANKO/Readonly-2.05/lib/Readonly.pm

das könnte man mitliefern. ("muss da die Mauer sein?")
Dann tut das für den User. Wenn er es noch besser will, wird er sich Readonly::XS installieren.

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #12 am: 01 Mai 2020, 17:06:11 »
An das mit ausliefern von Perl Modulen habe ich auch schon mehrmals gedacht.
Aktuell ist es ja leider immer ein Hemmschuh ein Modul von CPAN zu nehmen, weil es manuell installiert werden muss.

Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

So wie ich das einschätzen sind da zwei Dinge zu klären:
1. Lizenzbedingungen
2. Maintainer Frage

Ich hatte ja auch vor einiger Zeit vorgeschlagen, dass wir das Update Modul anpassen, so dass man Verweise auf andere Installationsquellen einbauen kann.
Leider hielt sich die Begeisterung in Grenzen und der Patch verweilt derzeit auf meiner Platte.

Durch das Nachladen würde ich annehmen, dass es einfacher ist die jeweiligen Lizenzbedingungen des CPAN Modules einhalten zu können. Die Maintainer Frage stellt sich dann auch nicht, weil es so nicht im SVN hinterlegt werden müsste. :)

Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa

Offline Icinger

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1395
Antw:Perl Readonly / Debian
« Antwort #13 am: 01 Mai 2020, 17:42:41 »
Zitat
Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

Wenn die Module richtig gewartet sind, könnte das Installer-Modul ja das Nachinstallieren von CPAN übernehmen.

Müsste man halt
1) Die Meta-Daten der Module pflegen
2) Sicherstellen, dass bei der ersten Definition eines Moduls der Installer drüberschaut, ob vlt. etwas noch zu installieren ist.

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #14 am: 01 Mai 2020, 17:47:20 »
Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

Deswegen ich ja mit GLeichnis "Warum muss die Mauer da sein?", weil Rudolf explizit gesagt hat, im Repo
sollen keine CPAN Module sein.

Es ist ja auch nicht schwarzweiß das Ganze:

1. Einige Module können wir nicht mitliefern, weil die erstmal compiliert werden müssten.
2. Irgendjemand muss das ja dann auch warten, sonst haben "wir" im Repo eine Asbach-Uralt


ad 1) Dann eben nur Perl-only, besser als nix
ad 2) Habe ich euch eigentlich schon die Geschichte von den Janitors erzählt?

 

decade-submarginal