Autor Thema: Perl Readonly / Debian  (Gelesen 8607 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?

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #15 am: 01 Mai 2020, 18:52:20 »
2. Irgendjemand muss das ja dann auch warten, sonst haben "wir" im Repo eine Asbach-Uralt

Da würde ich bestimmt zu tendieren einmal im Monat die letzte Version aus der Quelle zu laden. Das mit 1x im Monat ist einfach aus dem Bauch heraus so gesagt.
Wobei ein brauchbares Interface aus FHEM heaus würde meiner Ansicht nach auch ausreichen. Die Idee das über das META Modul zu machen gefällt mir auch und über den Update Befehl könnten prinzipiell auch vorhandene CPAN Module mit aktualisiert werden.

Es gibt ja sogar Schnittstellen, die man einbinden könnte, ob sich da auch ein Zielverzeichnis angeben lässt habe ich nicht näher untersucht.
https://metacpan.org/pod/CPAN

Wenn der Wille da ist, wird sich auch sicher ein Weg finden.

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 #16 am: 01 Mai 2020, 19:23:12 »
Es gibt ja sogar Schnittstellen, die man einbinden könnte, ob sich da auch ein Zielverzeichnis angeben lässt habe ich nicht näher untersucht.
https://metacpan.org/pod/CPAN

Wenn der Wille da ist, wird sich auch sicher ein Weg finden.

$ ./updatecheck
File                                                         Local       CPAN
Hash::Case                                                    1.03       1.05
Hash::Case::Lower                                             1.03       1.05
Hash::Case::Preserve                                          1.03       1.05
Hash::Case::Upper                                             1.03       1.05


Ist jetzt leider Firmencode, kann den also nicht hier komplett abladen, aber auch nicht Hexerei, nutzt im Wesentlichen CPAN.

   find(\&_find_package_names, "$path/");   # Recursive checking for .pm files results storing in %$packages
...
    for my $module (@$list) {                                         # inspect all modules in dir
        for my $mod (CPAN::Shell->expand('Module', $module)) {        # expands submodules
            next if ($mod->uptodate());                               # no need to update -> check next

            my $name = $mod->id();
            my $installed = (!defined $mod->inst_version || $mod->inst_version eq 'undef') ? next : $mod->inst_version;
            my $available = (!defined $mod->cpan_version || $mod->cpan_version eq 'undef') ? '-'  : $mod->cpan_version;

            push @$updates, [$name, $installed, $available];
        }
    }

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4501
Antw:Perl Readonly / Debian
« Antwort #17 am: 02 Mai 2020, 07:59:14 »
oh je da habe ich ja wieder was angefangen ... mir ist nicht in Erinnerung auf meinem Test Rapi extra was mit Readonly installiert zu haben.
Da es aus dem Stand aber ging bin ich davon ausgegangen das es fester Bestandteil einer normalen Debian/Raspbian Installation ist und dieses Zusatzpaket ein Problem fixt.
Anyway ich kann es verstehen das man sich die Mühe machen muß ein CPAN Modul extra zu installieren wenn dessen Funktion zwingend für das Modul erforderlich ist und man es nicht mit ein paar Zeilen Code nachbilden kann. Beispiel war früher mal Net::SIP , das was da mit wheezy ausgeliefert wurde war nicht zu gebrauchen. D.h. wollte der User das Modul nutzen musste er wohl oder übel sich eine aktuelle Version holen. Wer mag kann ja mal im FB Unterforum suchen was das für die Mehrheit der User für ein Drama war.

Aber back to Topic : wenn Readonly so rausfällt bleibt ja doch noch der Weg via use constant in eine ähnliche Richtung zu gehen. Oder sehe ich hier wieder etwas falsch ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #18 am: 02 Mai 2020, 08:29:01 »
Man wird vielleicht gemerkt haben, dass ich in einigen Belangen ruhiger geworden bin, weil mich mittlerweile viele Sachen in FHEM nicht mehr per se aufregen, sondern ich einfach nur noch mit dem Kopf schüttele. Abgesehen davon habe ich ja mein HoBo-Ventil.

1) Man lege in der Projektroot ein Verzeichnis "lib" an.
2) in fhem.pl füge man dem use lib '.'; noch ein use lib 'lib'; hinzu
3) man kopiere einfach Readonly.pm nach lib und füge beides dem Repo hinzu
4) man füge dieses Verzeichnis in filelist von fhemupdate.pl mit ein

fertig.

Eventuell kann man das auch mit anderen Modulen machen:

https://gl.petatech.eu/root/HomeBot/-/tree/master/lib

optional könnte man dann auch die FHEM/lib Zombies updaten und nach lib ziehen.
und ganz eventuell kann man auch gleich ein t Verzeichnis nebendran legen und mal anfangen da was reinzuschreiben.

Zitate aus Glückskeksen zum Beispiel.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #19 am: 02 Mai 2020, 14:04:31 »
Tia, ein Lösungswege ist aufgezeigt.

Das ganze lässt sich auch noch ausbauen.

Nun die Spannende Frage.
Fügen wir CPAN Module unter gewissen Bedingungen so ein?
Ich hätte da durchaus noch weitere Vorschläge, was sich anbieten würde.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #20 am: 03 Mai 2020, 00:01:28 »
Der ein oder andere hat ja schon bemerkt, dass ich bei Buienradar in den neueren Versionen Readonly verwende. Ich finde es nicht zu viel verlangt, die README und/oder Release-Notes zum Modul zu lesen bevor man es einbindet und sich selbst einen Weg - wenn man cpan / cpanm nicht nutzen möchte und / oder das Debian nicht nutzen kann oder möchte - sucht wie man Readonly an den Start bekommt. Wo genau hört eigentlich die Veratwortung für eine Installationsbasis für einen Modul-Maintainer auf bzw. wo fängt sie an?

Wenn sich jemand im Core dazu entscheidet, CPAN-Pakete mit auszuliefern fände ich das auch völlig opportun und dann sollte es halt einen Maintainer/Janitor für sowas geben (Integrations-/Regressionstests wären auch nett). Ich wette, es wäre eh keine besonders lange Liste und wir würden vielleicht ein paar Redundanzen in den Modulen los.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4501
Antw:Perl Readonly / Debian
« Antwort #21 am: 03 Mai 2020, 07:16:23 »
@CM, wenn ich ein neues Modul schreibe und den Leuten sage "dafür müsst ihr aber Wzut::Blub  von CPAN installieren" werden die User das auch ohne Murren tun.
Wenn ich aber ein ein seit Jahren benutzes Modul " nur" update und von heute auf morgen wird  Wzut::Blub fällig dann wird das Geschrei groß sein.
Frei nach dem Motto "wieso , es lief doch jetzt bei mir seit Jahren und plötzlich muß ich alles ändern .....  Ich bin kein Linux Experte ... wo gibt es eine Schritt für Schritt Anleitung .... die Installation via CPAN schlägt bei mir fehl ....." Sucht euch was davon aus, IMHO haben wir das alle (Richard ausgenommen) hier schon genau so in der einen oder anderen Form so erlebt. Und wie Rudi darüber denkt CPAN Module auf den SVN zu packen sollte auch bekannt sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #22 am: 03 Mai 2020, 12:50:00 »
@CM, wenn ich ein neues Modul schreibe und den Leuten sage "dafür müsst ihr aber Wzut::Blub  von CPAN installieren" werden die User das auch ohne Murren tun.
Wenn ich aber ein ein seit Jahren benutzes Modul " nur" update und von heute auf morgen wird  Wzut::Blub fällig dann wird das Geschrei groß sein.

Ja mag sein, aber irgendwann muss man halt auch mal alte Zöpfe abschneiden. Um das zu mitigieren gibt es Versionierung, d.h. ein User kann sich entscheiden, dass er z.B. bei 2.0 ohne Readonly bleibt, bekommt dann halt aber auch die tollen neuen BarCharts oder Bugfixes nicht. Oh, das geht bei FHEM Core nicht ohne Verrenkungen mit exclude, Kopierorgien oder Pflege eines Parallel-Repositories oder was auch immer? Pity, dann macht man halt kein update mehr und alles bleibt alt.

Und wie Rudi darüber denkt CPAN Module auf den SVN zu packen sollte auch bekannt sein.

Das Resultat aus dieser Argumentation ist, dass man jede Menge Code (ggf. minderwertig) dupliziert um jemand kein cpanm Readonly zuzumuten. Finde ich einen schlechte Deal, auch für die User.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #23 am: 03 Mai 2020, 13:52:14 »
Ich bin da ganz der Meinung von WZut.

Es ist Anwender Unfreundlich wenn nach einem Update auf einmal der Kram nicht mehr geht.
Wer hätte das noch nicht, Sonntags noch schnell ein Update gemacht und am nächsten Tag wundert man sich, dass auf einmal keine Jalousien mehr fahren.
Das muss ja nicht so sein.

Wenn man als Entwickler die Anwender schonend vorbereiten möchte, kann man erst mal Warnung ausgeben oder featurelevel versenden. Denn wenn man es schlecht macht, kann Fhem sogar crashen.

Und wieso? Weil es a) keine Option gibt einfach ein CPAN Modul dem Anwender zur Verfügung zu stellen und b) auch keine Option akzeptiert wurde, im Update Prozess Referenzen einzupflegen.

Ich verstehe halt nicht, was dagegen spricht so ein cpan Modul bei Bedarf mit zu installieren.
Und wenn es gute Gründe gibt, es nicht ins SVN zu legen, dann lege ich ein git Repo an und lade benötigt cpan Module dort ab.
Ein kleiner Patch im Update.pm und die Module würden dann automatisch von dort aktualisiert werden.
Meinetwegen kann man es auch über META .PM laufen lassen.

Bevor ich hier Zeit investiere, hätte ich aber gerne ein paar Informationen unter welchen Bedingungen der Patch eine Chance hat.


Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

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

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #24 am: 03 Mai 2020, 14:22:57 »
Es ist Anwender Unfreundlich wenn nach einem Update auf einmal der Kram nicht mehr geht.
Wer hätte das noch nicht, Sonntags noch schnell ein Update gemacht und am nächsten Tag wundert man sich, dass auf einmal keine Jalousien mehr fahren.
Das muss ja nicht so sein.

"Sonntags noch schnell ein Update" ist halt eine sehr sehr risikobehaftete Update-Strategie, insbesondere wenn die Frau quängelt, wenn sie morgens dann im Dunklen sitzt und kein Licht mehr wie erwartet schaltet. Zumal man das bei einem ordentlichen Versionierungssystem einfach umgehen kann, in dem man halt ein fixes Release abonniert, wenn man überhaupt kein Risiko eingehen will bzw. manuell ein höheres Release auswählt. Meine Versionierungsstrategie stellt sicher, dass sowas wie "Readonly" nur in einem Major-Release geändert wird. Schaut euch mal Semantic versioning an.

ceterum censeo wäre es mir aber auch recht, wenn man einfach sagen könnte: Ok, BR will in 3.0 nun Readonly, JSON und Foobaz, also referenziere ich das in der Controls und FHEM sorgt dann dafür, dass Readonly, JSON und Foobaz auf dem System landet. Jeder der Perl hat, hat auch cpan.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24130
Antw:Perl Readonly / Debian
« Antwort #25 am: 03 Mai 2020, 14:52:26 »
Zitat
Jeder der Perl hat, hat auch cpan.
Aber nicht unbedingt einen (dazu passenden) Compiler, und manche bevorzugen Perl-Module ueber OS-Pakete.
Gibt es eine Moeglichkeit aus dem Perl-Modulnamen den OS-Paketnamen zu berechnen?

Idealerweise laeuft das so ab:
- vor dem ersten Definieren eines Moduls prueft FHEM, ob alle CPAN-Module vorhanden sind, und installiert diese auf Benutzer-Aufforderung.
- update warnt, falls neue Abhaengigkeiten fuer verwendete Module existieren, und installiert sie auf Benutzer-Aufforderung, alternativ setzt sie das Modul auf ignoreList oder verweigert das update (je nachdem, ob das alte Modul noch kompatibel mit dem Rest ist).
- Modul-Installation laeuft entweder ueber CPAN oder ueber OS-Paket, jenachdem, was der Benutzer spezifiert hat.
- es gibt eine Moeglichkeit fuer update der CPAN-Pakete
- Pluspunkte gibt es fuer optionale Pakete, z.Bsp. wenn ein Calendar-Modul auch SAP abfragen kann, falls man das passende Perl-Modul installiert hat, was aber SAP-Bibliotheken benoetigt, und 99.9% der Anwender nicht braucht.

Das fehlerfrei fuer mehrere Betriebsysteme zu implementieren ist eine Herausforderung, ich erinnere mich noch an meinem Versuch mit cpan IO::Socket::SSL mit dem richtigen(!) openssl Bibliothek zu installieren.

Ich bin bereit optionale Hooks fuer LoadModule und update einzubauen, wenn irgendwer meint, die Aufgabe implementieren _und_ supporten zu koennen.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #26 am: 03 Mai 2020, 15:54:05 »
Das fehlerfrei fuer mehrere Betriebsysteme zu implementieren ist eine Herausforderung,

Ich zappel schon seit gestern das wenigstens distri-unabhängig für Linux hinzubekommen. (AppImage)

Mittlerweile bin ich vom 100sten ins 1000ste gekommen: https://gl.petatech.eu/root/linuxdeploy-plugin-perl

Wenn das klappt, dann sollte die Sache zumindest für Linux gegessen sein. Also alles. Perl-Version, Module, optionale Binaries...
Wird dann zwar ein riesiger Blob, aber bis 100MB wäre es das wert - denke ich.

Wenn man das dann für x86 und ARM hat (wobei ein halbes Königreich für den, der mir zeigt wie ich unter Proxmox eine "RasPi-VM" aufsetze), sollte das reichen.

Stand Perl-only, 20MB ist also noch etwas Luft.

20M May  3 15:43 linuxdeploy-plugin-perl-x86_64.AppImage


Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #27 am: 03 Mai 2020, 22:15:11 »
$ HomeBot-x86_64.AppImage
Can't locate HoBo.pm in @INC (you may need to install the HoBo module) .....


Mittlerweile bin ich für die Wiedereinführung von Menschenopfern, aber ja, es geht langsam vorwärts.

41M May  3 22:12 HomeBot-x86_64.AppImage

Perl + Projektsourcen/Daten 41MB


Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5855
Antw:Perl Readonly / Debian
« Antwort #28 am: 03 Mai 2020, 22:38:55 »
Richard, verstehe ich das richtig dass du einen installer für cpan Module schreibst der distri unabhängig cpan Module beim Benutzer, ohne Benutzereingriff installiert? Wenn ja, finde ich wertvoll! Muss aber rocking solid und bulletproof sein. Linux Recht imho

smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #29 am: 03 Mai 2020, 22:41:55 »
Richard, verstehe ich das richtig dass du einen installer für cpan Module schreibst der distri unabhängig cpan Module beim Benutzer, ohne Benutzereingriff installiert? Wenn ja, finde ich wertvoll! Muss aber rocking solid und bulletproof sein. Linux Recht imho

Ne - selber schreiben ... so wahnsinnig bin ich auch wieder nicht.

Ich versuche einen real existierenden anzuwenden: https://appimage.org/


Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5855
Antw:Perl Readonly / Debian
« Antwort #30 am: 03 Mai 2020, 22:45:43 »
Naja, wenn wir mal aus dem NoCpan Tal Rauswollen braucht es einen Installer der dem normalo User das nachinstallieren abnimmt.wenn du einmal dabei bis, kannst du das dahingehend erweitern?
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #31 am: 03 Mai 2020, 22:56:04 »
Naja, wenn wir mal aus dem NoCpan Tal Rauswollen braucht es einen Installer der dem normalo User das nachinstallieren abnimmt.wenn du einmal dabei bis, kannst du das dahingehend erweitern?

Ich habe für mich zwei "Kanäle":

1) Für den DAU

AppImage = Alles in einer Datei (ist eigentlich ein komprimiertes FUSE filesystem)

Der User lädt einen ~ 50MB Blob herunter und startet ihn. Da ist alles drin - distri unabhängig.
Updates überlege ich mir, wenn ich erstmal ein funktionierendes AppImage hinbekomme.
Das ist sozusagen mein .deb Ersatz.

2) Für den Profi

siehe https://gl.petatech.eu/root/HomeBot/-/blob/master/README.md#how-do-i-install-it

Ich versuche erstmal ohne CPAN Module auszukommen, also CPAN außerhalb des eigenen lib Verzeichnisses,
habe aber einige CPAN Module im eigenen Repository. (https://gl.petatech.eu/root/HomeBot/-/tree/master/lib)

> make update

und sollte tun.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5855
Antw:Perl Readonly / Debian
« Antwort #32 am: 03 Mai 2020, 23:07:55 »
Ja genau. Dem DAU müssen wir da aber unter die Arme greifen. Nachinstallieren und deinstallieren ist da wichtig, genautwie Rollback und Recovery im Fehlerfall. Ist das appimage denn da der richtige Weg? Was ist mit perlbrew Usern?
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #33 am: 04 Mai 2020, 00:11:16 »
Ich bin der Ansicht, dass jemand, der nur bereit ist einen DAU-Level zu investieren, keinen Anspruch auf Nach- & Deinstallation hat.
Der bekommt ein fertig geschnürtes Paket, das kann viel, vermutlich mehr als er nutzt und einiges davon bleibt halt ungenutzt.
Soviel Platz ist auch auf einem RasPi.

Wenn der irgendwann mal was neueres will ., holt er sich wieder ein fertig geschnürtes Paket.

Zu sagen DAU & fein granulare Installation/Deinstallation passt nicht zusammen IMHO.

Ich will das mal als Release-Format für HoBo testen. Wen njemand HoBo ausprobieren mag, holt er sich genau eine Datei und startet die.
Wenn's tut - gut. Wenn nicht - ist sein System nicht vollgekleistert mit irgendwas. Und er braucht weder Docker, noch LXC noch VMs.

Offline SCMP77

  • Developer
  • Full Member
  • ****
  • Beiträge: 135
    • GitHub SolvisSmartHomeServer
Antw:Perl Readonly / Debian
« Antwort #34 am: 04 Mai 2020, 01:18:02 »
Warum muss man sich eigentlich von Perl::Critic so gängeln lassen?

Der constant-Ausdruck ist doch fast genauso geeignet. Soweit ich weiß, ist das einzige, was damit nicht beherrscht wird, ist die Substitution in Strings oder gibt es noch etwas anderes?

Wenn man definiert hat:

Zitat
use constant NAME=> 'Tut nichts zur Sache';

Muss man dann bei der Verwendung in einem String so etwas schreiben:

Zitat
my $text = 'Der Name lautet: '.NAME

Würde man ein ReadOnly verwenden könnte man schreiben:

Zitat
my $text = "Der Name lautet: $NAME"

Oder gibt es noch andere Vorteile?
Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht

Offline Sidey

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2590
Antw:Perl Readonly / Debian
« Antwort #35 am: 04 Mai 2020, 08:15:04 »
Hi,

Klar kann man Cobstant verwenden.
Das geht schon.

Die Diskussion ist doch mittlerweile eher, wie wir die Hürde senken cpan Module zu verwenden.

Readonly ist doch eher ein Beispiel.

Gruß 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 #36 am: 04 Mai 2020, 08:50:26 »
Warum muss man sich eigentlich von Perl::Critic so gängeln lassen?

PBP 55-58

Müssen tut man nicht müssen.
Zwingt Dich ja auch keiner täglich Zähne zu putzen, aber wenn Du's nicht tust, wird das irgendwann Folgen haben.
PBP sagt auch, dass "use constant" besser ist als nix. Du kannst zur Mundhygiene auch auf Zimt rumkauen.

"There's more than one way to do it"

Zitat
Der constant-Ausdruck ist doch fast genauso geeignet. Soweit ich weiß, ist das einzige, was damit nicht beherrscht wird, ist die Substitution in Strings oder gibt es noch etwas anderes?

Das ist genau dann von Vorteil wenn man gelernt hat Interpolation (so der Fachausdruck) richtig anzuwenden.
Deine Interpolationsbeispiele sind halt der übliche FHEM Standard, da ist es schwer einen Vorteil zu sehen.
Wenn man seinem Concat-Operator-Fetisch frönt, dann ist es tatsächlich egal ob man irgendwo dazwischen
mal ein . CONSTANT . macht

    my $html;
    $html .= "<table>";
    $html .= "<tr><td><div class=\"devType\">$d</div></td></tr>";
    $html .= "<tr><td><table><tr><td>";
    $html .= "<div id=\"weekprofile.$d.header\">";
    $html .= "<table style=\"padding:0\">";
    $html .=
"<tr><td style=\"padding-right:0;padding-bottom:0\"><div id=\"weekprofile.menu.base\">";
    $html .= $editIcon . "&nbsp;" . $lnkDetails;
    $html .= "</div></td></tr></table></div>";
    $html .=
"<div class=\"fhemWidget\" informId=\"$d\" cmd=\"\" arg=\"$args\" current=\"$curr\" dev=\"$d\">"
      ;    # div tag to support inform updates
    $html .= "</div>";
    $html .= "</td></tr>";
    $html .= "</table>";
    $html .= "</td></tr></table>";
    return $html;

Ich bin aber dafür nach den if-elsif Bandwürmern auch die .= Bandwürmer und Zahnstocher-Syndrome zu entfernen.

    return << "EOHTML";
<table>
 <tr><td><div class="devType">$d</div></td></tr>
 <tr><td><table><tr><td>
 <div id="weekprofile.$d.header">
  <table style="padding:0">
   <tr><td style="padding-right:0;padding-bottom:0"><div id="weekprofile.menu.base">
    $editIcon&nbsp;$lnkDetails
 </div></td></tr></table></div>
 <div class="fhemWidget" informId="$d" cmd="" arg="$args" current="$curr" dev="$d">
 </div>
 </td></tr>
</table>
</td></tr></table>
EOHTML

Und in interpolierenden HEREDOCs haben "use constant" Konstanten leider keine Chance.
(eben weil es eigentlich Funktionsaufrufe sind)

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #37 am: 04 Mai 2020, 09:06:00 »
Warum muss man sich eigentlich von Perl::Critic so gängeln lassen?

Ich fühle mich von P::C nicht gegängelt, warum auch? Ich sehe P::C als eine in Software gegossene Ausgabe des PBP-Buches und das wiederum als Kondensat der Erfahrungen vieler Perl-Softwareentwickler, die garantiert besser Perl beherrschen als ich es bisher kann (aber man lernt ja, genau von dort). In PBP wird auf Seite 55 ff. auch der Rest zu dem Thema erklärt.

Mein Eindruck ist, dass ich weniger concat und sprintf mache und der Code allgemein kürzer (und damit auch hoffentlich weniger buggy) geworden ist. Ich nutze auch wieder mehr HEREDOC.

Offline SCMP77

  • Developer
  • Full Member
  • ****
  • Beiträge: 135
    • GitHub SolvisSmartHomeServer
Antw:Perl Readonly / Debian
« Antwort #38 am: 04 Mai 2020, 09:59:01 »
Meine Frage war eigentlich, warum ReadOnly anstelle von constant verwenden, welche Perl grundsätzlich ohne jegliches Modul nachladen beherrscht. Man verwendet constant ja meist, weil man numerische Konstanten im Header des Programmes oder in zentralen Dateien definieren will.

Ich will nicht auf einen Menschen mit vieilleicht hoher Perl-Erfahrung hingewiesen werden. Ich weiß, dass Perl::critic in Teilen durchaus sinnvoll ist. Aber man darf nicht vergessen, dieses Analyse spiegelt die Vorlieben einer Person oder einer kleinen Gruppe wieder.

Sollte meine  Frage bzgl. constant vs readonly dort wirklich auf S. 55 beschrieben worden sein, hilft mir Deine Antwort nicht weiter. Ich werde mit diesen Buch nicht kaufen, weil ich Perl nur notgedrungen benutzen muss (wegen FHEM), ich finde Perl furchtbar. Aber das ist auch nur meine persönliche Einschätzung (gewonnen aus 45 Jahren Programmiererfahrung).

Sicher kann ich constant trotzdem weiter verwenden, wenn ich hinter jedem constant-Ausdruck ein "#Violates" hinter setze. Dann kann ich die Fehler unterdrücken.

Erst bei einem überzeugenden Grund würde ich den Nachteil in Kauf nehmen, auf ein Modul zu setzen, was man u.U. erst nachinstalliern muss. Den habe ich aber bisher hier nicht lesen können.

Viele Grüße
  SCMP
Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht

Offline mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1207
Antw:Perl Readonly / Debian
« Antwort #39 am: 04 Mai 2020, 10:23:16 »
In einem der Threads in der Perl Ecke gab es einen Link, über den man sich PBP als PDF ansehen kann.
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 #40 am: 04 Mai 2020, 11:15:05 »
Sollte meine  Frage bzgl. constant vs readonly dort wirklich auf S. 55 beschrieben worden sein, hilft mir Deine Antwort nicht weiter. Ich werde mit diesen Buch nicht kaufen, weil ich Perl nur notgedrungen benutzen muss (wegen FHEM), ich finde Perl furchtbar. Aber das ist auch nur meine persönliche Einschätzung (gewonnen aus 45 Jahren Programmiererfahrung).

Worum geht es Dir? Nicht Perl benutzen zu müssen? Wenn Du willst, kann ich 73_SolvisClient.pm im HoBo Repository aufnehmen und dort maintainen (und ja - ohne Readonly). Dann schnappst Du Dir den Source von dort und kannst Du Dich voll und ganz Java widmen (was nach meiner Recherche auch ein wenig "Liebe" im SolvisSmartHome-Server gebrauchen könnte). Denn mit der Einstellung - muss ich sagen - ist es m.E. am besten wenn Du weder Perl::Critic, noch Readonly noch sonstwas benutzt.

Ich will natürlich 45 Jahre Programmiererfahrung nicht in Abrede stellen, insbesondere weil ich da noch 8 Jahre hin habe. Aber zumeist zählt das Ergebnis und nicht die Zeit.
Es stellt sich z.B. die Frage warum der Source auf GoogleDrive und nicht auf GitHub ist. Findest Du Git auch furchtbar?
Ich meine selbst die FHEM Führungsriege hat es mittlerweile schon von CVS zu SVN geschafft.

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #41 am: 04 Mai 2020, 13:08:41 »
Meine Frage war eigentlich, warum ReadOnly anstelle von constant verwenden, welche Perl grundsätzlich ohne jegliches Modul nachladen beherrscht. Man verwendet constant ja meist, weil man numerische Konstanten im Header des Programmes oder in zentralen Dateien definieren will.

Weil constant und ReadOnly halt nicht die gleichen Sachen machen. Hat Richard ja ausgeführt und ich hab dir die Quelle dazu genannt.

Ich will nicht auf einen Menschen mit vieilleicht hoher Perl-Erfahrung hingewiesen werden.

Was hast du gegen Leute mit Erfahrung?

Ich weiß, dass Perl::critic in Teilen durchaus sinnvoll ist. Aber man darf nicht vergessen, dieses Analyse spiegelt die Vorlieben einer Person oder einer kleinen Gruppe wieder.

Einer Gruppe an Leuten, die mehr Erfahrung mit Perl hat, als ich. Das ist für mich ein gutes Argument, erstmal auf diese Leute zu hören bis ich selbst genug weiß um mir meine eigenen Gedanken machen zu können. Vielleicht stelle ich irgendwann fest, dass mir Vorschlag a aus Grund b und c nicht zusagt und Option d besser wäre. Dann hab ich das aber qualifiziert selbst entschieden und nicht nur, weil ich kein Paket installieren möchte.

Sollte meine  Frage bzgl. constant vs readonly dort wirklich auf S. 55 beschrieben worden sein, hilft mir Deine Antwort nicht weiter. Ich werde mit diesen Buch nicht kaufen, weil ich Perl nur notgedrungen benutzen muss (wegen FHEM), ich finde Perl furchtbar.

Ja nun ... ¯\_(ツ)_/¯

Aber das ist auch nur meine persönliche Einschätzung (gewonnen aus 45 Jahren Programmiererfahrung).

bist du ja selbst jemand mit Erfahrung. Mich wundert natürlich, dass du weiter oben im Text zwar nicht auf eine Person mit viel Erfahrung hingewiesen werden möchtst, nun aber selbst diese Karte spielst? Zumal du ja selbst sagst, dass du Perl nicht leiden kannst.

Sicher kann ich constant trotzdem weiter verwenden, wenn ich hinter jedem constant-Ausdruck ein "#Violates" hinter setze. Dann kann ich die Fehler unterdrücken.

Du kannst P::C sogar einfach nicht benutzen. Ich verstehe irgendwie deinen Punkt nicht: Du wendest ein Tool, das dich gängelt, auf Quellcode in einer Sprache an, die du nicht leiden kannst.

Ich freue mich darüber, dass nun viele anfangen ihren Code noch mal zu überarbeiten. Da kommt doch sicher etwas gutes bei raus, vielleicht finden sich noch ein paar Bugs, vielleicht findet ja so jemand sogar mal die Lösung für das Speicherproblem.
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 1 Liste anzeigen

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4501
Antw:Perl Readonly / Debian
« Antwort #42 am: 04 Mai 2020, 13:22:28 »
vielleicht finden sich noch ein paar Bugs
Auf mich persönlich bezogen : in der Tat ja ! und man wundert sich das bisher noch niemand den im Forum angemeckert hat :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Online Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1640
Antw:Perl Readonly / Debian
« Antwort #43 am: 04 Mai 2020, 13:50:48 »
Auf mich persönlich bezogen : in der Tat ja ! und man wundert sich das bisher noch niemand den im Forum angemeckert hat :)

Genauso war es bei mir bei BR auch. Ich hatte den Code auch nur "geerbt" und bin nun überhaupt das erste mal voll durchgestiegen, inkl. ein paar lästiger Dinge zu finden. Ich hab mir vorgenommen, so lange alle zwei Wochen ein Release zu machen, bis der Code einmal auf links, wieder auf rechts und dann wieder auf links gebügelt wurde. P::C ist dabei nur ein Teil der Dinge, die ich dabei umsetze.

Offline SCMP77

  • Developer
  • Full Member
  • ****
  • Beiträge: 135
    • GitHub SolvisSmartHomeServer
Antw:Perl Readonly / Debian
« Antwort #44 am: 04 Mai 2020, 14:39:03 »
Worum geht es Dir? Nicht Perl benutzen zu müssen?

Mit dem SmartHome-Server habe ich das ja auch zum großen Teil erreicht, nur ein minimaler Teil davon musste ich in Perl schreiben. Den will ich aber halbwegs "richtig" schreiben und da kann man trotzdem die Frage stellen, warum an dieser Stelle unbedingt ReadOnly statt constant verwenden soll. Ich dachte, dafür ist die Perl-Ecke da.

Das Teil würde es bis zum Perl::critic Level 3 schaffen, wenn es da die Sache mit den constant-Ausdruck nicht gibt.

Aber ja, constant ist eben keine wirkliche Variable, das muss man eben wissen.

Zitat
Wenn Du willst, kann ich 73_SolvisClient.pm im HoBo Repository aufnehmen und dort maintainen (und ja - ohne Readonly). Dann schnappst Du Dir den Source von dort und kannst Du Dich voll und ganz Java widmen (was nach meiner Recherche auch ein wenig "Liebe" im SolvisSmartHome-Server gebrauchen könnte).

Was für einen Sinn macht das? Wenn Du mal reingesehen hättest, hättest Du erkannt, dass das Teil im Gegensatz zu anderen Modulen bzgl. Perl::critics gar nicht so schlecht dasteht. Gäbe es die Sache mit constant nicht , wäre er bis einschl. Level 3 ohne Beanstandungen. Es ist nicht mehr im globalen Namensraum etc.. Ich denke, das würde nicht viel bringen.

Meine Devise ist eben grundsätzlich, warum eine Library, wenn es mit dem dafür eigentlich vorgesehenen Element geht, da müssten für mich dann schon starke Pro-Argumente geben. Ich weiß, bei der Library-Beschreibung des readonly-Objekt ist der Unterschied zu constant näher ausgeführt, letztendlich ist es das, was ich schon schrieb.

Ja in Hashes muss man bei einer Konstante $hash{+CONSTANTE} schreiben, anstelle von $hash{$CONSTANTE}. Das ist aber ein recht geringer Unterschied. Rechtfertigt dieser wirklich die Nutzung von Readonly? Diese Frage habe ich hier in den Raum gestellt und man hört nur, die Gurus würden das besser wissen.

Das wesentliche ist doch in Wirklichkeit, dass man keine Magic-Nummern im Quellcode hat, sondern diese mit Namen versieht.

Zitat
Es stellt sich z.B. die Frage warum der Source auf GoogleDrive und nicht auf GitHub ist. Findest Du Git auch furchtbar?
Ich meine selbst die FHEM Führungsriege hat es mittlerweile schon von CVS zu SVN geschafft.

Naja, hättest Du mal nur einen ganz flüchtigen Blick in einen der Header der Java-Dateien gesehen, hättest Du erkannt, dass ich auch eine Versionsverwaltung nutze. Ich habe das Paket es hier noch nicht abgelegt, weil es die Voraussetzungen (bisher) nicht erfüllt(keien Engliche Hilfe-Datei etc.). Und der Server selber hat auch nicht wirklich etwas in FHEM zu suchen, man kann ihn (wenn man da einen Client schreibt) auch in anderen SmartHome-Systemen nutzen.

« Letzte Änderung: 04 Mai 2020, 14:56:55 von SCMP77 »
Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #45 am: 04 Mai 2020, 15:37:18 »
Mit dem SmartHome-Server habe ich das ja auch zum großen Teil erreicht, nur ein minimaler Teil davon musste ich in Perl schreiben. Den will ich aber halbwegs "richtig" schreiben und da kann man trotzdem die Frage stellen, warum an dieser Stelle unbedingt ReadOnly statt constant verwenden soll. Ich dachte, dafür ist die Perl-Ecke da.

Verstehe, also muss man noch (mal eben) Java installieren. Ja klar - warum nicht.

Zitat
Was für einen Sinn macht das? Wenn Du mal reingesehen hättest, hättest Du erkannt, dass das Teil im Gegensatz zu anderen Modulen bzgl. Perl::critics gar nicht so schlecht dasteht.

Perl::Critic -3 ist ja ok. Aber das ist eben auch nur eine statische Codeanalyse und der entgehen nahezu alle semantischen Schnitzer.
Absolut basale Hygiene - mehr ist das nicht. Das soll nur dazu dienen, dass man den Code nicht mit Schutzausrüstung anfassen muss.
Wer glaubt damit sei es getan... naja.

        my @channels = keys(%ChannelDescriptions) ;
        my $params = '' ;
        my $firstO = _TRUE_ ;
        foreach my $channel (@channels) {
            if ( $ChannelDescriptions{$channel}{GET} == _FALSE_ ) {
                next ;
            }
            if ( ! $firstO ) {
                $params .= ' ' ;
            } else {
                $firstO = _FALSE_ ;
            }
            $params .= $channel ;
            my $firstI = _TRUE_ ;
        }

Preisfragen (an alle): Was wollte dieser Code ursprünglich machen? Was macht dieser Code tatsächlich?
Antwort (an den Autor): Den Sinn macht das.

Zitat
Ich denke, das würde nicht viel bringen.

s.o.  ;) - aber ich will mich nicht aufdrängen.

Zitat
Das wesentliche ist doch in Wirklichkeit, dass man keine Magic-Nummern im Quellcode hat, sondern diese mit Namen versieht.

Ja, prinzipiell ja. Das sagt ja auch PBP ("besser als nix"). Insofern ist das Thema ja tatsächlich keine constant-Hexenverfolgung, sondern ob/wie man Module zu FHEM bringt.

Zitat
Naja, hättest Du mal nur einen ganz flüchtigen Blick in einen der Header der Java-Dateien gesehen, hättest Du erkannt, dass ich auch eine Versionsverwaltung nutze. Ich habe das Paket es hier noch nicht abgelegt, weil es die Voraussetzungen (bisher) nicht erfüllt(keien Engliche Hilfe-Datei etc.). Und der Server selber hat auch nicht wirklich etwas in FHEM zu suchen, man kann ihn (wenn man da einen Client schreibt) auch in anderen SmartHome-Systemen nutzen.

Ich habe ja auch nicht von FHEM-SVN gesprochen, sondern z.B. von GitHub. Vermutlich hast aber Recht, dass für den Endanwender ein ZIP File und ein wenig HowTo mehr als ausreichend ist.

Offline SCMP77

  • Developer
  • Full Member
  • ****
  • Beiträge: 135
    • GitHub SolvisSmartHomeServer
Antw:Perl Readonly / Debian
« Antwort #46 am: 04 Mai 2020, 18:37:12 »
Verstehe, also muss man noch (mal eben) Java installieren. Ja klar - warum nicht.

Das mag eine "Herausforderung" sein, aber ich denke, Java dürfte schon etwas performanter sein als Perl und es ist eben keine einfache Sache die dort erfolgt. Dort wird die Console der Solvis -Anlage gescannt, es werden bestimmte Bildschirme angefahren, grafisch identifiziert, auf dem Bildschirm Bereiche gescannt und die per OCR in wirkliche maschinenlesbare Werte umgewandelt. (Nur das xml-Steuerfile, was die notwendigen Steuerungsdaten enthält hat allein 2000 Zeilen).Ich hatte das seit 2016 immer mal versucht in Perl umzusetzen, habe es aber immer wieder aufgegeben. manchmal ist es eben besser, Java nachzuinstallieren, als gar nichts zu haben oder nur etwas, was nur einen Teil der Daten auslesen kann, aber bei der Steuerung aufgeben muss.


        my @channels = keys(%ChannelDescriptions) ;
        my $params = '' ;
        my $firstO = _TRUE_ ;
        foreach my $channel (@channels) {
            if ( $ChannelDescriptions{$channel}{GET} == _FALSE_ ) {
                next ;
            }
            if ( ! $firstO ) {
                $params .= ' ' ;
            } else {
                $firstO = _FALSE_ ;
            }
            $params .= $channel ;
            my $firstI = _TRUE_ ;
        }
Preisfragen (an alle): Was wollte dieser Code ursprünglich machen? Was macht dieser Code tatsächlich?
Antwort (an den Autor): Den Sinn macht das.

Ja, ich denke, wenn Du das Modul ausprobieren würdest, würdest Du den Sinn verstehen, denn es macht, was es soll. Das kann ich mir in der Web-Oberfläche jederzeit ansehen, denn es versorgt das Pull-Down-Menü des GET-Befehles.Es lebt natürlich davon, was für Beschreibungen ihm der Server schickt, um es vollständig zu verstehen müsste man auch die JSON-Übertragung kennen. Der Server bestimmt, welche GET-Befehle möglich sind. Soweit jedenfalls die Praxis.

Was ich erkannt habe, ist, dass "my firstI ..." überflüssig ist, ein typischer Copy-Paste-Fehler.

Wenn man Deine Frage anders formuliert, warum macht es vielleicht nur zufällig das was es soll, ja, die Frage wäre vielleicht berechtigt. Scheint aber nicht so einfach zu sein, nach 3h gibt es hier keine Antwort.

Sicher ist das auch nicht gerade Perl-Like programmiert.

Gut, ich gebe Dir recht, da könnte mal ein Perl-Guru drüber schauen, denn Du siehst da eine Stelle, wo ich mich wieder mal massivst über Perl ärgern musste. Wie ich schon mal vor einigen Wochen hier gesagt habe, ich sehe Perl nur als Mittel zum Zweck an, und jemand der nicht täglich damit umgeht, muss sich da durchwurschteln, bis es endlich lauffähig ist. Das hat mich an meine C-Zeit erinnert, wo ein ***-Gewurschtel notwenig war und da gab es dann bei Fehlern nette SIGSEGV (wenn überhaupt), das tritt bei Perl nicht auf, weil es ein Interpreter ist. Aber Fehlermeldungen hat man da auch nicht immer, man bekommt stattdessen einen String mit einem schönen Inhalt, den man sich erstmal ansehen muss, um weiter zu kommen. Bei C++ war das dann glücklicherweise nicht notwendig. Dieses @%$\-Gewurschtel ist einfach aus meiner Sicht nicht mehr zeitgemäß. Ich hatte einige Zeit benötigt bis ich es meinte wieder verstanden zu haben, und ich wusste damals schon, in ein paar Wochen stehe ich wieder wie der Ochs vor'm Berg. Ich konnte nachvollziehen, warum Perl als unbeliebteste Sprache angesehen wird (https://stackoverflow.blog/2017/10/31/disliked-programming-languages/). Ein Perl-Guru hat da sicher keine  Probleme mit, so einer will ich aber nicht werden.

Ja, prinzipiell ja. Das sagt ja auch PBP ("besser als nix"). Insofern ist das Thema ja tatsächlich keine constant-Hexenverfolgung, sondern ob/wie man Module zu FHEM bringt.

Aber leider sind wir hier massiv vom eigentlich Thema angekommen, warum ReadOnly und nicht constant, die Frage schein hier wirklich niemand wirklich zu beantworten. Das die nicht die 100%ig gleichen Sachen machen ist klar, die Unterschiede habe ich auch schon genannt. Das das schon im Level 4 angemotzt wird, ist für mich zwar keine Hexenverfolgung aber doch eine Gängelung. Etwas anderes verwenden, als die Sprache selber für diesen Fall vorsieht, kann man doch nicht so hoch aufhängen (meine Meinung). Und habe hier klare Gründe erwartet und nicht einfach, dass es zwischen beiden Unterschiede gibt.

Gibt es weitere?
« Letzte Änderung: 04 Mai 2020, 18:39:51 von SCMP77 »
Raspberry Pi 3 Model B mit Rasbian, SolvisMax, AVM DECT 200, Sonoff mit Tasmota geflasht

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #47 am: 04 Mai 2020, 18:47:18 »
Ich würde stark vorschlagen die Diskussion nach https://forum.fhem.de/index.php/topic,110887.0.html umzubiegen.
Das hat dieser Thread nicht verdient.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #48 am: 05 Mai 2020, 09:12:01 »
Rollback und Recovery im Fehlerfall. Ist das appimage denn da der richtige Weg?

Ob AppImage der richtige Weg ist, sehen wir dann wenn es tut. Ich glaube, dass es  zumindest richtiger ist als .deb Pakete,
weil jemand vielleicht seine Smarthome Steuerung auch auf Fedora oder OpenSUSE oder - wie ich - Arch laufen lassen möchte.

zumindest röchelt es schon ein bischen

https://gl.petatech.eu/root/HomeBot/pipelines/85

Vorläufiges Ziel ist aber nicht bei jedem commit ein AppImage zu bauen, sondern "nightly" oder so.
Rollback könnte sein, dass man das vorhergehende (oder N) AppImage nicht löscht und im Fehlerfall
darauf zurückgeht.

Offline Icinger

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1395
Antw:Perl Readonly / Debian
« Antwort #49 am: 05 Mai 2020, 16:41:01 »
Korrigiert mich bitte, wenn ich falsch liege:

AppImage liefert ja im Prinzip das ganze fhem/-Verzeichnis inkl. Unterordner aus, oder?

Damit falle ich ja aber um die Möglichkeit um, zB gewisse Module per exclude_from_update auszuschließen.
Ich muss also immer die aktuellsten Modul-Versionen nehmen, obwohl mir bewusst ist, daß die aktuelle Version mit meinem Gerät xyz nicht richtig funktioniert (oder aber auf einem älteren FHEM-Stand bleiben, obwohl andere Module vlt. etwas implementiert haben, was ich brauchen würde.

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 #50 am: 05 Mai 2020, 17:56:18 »
Korrigiert mich bitte, wenn ich falsch liege:

AppImage liefert ja im Prinzip das ganze fhem/-Verzeichnis inkl. Unterordner aus, oder?

So genau weiß das keiner, folglich ist es für Spekulationen was geht und was nicht geht noch zu früh.
Soweit ich das verstanden habe:
AppImage liefert eher eine Applikation als "ein Binary" aus. Das Ding verhält sich dann wie diese Applikation, allerdings hat es ein kleines privates Filesystem im Schlepptau in dem die ganzen Abhängigkeiten sind. Dieses FUSE-Filesystem ist komprimiert und read-only.

Die App kann (muss) also sehr wohl auch auf der lokalen Platte rumschmieren, aber eben nichts Installationrelevantes, sondern nur App-spezifische Daten.
AppImage als solches ist offensichtlich für compilierte Apps gemacht/gedacht. Der Versuch da einen perl Interpreter und perl sourcen reinzuknödeln wollte nicht gelingen.

Also: https://metacpan.org/release/App-Staticperl und dann AppImage

Ich konnte damit HoBo in der FHEM SVN Sandbox starten und ein update check macht:

Downloading https://fhem.de/fhemupdate/controls_fhem.txt
List of new / modified files since last update:
UPD ./CHANGED
UPD ./MAINTAINER.txt
UPD ./configDB.pm
UPD ./fhem.cfg.demo
UPD ./fhem.pl
UPD FHEM/00_CM11.pm
UPD FHEM/00_CUL.pm
UPD FHEM/00_DFPlayerMini.pm
UPD FHEM/00_ElsnerWS.pm
UPD FHEM/00_FBAHA.pm
UPD FHEM/00_FBAHAHTTP.pm
UPD FHEM/00_FHZ.pm
UPD FHEM/00_HMLAN.pm
UPD FHEM/00_HMUARTLGW.pm
UPD FHEM/00_HXB.pm
UPD FHEM/00_KM271.pm
...



https://youtu.be/_Mt38g-0bz0?t=170 (Niemand weiß was die Zukunft bringt)

Theoretisch könnte ich mir AppImage auch ganz sparen und es nur mit dem staticperl probieren.
Dann hätte ich das CPAN Problem und das Perl Version Problem erschlagen, aber hätte noch
ein paar Abhängigkeiten von OS Systemlibs (glibc, ssl, ...)
« Letzte Änderung: 05 Mai 2020, 18:02:36 von RichardCZ »

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7355
Antw:Perl Readonly / Debian
« Antwort #51 am: 05 Mai 2020, 18:13:03 »
AppImage will doch gerade Systemunabhängig sein, d.h. eben "Nicht-Standardlib" oder Spezialitäten mitliefern. Perl will wirklich nicht? Bei Phyton z.B. funktioniert es (laut einem Freund).

Jemand der Spezielle FHEM Module in Speziellen Versionen haben möchte, kann FHEM ja immer noch klassisch installieren.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #52 am: 05 Mai 2020, 18:35:46 »
AppImage will doch gerade Systemunabhängig sein, d.h. eben "Nicht-Standardlib" oder Spezialitäten mitliefern. Perl will wirklich nicht? Bei Phyton z.B. funktioniert es (laut einem Freund).

Du kannst es gerne probieren. Ich habe nach 3 Tagen aufgegeben. Aber derzeit erscheint mir das Tandem staticperl-AppImage sehr interessant. Die Möglichkeiten muss ich erst ausloten.

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7355
Antw:Perl Readonly / Debian
« Antwort #53 am: 05 Mai 2020, 18:44:22 »
Habe leider mit AppImage noch nichts zu tuen gehabt ...

Was ist eigentlich der Unterschied zwischen perl und staticperl??
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #54 am: 05 Mai 2020, 18:52:52 »
Was ist eigentlich der Unterschied zwischen perl und staticperl??

Staticperl = Perl-Interpreter + Module (auch XS/binary) in einem binary

http://staticperl.schmorp.de/bigperl.html

Für den Aha-Effekt empfehle ich tatsächlich das

download binary, chmod u+x and use it as perl, or try bigperl.bin -Mhttpd

Und dann Browser auf http://localhost:9090

Wie gesagt, selbst ohne AppImage könnte das für FHEM sehr nützlich sein, denn dieses staticperl würde Probleme mit Perl-Version und CPAN Modulen lösen.
Also ich habe jetzt in HoBo keinen Mangel an CPAN Funktionalität - bereits im Lieferumfang.

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7355
Antw:Perl Readonly / Debian
« Antwort #55 am: 05 Mai 2020, 19:14:17 »
Mit anderen Worten: StaticPerl ist genau das, was Du für AppImage brauchst .... wäre dann sehr Einsteiger freundlich ;o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7416
Antw:Perl Readonly / Debian
« Antwort #56 am: 12 Juni 2020, 19:59:32 »
Jemand der Spezielle FHEM Module in Speziellen Versionen haben möchte, kann FHEM ja immer noch klassisch installieren.
Dann ist die Frage: wie komme ich von einer laufenden Installation mit Appimage zurück zu eine klassische Installation?

Dass man andere Versionen von einem Modul braucht, passiert nicht so selten:
- ein Benutzer entdeckt ein Bug in einem Modul. Der Modulautor stellt  eine Korrektur zur Verfügung, und möchtet gern wissen, ob das das Problem tatsächlich löst, bevor er das eincheckt. Wie testet der Appimage Benutzer?
- ein Entwickler liefert ein neues Modul und möchtet gerne ein paar Tester finden (was nicht immer einfach ist). Leider sind alle interessierte Freiwillige in Appimage gefangen...

Oder habe ich etwas von Appimage falsch verstanden?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4501
Antw:Perl Readonly / Debian
« Antwort #57 am: 13 Juni 2020, 06:50:38 »
schau dir doch mal die letzten Seiten von  https://forum.fhem.de/index.php/topic,109740.0.html an.
IMHO hatte Richard in seinem Image fhem.pl bzw Hobo.pl plus den CPAN Modulen, aber alle FHEM Module waren meine.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #58 am: 15 Juni 2020, 09:10:38 »
Dann ist die Frage: wie komme ich von einer laufenden Installation mit Appimage zurück zu eine klassische Installation?

Was ist eine "klassische Installation"?

Prinzipiell hat jede Installationsart ihre Vor- und Nachteile und auch ihre Zielgruppe. Von all den Zielgruppen ist jedoch stets diejenige zum Unglücklichsein verdammt, die eierlegende Wollmilchsäue möchte: 0-Installationsaufwand & feingranulare Updatemöglichkeiten, am besten nightly.

AppImages sind für die Leute gedacht, die sich einen "Blob" holen und dann - never touch a running system - den laaange laufen lassen, bevor sie sich einen neuen holen.
Leute, die sich nicht mit Perl-Versionen und CPAN auseinandersetzen möchten.

Wer hinggen sein System unentwegt pimpen möchte, der sollte m.E. den versionless-Ansatz wählen, m.a.W. Selbst die System-Infrastruktur backen und dann updates direkt über ein vcs.

Beides passt in meinen Augen irgendwie nicht zusammen. Man müsste schon sehr schizo sein um das System nicht anfassen zu wollen/können, aber dann bis zu den Ellbögen tief in Feintuning/Aktualität stecken zu wollen.

Beide Herangehensweisen decken also komplementäre Anforderungsprofile ab. Um dennoch den "Wirkbereich" dieser Anforderungsprofile möglichst nahtlos zu gestalten, mache ich zwei Sachen:

1) HoBo AppImage soll ein "all-inklusive" Paket werden. Nicht nur Perl-Interpreter, CPAN module (einschl. kompilierter libs), sondern auch FHEM Module, die nicht im "standard SVN Kanon" sind.  Siehe z.B. die Module im HoBo Repo aus externen Quellen, bfs, Buienradar, Liquid_Check etc. Klar bekommt man sich viel Zeug, das man gar nicht braucht, aber die paar Kilobyte...

2) Da ich nicht einsehe, warum Perl-only CPAN Module nicht Bestandteil des Projektrepositorys sein sollten, habe ich die mit drin. Das bedeutet, dass bei einer versionless Installation sehr viel von CPAN bereits mit dem Projekt mitkommt. D.h. es erspart selbst dem "Power User" einiges an "cpan install"

Der Wechsel von static -> versionless und zurück sollte nicht das Problem sein, denn die User-spezifische Konfiguration ist ja das was die lokale Installation individualisiert und das ist ja weder Bestandteil eines Repository, noch eines AppImage.

Das AppImage wird - sobald es denn mal richtig funktioniert - im Wesentlichen ein Konglomerat aus

* Perl Interpreter
* benötigte "System CPAN Module" - auch mit gelinkten binary-libs
* Hauptskript (fhem.pl/hobo.pl)

sein. Perl code in FHEM und so Sachen wie AttrTemplates könnte man zwar auch reinknödeln, aber das sind ja nicht die problematischen Dateien.
Mir geht es vorwiegend darum, dass jemand das AppImage hernehmen und auf Debian, Redhat, SUSE, Arch, ... laufen lassen kann.

Offline amenomade

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7416
Antw:Perl Readonly / Debian
« Antwort #59 am: 15 Juni 2020, 21:04:17 »
Danke für die ausführliche Antwort, wobei nur folgender Teil teilweise meine Frage beantwortet :
Zitat
Der Wechsel von static -> versionless und zurück sollte nicht das Problem sein, denn die User-spezifische Konfiguration ist ja das was die lokale Installation individualisiert und das ist ja weder Bestandteil eines Repository, noch eines AppImage.
Meine Verständnis von AppImage ist: der Wechsel von static -> versionless bedeutet eine volle (neue) parallel Installation von der "versionless Version" von Fhem.

Es gäbe evtl die Möglichkeit die (App-)Image "loop" zu mounten, und dann dort ein Modul evtl. zu ersetzen, aber ob das mit einem perl executable und perl Modulen funktioniert ...
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #60 am: 16 Juni 2020, 05:59:31 »
Wie Wzut schon ausführte, sind die FHEM "Module", web, Javascript, Doku etc. nicht Bestandteil des AppImage - zumindest vorerst.

Sofern die Updates eben die Module, oder z.B. AttrTemplates betreffen, können die ja unabhängig vom AppImage aktualisiert werden. Ziel des AppImage ist tatsächlich "nur" die Frage der Perl Version und benötigter "System CPAN Module" zu lösen.
Informativ Informativ x 1 Liste anzeigen

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7355
Antw:Perl Readonly / Debian
« Antwort #61 am: 16 Juni 2020, 07:35:27 »
D.h. ein FHEM update intern funktioniert? Es muß nicht das AppImage aktualisiert werden?

Frage sicherheitshalber für die Klarstellung.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Perl Readonly / Debian
« Antwort #62 am: 16 Juni 2020, 10:05:01 »
D.h. ein FHEM update intern funktioniert? Es muß nicht das AppImage aktualisiert werden?

Frage sicherheitshalber für die Klarstellung.

Nicht für HoBo, da ich diesen Update-Mechanismus da erstmal kaltgestellt habe.

 

decade-submarginal