Perl Readonly / Debian

[herrmannj]

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?

[RichardCZ]

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.

[herrmannj]

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?

[RichardCZ]

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.

[SCMP77]

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:

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

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

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

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

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

Oder gibt es noch andere Vorteile?

[Sidey]

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

[RichardCZ]

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"

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

Code Auswählen Erweitern

    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.

Code Auswählen Erweitern

    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)

[Christoph Morrison]

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.

[SCMP77]

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

[mahowi]

In einem der Threads in der Perl Ecke gab es einen Link, über den man sich PBP als PDF ansehen kann.

[RichardCZ]

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.

[Christoph Morrison]

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.

[Wzut]

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

[Christoph Morrison]

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.

[SCMP77]

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.

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.

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.