Perl Readonly / Debian

[RichardCZ]

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.

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.

Code Auswählen Erweitern

        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.

Ich denke, das würde nicht viel bringen.

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

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.

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.

[SCMP77]

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.

Code Auswählen Erweitern

        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?

[RichardCZ]

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.

[RichardCZ]

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.

[Icinger]

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

[RichardCZ]

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

[Wernieman]

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.

[RichardCZ]

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.

[Wernieman]

Habe leider mit AppImage noch nichts zu tuen gehabt ...

Was ist eigentlich der Unterschied zwischen perl und staticperl??

[RichardCZ]

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.

[Wernieman]

Mit anderen Worten: StaticPerl ist genau das, was Du für AppImage brauchst .... wäre dann sehr Einsteiger freundlich ;o)

[amenomade]

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?

[Wzut]

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.

[RichardCZ]

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.

[amenomade]

Danke für die ausführliche Antwort, wobei nur folgender Teil teilweise meine Frage beantwortet :

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