FHEM Forum

FHEM - Entwicklung => FHEM Development => Perl Ecke => Thema gestartet von: Wzut am 28 März 2020, 19:53:24

Titel: Wunschlliste Themen
Beitrag von: Wzut am 28 März 2020, 19:53:24
Sind vllt. Themen die nicht unbedingt unter PBP fallen , aber ich mir einbilde irgendwo mal etwas dazu zu gelesen zu haben und eventuell klar gestellt werden können.

a. $s = 'Test Nr '.$i.' bestanden'  vs. "Test Nr $i bestanden"
Ich tippe mir teilweise die Finger wund weil ich Strings von " auf einfaches Hockomma umbaue.
Grund : irgendwo gelesen das würde Perl entlasten, da nicht nach Variablen gesucht wird. Mythos oder Wahrheit ?

b. $i += 1  vs. $i++
++ ist angeblich effektiver ,    M o W ?

c.  int($i)  vs. $i++; $i--; 
der schnellste Weg eine Variable numerisch zu bekommen,   M o W ?

d. Substring im String suchen : grep vs. index()  ,
ich verwende wo immer es geht index,  ist schneller als grep ?

 
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 28 März 2020, 20:29:11
Zitat von: Wzut am 28 März 2020, 19:53:24
Sind vllt. Themen die nicht unbedingt unter PBP fallen , aber ich mir einbilde irgendwo mal etwas dazu zu gelesen zu haben und eventuell klar gestellt werden können.

Finde ich sehr gut! Ich habe teilweise den Eindruck, dass ich hier viel Sermon ablasse, Konkrete Fragestunde wo Leute was drückt wäre doch mal zur Abwechslung besser.

Zitat
a. $s = 'Test Nr '.$i.' bestanden'  vs. "Test Nr $i bestanden"

letzteres

Zitat
Grund : irgendwo gelesen das würde Perl entlasten, da nicht nach Variablen gesucht wird. Mythos oder Wahrheit ?

Es wird wohl homöopatisch schneller sein, aber es ist (wird auch im PBP empfohlen) für den Maintainer eine wesentliche Entlastung, weil er gleich sieht ob der String interpoliert oder nicht.

Also:

my $str = 'tralala'; # nicht: "tralala"
my $str = "aha $tralala bebe"; # nicht 'aha ' . $tralala . ' bebe'
my $str = $aha . $bebe;   # ist ok
my $str = "$aha$bebe";   # ist genauso ok

Pro Tipp:

my $string = q{Hier kann's echt "dicke" stehen.};

Dann stellt man fest, man möchte doch eine Variable drin interpolieren:

my $string = qq{Hier kann's echt "dicke" stehen: $tralala};

Ein q vorne dazu oder weg und fertig. Überdies muss man keine Angst vor " oder ' im String haben.


Zitat
b. $i += 1  vs. $i++
++ ist angeblich effektiver ,    M o W ?

Effizienter.  ;)  Beide sind gleich effektiv.
Wahrheit. $i += 2 ist aber effizienter als $i++; $i++ und wesentlich effizienter als $i = $i + 2;
Auch Wahrheit: ++$i ist schneller als $i++;

Aber der wahre Vorteil ist hier nicht geschwindigkeit. Der Wahre Vorteil sind Subtilitäten wie

if (++$variable < 5)
oder
if ($variable++ < 5)

Echte Programmierer können da dann sehr eleganten Code schreiben. Ist aber nicht Perl spezifisch.


Zitat
c.  int($i)  vs. $i++; $i--; 
der schnellste Weg eine Variable numerisch zu bekommen,   M o W ?

Numerisch oder Integer? numerisch: $var+0
Integer: int($var)

Zitat
d. Substring im String suchen : grep vs. index()  ,
ich verwende wo immer es geht index,  ist schneller als grep ?

grep und index sind zwei verschiedene Dinge.
grep filtert eine Liste, index sucht einen substring.
Also index.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 29 März 2020, 17:58:09
THX, dann wäre das schon mal soweit klar.
Bei c. hatte ich mich blöd ausgedrückt, es ging mir da nicht um $i++ oder $i-- sondern um $i++ und $i--
Das sieht zwar auf den ersten Blick bescheuert aus , erst eins drauf dann gleich wieder weg, aber der Myhtos besagte das so der Perl Compiler den Assembler Code INC und DEC erzeugen würde ... ja Anfang der 80er was CPU Power und Speicherplatz noch ein rares Gut :)
das $var+0 nutze ich heute schon, meist nach einem sprintf("%.1", $var) wenn ich ordenliche Zahlen wie 1,2,3 haben will und keine 1.0, 2.0 usw.
 
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 30 März 2020, 10:59:10
Ich mach mal mit dem Thema shift und @_ hier weiter da es im return undef Thread doch OT ist :
Es ging um : my ( $hash, $name) = @_;    vs.   my $hash = shift; my $name = shift; und wo die Grenze liegen sollte wie oft man shift nutzt.
Richards Antwort war :
ZitatDie 3 und mehr Argumente ist eher die Grenze um zu named Arguments überzugehen, weil positionale Parameter ihre Vorteile (Kürze/Würze) verlieren:

= @_; macht man eigentlich nur, wenn man tatsächlich eine Liste übergibt aber selbst das macht man nicht, weil man eine listreferenz übergeben sollte. (Um den Stack nicht immer vollzukleistern)

zu : macht man eigentlich nur, wenn man tatsächlich eine Liste übergibt
Konkret -> die Attr Funktion in einem Modul , i.d.R. sieht die so aus : my ($cmd, $name, $attrName, $attrVal) = @_;
Nun die Preisfrage , was liefert mir den da @_ eine Liste oder eine listrefrenz ? (das mit den Referenzen kommt die Tage hier so oft das das schon wieder ein Thema wert wäre)
Und ob es nun Fisch oder Fleisch ist, irgendwie bin ich doch zu doof für das Thema, denn bei Perlcritc -4 bekomme ich es wieder vorgesetzt und dann mit :
ZitatAlways unpack @_ first at line xyz, column 1.  See page 178 of PBP.  (Severity: 4)


Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 30 März 2020, 11:20:07
Zitat von: Wzut am 30 März 2020, 10:59:10
Konkret -> die Attr Funktion in einem Modul , i.d.R. sieht die so aus : my ($cmd, $name, $attrName, $attrVal) = @_;
Nun die Preisfrage , was liefert mir den da @_ eine Liste oder eine listrefrenz ?

Liefert eine Liste. Das ist aber nunmal so und das wird sich auch nicht ändern. Der Vorschlag ist auch nicht aus

my ($cmd, $name, $attrName, $attrVal) = @_;

nur ein

my $cmd      = shift;
my $name     = shift;
my $attrName = shift;
my $attrVal  = shift;


zu machen, denn das wäre zu kurz gegriffen. Da man nun jedes Argument individuell vom Stack holt, kann man auch gleich validieren. Also an Stelle eines

my ($cmd, $name) = @_

return '' if (! defined $cmd);
$name = 'Gonzo' if (!$name);
...


Macht man eben

my $cmd  = shift // return '';
my $name = shift || 'Gonzo'


Nicht nur ist die zweite Form kürzer und übersichtlicher, sie ist auch effizienter, denn für den Fall dass $cmd undefiniert ist, muss man auch nicht sinnlos $name vom Stack holen, nur um ihn später wegzuschmeissen. Es wird schon vorher aus der Sub gesprungen.

Also lautet meine Empfehlung ein xxx = @_ nur dann zu shifts zu transformieren, wenn man gleich drunter im Code irgendwelche if (! defined $arg) bzw. if (! $arg) Validierungen oder Default-Initialisierungen der Argumente entdeckt, die man auf diese Art und Weise gleich abfackeln könnte.

Zitat
denn bei Perlcritc -4 bekomme ich es wieder vorgesetzt und dann mit :
Always unpack @_ first at line xyz, column 1.  See page 178 of PBP.  (Severity: 4)

Diese Meldung kommt, weil die Verwendung von $_[0], $_[1] etc. praktisch immer eine schlechte Idee ist. PBP Seite 178-181 erklärt.
Wer das Buch nicht hat, geht krass in Ukraine und guggt sich dort um: ftp://ftp.happy.kiev.ua/pub/doc/
oder kauft es oder glaubt mir.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 30 März 2020, 19:05:06
@Richard irgendwie reden wir gerade eineinader vorbei.
a. Ich sprech direkt die Attr Funktion an die man als Autor in sein Modul einbauen kann, dort muss ich nicht groß auf valide Parameter prüfen das macht fhem.pl schon für mich. D.h. ich muss jetzt mit den vier Werten arbeiten und Entscheidungen treffen. Meist in zwei Blöcken , ala wurde eben ein Attribut zugefügt/geändert (cmd set) oder eines gelöscht (cmd del) usw. usw

b. der eigentlich Grund für den Post  war :
my ($cmd, $name, $attrName, $attrVal) = @_;
Selbst PBP hat das so auf Seite 179
my ($text, $cols_count, $want_centering) = @_;

wo ist da jetzt der Unterschied zu meiner Zeile ?  Und nein ich greife dort nicht auf $_[0] zu (das war in einem anderen Thread, Beispiel) und da schreibt PBP ja auch :
auf Seite 178 :
ZitatBut accessing them via $_[0] , $_[1] , etc. directly is almost always a Very Bad Idea.

Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 30 März 2020, 19:17:37
Zitat von: Wzut am 30 März 2020, 19:05:06
@Richard irgendwie reden wir gerade eineinader vorbei.

Um das zu vermeiden am besten Link auf das gesamte File senden oder es hier anhängen, damit ich lokal sehen kann woher das Problem kommt. Diese 1-Zeilen Excerpts sind wie ne Peep Show durch ein verstaubtes Schlüsselloch.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 31 März 2020, 09:15:05
Das mit dem Staub ist schon ok, denn glaube mir wenn der alte Herr dahinter die Hosen runter lässt das willst du gar nicht so genau sehen :)
Aber ok, es gilt doch noch der alte Spruch "wer lesen kann ... " , in dem Fall ich, denn ich war zu fixiert auf das @_ Thema, aber in Wahrheit bezieht sich die Meldung auf ein Stück tiefer im Code :
$_[3] = $hash->{type};
Die Zeile entstand durch https://wiki.fhem.de/wiki/DevelopmentModuleIntro
ZitatZusätzlich ist es möglich auch übergebene Attributwerte zu verändern bzw. zu korrigieren, indem man im Parameterarray @_ den ursprünglichen Wert anpasst. Dies erfolgt im Beispiel über die Modifikation des Wertes mit Index 3 (entspricht dem 4. Element) im Parameterarray, also $_[3]
Und genau das passiert hier, d.h. der übergebene Wertr passt mir an der Stelle nicht , also wird er überbügelt.
Die eigentliche Frage ist aber nun  : Wie bekommt man genau dieses Verhalten hin bleibt aber PBP konform ?

Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 31 März 2020, 09:42:16
Zitat von: Wzut am 31 März 2020, 09:15:05
Das mit dem Staub ist schon ok, denn glaube mir wenn der alte Herr dahinter die Hosen runter lässt das willst du gar nicht so genau sehen :)
Aber ok, es gilt doch noch der alte Spruch "wer lesen kann ... " , in dem Fall ich, denn ich war zu fixiert auf das @_ Thema, aber in Wahrheit bezieht sich die Meldung auf ein Stück tiefer im Code :
$_[3] = $hash->{type};
Die Zeile entstand durch https://wiki.fhem.de/wiki/DevelopmentModuleIntroUnd genau das passiert hier, d.h. der übergebene Wertr passt mir an der Stelle nicht , also wird er überbügelt.
Die eigentliche Frage ist aber nun  : Wie bekommt man genau dieses Verhalten hin bleibt aber PBP konform ?

my $val1 = 3;

by_reference(\$val1);

print "Val1: $val1\n";


sub by_reference {
    my $arg1 = shift;

    $$arg1 *= 2;

    return;
}


gibt 6 aus. Perlcritic schweigt.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 31 März 2020, 19:04:03
ja nehme ich dein Beispiel direkt läuft das, aber angepasst auf das FHEM Umfeld mit zusätzlich use strict und dann by_reference($val1);
wird daraus
Can't use string ("3") as a SCALAR ref while "strict refs" in use at ./test.pl line 13
und genau das gleiche passiert als Totalabsturz in FHEM wenn ich
$$attrVal = 'test'  schreibe. Vermutlich weil in fhem,pl steht
$ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);
und das kann man nicht einfach mal schnell in $ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, \$attrVal); ändern, da dann FHEM gar nicht mehr startet.

Ich habe die Zeile jetzt ganz entfernt und gebe nur return 'Fehlermeldung';  zurück

Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 31 März 2020, 20:40:55
Zitat von: Wzut am 31 März 2020, 19:04:03
ja nehme ich dein Beispiel direkt läuft das, aber angepasst auf das FHEM Umfeld mit zusätzlich use strict und dann by_reference($val1);
wird daraus
Can't use string ("3") as a SCALAR ref while "strict refs" in use at ./test.pl line 13
und genau das gleiche passiert als Totalabsturz in FHEM wenn ich
$$attrVal = 'test'  schreibe. Vermutlich weil in fhem,pl steht
$ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);

(Das hat jetzt gedauert, bis ich es geschafft habe die Forumssoftware zu verarschen, damit sie $_⦋x⦌ im Fliesstext anzeigt.)

Also wenn man ein Argument nicht "by Reference" übergibt, sondern "normal", dann ist der einzige, der darauf eine Referenz abbildet @_!
Folglich ist auch $_⦋x⦌  dann die einzige Möglichkeit dieses Argument en-passant zu verändern.
Das ist aber in etwa so, als würde man die Anleitung geben wie man Sarin herstellt.

shift und $_⦋x⦌  gehen gar nicht zusammen. Wer sich erinnert, ich habe mal geschrieben, dass shift die Argumentliste "konsumiert" und dass man das will. Eben damit da keine Referenzen in der Sub rumfleuchen. Hat man das mit shift gemacht, findet  $_⦋x⦌  i.d.R. nix mehr auf dem Stack (und für gewöhnlich ist das eine gute Sache)

Der übliche "wenn es gar nicht anders geht" Ratschlag lautet dann: ja, $_⦋x⦌  zusammen mit = @_ verwenden, wie es die ModuleIntro Doku sagt. Aber in Wirklichkeit möchte man da vielleicht eine bessere API - wo z.B. von einer CallFnNextGen eine Hashref zurückgegeben wird mit reichhaltigem Frühstück.

Gutes Design ist, wenn Argumente in die Sub reinkommen und dann via Return was rauskommt und Daten nicht noch durch diverse und Lecks "en passant" verändert werden. Man sieht ja dem CallFn Aufruf nicht an, dass er das Argument verändert. Schon gar nicht sieht man ihm an ob er es immer oder nur manchmal verändert.

my ($x, $y, $z) = @_

$_[2] = complex($z);
...


Konnte ich jetzt mein lokales perlcritic nicht dazu bekommen zu meckern.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 01 April 2020, 07:32:11
Zitat von: RichardCZ am 31 März 2020, 20:40:55
shift und $_⦋x⦌  gehen gar nicht zusammen.
---snipp ----
Der übliche "wenn es gar nicht anders geht" Ratschlag lautet dann: ja, $_⦋x⦌  zusammen mit = @_ verwenden, wie es die ModuleIntro Doku sagt
--- snipp ---
Konnte ich jetzt mein lokales perlcritic nicht dazu bekommen zu meckern.
a. OK , wieder was gelernt.
b. an der Stelle sollte man sich vllt. genau überlegen ob es überhaupt sein muß $_[3] anzufassen oder ob es nicht reicht direkt mit return $error zu verhindert das das Attribut geändert wird.
c. hmm das wäre dann nun schon der zweite Fall wo mein 5.24.1 und percritic nicht so recht zusammen wollen.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 08:14:02
Zitat von: Wzut am 01 April 2020, 07:32:11
c. hmm das wäre dann nun schon der zweite Fall wo mein 5.24.1 und percritic nicht so recht zusammen wollen.

Wobei sich hier die kategorische Frage stellt, warum man bewusst eine kaputte Perl Version verwendet.
https://perldoc.perl.org/index-history.html

5.24.4 wenn es schon 5.24 sein muss.
Titel: Antw:Wunschlliste Themen
Beitrag von: mahowi am 01 April 2020, 08:30:19
Zitat von: RichardCZ am 01 April 2020, 08:14:02
Wobei sich hier die kategorische Frage stellt, warum man bewusst eine kaputte Perl Version verwendet.
https://perldoc.perl.org/index-history.html

5.24.4 wenn es schon 5.24 sein muss.

Vermutlich läuft sein System unter Debian Stretch, da ist 5.24.1 noch aktuell:
Zitat von: https://packages.debian.org/de/stretch/perlPaket: perl (5.24.1-3+deb9u6)

Bei Buster läuft 5.28.1.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 08:52:20
Zitat von: mahowi am 01 April 2020, 08:30:19
Vermutlich läuft sein System unter Debian Stretch, da ist 5.24.1 noch aktuell:
Bei Buster läuft 5.28.1.

Gut, bei Debian weiß man immer nie so genau, was das "-3" nach 5.24.1 bedeutet. Gibt's bestimmt irgendwo changelogs, könnten Backports der kritisch(st)en Fixes sein. Man verwendet - als Entwickler schon gar nicht - ja auch das OS Perl.

Perlbrew (https://perlbrew.pl/) Leute...

# perlbrew list
* 5.30                                     
  perl-5.30.1                               
  5.28                                     
  perl-5.28.0                               
  5.26                                     
  perl-5.26.0 


ein perlbrew  use <version> und schon hat man umgeschaltet. 5.24 müsste ich jetzt erst installieren  - ist zu weit weg.  :)
Und dann ist es wurst ob man sein Debian updated oder nicht, die eigene Perl Installation ist davon unbeeindruckt.

Ich muss das so machen, ich habe Arch und die drücken einem ja alle Nase lang was neues rein, da braucht man perlbrew schon wegen der Stabilität der eigenen Entwicklungsumgebung. Gilt aber prinzipiell für jede Distri.


Bei Perlbrew bekommt man momentan aber auch nix anderes als 5.24.4 mehr:

$ perlbrew available

  perl-5.31.10   
   perl-5.30.2   
   perl-5.28.2   
   perl-5.26.3   
  perl-5.26.3.tar.bz2   
   perl-5.24.4   
  perl-5.22.4.tar.bz2   
   perl-5.22.4   
  perl-5.20.3.tar.bz2   
   perl-5.20.3   
  perl-5.18.4.tar.bz2   
   perl-5.18.4   
   perl-5.16.3   
  perl-5.16.3.tar.bz2   
   perl-5.14.4   
  perl-5.14.4.tar.bz2   
  perl-5.12.5.tar.bz2   
   perl-5.12.5   
  perl-5.10.1.tar.bz2   
   perl-5.10.1   
  perl-5.8.9.tar.bz2   
    perl-5.8.9   
    perl-5.6.2   
  perl5.005_03   
  perl5.004_05   
  cperl-5.29.2   
  cperl-5.30.0   
  cperl-5.30.0-RC1   
Titel: Antw:Wunschlliste Themen
Beitrag von: mahowi am 01 April 2020, 09:06:43
Ich habe mir gerade mal die Versionshistorie angesehen. Das letzte Mal, daß ich mehr mit Perl programmiert habe, war wohl so zwischen 5.003 und 5.6.0. Irgendwo müsste ich auch noch ein Buch aus der Zeit zur Perlprogrammierung haben.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 09:08:34
Zitat von: mahowi am 01 April 2020, 09:06:43
Ich habe mir gerade mal die Versionshistorie angesehen. Das letzte Mal, daß ich mehr mit Perl programmiert habe, war wohl so zwischen 5.003 und 5.6.0. Irgendwo müsste ich auch noch ein Buch aus der Zeit zur Perlprogrammierung haben.

Damit kannst Du ja perfekt Feuer machen, wenn die Gaslieferungen aus Russland eingestellt werden.
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 01 April 2020, 09:49:31
Zitat von: RichardCZ am 01 April 2020, 08:14:02
Wobei sich hier die kategorische Frage stellt, warum man bewusst eine kaputte Perl Version verwendet.
Die Antwort ist simpel, wenn auch OT :
Weil das mein Desktop PC ist und ich auf dem eigentlich nichts mehr mit Perl mache. Ich habe einmal den Fehler gemacht das 96_SIP Modul drauf zu schreiben und bin bald wahnsinnig geworden warum fast nur bei mir die DTMF Erkennung lief und nicht bei der Masse der Usern. Die Lösung war damals eine Eigenart des Raspi. Seit dieser Zeit schreibe und teste ich alle meine Module nur noch auf dem 3er Raspi. D.h. ich habe eine Testumgebung aus Hard & Software die dem entspricht was die Mehrheit der FHEM User auch im Einsatz hat.  Auf meinem Testraspi halte ich auch FHEM recht aktuell, auf meinen Produktiv Systemen sieht das aber ganz ganz andres aus (Bsp der eine läuft noch unter wheezy mit FHEM 5.5 ) I.d.R. checke ich auch erst ein Modul bzw eine neue Version ein wenn sie bei mir sowohl unter uralt als auch aktuell läuft. Mir ist schon klar das das nicht deiner Sicht der Dinge entspricht, aber ich kämpfe lieber ein paar Stunden für mich alleine als nachher hier im Forum mit den Usern :) Es wurde an andere Stelle schon öfters geschrieben : Was die FHEM User teilweise da für Hardware /Software Zoos am laufen haben ist der Wahnsinn und ich wage zu behaupten das jeder Modulautor das nur zu einem Bruchteil bei sich nachstellen kann.   
   
Titel: Antw:Wunschlliste Themen
Beitrag von: CoolTux am 01 April 2020, 09:56:14
Zitat von: RichardCZ am 01 April 2020, 08:14:02
Wobei sich hier die kategorische Frage stellt, warum man bewusst eine kaputte Perl Version verwendet.
https://perldoc.perl.org/index-history.html

5.24.4 wenn es schon 5.24 sein muss.

Ganz einfach. Die meisten User kennen sich mit IT und Co nicht sonderlich aus. Sie nehmen den einfachsten Weg.

apt-get install perl

Und behalten die Version so lange bis ein dist-upgrade eine neuere Version liefert.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 10:02:25
Zitat von: Wzut am 01 April 2020, 09:49:31
Es wurde an andere Stelle schon öfters geschrieben : Was die FHEM User teilweise da für Hardware /Software Zoos am laufen haben ist der Wahnsinn und ich wage zu behaupten das jeder Modulautor das nur zu einem Bruchteil bei sich nachstellen kann.   

Ja - derzeit. Ich bin halt jemand, der nicht kampflos aufgibt. Man kann sich gegen diese Kombinatorik stemmen. Bin ja dabei und auch wenn ich jetzt in so manchen Augen "Druck mache" - das wird trotzdem nicht von Heute auf Morgen gehen, denn der Stapel an Legacy durch den ich mich durchbeissen muss - zusätzlich zum FHEM KnowHow der Interna aneignen - ist nicht unbeträchtlich.

Also ich habe einen RasPi auf einer VM unter Proxmox laufen. Und einen BBB.
Den Zoo wird man früher oder später auch virtuell nachstellen können.
https://metacpan.org/pod/Test::MockObject und andere.

Der Unterschied ist wohl, dass ich den erreichbaren Bruchteil quantitativ anders einschätze.

Zitat von: CoolTux am 01 April 2020, 09:56:14
Ganz einfach. Die meisten User kennen sich mit IT und Co nicht sonderlich aus. Sie nehmen den einfachsten Weg.
apt-get install perl
Und behalten die Version so lange bis ein dist-upgrade eine neuere Version liefert.

Ich bilde mir ein was von Entwicklern und nicht Usern gesagt zu haben.
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 01 April 2020, 10:10:32
Mal was on Topic:

Am WE habe ich nebenbei auch die MySensors-relevanten .pm durch perlcritic gejagt, mit teils unterschiedlichen Ergebnissen. Eines davon war die (recht nachdrückliche) Empfehlung, statt "constant" doch besser jeweils (feste) Variablen zu nutzen, wenn ich das richtig verstanden habe.

Für neuen Code kein allzugroßes Thema, aber nun ist die "multidimensionale lookup-Table" (oder wie auch immer man sowas nennt) nun mal vorhanden: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Device/MySensors/Constants.pm.

Die ist quasi das Gegenstück zu der entsprechenden Arduino-lib, die auf den Nodes werkelt: https://github.com/mysensors/MySensors/blob/development/core/MyMessage.h.

Klar, hätte man damals auch anders lösen können, aber das Ding ist da und funktioniert auch. Ist so statisch wie der Name vermuten läßt, und ich gehe auch davon aus, dass in überschaubarer Zukunft nicht noch viele weitere Sensor- und Aktortypen erfunden werden...

Frage dazu: Mein Bauchgefühl sagt mir, dass es sich nicht lohnt, der Empfehlung nachzugehen, Aufwand (sehr zentrale Stelle des Gesamtcodes) und Ertrag (?) scheinen mir nicht in einem akzeptablen Verhältnis zu stehen.

Richtig oder falsch?





FALLS falsch (geht eher an die FHEM-Experten):
Wo wären die Daten eigentlich am besten unterzubringen?
Tendenziell stört es mich "schon immer", dass diese ganzen statischen Daten, (die im Lauf der Zeit auch erheblich gewachsen sind), in jedem List eines MYSENSORS_DEVICE auftauchen, und mit einem einfachen Punkt vor dem jeweiligen Elementnamen (readingMappings bzw. typeMappings, an sich sollte also auch ".readingMappings" bzw. ".typeMappings" gehen) scheint es nicht getan zu sein, ich _vermute_ das liegt an der Art der Referenzierung (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MYSENSORS_DEVICE.pm).

624        my $readingMappings = $hash->{readingMappings};
625        my $typeMappings = $hash->{typeMappings};
Da dieser ganze Part eigentlich statisch sein müßte, _könnte_ man die Daten auch entsprechend der DevMod-Intro nach %data schieben (da in eine Array-Struktur, die MySensors heißen könnte), und dann im Device selbst nur vorhalten, was genutzt wird (und/oder benannt).

(Nur für den Fall der Fälle!): Gute Idee oder überholt?

Gruß, Beta-User
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 10:19:39
Zitat von: Beta-User am 01 April 2020, 10:10:32
Frage dazu: Mein Bauchgefühl sagt mir, dass es sich nicht lohnt, der Empfehlung nachzugehen, Aufwand (sehr zentrale Stelle des Gesamtcodes) und Ertrag (?) scheinen mir nicht in einem akzeptablen Verhältnis zu stehen.

PBP 55-58

ZitatThe obvious question at this point is: why use Readonly instead of use constant? After all, the constant pragma comes standard with Perl, and the constants it creates don't have those annoying sigils.

Well, it turns out those annoying sigils are actually highly useful, because they allow Readonly-generated constants to be interpolated into other strings.
...
ZitatBut perhaps most importantly, use Readonly allows you to create lexically scoped constants at runtime

Und ganz zum Schluss hat auch Conway die "Wenn es gar nicht anders geht..."

ZitatIf you decide not to use the Readonly module in production code (for performance or political reasons), then using constant is still better than using literal values.
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 01 April 2020, 10:33:34
Danke erst mal für die Rückmeldung, scheint so, als käme da ein dickes Pflaster drauf ::) .

Btw.: Du darfst davon ausgehen, dass ich den Text gelesen habe. Das Problem ist: Ich verstehe ihn - v.a. wg. der Fachbegriffe - nicht, und vermutlich muß ich (mit der Geschwindigkeit, in der ich mir diese Dinge eben erschließen kann) etwa 230 Jahre alt werden, um eventuell die Chance zu haben, das bis dahin tatsächlich einigermaßen verstanden zu haben (jedenfalls, unter der Annahme, meine Lerngeschwindigkeit bliebe bis dahin in etwa konstant...).
Ich hoffe zwar sehr, dass ich damit die große Ausnahme bleibe, vermute aber eher, dass ich "nur" einer der Wenigen bin, der sich traut, das zuzugeben.




@FHEM-Experten:
Hat einer eine Idee, wie ich diesen Teil ggf. auf schnellem Wege unsichtbar machen könnte?
(Habe ich bei meinen Tests mit dem Punkt nur ein Vorkommen des Namens im Code übersehen, oder geht das eben prinzipiell nicht?)
(Ich kann weiter testen oder versuchen, das Rätsel irgendwo anders zu lösen, aber das kommt mir ehrlich gesagt auch unter Kosten/Nutzen-Gesichtspunkten unverhältnismäßig vor).
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 10:46:35
Ich verstehe dein 'problem' nicht, hast du bitte ein Beispiel für mich bitte?
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 10:56:19
Zitat von: Beta-User am 01 April 2020, 10:33:34
Das Problem ist: Ich verstehe ihn - v.a. wg. der Fachbegriffe - nicht

Keine Scheu! Einfach fragen.

Pragma(ta)?
Interpolation?
Sigils?
Lexical scope?
Literal value?
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 01 April 2020, 11:17:57
Zitat von: Beta-User am 01 April 2020, 10:33:34
vermute aber eher, dass ich "nur" einer der Wenigen bin, der sich traut, das zuzugeben.
wir beide sind die einzigen NOOPS :) 
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 11:25:37
Zitat von: Wzut am 01 April 2020, 11:17:57
wir beide sind die einzigen NOOPS :)
das glaube ich nicht. Wo is denn die messbare Grenze zwischen NOOP und ... 'PRO'? Ihr könnt mehr als 99% vom Rest der Bevölkerung! Nach oben ist immer Lust.


@beta: mglw oben untergegangen. Bitte gib mir ein Beispiel von dem was Du lösen willst. Ich "glaube" zu verstehen will mir aber sicher sein
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 01 April 2020, 11:35:54
Zitat von: herrmannj am 01 April 2020, 10:46:35
Ich verstehe dein 'problem' nicht, hast du bitte ein Beispiel für mich bitte?
"Problem" ist es nur dahingehend, dass in jedem list eines MYSENSORS_DEVICE ca. 50+ Zeilen drin sind, die eigentlich nichts speziell mit dem Device zu tun haben und bei allen gleich sind, habe grade keinen einfachen Zugriff auf ein Testsystem, aber ein einfaches "define MyNode1 MYSENSORS_DEVICE 10" sollte ausreichen (bei Bedarf liefere ich nach). So unnötig wie unübersichtlich... (beschwert hat sich noch keiner, mich hat es aber schon in der Zeit als reiner Anwender irritiert  ;D ). Ist aber bestenfalls ein "Schönheitsfehler"...

Achtung: Es gibt neben den genannten noch ein drittes Mapping im Code. Über das kann der Anwender dann den Readingnamen bestimmen, wenn er will (macht praktisch keiner, aber wenn, ist es sinnvoll, das im list zu sehen. Also z.B. aus "temperature23" (Type-mapping.ChildID) "Außentemperatur" machen u.ä.).




Zitat von: RichardCZ am 01 April 2020, 10:56:19
Keine Scheu! Einfach fragen.

Pragma(ta)?
Interpolation?
Sigils?
Lexical scope?
Literal value?

Na ja, du willst vermutlich keinen mehrseitigen Vortrag dazu schreiben, aber "im Prinzip": alles...
Vielleicht einfach nochmal zu Erinnerung: eigentlich bin ich totaler noob, meine "theoretische Ausbildung" im Programmieren beschränkt sich auf 2 Halbjahre "Informatik"-Unterricht vor Jahrzehnten am Gymnasium (BASIC+TurboPascal, damals mußte man noch Disketten verwenden, um dem "Rechner" das OS beizubiegen...). Der Lehrer war uns gefühlt 2 Unterrichtstunden voraus (und hat das gut und strukturiert gemacht, die Unterlagen habe ich Jahre später dann mal zu Rate gezogen, als ich ganz was anderes privat auf Basis von Excel-Makrosprache (....) zusammengeschustert habe).

Aber "Sigils", "Lexical scope"....?!? Bauchgefühl sagt: das wären die Schlüsselbegriffe für diesen Text, und zu "Literal value" habe ich was vor meinem "geistigen Auge", das ich am ehesten mit "irgendein Zahlen- oder Text-Wert" in Worte fassen würde. Die anderen beiden liegen irgendwo dazwischen.

(Ich habe für mich selbst auch kein echtes Problem damit, dass ich das nicht so recht verstehe. Daher: nur wenn du glaubst, es mir (oder eventuellen anderen DAM-nahen Kollegen mit vergleichbarem "Kenntnisstand") verständlich machen zu können oder einen hilfreichen Link zu haben: gerne. Ansonsten ist es für mich auch ok, wenn mir an der Stelle dann jemand schlicht sagt: "ja, der Code ist formal ok und das Risiko bei kleineren Änderungen am Code gering, wenn du dich an dem orientierst, was da ist". Oder: "mach das so oder so" (umsetzbar).)

Zitat von: herrmannj am 01 April 2020, 11:25:37
Ihr könnt mehr als 99% vom Rest der Bevölkerung! Nach oben ist immer Lust.
Das mit den 99% fasse ich als Beleidigung auf, da fehlt was >5 hinter dem Komma  ;D .
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 12:15:31
Zitat von: Beta-User am 01 April 2020, 11:35:54
Na ja, du willst vermutlich keinen mehrseitigen Vortrag dazu schreiben, aber "im Prinzip": alles...

Mehrseitigen Vortrag mache ich nicht, dann wäre ich ein schlechter Ratgeber.

Pragma = "Wie sage ich es meinem Compiler?"

use utf8;
use warnings;
use strict;

All das sind Pragmata (Mehrzahl von Pragma). Werden klein geschrieben. Damit sagt man Perl:  "Ich möchte jetzt von Dir so ein Verhalten haben."

use constant; ist auch ein pragma. PBP sagt nun, der Perl Weg Konstanten zu erzeugen ist doof und man sollte use Readonly; verwenden. (Modul, kein pragma)




Interpolation = "Variablenwert im String anzeigen"

Das was (u.a.) in doppelten Anführungszeichen oder qq{...} stattfindet:

my $x = 'Richard';
my $y = "$x ist pöhse zu mir.";

$x wurde in $y interpoliert. Oder $y wurde interpoliert oder in $y ist eine Interpolation erfolgt. Hey eigentlich keine Ahnung.
"$blah" interpoliert,  '$blah' interpoliert nicht.




Sigils = "diese Dinger da vor den Variablennamen"

$ @ % & sind "Sigils" also diese Dinger da vor den Variablennamen in Perl, die vage darauf hindeuten mit was für einem Datentyp man es zu tun hat.




Lexical scope = "zumeist ein { }-Block"

Bei Perl zumeist das was zwischen zwei geschweiften Klammern geschieht: {<---- lexical scope hier ------>}

Deswegen haben ja my-Variablen darin eine beschränkte Gültigkeit/Lebensdauer

if ($blah) {<--- START
my $foo; # jetzt lebt $foo
...
ENDE---->}
# jetzt ist $foo tot.

$foo lebt ab dem zeitpunkt ab dem die spitze öffnende Klammer die öffnende geschweifte Klammer berührt, bis zu de mZeitpunkt an dem die schliessende spitze Klammer die schliessende Geschweifte berührt.




Literal value - "Festwert"

5
'Hallo'
(1,2,3,4)

Sachen die gegeben sind und sich nicht ändern.




Das ist alles zwar grob vereinfacht, aber hey - Pareto - für 80% Verständnis reicht es.
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 12:18:48
Zitat von: Beta-User am 01 April 2020, 11:35:54
Das mit den 99% fasse ich als Beleidigung auf, da fehlt was >5 hinter dem Komma  ;D .
My fault, sorry. Mein Gehirn ist aus den 60ern - da gabs nur integer math in der Preisklasse.  ;D ;D
Titel: Antw:Wunschlliste Themen
Beitrag von: DS_Starter am 01 April 2020, 12:33:49
@Wzut  ...
Zitatwir beide sind die einzigen NOOPS :) 
Nö, bestimmt nicht ... *Finger heb*  ;)
Aber das macht nichts, man kann sich ja immer weiterbilden und dümmer werden wir durch die Beschäftigung mit FHEM/Perl auch nicht ... im Gegenteil.
Und außerdem ... wer will schon ständig im Garten Unkraut jäten oder Rasen mähen (ja, noch nicht automatisiert ! wegen der Bewegung) ?   :D ... geht jetzt ja wieder los ...
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 12:43:46
Zitat von: DS_Starter am 01 April 2020, 12:33:49
wer will schon ständig im Garten Unkraut jäten oder Rasen mähen
Vorsichtig Finger heb. Ein, zwei Wochen, ... bei gutem Wetter ... der Grill läuft. Bier steht kalt. Die Vögel machen Radau. Also ........ ich würde das schon testen. .... wenn niemand anders will.  8) Aber, wo kommt die Kohle dann her?
Titel: Antw:Wunschlliste Themen
Beitrag von: DS_Starter am 01 April 2020, 12:48:14
<OT>

@Hermann  8) ... Aber die Betonung lag auf ständig  ;D Ansonsten mache ich das sehr gerne und freue mich auf den Frühling. FHEM muss dann auf jeden Fall kürzer treten ...

</OT>
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 01 April 2020, 12:49:10
Zitat von: herrmannj am 01 April 2020, 12:43:46
... der Grill läuft...
Aber, wo kommt die Kohle dann her?

Hat eigentlich jeder Baumarkt.  ;)
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 01 April 2020, 12:50:25
Zitat von: RichardCZ am 01 April 2020, 12:15:31
Mehrseitigen Vortrag mache ich nicht, dann wäre ich ein schlechter Ratgeber.
THX!

Dieses kleine Vokabelblättchen ist wirklich hilfreich, dann kann ich mit meinem 70-er-Hirn also weiter so tun, als könnte ich mitreden - nur besser getarnt...  ;D .

Tatsächlich waren mir die funktionalen Zusammenhänge soweit sogar klar, ohne jeweils die Vokabel dafür zu haben. Aber mein Gefühl bei der Sache ist jetzt wesentlich besser: Die Verwendung der constants im konkreten Fall entspricht genau dem Zweck, für die sie gedacht sind: benötigt wird nur eine sehr minimalistische Funktion, Gebrauch nur zu internen Zwecken, da wirklich nur zum referenzieren => tatsächlich gut akeptabler Ausnahmefall und vermutlich effizientester Umgang (?) mit dem "ehemals raren Gut" (?) Speicher...

Btw.: mein "echter Einstieg" in's "Programmieren" war mit Arduino/MySensors; Man kann über das Arduino-framework denken, was man will, aber in jedem Fall schärft das mit den kleinen Microcontrollern auch ein wenig den Blick auf Speicheraspekte - auch wenn man als noob in der Regel nur ein paar Grundregeln lernt - aber eben schnell merkt, wenn was komplett in die falsche Richtung läuft... ;D .

(Unkraut zupfen ist übrigens nicht verkehrt, das lehrt Demut... und paßt zu einem meiner Lieblingssprüche: "Mühsam ernährt sich das Eichhörnchen" - gilt auch für's "Lernen von FHEM". Oder etwa nicht, alle miteinander...?!?
Grill war übrigens die Tage schon in Betrieb, Kohle kam vom "Lagerhaus", wie man früher so schön sagte.)
Titel: Antw:Wunschlliste Themen
Beitrag von: marvin78 am 01 April 2020, 12:53:02
Zitat von: RichardCZ am 01 April 2020, 12:49:10
Hat eigentlich jeder Baumarkt.  ;)

Die sind aber nicht mehr überall geöffnet.
Titel: Antw:Wunschlliste Themen
Beitrag von: DS_Starter am 01 April 2020, 12:57:15
ZitatHat eigentlich jeder Baumarkt.
Ich glaube Hermann meinte die Kohle für die Kohle aus dem Baumarkt.  :D
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 13:01:57
Zitat von: Beta-User am 01 April 2020, 12:50:25
...Grill war übrigens die Tage schon in Betrieb...
Wie jetzt? War der aus? Ein technischer Defekt ?
Titel: Antw:Wunschlliste Themen
Beitrag von: herrmannj am 01 April 2020, 13:02:41
Zitat von: DS_Starter am 01 April 2020, 12:57:15
Ich glaube Hermann meinte die Kohle für die Kohle aus dem Baumarkt.  :D
In der Tat. (btw: hier für Gas .. )
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 01 April 2020, 13:05:44
Zitat von: DS_Starter am 01 April 2020, 12:57:15
Ich glaube Hermann meinte die Kohle für die Kohle aus dem Baumarkt.  :D
Stimmt, da war die Verwendung des Literal value wohl außerhalb des Lexical scope... :P



Zitat von: herrmannj am 01 April 2020, 13:01:57
Wie jetzt? War der aus? Ein technischer Defekt ?
Soviel Kohle für soviel Kohle wollte ich halt nicht ausgeben, außerdem mußte jemand auch mal weg, um Kohle für Kohle zu beschaffen, was dann wieder zu Problemen bei der akuten Versorgung der brennenden Kohle gesorgt hätte. Habe daher auf den Einsatz von passenden Pragmas verzichtet und das Ding ganz praktisch auf der Terrasse bereitgehalten zum jederzeitigen Einsatz. hat ein paar Mal geklappt, ohne dass der Speicher für die vorhandene Kohle leer geworden wäre...
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 19 April 2020, 19:10:15
Ich möchte meine Wunschliste um einen weiteren Punkt erweitern über den ich heute hier schon zweimal gestolpert bin :

=pod
...
...
=cut

das war bisher für mich immer "nur" lästige Pflicht die Doku zur command.ref im Modul unterzubringen. D.h. über Syntax habe ich nie einen Gedanken verschwendet, sondern bei den anderen einfach abgeschrieben so das die Hilfe später ordenlich angezeigt und fehlerfrei durch die ganzen Prüfungen geht.
Nun lese ich heute das wir doch bitte das eine oder andere dort noch hinzufügen mögen oder das wir uns mit der eigenen History auch dort hin verziehen sollen.

Daher : wäre es möglich irgendwann mal einen mini Abschnitt als Beispiel zu haben ? Bitte dabei auch an das Thema Meta.pm denken da dafür ja auch noch ein zusätzlicher Block
=for :application/json;q=META.json
=end :application/json;q=META.json
einzutragen ist.


 
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 19 April 2020, 19:33:02
Zitat von: Wzut am 19 April 2020, 19:10:15
Daher : wäre es möglich irgendwann mal einen mini Abschnitt als Beispiel zu haben ? Bitte dabei auch an das Thema Meta.pm denken da dafür ja auch noch ein zusätzlicher Block

=> https://forum.fhem.de/index.php/topic,109740.msg1044645.html#msg1044645

Die nicht-so-Mini Beispiele werden dort wachsen, weil das Ziel einer "One Source Strategy" ja sein soll, dass man nicht code und Doku an zwei Stellen pflegen muss.
Also bitte ab und zu dort nachsehen. Ich werde auch versuchen neben der ganzen boilerplate auch die commandref Geschichten unterzubringen.

Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 23 April 2020, 21:21:53
und der nächste Punkt : Variablen vs. Konstanten.
Ich bin da im 10_MAX Modul über ein paar Stellen gestolpert wo u.a. bei jedem FHEMWEB Set ? Aufruf eine große Temeraturliste gebaut wird.
Ich habe mir die ganze Liste mal im Log ausgeben lassen und danach die Variable entfernt und gegen eine Konstante ersetzt , Bsp :
use constant TEMPLIST => 'off,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,on';
bevor  ich da jetzt noch andere Bandwürmer umbaue die Gretchenfrage : sinnvoll ja oder nein ?
Titel: Antw:Wunschlliste Themen
Beitrag von: Christoph Morrison am 23 April 2020, 22:04:06
Zitat von: Wzut am 23 April 2020, 21:21:53
bevor  ich da jetzt noch andere Bandwürmer umbaue die Gretchenfrage : sinnvoll ja oder nein ?

Sinnvoll wäre es, eine Funktion irgendwo zu haben, z.B. in 99_Utils.pm/Uconv.pm, der man "gib mir eine Temperaturliste von x bis y mit Interval i in Kelvin/Fahrenheit/Schuhgrößen" sagt und bekommt dann eine ordentliche Liste zurück, die man dann als Readonly irgendwo speichert. Ich möchte nicht wissen, in wie vielen Modulen es selbstgebastelte Temperaturlisten gibt.

Aber deine Idee ist schon ein Stück besser als wie es jetzt ist, schätze ich. Gibt es 10_MAX irgendwo, wo man mit drauf schauen kann (Github/Gitlab/Bitbucket/was weiß ich)?
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 24 April 2020, 06:21:58
Zitat von: Christoph Morrison am 23 April 2020, 22:04:06
Sinnvoll wäre es, eine Funktion irgendwo zu haben, z.B. in 99_Utils.pm/Uconv.pm, der man "gib mir eine Temperaturliste von x bis y mit Interval i in Kelvin/Fahrenheit/Schuhgrößen" sagt und bekommt dann eine ordentliche Liste zurück, die man dann als Readonly irgendwo speichert. Ich möchte nicht wissen, in wie vielen Modulen es selbstgebastelte Temperaturlisten gibt.

This.

Und analog zu unserer "ersten Challenge" - wo wäre ein besserer Ort als hier so einen generischen und robusten Utils-Code auszuarbeiten?
Titel: Antw:Wunschlliste Themen
Beitrag von: Wzut am 24 April 2020, 07:43:58
Zitat von: Christoph Morrison am 23 April 2020, 22:04:06
Ich möchte nicht wissen, in wie vielen Modulen es selbstgebastelte Temperaturlisten gibt.
----snipp ----
Gibt es 10_MAX irgendwo

a. das werden einige sein, in 38_BEOK habe ich damals auch ne eigene gebaut :) und IMHO sind alle ein kleines Stück andres da die Hardware i.d.R. eben ihren eigenen min/max Bereich hat.

b. natürlich , seit vielen Jahren im svn : 10_MAX.pm
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 24 April 2020, 08:08:29
Da gibt es vermutlich in der Tat einige (weekprofile würde mir einfallen, das aber on/off wieder anders löst).

Es gibt auch teilweise einen generischen Ansatz: die FHEMWEB-widgets (https://wiki.fhem.de/wiki/FHEMWEB/Widgets). Die sind aber afaik in Javascript realisiert und nur für FHEMWEB interessant (wie vermutlich das hier  auch). Was bei "selectnumbers" fehlt, wäre die option, weitere Elemente zu ergänzen (und deren Position in der Liste zu bestimmen), neben on/off noch "day", "night", "open", "half", "close"...

Also z.B. so:
attr <device> setList temperature:selectnumbersplus,4.5,0.5,30.5,lin:1,off:0,on:2,day,night
Ziffern hinter den Doppelpunkten für optionale Positionsangaben in der Dropdown-Liste, was nicht dezidiert angegeben ist, wird einfach unten angefügt...
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 24 April 2020, 08:18:52
Anderes Problem:

Wie bekommt man mehrstufige Module mit GPUtils exportiert, so dass die "Initialize"-Funktion auch gefunden wird?

Konkret: die MySensors-Modulfamilie besteht u.a. aus den Packages MYSENSORS und MYSENSORS::DEVICE. "MYSENSORS" ist kein Problem, aber versuche ich den Export bei bei MYSENSORS::DEVICE, wird die Funktion nicht gefunden... Habe dann erst mal ein "FHEM::" vor den Package-Namen plaziert und dann versucht, das ganze über einen wrapper zu lösen. Klappt beides nicht auf die Schnelle.
Vielleicht hat ja einer eine Idee, ohne dass ich da weiter  allzuviel  Zeit reinstecke? Aktuelle Modulfassung mit dem Wrapper-Versuch im Anhang.
Titel: Antw:Wunschlliste Themen
Beitrag von: Christoph Morrison am 24 April 2020, 09:02:49
Zitat von: Wzut am 24 April 2020, 07:43:58
b. natürlich , seit vielen Jahren im svn : 10_MAX.pm

Ich meinte deine Entwicklerversion, bevor sie final im SVN landet.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 24 April 2020, 09:35:54
Zitat von: Beta-User am 24 April 2020, 08:18:52
Anderes Problem:

Wie bekommt man mehrstufige Module mit GPUtils exportiert, so dass die "Initialize"-Funktion auch gefunden wird?

Konkret: die MySensors-Modulfamilie besteht u.a. aus den Packages MYSENSORS und MYSENSORS::DEVICE. "MYSENSORS" ist kein Problem, aber versuche ich den Export bei bei MYSENSORS::DEVICE, wird die Funktion nicht gefunden... Habe dann erst mal ein "FHEM::" vor den Package-Namen plaziert und dann versucht, das ganze über einen wrapper zu lösen. Klappt beides nicht auf die Schnelle.
Vielleicht hat ja einer eine Idee, ohne dass ich da weiter  allzuviel  Zeit reinstecke? Aktuelle Modulfassung mit dem Wrapper-Versuch im Anhang.

GP_Export macht aus MYSENSORS::DEVICE::Init ein main::DEVICE_Init
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 24 April 2020, 10:19:22
Zitat von: RichardCZ am 24 April 2020, 09:35:54
GP_Export macht aus MYSENSORS::DEVICE::Init ein main::DEVICE_Init
:) Das hatte ich schon vermutet. Die eigentliche Frage hinter der Frage war: Wie löst man das am besten auf? Ich sehe folgende Varianten:
- "leave as was" - Initialize bleibt weiter außerhalb des Packages (Bronzezeit oder so...?).
- Package-Struktur der Modulfamilie wird geändert, dieser Teil wird MYSENSORS_DEVICE. Das kommt mir aber kontraproduktiv zu der "angedachten" allgemeinen Modularisierung vor.
- GPUtils-Export wird angepaßt, dass es fhem.pl (?) was "passendes" unterschiebt (z.B. abgeleitet v. Dateinamen statt aus dem letzten Teil des Packages).
- fhem.pl (?) wird geändert, dass es bei "gepackage-ten" Modulen von sich aus "Initialize" sucht (=Verzicht auf Export). Dann müßte jemand Rudi einen patch vorschlagen, der das kann... (Das wäre eigentlich m.E. die "richtige" Lösung ;) ).
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 24 April 2020, 12:53:07
Zitat von: Beta-User am 24 April 2020, 10:19:22
Die eigentliche Frage hinter der Frage war: Wie löst man das am besten auf?

Ich glaube, die eigentliche Frage ist: Was willste haben?  :)
Wenn Du das mal kohärent darstellen kannst, kann ich Code anbieten.
Titel: Antw:Wunschlliste Themen
Beitrag von: Beta-User am 24 April 2020, 13:29:07
Zitat von: RichardCZ am 24 April 2020, 12:53:07
Ich glaube, die eigentliche Frage ist: Was willste haben?  :)
Wenn Du das mal kohärent darstellen kannst, kann ich Code anbieten.
Mir ist es im Prinzip egal. Ich kann das auch auf "as was" belassen (bzw. dahin zurückdrehen) und mit Perlcritic-Gemaule an der Stelle leben :P .

Die anderen Varianten waren eher zur allgemeinen Diskussion gedacht, was der "richtige Weg" ist. Wenn ich das nach meinem Bauchgefühl entscheiden müßte, würde ich mir in fhem.pl eine zentrale Erweiterung von CommandReload() wünschen, die die ganze Exportiererei überflüssig macht (ab https://svn.fhem.de/trac/browser/trunk/fhem/fhem.pl#L2587; das scheint intern von mehreren Stellen her aufgerufen zu werden, v.a. beim auch beim Start). Streng nach dem Motto: Wenn es in dem Package eine "Initialize" (oder von mit aus: "FHEM_Initialize")-Funktion gibt, dann führe die aus, wenn das Modul genutzt wird (via define)...

Alternativ müßte man GPUtils dahingehend "aufschlauen", dass "FHEM::" als Präfix generell verworfen wird (relevant für AutoShuttersControl und evtl. andere) und alle anderen Bestandteile mit einem "_" verbunden werden statt des "::"? Das macht aber nur Sinn, wenn die "Teil-Modul-Benennungsstruktur" ok ist, die MySensors da an der Stelle grade praktizieren.
Auch das kann ich nicht wirklich beantworten. Ich würde dazu neigen, da bei 00_MYSENSORS und 10_MYSENSORS_DEVICE evtl. noch ein FHEM:: davorzusetzen; diese Module arbeiten nur mit FHEM zusammen, die anderen beiden Bauteile (Message.pm/Constants.pm) könnten auch woanders (außerhalb FHEM in der allgemeinen Perl-Welt) genutzt werden... (k.A., ob sie das tun; vermute: nein).
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 24 April 2020, 18:35:27
GP ist ein wenig "matschig". Es macht in diesem Fall überhaupt keinen Unterschied ob man selbst custom-mäßig im Namespace rumfuhrwerkt oder das GP überlässt.
Da GP ohnehin eingeschränkt ist, kann man das auch selbst machen.

Du willst MYSENSORS::DEVICE::Init -> main::MYSENSORS_DEVICE_Init ?

Dann mach doch

*{'main::MYSENSORS_DEVICE_Init'} = *{'Init'};

in MYSENSORS::DEVICE. Das ist auch schon egal.  :)

oder

#!/usr/bin/perl
# For Emacs: -*- mode:cperl; mode:folding -*-

use warnings;
use strict;
use v5.28.1;

package main;

MYSENSORS_DEVICE_Init();


package MYSENSORS::DEVICE;

sub main::MYSENSORS_DEVICE_Init { goto &Init }

sub Init {
    say "Blah";
    return;
}


das sollte "Blah" ausgeben. Das ist sogar etwas sauberer als GP. Aber noch ne Weile und ich entdecke meine Vorliebe für Schlammbäder.
Titel: Antw:Wunschlliste Themen
Beitrag von: RichardCZ am 26 Juni 2020, 17:04:46
Weil ich's "grad sehe":

https://svn.fhem.de/trac/changeset/22270/trunk/fhem/FHEM/98_JsonList2.pm?old=21509&old_path=trunk%2Ffhem%2FFHEM%2F98_JsonList2.pm

Siehe oben in diesem Thread diverse quoting Geschichten.

$ret .= "{ \"Value\":\"".JsonList2_Escape($v->{VAL})."\",";
$ret .=   " \"Time\":\"".JsonList2_Escape($v->{TIME})."\" }";

=>

$ret .= q|{ "Value":"| . JsonList2_Escape($v->{VAL})  . q|",|
      . q| "Time":"|   . JsonList2_Escape($v->{TIME}) . q|" }|;


Und wenn man sich die Sache so scharf anschaut, fragt man sich warum JsonList2_Escape nicht gleich die umliegenden Anführungszeichen setzt, denn das wird bei jedem Aufruf (mühsam - mit angelehnten Zahnstochern) im aufrufenden Code gemacht.

In einem Paralleluniversum würde also der Code so aussehen:

sub JsonList2_Escape {
  my $foo = shift // return q{"null"};

  $foo =~ s/([\x00-\x09\x0b-\x1f\x5c])/sprintf '\u%04x', ord($1)/ge; # Forum 57377
  $foo =~ s/"/\\"/g;
  $foo =~ s/\n/\\n/g;

  my $bar = "x$foo";

  return utf8::decode($bar) ? qq{"$foo"} : q{"<BINARY>"}; # Forum #55318
}


und dann

$ret .= '{ "Value":' . JsonList2_Escape($v->{VAL})  . ','
      . ' "Time":'   . JsonList2_Escape($v->{TIME}) . ' }';