Diese neue Kolumne ist dazu da um sicherzustellen, dass ich nicht in meinem "jugendlichen Leichtsinn"(tm) FHEM code plätte oder unzulässig verändere, der doch irgendwie etwas anderes macht als ich gedacht habe.
Das ist ein Win-Win:
* FHEM bekommt - wenn man es dann adoptieren will - ggf. besseren Code
* Vielleicht bekommt der ein- oder andere Inspiration wie er bei seinem Code was transformieren kann
* Ich habe vielleicht noch das ein oder andere Augenpaar, das den jugendlichen Leichtsinn bremst.
fhem.pl - DoTrigger:
my $events = deviceEvents($hash, $inform{$c}{type} =~ m/WithState/);
$max = int(@{$events});
for (my $i = 0; $i < $max; $i++) {
my $event = $events->[$i];
next if ($re && !($dev =~ m/$re/ || "$dev:$event" =~ m/$re/));
addToWritebuffer($dc,($inform{$c}{type} eq "timer" ? "$tn " : '').
"$hash->{TYPE} $dev $event\n");
}
Ich mache daraus:
my $events = deviceEvents($hash, $inform{$c}{type} =~ m/WithState/);
for my $event (@{$events}) {
next if ($re && !($dev =~ m/$re/ || "$dev:$event" =~ m/$re/));
addToWritebuffer($dc, ($inform{$c}{type} eq "timer" ? "$tn " : '').
"$hash->{TYPE} $dev $event\n");
}
Also klassisches C-for -> Perl-for. Richtig?
man spart sich $max, $i, einen int-Aufruf. Ist kürzer, schneller, leserlicher... ein wenig vielleicht.
$max wird nie wieder gebraucht
Aber wichtig ist mir, dass es nicht falscher ist. Bestätigung/Veto wäre mir ganz recht.
Meistens mache ich solche Änderungen aus der Hüfte und benutze den Perl Interpreter in meinem Kopf - der ist aber nicht ganz fehlerfrei.
Ich bin der Ansicht, dass so ziemlich alle int(@list) in skalaren Zuweisungen, Arithmetik und boolschen Abfragen geknickt werden können.
my $x = int(@list);
my $v = int(@elements) - $max;
if (int(@args))
=>
my $x = @list;
my $v = @elements - $max;
if (@args)
korrekt?
Da ich etwas mehr jugendlicher bin wie Du sage ich mal "in meinem jugendlichen Leichtsinn" das ich Dir auf Basis des hier gezeigten Codes zu stimme.
Naja, grundsätzlich siehts schon mal nicht komplett falsch aus. ;)
Viel weiter lehne ich mich da aber auch nicht aus dem Fenster. Aus der sicheren persönlichen Erfahrung heraus oft genug auf meinen(!) eigenen code geschaut zu haben und zu sagen: "Yepp, sieht gut aus". Ist es auch, zumindest solange bis jemand einen bug meldet.
Zitat von: herrmannj am 31 März 2020, 22:42:19
"Yepp, sieht gut aus". Ist es auch, zumindest solange bis jemand einen bug meldet.
;D
Conway sagt ja auch, dass die Bugs im Code ja nicht einfach so aus dem Nichts erscheinen, sondern dass wir die da aktiv reinmachen.
Er spricht von "Enbugging".
int(@list) -> @list in scalar, numeric and boolean contexts;https://gl.petatech.eu/root/HomeBot/-/commit/f2a99c08c6b47d657472d01bb180d902606d2631
Läuft immer noch, wobei ich ja meine Installation kontinuierlich erweitere um auch mehr zu testen.
Bei dem Entfernen von int(@liste) bin ich aber an einem Punkt unsicher geworden:
if (int(@liste1) == int(@liste2))
ich gleich:
if (@liste1 == @liste2)und dann kurz erschrocken ob das nicht irgendwo klammheimlich eine Zuweisung wird. Aber ne.
Next (fhem.pl - CheckDuplicate)
$duplicate{$duplidx}{ION} = $ioname;
$duplicate{$duplidx}{MSG} = $msg;
$duplicate{$duplidx}{TIM} = $now;
$duplidx++;
return (0, $duplidx-1);
Eh?
$duplicate{$duplidx}{ION} = $ioname;
$duplicate{$duplidx}{MSG} = $msg;
$duplicate{$duplidx}{TIM} = $now;
return (0, $duplidx++);
Bei der ersten Schleife: ich gehe davon aus, dass es identisch ist, weiterhin ist es ca 30% schneller auf meinerm Rechner, allerdings ist der Gewinn pro Schleifendurchlauf mit 100 nanosekunden an dieser Stelle vernachlaessigbar.
Ich habe trotzdem Bauchschmerzen Schoenheitsaenderungen zu uebernehmen, weil ich danach die Begruendung fuer eine Aenderung (svn blame => svn log => Forumsdiskussion) nicht mehr nachvollziehen kann. Im Moment ist mir die Nachvollziehbarkeit mehr Wert als ein marginal schoeneres/kuerzeres Code.
Zitat von: rudolfkoenig am 31 März 2020, 23:41:18
Bei der ersten Schleife: ich gehe davon aus, dass es identisch ist, weiterhin ist es ca 30% schneller auf meinerm Rechner, allerdings ist der Gewinn pro Schleifendurchlauf mit 100 nanosekunden an dieser Stelle vernachlaessigbar.
Ich habe trotzdem Bauchschmerzen Schoenheitsaenderungen zu uebernehmen, weil ich danach die Begruendung fuer eine Aenderung (svn blame => svn log => Forumsdiskussion) nicht mehr nachvollziehen kann. Im Moment ist mir die Nachvollziehbarkeit mehr Wert als ein marginal schoeneres/kuerzeres Code.
"Wenn man sie adoptieren will"
Mir geht es erstmal nur darum ob ich richtig liege, bzw. dass ich mich nicht in einer Transformation verrenne, die dem Code eine andere Semantik aufdrückt,
$x++ = post-increment, die Variable wird inkrementiert
nachdem sie angefasst wurde.
++$x = pre-increment, die Variable wird inkrementiert
bevor sie angefasst wird
$x++;
function($x);
==
function(++$x);
function($x++)
==
function($x);
++$x;Wenn ich also eine Zeile/ein Statement vorher einen post-inkrement mache, ist das als hätte ich ein Statement später ein pre-inkrement gemacht.
Wenn ich dann -1 abziehen muss um zu kompensieren, kann ich gleich ein post-inkrement machen. So meine Überlegung.
Refactoring und PBP sind auch nicht relevant wegen 0 oder 100 Nanosekunden. "Man soll den Code für's Lesen (= Wartung) optimieren". Wenn er dabei nicht langsamer wird ist's ok.
Also es ist offiziell, ich habe irgendwo HoBo leicht zerschossen und weiß noch nicht wo.
Mit meinen bescheidenen FHEM Kenntnissen vermute ich ja, ich habe irgendwo den Notify Mechanismus geschrottet, denn das Einzige was nicht funktioniert ist das
dummy
myLamp1
mySwitch1 on off
aus dem QuickStart Beispiel. Ich schalte Switch on, aber Lamp1 bleibt dunkel. Egal, https://git-scm.com/docs/git-bisect sei dank werde ich das schnell finden.
Zu den marginalen Schönheitsänderungen möchte ich noch folgene Worte loswerden:
Jede alleine für sich betrachtet ist vielleicht eine marginale Schönheitsänderung, aber es gilt das Prinzip der 1000 Nadelstiche. Wenn man den Kelch der marginalen Schönheitsänderungen 100 mal an sich vorüberziehen lässt, dann ist der Unterschied eben nicht mehr so marginal.
Nach allem was ich so sehe, ist FHEM eigentlich eine Engine. Eine Art Interpreter, der User-Code "Steuer-/Ablaufcode Heimsteuerung" ausführt. Diese Engine wirkt auf mich wie Firmware, bzw. wie das Werk eines Embedded-Entwicklers. Das bitte jetzt nicht gleich als Wertung sehen. FHEM enthält einiges an "pretty slick" code, aber am Ende des Tages glaube ich, dass FHEM für das was es tun soll, bzw. welche Komplexität es erreicht hat eben keine Softwarearchitektur einer "Embedded Firmware" haben kann.
Gestern/Heute war ich noch so bis 1 Uhr früh an diversen Änderungen und wollte z.B. das hier:
for my $sdev (@devspecs) {
$arg[0] = $sdev;
$defs{$sdev}->{CL} = $cl if ($defs{$sdev});
my $ret = DoSet(@arg);
delete $defs{$sdev}->{CL} if ($defs{$sdev});
push @rets, $ret if ($ret);
}
In diese Richtung umwandeln:
for my $sdev (@devspecs) {
$arg[0] = $sdev;
if ($defs{$sdev}) {
$defs{$sdev}->{CL} = $cl; # strange
delete $defs{$sdev}->{CL}; # ?
}
my $ret = DoSet(@arg);
push @rets, $ret if ($ret);
}
Bei jedem normalen Code könnte man das machen, aber nicht so bei FHEM. Da es dort von globalen Variablen nur so wimmelt, und DoSet in einer dunklen Ecke potentiell auch etwas unredliches mit %defs macht, kann man eben nicht so vorgehen. Ein Minenfeld. Man sieht aber, dass da irgendwas in defs gesetzt wird nur um es nach dem DoSet-Aufruf wieder zu löschen. Sehr suspekt.
$hash->{CL} enthaelt den Kanal, worueber der Befehl getriggert wurde. Soll GetFn/SetFn/AttrFn ermoeglichen eine passende Antwort zu generieren, z.Bsp. die Ergebnisse zeitversetzt dem richtigen Browserfenster zu schicken.
Ja, ich wuerde es auch anders machen, wenn ich SetFn/GetFn aller Module schnell umbauen koennte.
Zitatkeine Softwarearchitektur einer "Embedded Firmware" haben kann.
"kann" ist nachweislich falsch, "sollte" ist richtig. Ich habe aber weder Zeit noch Lust das Gleiche nochmal komplett neu zu bauen, damit FHEM aus architektonischer Sicht schoen wird, geschweige denn hunderte von Entwickler und tausende von Benutzer dazu zu ueberreden. Und die Unwartbarkeit der aktuellen Loesung sehe ich noch nicht erreicht.
Zitat von: rudolfkoenig am 01 April 2020, 10:54:56
Und die Unwartbarkeit der aktuellen Loesung sehe ich noch nicht erreicht.
Die Definition von
nicht Unwartbar ist nicht "Es gibt genau eine Person auf diesem Planeten die sich damit auskennt."
Hätte ich Dein ganzes implizites Wissen um FHEM, sähe ich die Sache vielleicht auch noch anders, aber Du darfst nicht vergessen, dass ab dem Zeitpunkt ab dem Du die Unwartbarkeit siehst, sind wir alle verloren.
Das "noch" in Deinem Satz macht mir Angst. ;)
Ich muss erhebliche Mittel aufwenden (Zeit, Hirnschmalz), um das Ding zu verstehen - ist kein Vorwurf, ich mache das tatsächlich gerne - aber die "irrsinnige Energie" die ich dafür aufwenden muss ist ja gerade die Antithese zu Wartbarkeit. Ich verstehe zu 100%, dass Du da nix anfassen willst, weil ich bin auch nicht gerade unvorsichtig mit meinen Änderungen und es fliegt mir ständig um die Ohren.
Von daher: Dieser Thread geht um mein "kosmetisches Gewurschtel". Die Beispiele (C-for -> Perl-for, inkrement/dekrement-Akrobatik,...) sind auch auf Module anwendbar. Wenn ein Maintainer sieht "hey, das könnte ich ja auch machen", und es klappt dann ist das doch gut!
Und ich bekomme auch Feedback, ob ich mit dem Skalpell nicht zu tief ansetze.
Zitat von: RichardCZ am 01 April 2020, 09:44:57
Also es ist offiziell, ich habe irgendwo HoBo leicht zerschossen und weiß noch nicht wo.
Mit meinen bescheidenen FHEM Kenntnissen vermute ich ja, ich habe irgendwo den Notify Mechanismus geschrottet, denn das Einzige was nicht funktioniert ist das
dummy
myLamp1
mySwitch1 on off
aus dem QuickStart Beispiel.
gefunden. Da war ich wohl mit einer zu dicken Hose unterwegs. Das war die kaputte Transformation. Also reverted und nochmal das Ganze - diesmal behutsamer.
https://gl.petatech.eu/root/HomeBot/-/commit/f2a99c08c6b47d657472d01bb180d902606d2631#a4d383d38f91a3fa72c9aa6c51c000184e6da1ae_3546_3549
3553 return if (ref $hash->{CHANGED} eq 'ARRAY');
Sicher daß es eq und nicht ne heißen muss?
Zitat von: CoolTux am 01 April 2020, 20:31:26
3553 return if (ref $hash->{CHANGED} eq 'ARRAY');
Sicher daß es eq und nicht ne heißen muss?
Ich glaube, jetzt bin ich mir relativ sicher, dass es ne heißen muss. ;)
Aber vor allem muss ich mal mit den Tests anfangen, weil alles immer nach Änderungen durchklicken - da wirste ja irre.
Naja orig... halt ne ältere Version
sub GetTimeSpec_orig {
my $tspec = shift;
my ($hr, $min, $sec, $fn);
if ($tspec =~ m/^([0-9]+):([0-5][0-9]):([0-5][0-9])$/) { # HH:MM:SS
($hr, $min, $sec) = ($1, $2, $3);
}
elsif ($tspec =~ m/^([0-9]+):([0-5][0-9])$/) { # HH:MM
($hr, $min, $sec) = ($1, $2, 0);
}
elsif ($tspec =~ m/^{(.*)}$/) { # {function}
$fn = $1;
$tspec = AnalyzeCommand(undef, "{$fn}");
$tspec = "<empty string>" if (!$tspec);
my ($err, $fn2);
($err, $hr, $min, $sec, $fn2) = GetTimeSpec($tspec);
return ("the function \"$fn\" must return a timespec and not $tspec.",
undef, undef, undef, undef) if ($err);
}
else {
return ("Wrong timespec $tspec: either HH:MM:SS or {perlcode}",
undef, undef, undef, undef);
}
return (undef, $hr, $min, $sec, $fn);
}
wurde erstmal zu:
sub GetTimeSpec {
my $tspec = shift;
if ($tspec =~ m/^([0-9]+):([0-5][0-9]):([0-5][0-9])$/) { # HH:MM:SS
return (undef, $1, $2, $3, undef); # hr, min, sec, fn = undef
}
if ($tspec =~ m/^([0-9]+):([0-5][0-9])$/) { # HH:MM
return (undef, $1, $2, 0, undef);
}
if ($tspec =~ m/^{(.*)}$/) { # {function}
my $fn = $1;
$tspec = AnalyzeCommand(undef, "{$fn}") || '<empty string>';
my ($err, $hr, $min, $sec, $fn2) = GetTimeSpec($tspec);
return ("the function \"$fn\" must return a timespec and not $tspec.",
undef, undef, undef, undef) if ($err);
return (undef, $hr, $min, $sec, $fn); # if !$err
}
# default
return ("Wrong timespec $tspec: either HH:MM:SS or {perlcode}",
undef, undef, undef, undef);
}
Zustimmung?
Reguläre Ausdrücke sind auch eine ziemliche Achillesferse von FHEM. Ich habe erstmal die kaputten Regexen dringelassen "tut ja auch so".
Aber
if ($tspec =~ m/^([0-9]+):([0-5][0-9])$/) { # HH:MM
Ne Leute ... sicher nicht.
9999999999999994324234723947203947320947230:59 ist ne valide Uhrzeit?
Bitte nach dem "Fix" nicht vergessen eine Erklaerung fuer die zu basteln, deren at mit sunrise im ersten oder sunset im zweiten Halbjahr nicht mehr funktioniert.
Zitat von: rudolfkoenig am 02 April 2020, 09:01:48
Bitte nach dem "Fix" nicht vergessen eine Erklaerung fuer die zu basteln, deren at mit sunrise im ersten oder sunset im zweiten Halbjahr nicht mehr funktioniert.
Dann muss der Fix anders aussehen. Nämlich den Kommentar ändern.
# compute the list of defined logical modules for a physical module
sub
computeClientArray($$)
{
my ($hash, $module) = @_;
my @a = ();
my @mRe = split(":", $hash->{Clients} ? $hash->{Clients}:$module->{Clients});
foreach my $m (sort { $modules{$a}{ORDER}.$a cmp $modules{$b}{ORDER}.$b }
grep { defined($modules{$_}{ORDER}) } keys %modules) {
foreach my $re (@mRe) {
if($m =~ m/^$re$/) {
push @a, $m if($modules{$m}{Match});
last;
}
}
}
$hash->{".clientArray"} = \@a;
return \@a;
}
* foreach -> for, @a -> @client_array, prototypen weg ein wenig umsortieren und ich glaube, es ist:
sub computeClientArray {
my $hash = shift;
my $module = shift;
my @client_array = ();
my @mRe = split ":", $hash->{Clients} ? $hash->{Clients}:$module->{Clients};
for my $m (sort { $modules{$a}{ORDER}.$a cmp $modules{$b}{ORDER}.$b }
grep { defined($modules{$_}{ORDER}) } keys %modules) {
CCA_INNER1:
for my $re (@mRe) {
next CCA_INNER1 if ($m !~ m/^$re$/);
push @client_array, $m if ($modules{$m}{Match});
last CCA_INNER1;
}
}
$hash->{".clientArray"} = \@client_array;
return \@client_array;
}
So. Das ist wohl noch nicht das Ende der Fahnenstange, denn jetzt erst kapiere ich ein wenig mehr was das Ding macht.
Die Inner-Loop tut vermutlich
if (first { $m =~ m/^$_$/ } @mRe) {
push @client_array, $m if ($modules{$m}{Match});
}
Wir erinnern uns first aus List::Util. Falls die aber echt das tut, kann man auch gleich
push @client_array, $m if ($modules{$m}{Match}
&& first { $m =~ m/^$_$/ } @mRe);
machen, weil der push geschieht ja nur wenn eine Regex gefunden wurde UND dieser "Match" hash-lookup tut.
Da UND kommutativ ist, kann man das letztere UND vorziehen. Falls das fehlschlägt macht der interpreter einen shortcut und evaluiert den zweiten ausdruck (first ...) gar nicht mehr.
Ich würde meinen, das ist im Schnitt so ne Größenordnung schneller. Ok, können wieder nur ein paar Mikrosekunden hier und da sein, aber hey! Eichhörnchenernährung und so...
Also dann bin ich erstmal bei
sub computeClientArray {
my $hash = shift;
my $module = shift;
my @client_array = ();
my @mRe = split m{:}xms, $hash->{Clients} ? $hash->{Clients}:$module->{Clients};
for my $m (sort { $modules{$a}{ORDER}.$a cmp $modules{$b}{ORDER}.$b }
grep { defined($modules{$_}{ORDER}) } keys %modules) {
push @client_array, $m if ( $modules{$m}{Match}
&& first { $m =~ m/^$_$/ } @mRe);
}
return $hash->{'.clientArray'} = \@client_array;
}
split und die äußere Schleife schaue ich mir ein anderes mal an. Mal schauen, was mir jetzt um die Ohren fliegt. ;)
Hm...
Offensichtlich dient das hier dazu $hash->{'.clientArray'} zu setzen, warum machen wir das nicht gleich?
sub computeClientArray {
my $hash = shift;
my $module = shift;
my @mRe = split m{:}xms, $hash->{Clients} ? $hash->{Clients}
: $module->{Clients};
$hash->{'.clientArray'} = [];
for my $m (sort { $modules{$a}{ORDER}.$a cmp $modules{$b}{ORDER}.$b }
grep { defined($modules{$_}{ORDER}) } keys %modules) {
if ($modules{$m}{Match} && first { $m =~ m{\A$_\z}xms } @mRe) {
push @{$hash->{'.clientArray'}}, $m;
}
}
return $hash->{'.clientArray'};
}
Ich denke, so lasse ich das jetzt erstmal.
globale Variablen sind böse. Aber bevor ich auf die losgehe, suche ich mir - gemein wie ich bin - erstmal ein schwächeres Opfer:
my $srandUsed;
Dem werd' ich's jetzt zeigen! Erst schaut man nach, ob er einen Hinterhalt (im Sinne von Support, nicht im Sinne von Hinterhalt)
in der Community hat:
$ grep -r '$srandUsed' *
FHEM/98_todoist.pm:my $srandUsed;
hobo.pl:my $srandUsed;
hobo.pl: srand(gettimeofday()) if (!$srandUsed++);
hobo.pl: srand(gettimeofday()) if (!$srandUsed++);
Nicht viel. Die Nutzung in 98_todoist.pm ist komplett fake und die drei Zeilen in hobo.pl/fhem.pl haben keine Chance gegen mich.
$srandUsed wird verwendet um "nur einmal" srand aufzurufen bevor man dann im weiteren Verlauf des Programms rand nutzt
(um UUIDs zu generieren)
Erstmal schaut man nach, wofür srand überhaupt da ist https://perldoc.perl.org/functions/srand.html
Dann stellt man fest es dient dazu, dass rand() ein wenig zufälliger wird. Ansonsten ist rand ja nur ein Pseudozufallsgenerator.
Nun ist die Ganze UUID Geschichte keine Kryptographieanwendung, aber es wäre ziemlich uncool, wenn da immer nur gleiche
UUIDs aus den Funktionen purzeln würden.
Theoretisch könnte man sich nun auf den Standpunkt stellen, dass stets ein srand vor einem rand in diesem Fall nix ausmacht,
insbesondere wenn man als seed Mikrosekunden reinjagt, aber wer weiß was das mit der Performance macht. Auf der anderen
Seite ist einfach nur die Zeit zu verwenden bei einem srand nicht unbedingt best practice. Am besten wir knödeln dort noch die
Prozess-Id mit rein. srand(gettimeofday() . $$)
So. Zurück zu unserem Opfer, $srandUsed. Sich da einfach mitten im Quelltext als modulglobale Variable breitmachen
geht ja nun gar nicht. Könnte man da nicht ein tolles Feature von Perl 5.10.1 nutzen und statische Variablen benutzen?
Also sowas:
sub createUniqueId {
state $srandUsed = 0;
srand(gettimeofday() . $$) if (!$srandUsed++);
my $uniqueID = join '', map { unpack "H*", chr(rand(256)) } 1..16;
return $uniqueID;
}
Damit hat nun zwar jeder UUID-Generator sein eigenes, privates srandUsed Flag, aber ist doch auch ganz schön.
Und somit kann ich mich endlich meinem Opfer zuwenden:
my $srandUsed;
Muhahahaha.... aha ... doch halt, eine Sache hab' ich noch:
my $uniqueID = join '', map { unpack "H*", chr(rand(256)) } 1..16;
Das ist doch irgendwie komischer Code. "16 mal eine beliebig lange Bytefolge von einem byte ... what?"
Ich mach' das jetzt so:
sub createUniqueId {
state $srandUsed = 0;
srand(gettimeofday() . $$) if (!$srandUsed++);
return sprintf("%02x" x 16, map { rand(256) } 1..16);
}
Und Benchmark meint das Eichhörnchen bekommt wieder was zum Essen:
Benchmark: timing 1000000 iterations of my, orig...
my: 3 wallclock secs ( 2.49 usr + 0.00 sys = 2.49 CPU) @ 401606.43/s (n=1000000)
orig: 3 wallclock secs ( 3.06 usr + 0.00 sys = 3.06 CPU) @ 326797.39/s (n=1000000)
Tja ... schön wär's. Erstmal lautet das Ziel überhaupt Tests zu haben.
Dank der Auslagerung von einigem Code in echte Perl Module (also im Gegensatz zu den meisten Modulen in FHEM) und noch dazu in dafür Vorgesehene Verzeichnisse lib/t kann ich endlich einen "prove" laufen lassen.
$ prove -I lib -r t
t/Export/Attrs/00.load.t ............... 1/1 # Testing Export::Attrs v0.1.0
t/Export/Attrs/00.load.t ............... ok
t/Export/Attrs/01export.t .............. ok
t/Export/Attrs/author-pod-syntax.t ..... skipped: these tests are for testing by the author
t/Export/Attrs/release-distribution.t .. skipped: these tests are for release candidate testing
t/Gentoo/Version/20-version.t .......... ok
All tests successful.
Files=5, Tests=781, 0 wallclock secs ( 0.06 usr 0.01 sys + 0.27 cusr 0.05 csys = 0.39 CPU)
Result: PASS
Hey! 781 Tests. ;)
Gut, die meisten sind noch von Gentoo::Version, aber immerhin und bald schmeisse ich auch einige von Hobo mit rein.
In Other News:
Ich versuche einen Weg zu finden wie man mit dem ganzen Namespace Gewusel fertig wird.
Dazu habe ich mir erstmal 59_WUup.pm vorgenommen und versuche da den use von HttpUtil und UConv sauber hinzubekommen.
Um damit nicht alle anderen Module zu schrotten, habe ich mir erstmal Kopien dieser Files unter lib/HomeBot/* angelegt.
Aber ist noch alles sehr brüchig...
Ja, es ist soweit, ich schreibe mein erstes Modul. Natürlich nehme ich kritisch jeden Punkt in
https://wiki.fhem.de/wiki/DevelopmentModuleIntro
unter die Lupe.
So dachte mir ja heute, man könnte XXX_Initialize eleganter machen. Bislang (nur Beispiel):
sub HMCCU_Initialize ($)
{
my ($hash) = @_;
$hash->{DefFn} = "HMCCU_Define";
$hash->{UndefFn} = "HMCCU_Undef";
$hash->{SetFn} = "HMCCU_Set";
...
}
künftig - so dachte ich:
sub XXX_Initialize {
return {
DefFn => 'XXX_Define', # besser: coderef
UndefFn => 'XXX_UNdef',
...
};
}
Ja denkste!
CommandReload in fhem.pl habe ich um ein $init_hr erweitert, den Initialize-Aufruf erweitert zu
$init_hr = &{ "${fnname}_Initialize" }(\%hash);
und schliesslich das Modul verankern als
$modules{$m} = ref $init_hr eq 'HASH' ? $init_hr : \%hash;
Das sollte - dachte ich - schön rückwärtskompatibel sein mit dem alten Weg (\%hash) und mit dem neuen weg (argumentlos, direkt anonymes hash zurück.
Denn niemand liefert eine Hashref zurück - ist doch logisch. Dachte ich Naivling, ich sende Rudi einen Patch.
Als erstes ist mir natürlich Hobo um die Ohren geflogen. ;)
Ich also Debugmeldungen rein und siehe da:
Hallo: $VAR1 = {
'ClientFilter' => 'telnet',
'Fn' => 'CommandTelnetInform',
'Hlp' => '{on|onWithState|off|log|raw|timer|status},echo all events to this client'
};
Ja klar! Musste ja sein.
98_telnet.pm beendet Initialize mit
$cmds{inform} = { Fn=>"CommandTelnetInform",
ClientFilter => "telnet",
Hlp=>"{on|onWithState|off|log|raw|timer|status},".
"echo all events to this client" };
} # <--- end sub
Verfluchte "$&%""§ !!!
Klar beendet sich dann die Sub mit dem Wert des letzten Statements. Also besagter hashref. (Wert der Zuweisung)
Es kann doch nicht so schwer sein ans Ende der sub ein return; zu pflanzen - oder?
PBP hat's ja schon immer gesagt...
Ich möchte, dass FHEM und HoBo schön synchronisiert laufen. Gleichzeitig, möchte ich aber in HoBo kein "Kraut und Rüben". Daher wird aller FHEM source code bevor er ins HoBo Repository kommt einem automatischen Waschgang unterzogen.
Aus fachlicher Sicht erfolgt eine "Normalisierung des Source Codes"
bislang (kann künftig mehr sein):
* latin1 -> utf-8
* de-htmlentities-ierung (ü -> ü)
* perltidy (http://perltidy.sourceforge.net/tutorial.html)
und ein paar andere Details, die man dem Source erstmal nicht groß ansieht, wie chmod 644 (einige .pm Module in FHEM sind executable)
D.h. jetzt wird erstmal ein Schwall commits im Hobo Repository kommen, die irrsinnig viel Diffs zeigen. Aber, sobald das erledigt ist und irgendjemand aktualisiert sein Modul und ändert nur ein Zeichen, dann wird beim nächsten Version bump im Hobo Repo auch nur dieses eine Zeichen im Diff angezeigt.
Was dann vielleicht magisch aussehen mag, denn dieses Diff erfolgt u.U. in einem source, der strukturell anders aussieht. Magic...
Für die allermeisten Module funktioniert das, ab und zu finde ich welche, die aus mir unerfindlichen Gründen noch zicken. So fällt z.B. bei 00_THZ.pm perltidy auf die Schnauze
Perltidy version is 20200110
/tmp/00_THZ.pm.f2h: Begin Error Output Stream
1: unexpected character decimal 239 (ï) in script
1: unexpected character decimal 187 (») in script
1: unexpected character decimal 191 (¿) in script
1: Giving up after error
Warum - keine Ahnung - ist mir erstmal wurst, solche Module passen halt momentan nicht in die Waschstrasse. :)
Wenn natürlich jemand sein Modul 100 Jahre nicht angefasst hat und vielleicht die gewaschene Version im Hobo Repo als Grundlage für weiteres Hacking machen möchte - nur zu, be my guest.
Der Prozess ist automatisch und sicher bekommt er nicht alles 100%ig hin, aber 80% machen ist besser als 100% wollen - habe ich mal hier irgendwo wiederholt gelesen. ;)
ZitatWarum - keine Ahnung - ist mir erstmal wurst, solche Module passen halt momentan nicht in die Waschstrasse. :)
UTF-8 BOM.
Zitat von: rudolfkoenig am 05 April 2020, 14:02:24
UTF-8 BOM.
Ja, mir schwante schon sowas nachdem ich die Korrelation gesehen habe:
00_THZ.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
10_Itach_IR.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
23_LUXTRONIK2.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
32_withings.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
38_netatmo.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
39_Talk2Fhem.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
55_DWD_OpenData.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
70_JSONMETER.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
70_NEUTRINO.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
70_Pushsafer.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
70_VIERA.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
71_YAMAHA_MC.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
72_XiaomiDevice.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
73_PRESENCE.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
88_Itach_IRDevice.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
93_DbRep.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
95_Alarm.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_Babble.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_Dashboard.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_FLOORPLAN.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_PostMe.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_remotecontrol.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
95_YAAHM.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
98_alarmclock.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
98_cloneDummy.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
98_DSBMobile.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
98_livetracking.pm: Perl5 module source, UTF-8 Unicode (with BOM) text, with very long lines
98_statistics.pm: Perl5 module source, UTF-8 Unicode (with BOM) text
98_todoist.pm: Perl5 module source, UTF-8 Unicode (with BOM) textAlles Perltidy Fehler:
/tmp/00_THZ.pm.f2h.ERR /tmp/38_netatmo.pm.f2h.ERR /tmp/59_PROPLANTA.pm.f2h.ERR /tmp/70_VIERA.pm.f2h.ERR /tmp/73_PRESENCE.pm.f2h.ERR
/tmp/10_Itach_IR.pm.f2h.ERR /tmp/39_Talk2Fhem.pm.f2h.ERR /tmp/70_JSONMETER.pm.f2h.ERR /tmp/71_YAMAHA_MC.pm.f2h.ERR /tmp/88_Itach_IRDevice.pm.f2h.ERR
/tmp/23_LUXTRONIK2.pm.f2h.ERR /tmp/55_DWD_OpenData.pm.f2h.ERR /tmp/70_NEUTRINO.pm.f2h.ERR /tmp/72_FRITZBOX.pm.f2h.ERR
/tmp/32_withings.pm.f2h.ERR /tmp/59_OPENWEATHER.pm.f2h.ERR /tmp/70_Pushsafer.pm.f2h.ERR /tmp/72_XiaomiDevice.pm.f2h.ERR
Was kann man da machen? Recode?
Das wuesste ich auch gerne.
Die Maintainer bitten sich das mit perltidy einmal an zu schauen.
Ok. Also erstmal muss man rausfinden ob BOM ja oder nein. HIerzu fragt man bei dem Unicode Konsortium nach:
Zitat2.6 Encoding Schemes
... Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature. See the "Byte Order Mark" subsection in Section 16.8, Specials, for more information.
Das interpretiere ich jetzt mal als klares NEIN.
Dann muss man rausfinden, wie man es los wird.
$ dos2unix 00_THZ.pm
dos2unix: converting file 00_THZ.pm to Unix format...
$ file 00_THZ.pm
00_THZ.pm: Perl5 module source, UTF-8 Unicode text, with very long lines
$ perltidy 00_THZ.pm
(kein Fehler) -> Profit!
edit:
das sieht relativ gut aus, etliche rauschen jetzt auch durch. Aber nicht alle
00_THZ.pm...
10_Itach_IR.pm...
38_netatmo.pm...
59_PROPLANTA.pm...
## Please see file /tmp/59_PROPLANTA.pm.f2h.ERR
70_VIERA.pm...Perltidy version is 20200110
/tmp/59_PROPLANTA.pm.f2h: Begin Error Output Stream
1: unexpected character decimal 239 (<EF>) in script
1: unexpected character decimal 187 (<BB>) in script
1: unexpected character decimal 191 (<BF>) in script
1: Giving up after errorMuss ich bei Gelegenheit gugge.
edit2:
PROPLANTA OPENWEATHER und FRITZBOX sind irgendwie stur.
IMHO beginnen alle diese Dateien nicht mit HEX23 = # , sondern mit einem HEX EF ?
Edit : ok hat Richard schon gefunden , bleiben noch BB & BF
und 95_YAAHM bockt auch irgendwie, aber anders als alle anderen:
/tmp/95_YAAHM.pm.f2h: Begin Error Output Stream
1029: already saw definition of 'sub YAAHM_restore' in package 'main' at line 357
1991: already saw definition of 'sub YAAHM_setWeeklyTime' in package 'main' at line 358
4401: To see 1 non-critical warnings rerun with -w
Noch k.A. aber da ich mir bei der Gelegenheit auch den Source angesehen habe:
https://gl.petatech.eu/root/HomeBot/-/blob/master/FHEM/95_YAAHM.pm#L4163
möchte ich schon anmerken, dass es sowas wie HEREDOCs gibt.
(siehe z.B. https://perlmaven.com/here-documents)
Zitat von: RichardCZ am 05 April 2020, 13:41:00
Aber, sobald das erledigt ist und irgendjemand aktualisiert sein Modul und ändert nur ein Zeichen, dann wird beim nächsten Version bump im Hobo Repo auch nur dieses eine Zeichen im Diff angezeigt.
Was dann vielleicht magisch aussehen mag, denn dieses Diff erfolgt u.U. in einem source, der strukturell anders aussieht. Magic...
Ich muss mich natürlich loben (macht ja sonst keiner) - das scheint zu funktionieren:
https://gl.petatech.eu/root/HomeBot/-/commit/295596c9328eecb738970a366350019d11987331
Ich würde dir ja einen Keks geben wenn sich sehen könnte was die Waschstrasse abgewaschen hat.
Was ich da sehe sind lediglich die Diffs zum Vorgänger ? Gerade das Thema UTF8 hätte mich interessiert ob da nun alles stimmt,
98_DSBMobile hatte offensichtlich kein Problem mit Perltidy (verwende ich ohnehin immer) aber falsches encoding. Hab das mal geändert und eingecheckt- macht sich das bei dir jetzt irgendwie bemerkbar?
Gesendet von iPhone mit Tapatalk
Zitat von: KernSani am 06 April 2020, 07:53:09
98_DSBMobile hatte offensichtlich kein Problem mit Perltidy (verwende ich ohnehin immer) aber falsches encoding. Hab das mal geändert und eingecheckt- macht sich das bei dir jetzt irgendwie bemerkbar?
Gesendet von iPhone mit Tapatalk
Sieht nicht so aus, das Encoding ist ja bereits teil der Normalisierung:
https://gl.petatech.eu/root/HomeBot/-/commit/29d9e22953d6ece9d3d718290d022738afb7fbd1
ein paar andee diffs sind wohl drin. Für mich sieht auch das funktional aus.
Zitat von: Wzut am 06 April 2020, 07:29:14
Ich würde dir ja einen Keks geben wenn sich sehen könnte was die Waschstrasse abgewaschen hat.
Was ich da sehe sind lediglich die Diffs zum Vorgänger ? Gerade das Thema UTF8 hätte mich interessiert ob da nun alles stimmt,
Was die Waschstraße abwäscht sieht man in den riesigen diffs von gestern. Ab dem Zeitpunkt waren im Hobo die normalisierten Codes die Basis und ab dann - da ja jeder neue diff vom SVN auch durch die Normalisierung gejagt wird - sieht man eben nur noch den diff den man auch im SVN sieht ... nur eben in einem perltidy-formatierten code.
vgl.
https://svn.fhem.de/trac/changeset?reponame=&new=21606%40%2F&old=21605%40%2F
und
https://gl.petatech.eu/root/HomeBot/-/commit/295596c9328eecb738970a366350019d11987331?view=inline#caf2fc0b293b32e58dd0a79f5e73513fec123413_1_1
("view inline" - vmtl. besser, weil es im FHEM trac per default auch so angezeigt wird.)
Zitat von: RichardCZ am 04 April 2020, 20:36:51
künftig - so dachte ich:
sub XXX_Initialize {
return {
DefFn => 'XXX_Define', # besser: coderef
UndefFn => 'XXX_UNdef',
...
};
}
Man bekommt es schon ein wenig auch so hin:
my %hash = (test => 1);
Moerder_Init(\%hash); # oder halt eben &{$initfn}(\%hash) siehe CommandReload
sub Moerder_Init {
my $hash = shift;
%{$hash} = (
%{$hash},
DefFn => 'Knödel',
UndefFn => 'Dödel',
SetFn => 'Moe',
GetFn => 'Larry',
ReadFn => 'Curly',
);
}
Dieses %{$hash} im hash ist nicht notwendig, wenn man weiß, dass an Init kein vorbelegtes hash übergeben wurde (was - soweit ich das überblicken kann - auch nicht der Fall ist) ansonsten will man eventuell obiges
test => 1 nicht verlieren. Also zumeist einfach kurz:
sub Moerder_Init {
my $hash = shift;
%{$hash} = (
DefFn => 'Knödel',
UndefFn => 'Dödel',
SetFn => 'Moe',
GetFn => 'Larry',
ReadFn => 'Curly',
);
}
Man spart sich also die ganzen
$hash->{xxx} = yyy; Hash lookups/settings pro Zeile und macht das in einem Aufwasch.
Zitat von: RichardCZ am 06 April 2020, 12:01:09
Man spart sich also die ganzen $hash->{xxx} = yyy; Hash lookups/settings pro Zeile
Nun gut , aber an der Stelle sehe ich den Nutzen nicht.
Neue FHEM Module sind für mich wie mein alter Lego Baukasten, (copy & paste) und ob der erste 8er Stein nun weiß oder rot ist, ich klick ihn einfach auf die Grundplatte, Hauptsache er sitzt fest und nicht locker :)
Zitat von: Wzut am 06 April 2020, 13:24:30
Nun gut , aber an der Stelle sehe ich den Nutzen nicht.
Du sollst ja auch nicht Deine Termine beim Optiker schwänzen. ;)
Altkanzler Schmidt hat zwar mal gesagt, wer Visionen hat soll zum Arzt gehen, aber ich
denke, ein wenig strategische Voraussicht kann nicht schaden.
sub Moerder_Init_jetzt {
my $hash = shift;
$hash->{DefFn} = "Knödel";
$hash->{UndefFn} = "Dödel";
$hash->{SetFn} = "Moe";
$hash->{GetFn} = "Larry";
$hash->{ReadFn} = "Curly";
}
sub Moerder_Init_dann {
my $hash = shift;
%{$hash} = (
DefFn => 'Knödel',
UndefFn => 'Dödel',
SetFn => 'Moe',
GetFn => 'Larry',
ReadFn => 'Curly',
);
}
sub Moerder_Init_noch_spaeter {
return {
DefFn => 'Knödel',
UndefFn => 'Dödel',
SetFn => 'Moe',
GetFn => 'Larry',
ReadFn => 'Curly',
};
}
sub Moerder_Init_noch_spaeter_eventuell {
return {
DefFn => \&Knoedel,
UndefFn => \&Doedel',
SetFn => \&Moe,
GetFn => \&Larry,
ReadFn => \&Curly,
};
}
Zitat von: Wzut am 06 April 2020, 13:24:30
Neue FHEM Module sind für mich wie mein alter Lego Baukasten, (copy & paste)
...und genau deswegen hat FHEM 1 mio Zeilen redundanten Code, dessen Funktionalität man auch in 100k Zeilen hinbekommen würde.
Zitat von: RichardCZ am 06 April 2020, 13:46:55
Altkanzler Schmidt hat zwar mal gesagt, wer Visionen hat soll zum Arzt gehen, ...
Wer hat uns verraten ... ;D
Ab und zu schaue ich zurück was mit dem Code "nach einer Reihe marginaler Codeänderungen" passiert ist:
fhem.pl
sub
IsDevice($;$)
{
my $devname = shift;
my $devtype = shift;
return 1
if ( defined($devname)
&& defined( $defs{$devname} )
&& (!$devtype || $devtype eq "" ) );
return 1
if ( defined($devname)
&& defined( $defs{$devname} )
&& defined( $defs{$devname}{TYPE} )
&& $defs{$devname}{TYPE} =~ m/^$devtype$/ );
return 0;
}
HomeBot::Device modul
sub IsDevice :Export {
my $devname = shift // return 0;
my $devtype = shift || return 1;
my $dev_hr = $main::defs{$devname} // return 0;
my $type = $dev_hr->{TYPE} // return 0;
return 1 if ($type =~ m{\A$devtype\z}xms);
return 0;
}
Von heute auf morgen ging das nicht. Da sind 4-5 Schritte dazwischen - und der neuere Code hat noch bestimmt 2-3 vor sich.
fhem.pl
sub
setKeyValue($$)
{
my ($key,$value) = @_;
my $fName = AttrVal("global", "keyFileName", "uniqueID");
$fName =~ s/\.\.//g;
$fName = $attr{global}{modpath}."/FHEM/FhemUtils/$fName";
my ($err, @old) = FileRead($fName);
my @new;
if($err) {
push(@new, "# This file is auto generated.",
"# Please do not modify, move or delete it.",
"");
@old = ();
}
my $fnd;
foreach my $l (@old) {
if($l =~ m/^$key:/) {
$fnd = 1;
push @new, "$key:$value" if(defined($value));
} else {
push @new, $l;
}
}
push @new, "$key:$value" if(!$fnd && defined($value));
return FileWrite($fName, @new);
}
hobo.pl (nur der teil ab FileRead)
sub setKeyValue {
my $key = shift;
my $value = shift;
my $fName = AttrVal(qw(global keyFileName uniqueID));
$fName =~ s/\.\.//g;
$fName = $attr{global}->{modpath}."/FHEM/FhemUtils/$fName";
my ($err, @old) = FileRead($fName);
my @new = !$err ? grep { ! m{^$key:}xms } @old # if no error, pass non-matching lines 1:1
: ("# This file is auto generated.", # else create new preamble
"# Please do not modify, move or delete it.",
'');
push @new, "$key:$value" if (defined $value); # if value defined, add that k:v as new
return FileWrite($fName, @new); # store (overwrite) file with new values
}
Vermutlich kann man das noch zusammenschnurren. In-place regexp-replace.
Sehe ich richtig, dass der xms Regexp modifier an dieser Stelle ueberfluessig ist, oder uebersehe ich etwas?
Zitat von: rudolfkoenig am 07 April 2020, 11:18:03
Sehe ich richtig, dass der xms Regexp modifier an dieser Stelle ueberfluessig ist, oder uebersehe ich etwas?
PBP 236-241. Es gibt einen durchaus nichtsubtilen Unterschied zwischen "überflüssig" und "nicht zwingend notwendig".
my %blah = (
tralala => 1,
sowieso => 1,
);
Da ist das Komma hinter
sowieso => 1 auch "nicht zwingend notwendig". Jemand würde vielleicht von überflüssig sprechen. Ich nicht.
(ok, JSON-Geschädigte mögen das anders sehen)
m{ ^$key: }xmsWer sich angewöhnt hat JEDE regex mit m{...}xms aufzusetzen, wird mit der Zeit u.A. ein feineres Gespühr für den Unterschied zwischen \A und ^ sowie \z und $ entwickeln, seine Regexen besser formatieren usw. Mittel-/langfristig fährt man so besser. IMHO.
Auf der anderen Seite muss man Selbstbewusst genug sein, um es besser zu wissen als die perl-Voreinstellung, Anfaenger haben auch schwerer, weil man xms _zusaetzlich_ verstehen muss. Ich will damit deine Argumente nicht herunterspielen, will nur sagen, dass auch andere Sichtweisen gibt.
Zitat von: rudolfkoenig am 07 April 2020, 11:46:32
Auf der anderen Seite muss man Selbstbewusst genug sein, um es besser zu wissen als die perl-Voreinstellung, Anfaenger haben auch schwerer, weil man xms _zusaetzlich_ verstehen muss. Ich will damit deine Argumente nicht herunterspielen, will nur sagen, dass auch andere Sichtweisen gibt.
Andere Sichtweisen? Unvorstellbares Konzept. ;)
Bei perlcritic -3 fängt er an /x anzumeckern
bei -2 kommt /m und /s dazu
wenn man's gleich macht ist man das schonmal los.
Ok - Anfänger mal außen vor gelassen (wobei ich ja glaube, wenn man denen sagt "mach m{...}xms", dann machen die das einfach cargo-kult-mäßig"): sehen wir uns das aus der Profi & Semi-Profi Perspektive an:
Ich wollte noch etwas über split schreiben, kann es aber auch gleich hier loswerden.
Das erste Argument von split ist
immer eine Regex. Nun wird split in FHEM so häufig als
split 'blah', $string verwendet, dass ich schon fast glaube, dass die meisten gar nicht wissen, dass 'blah' eine Regex ist. Da täte IMHO ein
split m{blah}, $string schon viel um das Bewusstsein dafür zu schärfen.
Aber dann gibt es ja auch die Semiprofis:
@a = split("[ \t][ \t]*", $def, 3);hier ahnt man wohl dass das eine Regex ist, und man möchte wohl auch "Leerzeichen und Tabs" abfangen. Der Profi würde vorschlagen:
@name = split m{ \s+ }xms, $def, 3;ist jetzt nicht viel länger, IMHO lesbarer, intuitiver und vor allem matcht auch non-breakable spaces (im Idealfall diesen ganzen Sotter: http://jkorpela.fi/chars/spaces.html). Das wären derzeit 403 Stellen, wo man das ein für alle mal verbessern könnte.
$ grep -Fr '[ \t][' * | wc -l
403
Will sagen: Die drei modifier Zeichen machen das Kraut nicht fett, sie erlauben aber wesentlich lesbarere und
korrekte(re) Regexps
Das funktioniert soweit alles gut - neuester Zugang in beiden Repos:
https://gl.petatech.eu/root/HomeBot/-/commit/4baccd217b3b336891d7a41c5183573cee098016
Ich werde den autosync jetzt mit Absicht für ne Weile abschalten, weil ich sehen möchte wie er dann damit zurechtkommt, wenn sich im FHEM mal mehr diffs angesammelt haben.
Da fing alles an:
sub
GetDefAndAttr($;$)
{
my ($d, $dumpFUUID) = @_;
my @ret;
if($d ne "global") {
my $def = $defs{$d}{DEF};
if(defined($def)) {
$def =~ s/;/;;/g;
$def =~ s/\n/\\\n/g;
push @ret,"define $d $defs{$d}{TYPE} $def";
} else {
push @ret,"define $d $defs{$d}{TYPE}";
}
}
push @ret, "setuuid $d $defs{$d}{FUUID}"
if($dumpFUUID && defined($defs{$d}{FUUID}) && $defs{$d}{FUUID});
# exclude attributes, format <deviceName>:<attrName>, space separated list
my @dontSave = qw(configdb:rescue configdb:nostate configdb:loadversion
global:configfile global:version);
foreach my $a (sort {
return -1 if($a eq "userattr"); # userattr must be first
return 1 if($b eq "userattr");
return $a cmp $b;
} keys %{$attr{$d}}) {
next if (grep { $_ eq "$d:$a" } @dontSave);
my $val = $attr{$d}{$a};
$val =~ s/;/;;/g;
$val =~ s/\n/\\\n/g;
push @ret,"attr $d $a $val";
}
return @ret;
}
Mittlerweile bin ich da:
sub GetDefAndAttr {
my $d = shift;
my $dumpFUUID = shift;
my @ret;
if ($d ne 'global') {
my $def = $defs{$d}->{DEF} // '';
$def =~ s/;/;;/g;
$def =~ s/\n/\\\n/g;
push @ret, "define $d $defs{$d}->{TYPE} $def";
}
push @ret, "setuuid $d $defs{$d}->{FUUID}"
if ($dumpFUUID && defined($defs{$d}->{FUUID}) && $defs{$d}->{FUUID});
# exclude attributes, format <deviceName>:<attrName>, space separated list
my @dontSave = qw(configdb:rescue configdb:nostate configdb:loadversion
global:configfile global:version);
for my $a (sort {
return -1 if ($a eq "userattr"); # userattr must be first
return 1 if ($b eq "userattr");
return $a cmp $b;
} keys %{$attr{$d}}) {
next if (grep { $_ eq "$d:$a" } @dontSave);
my $val = $attr{$d}->{$a};
$val =~ s/;/;;/g;
$val =~ s/\n/\\\n/g;
push @ret,"attr $d $a $val";
}
return @ret;
}
und würde mich gerne dem zweiten Teil der sub widmen. Erstmal tief durchatmen. Also dass man nicht magische Variablen wie $a verwenden sollte ist bekannt. Dass for-Schleifenvariablen Referenzen auf die iterierte Liste bilden auch. Was zum Geier geschieht da? Welches $a ist welches?
https://de.wikipedia.org/wiki/Obfuscated_Perl_Contest
Wir sollten den vielleicht wieder zum Leben erwecken?
Also, wenn ich das recht verstehe, will die For Schleife alle Schlüssel aus %{$attr{$d}} - abzüglich derer in @dontSave durchlaufen, wobei diese Restschlüssel alphabetisch sortiert sein sollen mit der Spezialität, dass userattr immer erster Eintrag ist. Auf den zugehörigen Hashwerten zu diesen Schlüsseln, wird ein wenig Escaping-Geknödel betrieben, in einer @ret Liste gespeichert und diese zurückgegeben. Ja?
Falls ja, dann:
sub GetDefAndAttr {
my $d = shift;
my $dumpFUUID = shift;
my @ret;
if ($d ne 'global') {
my $def = $defs{$d}->{DEF} // '';
$def =~ s/;/;;/g;
$def =~ s/\n/\\\n/g;
push @ret, "define $d $defs{$d}->{TYPE} $def";
}
push @ret, "setuuid $d $defs{$d}->{FUUID}"
if ($dumpFUUID && defined($defs{$d}->{FUUID}) && $defs{$d}->{FUUID});
# first we build a hash to be able to eliminate exclude attributes in O(1) lookup
my %dontSave = map { $_ => 1 }
qw(configdb:rescue configdb:nostate configdb:loadversion
global:configfile global:version);
# then we generate the list of attributes to iterate in a special sorted way
# (userattr must be first) and filter the %dontsave combinations out
my @attrkeys = grep { ! exists $dontSave{"$d:$_"} }
sort { return -1 if ($a eq 'userattr');
return 1 if ($b eq 'userattr');
return $a cmp $b;
} keys %{$attr{$d}};
for my $ak (@attrkeys) {
my $val = $attr{$d}->{$ak};
$val =~ s/;/;;/g;
$val =~ s/\n/\\\n/g;
push @ret,"attr $d $ak $val";
}
return @ret;
}
Der Code ist jetzt zwar nicht kürzer, aber die Komplexität der Schleife ist extrem reduziert, eigentlich bis hin zur trivialität.
Der Aufbau von %dontSave ist übersichtlich, die größte Komplexität liegt im Aufbau der @attrkeys Liste. Da kann man vermutlich
noch was mit dem sort-Block machen.
Aber auch diese Lösung ist ein Beispiel einer Reduktion O(n²) -> O(n): Der Schlüssel liegt im konstanten lookup eines Hashes (exists) gegenüber der linearen iteration einer Liste (grep).
Zitat von: RichardCZ am 04 April 2020, 09:16:15
Hey! 781 Tests. ;)
Gut, die meisten sind noch von Gentoo::Version, aber immerhin und bald schmeisse ich auch einige von Hobo mit rein.
Kann man das sehen?
https://gl.petatech.eu/root/HomeBot/-/jobs/82
Erste CI Pipeline röchelt schon. :)
edit:
Ich bin ja so stolz auf mich. Eigentlich sollte ich ja sagen "Wir sind ja so stolz auf uns." Pluralis MaJestatis - wissensschon. ;)
https://gl.petatech.eu/root/HomeBot/-/jobs/89
1355 Tests.
Mal eben Net::SNMP, Net::MQTT, Readonly mitgeliefert und HomeBot -> HoBo (bei den Modulen umbenannt). Letzteres wäre bereits ohne die einfachen "use smoketests" eine Tortur.
https://gl.petatech.eu/root/HomeBot/-/jobs/103
1395 tests. Ich frohlocke. Im übrigen: hinter der unscheinbaren Zeile 32
t/HoBo/01_func.t .............................. ok
verbergen sich 40 tests
ok 1 - goodDeviceName: without params
ok 2 - goodDeviceName: undef param
ok 3 - goodDeviceName: invalid name
ok 4 - goodDeviceName: invalid name 2
ok 5 - goodDeviceName: valid name
ok 6 - goodDeviceName: numeric context is ok
ok 7 - goodDeviceName: we do not care about superfluous parameters
ok 8 - goodDeviceName: invalid "hidden" name
ok 9 - goodDeviceName: valid but questionable name
ok 10 - goodReadingName: without params
ok 11 - goodReadingName: undef param
ok 12 - goodReadingName: invalid name
ok 13 - goodReadingName: valid name
ok 14 - goodReadingName: numeric context is ok
ok 15 - goodReadingName: we do not care about superfluous parameters
ok 16 - goodReadingName: valid hidden name
ok 17 - goodReadingName: invalid hidden name
ok 18 - goodReadingName: valid, but questionable name
ok 19 - goodReadingName: valid name with all character classes
ok 20 - makeDeviceName: without params
ok 21 - makeDeviceName: valid name
ok 22 - makeDeviceName: invalid name - corrected
ok 23 - makeReadingName: without params
ok 24 - makeReadingName: nothing to convert
ok 25 - makeReadingName: convert invalid char
ok 26 - makeReadingName: hidden can do anything
ok 27 - ReadingsTimestamp: without params
ok 28 - ReadingsTimestamp: explicit undefs
ok 29 - ReadingsTimestamp: default shortcut
ok 30 - ReadingsTimestamp: default because device & reading not present
ok 31 - ReadingsTimestamp: default because reading not present
ok 32 - ReadingsTimestamp: got reading
ok 33 - ReadingsAge: without params
ok 34 - ReadingsNum: without params
ok 35 - ReadingsVal: without params
ok 36 - OldReadingsAge: without params
ok 37 - OldReadingsNum: without params
ok 38 - OldReadingsTimestamp: without params
ok 39 - OldReadingsVal: without params
ok 40 - _oldreadings: without params
1..40
Und ich würde "den Verantwortlichen" doch mal stark ans Herz legen sowohl die Unit-Tests wie auch die Codeänderungen zu beobachten. Da stimmt nämlich einiges vorne und hinten nicht in FHEM - sowohl was Code, als auch was WIki betrifft.
Genauer ausgeführt habe ich das unter: https://gl.petatech.eu/root/HomeBot/-/wikis/FHEM_CodeDocs
Aber Vorsicht! Schnappatmungsgefahr...
ZitatHarte Fakten:...Nein, goodReadingName kann nicht direkt im if verwendet werden
Ist mir neu. Muss ich was aendern?
fhem> setreading global ätschbätsch value
global: bad reading name 'ätschbätsch' (allowed chars: A-Za-z/\d_\.-)
Kriegen wir eigentlich eine Richtigstellung auf deine Seite oder muessen wir Falschaussagen einfach so hinnehmen?
Zitat von: rudolfkoenig am 17 April 2020, 13:22:14
Ist mir neu. Muss ich was aendern?
Ja, die Dioptrien bei der Brille. ;)
Zitat
fhem> setreading global ätschbätsch value
global: bad reading name 'ätschbätsch' (allowed chars: A-Za-z/\d_\.-)
Nochmal lesen. Da ist ein Punkt davor.
Zitat
Kriegen wir eigentlich eine Richtigstellung auf deine Seite oder muessen wir Falschaussagen einfach so hinnehmen?
Ich weiß nicht. Was sagt Dein Optiker?
Zitat von: RichardCZ am 17 April 2020, 13:32:29
Ja, die Dioptrien bei der Brille. ;)
Nochmal lesen. Da ist ein Punkt davor.
Ich weiß nicht. Was sagt Dein Optiker?
Verstehe ich nicht. Wo ist da ein Punkt davor. Kann mich mal bitte einer aufklären.
Und was hat das mit der vorher erwähnten If Condition zu tun.
hem> setreading global ätschbätsch value
global: bad reading name 'ätschbätsch' (allowed chars: A-Za-z/\d_\.-)Ist doch korrekt. Umlaute sind nicht erlaubt. Oder über sehen ich da auch was?
Leute... ihr geht jetzt alle geschlossen zum Optiker.
.ätschbätsch
Kann ich hier größere Schrift machen?
Der Optiker sagt, dass ich den Punkt uebersehen habe, Punkt fuer Dich.
Die Pruefung in diesem Fall zu lassen ist Absicht, weil Modulautoren auf eine Ausnahme beharrt haben.
"Nein, goodReadingName kann nicht direkt im if verwendet werden" ist weiterhin eine Falschaussage.
Zitat von: rudolfkoenig am 17 April 2020, 13:48:56
Der Optiker sagt, dass ich den Punkt uebersehen habe, Punkt fuer Dich.
Die Pruefung in diesem Fall zu lassen ist Absicht, weil Modulautoren auf eine Ausnahme beharrt haben.
Ist ja ok, könnte man auch in der Doku sagen. Schliesslich ist diese ja für Modulautoren.
Oder gibt es noch anderes Geheimwissen was nur Super-Modulautoren vorbehalten ist?
Zitat
"Nein, goodReadingName kann nicht direkt im if verwendet werden" ist weiterhin eine Falschaussage.
Ach tatsächlich?
$ grn.pl
Use of uninitialized value in string eq at ./grn.pl line 16.
grn.pl:
#!/usr/bin/env perl
use strict;
use warnings;
sub
goodReadingName($)
{
my ($name) = @_;
return undef if(!$name);
return ($name =~ m/^[a-z0-9._\-\/]+$/i || $name =~ m/^\./);
}
if (goodReadingName(0) eq '0') {
print "Tadaaa\n";
}Und das
trotz Prototypen! Nit möööchlich!
Noch ein Punkt für mich?
edit:
Oder ich gehe ganz nach Vorschrift vor. Doku sagt Readinname kann Ziffer, Zeichen, punkt, Underscore sein.
my $readingname = '0'; # laut Doku valide
if (goodReadingName($readingname) == 1) { # laut Doku liefert das 0 oder 1 zurück
print "Tadaaa\n";
}
Ich habe alles richtig gemacht, und dennoch
$ grn.pl
Use of uninitialized value in numeric eq (==) at ./grn.pl line 17.Die sind alle so böse zu mir. denkt sich da der Modulautor.
Nein, es bleibt eine Falschaussage: die Funktion kann man im if verwenden.
Die Doku im Wiki will ich nicht verteidigen, die ist zwar richtig gemeint, man darf nur nicht jede Buchstabe auf die Waage liegen.
In der Wiki sind vermutlich noch etliche Fehler: ich habe die Artikel weder verfasst, noch habe ich es vor sie zu korrigieren.
Warum man das Beduerfnis hat, aus diesen Ungenauigkeiten so ein Aufschrei und noch dazu in so einem herablassenden Ton zu machen, ist mir ein Raetsel.
Zitat von: rudolfkoenig am 17 April 2020, 14:51:39
Nein, es bleibt eine Falschaussage: die Funktion kann man im if verwenden.
Das ist der Unterschied zwischen uns. Ich bin präzise - Du nicht.
Hast mal eben das Wörtchen
"direkt" unterschlagen. Klar kann man die die Funktion im if verwenden
if (defined goodReadingname($blah) && goodReadingname($blah) == 0) {aber eben nicht direkt - also ohne den defined-Schutz. ABer warum sollte man das tun, wenn man doch goodReadingname einfach verbessern kann?
ZitatDie Doku im Wiki will ich nicht verteidigen, die ist zwar richtig gemeint, man darf nur nicht jede Buchstabe auf die Waage liegen.
In der Wiki sind vermutlich noch etliche Fehler: ich habe die Artikel weder verfasst, noch habe ich es vor sie zu korrigieren.
Klar sind dort noch viele Fehler. Das hindert aber zappendustre Zeloten wie zap nicht daran z.B. "return undef;" im Code zu behalten
"weil es die Doku so sagt".
Könntest ihm ja mal sagen, dass die Doku nicht heilig ist und man da nicht jeden Buchstaben auf die Waage legen soll... ::)
Zitat
Warum man das Beduerfnis hat, aus diesen Ungenauigkeiten so ein Aufschrei und noch dazu in so einem herablassenden Ton zu machen, ist mir ein Raetsel.
Das Problem ist nicht nur im Wiki, das Problem ist ja auch im Code. Und wieder sind wir angekommen bei "Najaaaa vielleicht ne kleine Ungenauigkeit, aber der Code ist ja eigentlich in Ordnung." Da bleibt einem nicht viel anderes übrig als sich darüber lustig zu machen. Das kann man als herablassend interpretieren - ja.
Also ich glaube ja, einige hier hätten im 14. Jh sehr gute Kirchenvertreter abgegeben und ich wäre längst Asche. :-X
Bin ich erleichtert, dass wir 2020 A.D. schreiben.
Aber weisste was das richtig Traurige an der ganzen Sache ist?
Du hast im HoBo Repository gefixten Code. Sogar formal getestet. Brauchst Dich nur bedienen. Aber nein - da werde ich lieber der Falschaussage, der herablassenden Art etc. bezichtigt. Du willst herablassend? Ok. Dieses Verhalten nenne ich "stur", hart an der Grenze zu "dumm".
Denk' drüber nach - wenn möglich.
Zitataber eben nicht direkt - also ohne den defined-Schutz.
Klar doch: if(goodReadingname($bla)). Steht im Bibel nicht, dass == 0 eine Todsuende ist? :)
ZitatDu hast im HoBo Repository gefixten Code. Sogar formal getestet.
Das ist deine Sicht.
Meine Sicht: formal getestet ist sinnlos, solange man nicht so recht weiss, wozu der Code da ist. Von mir nicht mehr wartbar, da komplett umgebaut, und die Aenderungshistorie verlorengegangen ist. Ungetestet in Real-Life.
Zitat von: rudolfkoenig am 17 April 2020, 15:32:50
Klar doch: if(goodReadingname($bla)). Steht im Bibel nicht, dass == 0 eine Todsuende ist? :)
== 0 wüsste ich nicht.
/ 0 vielleicht.
if(goodReadingname($bla))funktioniert nur durch Zufall, weil Perl "undef" zu "false" evaluiert (was das FHEM Wiki als "0" beschreibt)
Wenn es nicht so irre wäre, wäre es ja richtig lustig.
Wehe ... wehe! irgendjemand legt die Wiki Worte auf die Waagschale und erwartet da nicht undef zurück.
Zitat
Das ist deine Sicht.
Meine Sicht: formal getestet ist sinnlos, solange man nicht so recht weiss, wozu der Code da ist. Von mir nicht mehr wartbar, da komplett umgebaut, und die Aenderungshistorie verlorengegangen ist. Ungetestet in Real-Life.
Ich verstehe die konservative Herangehenseweise. Aber würde ich nicht in meinem Elfenbeinturm über den Dingen schweben, würde ich Dich jetzt der Falschaussage bezichtigen:
a) die Änderungshistorie ist natürlich da (gibt im GitLab zu jeder Datei den "History" Button).
b) es ist tatsächlich mehr getestet als in Real-Life, weil sogar die Grenzfälle, die in Real-Life nie getestet wurden (weil man sonst die Fehler gemerkt hätte) getestet sind.
c) wenn man solchem Code nie die Chance auf "Real-Life" gibt, dann wird das "Ungetestet in Real-Life" zu einer selbterfüllenden Prophezeiung.
ABER:
Selbst dieser "total umgebaute Code" ist m.E. noch nicht fertig. Das wäre er, wenn es uns statt dieser Rhetorikübungen gelingen würde, ein wenig Synergie zu finden. Z.B. wo Du - mit all Deinem Hintergrundwissen zu FHEM in "Real-Life" - und ich - mit meinem Perl Wissen - den Code finalisieren könnten.
Offene Fragen sind u.a. nämlich:
//////
......
-------.....////.....will man das tatsächlich als valide Readingnames haben? Wen nein, was will man genau haben? Das wäre IMHO produktiv, weil bis man das festgenagelt hat bleibt die ganze Geschichte in einer diffusen Wolke. Und außerdem möchte ich natürlich angeben wie tolle reguläre Ausdrücke ich schreiben kann.
Pah! Ihr habt mich noch nicht negative Lookbehinds machen sehen!
ZitatOffene Fragen sind u.a. nämlich:...
Ich weiss nicht, wo ich die Grenze ziehen soll: ist A--B noch ok, oder -AB ?
Readingnamen werden in etlichen Modulen aus Input generiert.
Was ist wenn jemand nicht druckbare Zeichen nach - oder . konvertiert?
Ich weiss nicht, warum ich mich damit beschaeftigen soll, Konstellationen, die zwar kaputt ausschauen, aber nicht stoeren, zu beheben.
Ich bin daran gescheitert die Laenge auf 64 Zeichen zu beschraenken, und DAS stoert mich.
Zitata) die Änderungshistorie ist natürlich da (gibt im GitLab zu jeder Datei den "History" Button).
Klar, macht aber die Verfolgung kompliziert, weil ich erst den Code vor dem Umbau auschecken muss, um danach mit blame zu sehen, wegen welchem Beitrag eine Zeile eingebaut wurde. Vorher irgendwie rausfinden, welcher neuen Zeile welche Alte entspricht, und ob das Problem durch die Aenderung gekommen ist, oder vorher schon da war. Ist nicht viel Unterschied mehr zu "Historie ist weg"
Zitatb) es ist tatsächlich mehr getestet als in Real-Life, weil sogar die Grenzfälle, die in Real-Life nie getestet wurden (weil man sonst die Fehler gemerkt hätte) getestet sind.
Das ist so nicht richtig: ob durch den Umbau Real-Life Probleme reingekommen sind oder nicht, weiss man nicht, insofern ist der "Real-Life" getestet Siegel erstmal weg. Es wird nur getestet, was der Tester fuer moeglich haelt, und nach meiner Erfahrung sind Tester (und Programmierer) nicht so erfinderisch, wie Real-Life.
Zitat von: rudolfkoenig am 17 April 2020, 17:13:59
Ich weiss nicht, wo ich die Grenze ziehen soll: ist A--B noch ok, oder -AB ?
Readingnamen werden in etlichen Modulen aus Input generiert.
Was ist wenn jemand nicht druckbare Zeichen nach - oder . konvertiert?
Ich weiss nicht, warum ich mich damit beschaeftigen soll, Konstellationen, die zwar kaputt ausschauen, aber nicht stoeren, zu beheben.
Ich bin daran gescheitert die Laenge auf 64 Zeichen zu beschraenken, und DAS stoert mich.
Das stört mich auch, denn momentan ist es echt unbegrenzt. Wenn ich jetzt den Roman "KriegUndFrieden" in einen Readingname verwandle und in der Config verewige, dann passieren bestimmt auch lustige Sachen.
Also gut. 64 Zeichen nö. Aber 128? 256? 256000? Es muss doch möglich sein einen Limes Superior anzugeben. So lange man das nicht tut ... siehe mein Avatar-Bild.
Und noch hat niemand von "beheben" gesprochen. "Definieren" würde mir ja in erster Annäherung reichen.
Das "wir alle" momentan nicht wissen wo man die Grenze ziehen soll, würde ich eher als Bestätigung sehen ebendiese Grenze zu finden und nicht "Klappe zu , Deckel drauf wird schon irgendwie laufen".
Und dann kann man noch über andere Sachen nachdenken - das mache ich dann in der HoBo Freiheit - wie zum Beispiel bidirektionale Konversion.
Warum muss unbedingt
ä -> _ Information verlorengehen? Insbesondere da es ja RFC3492 gibt bzw. https://de.wikipedia.org/wiki/Punycode
Zitat
Das ist so nicht richtig: ob durch den Umbau Real-Life Probleme reingekommen sind oder nicht, weiss man nicht, insofern ist der "Real-Life" getestet Siegel erstmal weg. Es wird nur getestet, was der Tester fuer moeglich haelt, und nach meiner Erfahrung sind Tester (und Programmierer) nicht so erfinderisch, wie Real-Life.
Nach meiner Erfahrung kommt das sehr auf die Tester und Programmierer an.
ZitatAlso gut. 64 Zeichen nö. Aber 128? 256? 256000? Es muss doch möglich sein einen Limes Superior anzugeben. So lange man das nicht tut ... siehe mein Avatar-Bild.
Fuehl dich frei das mit dem Neinsager auszudiskutieren.
Es geht darum, als "Meta-Modul" an beliebige ReadingNamen von anderen Modulen ein Praefix (oder war das Suffix?) ranhaengen zu duerfen.
Nach dem Motto: immer zweimal mehr wie du.
Zitat von: rudolfkoenig am 17 April 2020, 17:48:10
Fuehl dich frei das mit dem Neinsager auszudiskutieren.
Es geht darum, als "Meta-Modul" an beliebige ReadingNamen von anderen Modulen ein Praefix (oder war das Suffix?) ranhaengen zu duerfen.
Nach dem Motto: immer zweimal mehr wie du.
Ok. Ich beschränke das bei mir jetzt auf 256 und bevor ich nichts Gegenteiliges höre, gilt das auch für Devicenamen.
/////////////
immer noch guter Readingname?
edit:
https://gl.petatech.eu/root/HomeBot/-/commit/11e2b848ddfa58385198939275551242b6dda718
Da fackelt unser politisch und gendermäßig korrektes internationales multi-kulti HoBo-Entwicklerteam nicht lang rum.
edit2 - a.k.a. "einen hab' ich noch":
Mich hat die Testsuite tatsächlich jetzt schon vor einem Bug bewahrt, denn ich hatte bei goodDeviceName tatsächlich geschrieben
return $name =~ m{\A # return truth value (true/false) of this rx match
[a-z0-9_] # start with character, digit or underscore
[a-z0-9._]{1,255} # continue, but now can also contain '.', max 255 chars
\z}xmsi;*Boom*not ok 6 - goodDeviceName: numeric context is ok
# Failed test 'goodDeviceName: numeric context is ok'
# at lib/HoBo/Test.pm line 32.
# got: ''
# expected: '1'
not ok 7 - goodDeviceName: we do not care about superfluous parameters
# Failed test 'goodDeviceName: we do not care about superfluous parameters'
# at lib/HoBo/Test.pm line 32.
# got: ''
# expected: '1'Klar, wer ist auch so blöd und ersetzt * durch {1,255}
return $name =~ m{\A # return truth value (true/false) of this rx match
[a-z0-9_] # start with character, digit or underscore
[a-z0-9._]{0,255} # continue, but now can also contain '.', max 255 chars
\z}xmsi;Muss es natürlich im "Real-Life" heissen.
Zitat von: rudolfkoenig am 17 April 2020, 17:48:10
Fuehl dich frei das mit dem Neinsager auszudiskutieren.
Wer genau hat denn für
unbegrenzte Länge für Reading-Keys plädiert? Die Diskussion drehte sich lediglich darum, dass 64 zu wenig sind. Ich glaube, ich war mit 256 oder so am Start, so wie Richard sie nun bei sich eingeführt hat. betateilchen mit 128 iirc.
Wenn ich mich genau erinnere, haben wir nie wirklich darüber diskutiert, wie viel zu viel ist, sondern nur darüber, dass 64 zu wenig sind und dafür gab es auch gute Beispiele. Ausdiskutiert ist die Geschichte nach wie vor nicht, du hast nur die Einschränkungen zurück gedreht. Ohne dass ich das gut finde übrigens, es ist ja nach wie vor offen, wie wir hier sehen.
Zitat von: Christoph Morrison am 17 April 2020, 18:33:29
Ausdiskutiert ist die Geschichte nach wie vor nicht, du hast nur die Einschränkungen zurück gedreht. Ohne dass ich das gut finde übrigens, es ist ja nach wie vor offen, wie wir hier sehen.
Wieso? Die Sache ist doch jetzt ausdiskutiert. 256 ist der neue Standard.
Kannste mal sehen - wenn ihr mich nicht hättet... :-*
Eigentlich können wir das aber noch weiter ausdiskutieren, denn ist der neue Standard 256 mit oder ohne Punkt?
Ich habe jetzt "mit Punkt", bin da aber schmerzfrei wenn es gewichtige Exklusions-Argumente gibt.
Wenn Du den Punkt am Anfang meinst, der sollte bleiben. Denn wie gesagt können damit Readings versteckt werden was ich sehr schön finde und auch nutze.
Zitat von: CoolTux am 17 April 2020, 19:17:18
Wenn Du den Punkt am Anfang meinst, der sollte bleiben. Denn wie gesagt können damit Readings versteckt werden was ich sehr schön finde und auch nutze.
Das ist nicht der Punkt. Der Punkt bleibt natürlich. ;D
Es geht darum ob der Punkt zu den 256 Zeichen zählt oder nicht.
Mein Code sagt jetzt ... sche!*e muss ich nachsehen....
Mein Code sagt jetzt komische Sachen.
256 Zeichen max MIT Punkt (am Anfang)
255 Zeichen max OHNE Punkt
Wenn ich sage "256 Zeichen Längenbeschränkung", dann ist das Verhalten unintuitiv.
Jetzt ist die Frage ob 256 Zeichen mit oder ohne Punkt
ODER
"optional punkt" + 256 zeichen max
(also hidden Readingnames 257 Zeichen wenn man den Punkt dazuzählt)
Ich tendiere fast zu der
256 Zeichen Limit für non-hidden Readingnames
257 Zeichen Limit für hidden (wobei de facto Punkt nicht mitgezählt wird bei den 256 danach)
Weiß jeder was ich meine? Gut - dann kann er es mir ja nachher erzählen. ???
Warum würde ich den Punkt nicht dazuzählen? Weil das ja genau genommen kein zeichen ist, sondern ein Steuersymbol HIDDEN/NOTHIDDEN.
Also?
"optional punkt" + 256 zeichen max
also
256 Zeichen Limit für non-hidden Readingnames
257 Zeichen Limit für hidden (wobei de facto Punkt nicht mitgezählt wird bei den 256 danach)
Zitat von: CoolTux am 17 April 2020, 19:34:54
"optional punkt" + 256 zeichen max
Ja, sehe ich auch so:
https://gl.petatech.eu/root/HomeBot/-/commit/15aef00c516f2e4f73d10177e642093ee6f6244e
und die (1401) Tests auch
https://gl.petatech.eu/root/HomeBot/-/jobs/105
Happy bin ich mit ///////////// aber noch nicht. Jetzt mache ich erstmal noch andere Unit Tests fertig, dann sehe ich mir das (und Punycode) nochmal genauer an.
Zitat von: Christoph Morrison am 17 April 2020, 18:33:29
Wer genau hat denn für unbegrenzte Länge für Reading-Keys plädiert?
Ich war es nicht - allerdings bin ich dafür. Im übrigen bin ich auch gegen die gültige Beschränkung der aktuellen Zeichen.
Was spricht denn
technisch dagegen dass ein Reading "Thüringen" heist. Oder "中國" ? Regex? Da wird Dir der Muttersprachler der Region was anderes sagen.
Was spricht
technisch gegen einen Reading Namen mit 1024, 2048 oder 65k Zeichen Länge? Datenbankfelder? Glaub ich nicht.
Schaut man von der anderen Seite darauf und argumentiert mit der Lesbarkeit (Anwenderfreundlichkeit) dann sind doch 64 Zeichen schon too much. Jetzt stellt man fest dass man aus guten Gründen mehr braucht. 128? 256?
Gehen wir doch mal davon aus das der entsprechende Dev kein Vollhonk ist, sondern aus (möglicherweise guten) Sachzwängen handelt. Warum soll dann der Sachzwang 256 Zeichen gerecht sein - 512 aber nicht?
Gibt es
echte technische Gründe das zu verbieten? Was sind objektive Gründe für die Notwendigkeit einer Regulierung unter der Annahme dass sich ohnehin jeder dev anstrengt, anwenderfreundliche Reading Namen zu generieren ?
gegen nicht ascii readings spricht aktuell vor allem das alte utf-8 problem. sobald die verwendet werden funktionieren aktuell alle möglichen regex im fhem und user code nicht mehr wie erwartet.
einfaches beispiel: . matched nicht auf umlaut da intern als zwei einzelne byte repräsentiert und nicht als ein utf-8 zeichen.
wenn wir das beheben sollten umlaute und anderes erlaubt sein.
ich fände es sogar gut wenn : erlaubt sind. mac adressen kommen öfter als reading vor. aber dann bräuchte es ein neues konzept wie man event darstellt.
was die länge angeht: ich meine eigentlich sollte es keine beschränkungen geben. wenn aber ich sehe was zum teil als reading namen verwendet wird statt nachzudenken und das ganze lesbar zu halten sind zum teil 20 erlaubte zeichen schon zu viel.
punycode ist keine lösung. das ist ganz schnell nicht mehr menschen lesbar.
Zitat von: herrmannj am 17 April 2020, 23:03:03
Ich war es nicht - allerdings bin ich dafür. Im übrigen bin ich auch gegen die gültige Beschränkung der aktuellen Zeichen.
Was spricht denn technisch dagegen dass ein Reading "Thüringen" heist. Oder "中國" ? Regex? Da wird Dir der Muttersprachler der Region was anderes sagen.
Das weiß ich nicht, Ich dachte vielleicht fliegt dann einem der "Parser" um die Ohren wenn er auf : oder { oder whitespace oder sowas trifft, weil er das dann falsch zuordnet.
Mein Hinweis auf Punycode war genau wegen den Mutterprachlern gemeint, auch ich wollte das "中國" Beispiel anbringen. "Und morgen die ganze Welt!"
Also wenn das geht, bin ich dafür.
Dann würden wir im Grunde nur eine Filterliste brauchen was
nicht in so einen Readingname kann. Negative character class ist ja auch nicht so schwierig.
Zitat
Was spricht technisch gegen einen Reading Namen mit 1024, 2048 oder 65k Zeichen Länge? Datenbankfelder? Glaub ich nicht.
Das habe ich mit meinem Tolstois-Krieg-Und-Frieden Beispiel gemeint. Unbegrenzt ist schlecht. Da mit "User ist kein Vollhonk" zu argumentieren ist unzulässig.
Vielleicht sind User von onlinebanking auch keine Vollhonks, aber versuch da mal aus der Reihe zu tanzen.
Ansonsten empfehle ich mal so Normalverteilungen zu studieren. Und falls Du 65k Zeichen zulassen willst, dann vermutlich weil von den 7 Mrd. FHEM Nutzern 2 diese Länge brauchen werden.
Zitat
Gehen wir doch mal davon aus das der entsprechende Dev kein Vollhonk ist, sondern aus (möglicherweise guten) Sachzwängen handelt. Warum soll dann der Sachzwang 256 Zeichen gerecht sein - 512 aber nicht?
Also ich werde das bei mir wie folgt machen:
"256 chars ought to be enough for anybody"
Und sollte jemand aufschlagen, dem das nicht reicht, werden wir feststellen ob das Limit zu klein oder er ein Vollhonk ist.
Zitat
Gibt es echte technische Gründe das zu verbieten? Was sind objektive Gründe für die Notwendigkeit einer Regulierung unter der Annahme dass sich ohnehin jeder dev anstrengt, anwenderfreundliche Reading Namen zu generieren ?
Gibt es echte technische Gründe warum z.B. ein Aufzug von alleine im obersten Stockwerk anhält? Wenn wir annehmen, dass nicht jeder Aufzugnutzer ein Vollhonk ist und nicht sterben will, dann lassen wir den Aufzug einfach so lange fahren wie die "rauf Taste" gedrückt bleibt.
Zitat von: justme1968 am 18 April 2020, 08:02:15
gegen nicht ascii readings spricht aktuell vor allem das alte utf-8 problem. sobald die verwendet werden funktionieren aktuell alle möglichen regex im fhem und user code nicht mehr wie erwartet.
einfaches beispiel: . matched nicht auf umlaut da intern als zwei einzelne byte repräsentiert und nicht als ein utf-8 zeichen.
wenn wir das beheben sollten umlaute und anderes erlaubt sein.
ich fände es sogar gut wenn : erlaubt sind. mac adressen kommen öfter als reading vor. aber dann bräuchte es ein neues konzept wie man event darstellt.
Ah. Deswegen habe ich ein use utf8 in Source und Testfile gebraucht. :-)
Weil sonst hatte der mir mal flugs ein ä in __ umgewandelt.
Zitat
punycode ist keine lösung. das ist ganz schnell nicht mehr menschen lesbar.
Also ich fände es auch besser
Ochranný_štít (Schutzschild 8) )
als Readingname haben zu können. Wenn das System mit sowas Probleme hat, könnte man ja den Spieß umdrehen -> Punycode systemintern, User sieht die "intuitive Fassung".
intern umcodieren hätte den nachteil das man immer hin und her wandeln muss. ich denke es wäre besser überall wirklich utf-8 zu verwenden. das ist nicht mehr arbeit aber das ergebnis ist sinnvoller.
eine idee zum : als trenner in den events: wenn man hier ein anderes zeichen verwendet (z.b. RECORD SEPARATOR:␞) könne man vielleicht die : auch wieder zulassen. etwas ähnliches macht fhemweb jetzt auch schon bei der darstellung der newline. aber das wäre noch mal eine ganz andere baustelle.
Zitat von: justme1968 am 18 April 2020, 08:50:03
intern umcodieren hätte den nachteil das man immer hin und her wandeln muss. ich denke es wäre besser überall wirklich utf-8 zu verwenden. das ist nicht mehr arbeit aber das ergebnis ist sinnvoller.
Zünde bitte jemand ne Kerze an, ich bin der gleichen Meinung wie justme1968. ;)
Und falls ich das gerade beim Frühstück richtig durchdacht habe, gäbe es nicht einmal Kompatibilitätsprobleme mit alten Installationen, denn die haben by default ja keine Readingnames die unter UTF-8 anders aussehen.
Ich mache jetzt folgendes:
a) die Maximallänge kofigurierbar (wobei ich immer noch den 256 Default beibehalte)
b) akzeptiere erstmal alles ausser Leerzeichen und sehe wo das auf die Schnauze fliegt, dann kann man einschränken
c) makeReadingName wird auf die Maximallänge beschnitten wenn was Längeres daherkommt (die sub nennen wir dann aber Brit_Mila)
Das wuerde auch die Regexps (Notify, FileLog, etc) der Benutzer betreffen, und wir muessten den Herrschaften beibringen, wo man ␞ auf der Tastatur findet.
Ich habe jetzt nicht die ganze Diskussion verfolgt, aber die Maximallänge von Readingnamen konfigurierbar zu machen macht aus meiner Sicht keinen Sinn. Wenn eine Beschränkung existiert möchte ich mich auf die auch verlassen können.
Gesendet von iPhone mit Tapatalk
Zitat von: KernSani am 18 April 2020, 10:46:19
Ich habe jetzt nicht die ganze Diskussion verfolgt, aber die Maximallänge von Readingnamen konfigurierbar zu machen macht aus meiner Sicht keinen Sinn. Wenn eine Beschränkung existiert möchte ich mich auf die auch verlassen können.
Wer ist "ich" und was bedeutet "sich darauf verlassen"? ;)
Ich hab's erstmal konfigurierbar im Source. Wenn irgendein Display "sich darauf verlassen will", kann man ja über eine methode zur Selbstauskunft nachdenken.
Readonly my $MAXLEN_DN = 256; # maximum length of Devicename
Readonly my $MAXLEN_RN = 256; # maximum length of ReadingnameWenn der user im Code rumfuhrwerkt... gehen wir einfach davon aus, dass er kein Vollhonk ist.
Was macht eigentlich das Display momentan wenn man ihm KriegundFrieden reinstopft? Hat das schonmal wer ausprobiert?
Status Quo:
sub goodDeviceName :Export {
my $name = shift // return !1; # according to docs we do not return undef, but false
return $name =~ m{\A # return truth value (true/false) of this rx match
[^\s.] # for now everything except whitespace and dot is allowed
[^\s]{0,$MAXLEN_DN-1} # continue, but now can also contain '.', up to maximum length
\z}xmsi; # case insensitive
}
sub goodReadingName :Export {
my $name = shift // return !1; # according to docs we do not return undef, but false
return $name =~ m{\A # return truth value (true/false) of this rx match
\.? # optionally start with a . (internal ReadingName)
[^\s]{1,$MAXLEN_RN} # followed by up to maxlen chars (except whitespace)
\z}xmsi; # case insensitive
}
sub makeDeviceName :Export {
my $name = shift // return 'UNDEFINED';
my $len = length $name; # get length of given name
if ($len > $MAXLEN_DN) { # if it's longer than the defined maximum
$name = substr $name, 0, $MAXLEN_DN; # prune it (one could think about a trailing '...')
}
$name =~ s/\s/_/gi; # replace all whitespaces with _
return $name; # return the transformed name, guaranteed to be compliant
}
sub makeReadingName :Export {
my $name = shift // return 'UNDEFINED';
my $len = length $name; # get length of given name
my $max = $name =~ m{\A\.}xms # if we do start with a dot
? $MAXLEN_RN + 1 # acceptable maxlength is +1
: $MAXLEN_RN; # if we don't it's maxlength
if ($len > $max) { # we are over allowed length
$name = substr $name, 0, $max; # prune it (one could think about a trailing '...')
}
$name =~ s/\s/_/gi; # replace all whitespaces with _
return $name; # return the transformed name, guaranteed to be compliant
}Man beachte: Ich verwende Kommentare im Code, das ist auch so neumodisches Zeug.
Das hindert natürlich die Royalität nicht daran zu sagen, der Code sei für ihn nicht wartbar. ;)
edit:
Tests meinen im Code sind noch Bugs... *seufz*
Zitat von: RichardCZ am 18 April 2020, 11:02:10
Wer ist "ich" und was bedeutet "sich darauf verlassen"? ;)
Spontan fällt mir die Tabellendefinition für DBLog ein... Mache ich die Spalte unendlich breit oder kann ich mich auf die 257 verlassen?
Eine Konstante im Source ist für mich übrigens was anderes als ,,konfigurierbar" ;-) Wenn es dazu gedacht ist, die Länge an einer zentralen Stelle ändern zu können falls sich herausstellt 257 reicht nicht, dann gut..
Gesendet von iPhone mit Tapatalk
ZitatWas macht eigentlich das Display momentan wenn man ihm KriegundFrieden reinstopft?
Das haengt vmtl. vom Browser, und verfuegbaren Hauptspeicher ab.
Diese Argumentationslinie ist vmtl. nicht zielfuehrend, da die Werte ja auch angezeigt werden, und ueber deren Beschraenkung hat bisher keiner nachgedacht.
was mir noch zu nicht ascii readings einfällt:
die beschränkung auf ascii ist aus anwender sicht vermutlich schwerwiegender als jede längen beschränkung. userreadings im lokalen zeichensatz sollten möglich sein.
aber: device module sollte nur in aus ausnahmefällen lokalisierte readings verwenden. stattdessen sollte intern alles in so wenig wie möglich standardisierten readings in standardisieren einheiten abgebildet werden.
die übersetzung nach lokal sollte dann in einem zwischenschritt vor der darstellung erfolgen.
nur so lassen sich module einfach übersetzer, fhem selber in unterschiedlichen sprachen verwenden und selbst geschrieben routinen sprachunabhängif halten.
im prinzip gibt es hier schon anfänge mit reading kategorien und mit dem units modul.
Zitat von: rudolfkoenig am 18 April 2020, 11:23:01
Das haengt vmtl. vom Browser, und verfuegbaren Hauptspeicher ab.
Diese Argumentationslinie ist vmtl. nicht zielfuehrend, da die Werte ja auch angezeigt werden, und ueber deren Beschraenkung hat bisher keiner nachgedacht.
Ja, danke für die explizite Erwähnung des DoS Potentials. Ansonsten halte ich die komplementäre Argumentationslinie für nicht zielführend
a) natürlich habe ich darüber nachgedacht, nur kotze ich mich tatsächlich nicht über alles worüber ich nachdenke hier aus. (*)
b) Es kann ja nicht sein mit "bislang haben wir gar keine Restriktion, also macht es keinen Sinn mit einer anzufangen" zu argumentieren
(*) Das mag für jemanden jetzt überraschend sein.
PS: Außerdem bin ich traurig, HoBo liegt auf der Intensivstation
Invalid characters in name (not A-Za-z0-9._): WEB
Please define WEB 5e70a1c5-f33f-8c0a-8a10-dc51d292283b1446 first
...
Invalid characters in name (not A-Za-z0-9._): Logfile
Please define Logfile 5e70a1c5-f33f-8c0a-f36c-445cb4cf1efdf61a first
Invalid characters in name (not A-Za-z0-9._): autocreate
Please define autocreate 5e70a1c5-f33f-8c0a-bd1c-819f511b7ed9970e first
...
Invalid characters in name (not A-Za-z0-9._): eventTypes
Please define eventTypes 5e70a1c5-f33f-8c0a-9808-9a22a285b3e97831 first
Invalid characters in name (not A-Za-z0-9._): mySwitch1
Please define mySwitch1 5e70bb38-f33f-8c0a-d642-9eea3373709f4bb0 first
...
Invalid characters in name (not A-Za-z0-9._): myLamp1
Please define myLamp1 5e70bd92-f33f-8c0a-4be1-5db61ba18525e13a first
...
Invalid characters in name (not A-Za-z0-9._): soldisk
Please define soldisk 5e71e4ea-f33f-f89d-5aef-b9b8cc4ecb3aa27f first
Invalid characters in name (not A-Za-z0-9._): Qnap1
Please define Qnap1 5e724130-f33f-f89d-3edc-2180dd34b5c98481 first
Invalid characters in name (not A-Za-z0-9._): MyTTS
Please define MyTTS 5e8340b5-f33f-f89d-2c4c-69958c6e95faa032 first
... ad Inf.
Zitatb) Es kann ja nicht sein mit "bislang haben wir gar keine Restriktion, also macht es keinen Sinn mit einer anzufangen" zu argumentieren
Ich bin ja auf der Seite der Laengenbegrenzer :) ich will nur die "Gegner" mit schluessigen Argumentationen ueberzeugen.
Wg. der Intensivstation: setuuid hat die Trennung der Argumente vergeigt.
Resistance is futile. You will be assimilated!
Und wennschondennschon. Das behalte ich jetzt zum Testen.
Die Sortierreihenfolge ist komisch - isn't it?
Jaa liebe Leute. Sieht gut aus. Aber warum sieht das gut aus? Weil ich Tests habe und ihr nicht. ätschbätsch.
Jetzt mal benevolent konstruktiv: FHEM Stolperstein in goodReadingName (jetzt schon)
return ($name =~ m/^[a-z0-9._\-\/]+$/i || $name =~ m/^\./);
FHEM ist zwar "Real-Life getestet"(tm), aber erlaubt hier hidden Readingnames die z.B. Leerzeichen enthalten -> *Boom*
Das fängt zwar in den meisten Fällen der split ab, aber k.A. ob nicht doch irgendwo ein Readingname auf einem Seitenkanal antanzen kann.
edit: Devicenamen tun auch, siehe Anhang
Würde mich über Testvorschläge freuen. Soweit ich rumgestochert habe ist mir noch nichts um die Ohren geflogen.
ZitatFHEM ist zwar "Real-Life getestet"(tm), aber erlaubt hier hidden Readingnames die z.B. Leerzeichen enthalten -> *Boom*
Mir ist kein Weg bekannt, wie ein Benutzer ein *Boom* erzeugen kann.
Da ich aber nicht alle Module, die diese Funktion aufrufen, nach Unsinn absuchen will, habe ich die Pruefung (und die Korrektur in makeReadingName) erweitert: \s wird in .name nicht zugelassen.
Quick&Dirty Skript
https://gl.petatech.eu/root/HomeBot/-/blob/d117007c527108a1a271926fcf7456221f3f909b/scripts/pod2wiki.pl
nimmt künftig PODs wie z.B.
https://gl.petatech.eu/root/HomeBot/-/blob/d117007c527108a1a271926fcf7456221f3f909b/lib/HoBo.pm
und macht daraus
https://gl.petatech.eu/root/HomeBot/-/wikis/API-Test
künftig ist angedacht, dass https://gl.petatech.eu/root/HomeBot/-/wikis/DevelopmentModuleAPI
automatisch erzeugt wird.
Hätte ich heute nicht soviel Zeit mit gewissen Dingen verplempert, wäre das schon viel weiter. Lessons learned.
$ fhem2hobo.pl
Only in HOBO:
27_SNMP_Template.pm
remote: Enumerating objects: 74, done.
remote: Counting objects: 100% (74/74), done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 74 (delta 35), reused 59 (delta 21), pack-reused 0
Unpacking objects: 100% (74/74), 21.23 KiB | 289.00 KiB/s, done.
From https://github.com/fhem/mod-Buienradar
fe84261..d9c0c17 development/3.0.6 -> origin/development/3.0.6
* [new branch] development/3.0.7 -> origin/development/3.0.7
59_Buienradar.pm...
*** Diff detected! *** (42695 chars)
-> copying to Hobo sandbox.
88_WEBCOUNT.pm...
*** Diff detected! *** (4530 chars)
-> copying to Hobo sandbox.
60_uba.pm...
*** Diff detected! *** (30784 chars)
-> copying to Hobo sandbox.
98_unittest.pm...
*** Diff detected! *** (19229 chars)
-> copying to Hobo sandbox.
Enumerating objects: 18, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 8 threads
Compressing objects: 100% (16/16), done.
Writing objects: 100% (16/16), 28.50 KiB | 4.07 MiB/s, done.
Total 16 (delta 8), reused 0 (delta 0), pack-reused 0
To https://gl.petatech.eu/root/HomeBot.git
4672798..7f1c2a0 master -> master
fhem2hobo.pl ist nun zu einem Aggregator aufgebohrt worden. Sprich: mittlerweile holt es sich nicht nur Sachen aus dem offiziellen/Haupt- FHEM SVN, sondern auch aus anderen Quellen.
Derzeit habe ich ein paar Github repos (
mod-Buienradar mod-webcount uba UnitTest) zum Test.
Siehe https://gl.petatech.eu/root/HomeBot/-/commit/df9cf516cc87a252c49b01a3db3e794cf2051b40 ff
Selbstverständlich erfolgt der Merger bzw. die diff-Betrachtungen bereits mit normalisiertem Code.
Jetzt könnte ich doch eigentlich auch Byte09's Repo einfügen. Wo isses?
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
;)
https://gl.petatech.eu/root/HomeBot/-/jobs/164
das 98_FhemTestUtils test-Framework funktioniert nun auch unter HoBo und wurde ins GitLab CI integriert (s.o.)
Und Rudolf bekommt von mir das goldene Schwimmabzeichen für Freistil in der Klärgrube.
Zitat von: RichardCZ am 05 Juni 2020, 08:42:52
...GitLab CI Pipeline (siehe z.B. https://gl.petatech.eu/root/HomeBot/pipelines/118), die seit gestern bei mir auch erfolgreich statische Binaries baut (aber noch nicht abholt - artifact download und dann irgendwo auf dem Web als "release" bereitstellt - kommt noch).
Das ist hiermit geschehen, siehe https://gl.petatech.eu/root/HomeBot/pipelines
* guggst Du rechts, ist da ein download Symbol (jeweils oberste/neueste Pipeline)
* wenn man draufklickt kommt ein "download build_static artifacts"
* wenn man
da drauf klickt, wird ein artifacts.zip (ca. 8MB) geladen.
* entpackt ist das ein 29MB
HoBo_x86_64 (sorry, tut noch nicht auf dem RasPi) (*)
Das enthält:
* ein Perl 5.30.2
* alle benötigten Module (also Systemmodule, CPAN module für FHEM/HoBo)
* alle Module aus FHEM und lib
Device::USB und Mojolicious macht noch Ärger, alles andere sollte da sein.
Theoretisch sollte also das hier gehen:
$ ./HoBo_x86_64
Usage:
as server: hobo.pl [-d] {<configfile>|configDB}
as client: hobo.pl [host:]port cmd cmd cmd...
testing: hobo.pl -t <testfile>.tUnd falls ihr das Teil ins FHEM Installationsverzeichnis schiebt und mit
./HoBo_x86_64 fhem.cfg
aufruft (fhem.pl vorher beenden), dann sollte unter localhost:8083 irgendwas röcheln. Vielleicht.
Der Witz ist, das sollte auch auf einem Linux System passieren wo gar kein Perl installiert ist.
(*) Immer noch ein halbes Königreich für ein HowTo für eine RasPi VM unter Proxmox
Start als root schlägt fehl , start als normaler User ging nachdem dieser User Schreibrechte auf die aktuelle fhem.log hatte.
Beim ersten edit der config und save :
undefined subroutine &HoBo::Command::WriteStatefile called at HoBo/Command.pm line 1072.
Compilation failed in require.
2020.06.05 19:31:38 1: reload: Error:Modul 10_MAX deactivated:
Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC contains: ./lib ./FHEM lib . CODE(0x563401bdd1b8) ./FHEM/lib) at ./FHEM/10_MAX.pm line 32.
BEGIN failed--compilation aborted at ./FHEM/10_MAX.pm line 32.
update Versuch :
2020.06.05 20:03:53 1: Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2020.06.05 20:03:53 1: ERROR evaluating {Log('1','Downloading https://fhem.de/fhemupdate/controls_fhem.txt')}: Undefined subroutine &HoBo::Log::FW_logInform called at HoBo/Log.pm line 65.
Undefined subroutine &HoBo::Log::FW_logInform called at HoBo/Log.pm line 65.
Compilation failed in require.
Zitat von: Wzut am 05 Juni 2020, 19:26:44
Start als root schlägt fehl , start als normaler User ging nachdem dieser User Schreibrechte auf die aktuelle fhem.log hatte.
Beim ersten edit der config und save :
undefined subroutine &HoBo::Command::WriteStatefile called at HoBo/Command.pm line 1072.
Compilation failed in require.
2020.06.05 19:31:38 1: reload: Error:Modul 10_MAX deactivated:
Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC contains: ./lib ./FHEM lib . CODE(0x563401bdd1b8) ./FHEM/lib) at ./FHEM/10_MAX.pm line 32.
BEGIN failed--compilation aborted at ./FHEM/10_MAX.pm line 32.
flennAber danke für's testen. Positive Nachricht: Alle diese Fehlermeldungen kamen von einem 5.30.2 Perl. :-)
Dann schauen wir mal wo's hakt...
edit:
https://gl.petatech.eu/root/HomeBot/-/commit/ee89f3450f014396b7471d5988defefae2c88448
Die Magie einer CI Toolchain sollte ein Binary ausspucken, das nun ein wenig besser tut. Also wer auch immer Zeit hat das zu testen und mir z.B. via PM im ping-pong Verfahren die Bugs mitzuteilen, sei herzlich eingeladen.
ok, und schau auch mal nach den anderen interen Commands , ala :
Undefined subroutine &HoBo::Command::ReadingsVal called at HoBo/Command.pm line 1046.
Zitat von: Wzut am 05 Juni 2020, 20:12:28
ok, und schau auch mal nach den anderen interen Commands , ala :
Undefined subroutine &HoBo::Command::ReadingsVal called at HoBo/Command.pm line 1046.
ok. Nochmal intensiv geschaut, 3 Problemzonen gefixt. Sollte wieder ein Stückchen weiterkommen...
Ich kapier' ehrlich gesagt nicht, warum er bei mir nicht geschrien hat. Kann ich ggf. Deine .cfg haben?
klar,kein Problem. Ich muß dazu sagen das nachdem ich gesehen hatte das HoBo mit den normalen Userrechten startet, habe ich das aktuelle svn unterhalb meines Normalusers kopiert und HoBo dazu. Erster Start war dann mit der default fhem.cfg und dann soltte via define jeweils eins meiner eigenen Module dazu.
attr global userattr cmdIcon cmdIcon devStateIcon:textField-long devStateIcon:textField-long devStateStyle devStateStyle icon icon sortby sortby webCmd webCmd webCmdLabel:textField-long webCmdLabel:textField-long widgetOverride widgetOverride
attr global autoload_undefined_devices 1
attr global autosave 0
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd none
attr global statefile ./log/fhem.save
attr global verbose 3
define WEB FHEMWEB 8083 global
setuuid WEB 5eda8791-f33f-ed5f-bfa3-db4e12ff5dcb5b44
attr WEB editConfig 1
attr WEB stylesheetPrefix dark
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
setuuid Logfile 5eda8791-f33f-ed5f-18ae-cc87bf39c3e9987e
define autocreate autocreate
setuuid autocreate 5eda8791-f33f-ed5f-704d-3329ef4d69ac34b2
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
setuuid eventTypes 5eda8791-f33f-ed5f-63a8-bc5198473d69c2d9
und wie steht es mit den CPAN Modulen , hast du in HoBo alles gepackt was irgend ein Modul mittels use aufruft ?
denn da fehlen wohl noch einige , zb wird man z.Z. kein Modul nutzen können was Meta.pm eingebunden hat
2020.06.06 08:06:58 0: Server started with 5 defined entities (hobo.pl:99999/2020-04-11 perl:5.030003 os:linux user:eddy pid:3263)
2020.06.06 08:07:18 1: reload: Error:Modul 98_readingsWatcher deactivated:
Can't locate File/stat.pm in @INC (you may need to install the File::stat module) (@INC contains: ./lib ./FHEM lib . CODE(0x56126aacd1b8) ./FHEM/lib) at FHEM/Meta.pm line 20.
BEGIN failed--compilation aborted at FHEM/Meta.pm line 20.
Compilation failed in require at ./FHEM/98_readingsWatcher.pm line 96.
2020.06.06 08:07:18 0: Can't locate File/stat.pm in @INC (you may need to install the File::stat module) (@INC contains: ./lib ./FHEM lib . CODE(0x56126aacd1b8) ./FHEM/lib) at FHEM/Meta.pm line 20.
BEGIN failed--compilation aborted at FHEM/Meta.pm line 20.
Compilation failed in require at ./FHEM/98_readingsWatcher.pm line 96.
2020.06.06 08:08:43 1: reload: Error:Modul 96_SIP deactivated:
Can't locate Net/Domain.pm in @INC (you may need to install the Net::Domain module) (@INC contains: ./lib ./FHEM lib . CODE(0x56126aacd1b8) ./FHEM/lib) at ./FHEM/96_SIP.pm line 53.
BEGIN failed--compilation aborted at ./FHEM/96_SIP.pm line 53.
2020.06.06 08:08:43 0: Can't locate Net/Domain.pm in @INC (you may need to install the Net::Domain module) (@INC contains: ./lib ./FHEM lib . CODE(0x56126aacd1b8) ./FHEM/lib) at ./FHEM/96_SIP.pm line 53.
BEGIN failed--compilation aborted at ./FHEM/96_SIP.pm line 53.
2020.06.06 08:09:28 1: define beok BEOK 192.168.0.241 34:ea:34:79:02:99: please install Crypt::CBC first
Net::Domain habe ich z.B. nicht direkt in 96_SIP sondern Net::SIP , und Net::SIP will Net::Domain
Zitat von: Wzut am 06 Juni 2020, 07:39:55
klar,kein Problem. Ich muß dazu sagen das nachdem ich gesehen hatte das HoBo mit den normalen Userrechten startet, habe ich das aktuelle svn unterhalb meines Normalusers kopiert und HoBo dazu. Erster Start war dann mit der default fhem.cfg und dann soltte via define jeweils eins meiner eigenen Module dazu.
Hm. Das mache ich auch...
Zitat
und wie steht es mit den CPAN Modulen , hast du in HoBo alles gepackt was irgend ein Modul mittels use aufruft ?
eigentlich dachte ich ja, aber offensichtlich sind mir einige entgangen. Ich denke ich habe (eigtl. Du hast) einen blinden Fleck entdeckt.
Schaue ich mir gleich an.
IMHO ist der Fleck noch etwas größer :
use IO::Socket::Multicast schlägt auch fehl.
Mal schauen vllt. heute Nachmittag kann ich mal meine echten fhem.cfgs auf HoBo loslassen :)
Der Blinde Fleck hat die Ausmaße einer kleinen Zwerggalaxie. Dauert noch etwas...
Hm. Also:
* HoBo_x86_64 mittlerweile 44MB groß (noch nicht auf dem GitLab - erst noch in meiner Sandbox) - aber geht ja noch
* just IO::Socket::Multicast[6] ist noch ein Problem, weil IO::Interface partout nicht will unter staticperl
* Paws::Polly ist die Pest - also im FHEM Kontext
Will sagen: ich wäre da indifferent, aber just in FHEM mit dem Gebot der CPAN Sparsamkeit ist Paws::Polly eines der größten Schwergewichte die man holen kann.
Das holt mal eben die halbe AWS Infrastruktur, vorher noch schnell Moose und natürlich die ganzen Moose-Abhängigkeiten. Da habe ich dann irgendwann einen Riegel vorgeschoben.
(98_Text2Speech "will" das. Gute Nachricht ist, es macht einen eval-require also optional das ganze. Wenn diese ganze Infra nicht da ist, sollte das Modul nicht die Grätsche machen)
Man wird bald unter resources/HoBo.bundle die entsprechenden module sehen - da könnte man auch konsolidieren (also wenn es jemanden gäbe, der modulübergreifend and die Sache herangehen würde. Manchmal holt man sich - trotz proklamierter CPAN Sparsamkeit - verschiedene CPAN Module, die mehr oder minder das Gleiche machen. Für jemanden, der dann versucht ein Bundle zu machen ist das natürlich suboptimal.
Ansonsten ärgern mich noch
Crypt::Argon2
Crypt::NaCl::Sodium
HiPi::Device::I2C
IO::Interface (!!!)
IO::Interface::Simple (Folgefehler)
Wenn ich die IO::Interface Geschichte hinbekomme sollte tatsächlich etwas funktionales bei rauskommen.
Ich habe noch zwei Punkte , beim Hobo Start
2020.06.06 18:23:20 1: PERL WARNING: Prototype mismatch: sub main::time_str2num: none vs ($) at ./FHEM/99_Utils.pm line 22.
2020.06.06 18:23:20 1: PERL WARNING: Subroutine time_str2num redefined at ./FHEM/99_Utils.pm line 16.
Hast du bei dir time_str2num aus der 99_Utils.pm entfernt ? Ich habe es mir jetzt mal auskommentiert.
der zweite Punkt ist ein shutdown restart in der Eingabezeile :
2020.06.06 18:23:21 0: Server started with 6 defined entities (hobo.pl:99999/2020-04-11 perl:5.030003 os:linux user:eddy pid:2692)
2020.06.06 18:25:27 0: Server shutdown
2020.06.06 18:25:27 1: PERL WARNING: Use of uninitialized value $exitValue in exit at !boot line 1472.
Can't connect to localhost:./HoBo_x86_64
Compilation failed in require.
* Prototypes warnings bekannt und bleiben erstmal so. Sind auch nicht fatal. Ich habe ein HoBo::Utils ohne Prototypen, naja und das clasht halt mit dem 99_Utils.
* shutdown restart muss in einem statischen binary anders implementiert werden, das wird bis dahin nicht funktionieren.
* https://gl.petatech.eu/root/HomeBot/-/wikis/HoBo-static-binary (erstmal aus meiner Sandbox)
Ist entpackt jetzt nur 13MB groß, grüßt erstmal mit:
# ./HoBo_x86_64 hobo.cfg
Too late to run CHECK block at Attribute/Handlers.pm line 13.
Too late to run INIT block at Attribute/Handlers.pm line 13.
Aliasing via reference is experimental at lib/HoBo/Command.pm line 29.
Aliasing via reference is experimental at lib/HoBo/Command.pm line 30.
Aliasing via reference is experimental at lib/HoBo/Command.pm line 31.
Aliasing via reference is experimental at lib/HoBo/Command.pm line 33.
Aliasing via reference is experimental at lib/HoBo/Command.pm line 34.
Possible attempt to separate words with commas at !boot line 1.
aber egal. :-)
Schade nun bin ich als Beta Tester raus, sowohl auf meinem Debian Desktop PC sowie auf meiner FHEM Hauptinstanz (stretch) :
./HoBo_x86_64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./HoBo_x86_64)
./HoBo_x86_64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./HoBo_x86_64)
eddy@T610:~/fhem$ ldd --version
ldd (Debian GLIBC 2.24-11+deb9u4) 2.24
Zitat von: Wzut am 07 Juni 2020, 07:52:43
Schade nun bin ich als Beta Tester raus, sowohl auf meinem Debian Desktop PC sowie auf meiner FHEM Hauptinstanz (stretch) :
./HoBo_x86_64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./HoBo_x86_64)
./HoBo_x86_64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./HoBo_x86_64)
eddy@T610:~/fhem$ ldd --version
ldd (Debian GLIBC 2.24-11+deb9u4) 2.24
Ach Mist ... klar - auf dem GitLab Runner läuft ja ein Debian, Da ist die Glibc auch etwas älter. Dieses Binary kommt von meinem Arch Linux und das ist "relativ frisch".
https://gl.petatech.eu/root/HomeBot/-/wikis/HoBo-static-binary
Dann versuch' bitte das AppImage, das ist (geplant) komplett unabhängig vom Linux OS. Einzige Einschränkung da ist die Architektur (X86_64)
Aufruf:
./HomeBot-x86_64.AppImage hobo.cfg(oder eben mit fhem.cfg). In der Prozesstabelle sollte dann sowas (in der Art) auftauchen:
root 1587088 0.0 0.0 11644 1800 ? Ssl 08:37 0:00 ./HomeBot-x86_64.AppImage hobo.cfg
root 1587092 0.0 0.2 103284 40576 pts/22 S 08:37 0:00 ./HomeBot-x86_64.AppImage hobo.cfgalso zweimal, wovon eines ja nur so ne leere Hülle ist. Das ist dieser Fork den FHEM/HoBo am Anfang veranstaltet.
"shutdown restart" tut aber auch nicht - gilt das gleiche wie schon bei staticperl gesagt.
Der Prozess verschwindet einfach (also manueller Neustart dann)
Leider knapp vorbei ... GLIBC_2.25 , wie ich aber zuvor geschrieben haben kann ich nur GLIBC_2.24 bieten :(
Wie? Was?
Das AppImage will von Dir eine Lib?
$ ldd HomeBot-x86_64.AppImage
not a dynamic executable
k.A. , ich erfinde das doch nicht :
eddy@T610:~/fhem$ ./HomeBot-x86_64.AppImage ./fhem.cfg
./HomeBot-x86_64.AppImage: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by ./HomeBot-x86_64.AppImage)
./HomeBot-x86_64.AppImage: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by ./HomeBot-x86_64.AppImage)
./HomeBot-x86_64.AppImage: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./HomeBot-x86_64.AppImage)
eddy@T610:~/fhem$ ldd HomeBot-x86_64.AppImage
das Programm ist nicht dynamisch gelinkt
Ok. Ich muss eindeutig noch mehr Zeit mit dem Thema verbringen bis das ausgereifter ist.
das kannst nur du beurteilen, aber dein Ansatz von gestern ohne AppImage lief doch aus dem Stand.
https://svn.fhem.de/trac/changeset?reponame=&new=22228%40%2F&old=22227%40%2F
->
https://gl.petatech.eu/root/HomeBot/-/commit/d844dba5b1983e15bdda24f80257243e3ea802d9
und damit laufen die Tests auch wieder durch.
@CoolTux: sehr sehr schön. <hier denke man sich das daumen-rauf Unicode Symbol (Fehler beim Schreiben des Beitrages.
Textfeld wurde nicht ausgefüllt.)>
Und vor allem: Erster!
Genau vor 3 Stunden dachte ich noch so bei mir das ich schon lange nichts mehr von Richard gelesen habe und promt kommt Text. ;D
lib/FHEM wird nun von mir automatisch gesynct und da ich davon ausgehe, dass wer diesen Namespace verwendet schon ein großer Junge ist, erfolgt auch keine Transformation des dort befindlichen Codes (weder perltidy, noch return undef replacements noch sonstwas).
Nein, ich bin nicht tot (obwohl man ja in Prag derzeit nie weiß wann es einen trifft): https://gl.petatech.eu/root/HomeBot/-/commit/cdd1807c7fede654e045340ecb34019cf779989d
Ich bin derzeit nur im Schwaben-Modus (schaffe schaffe Häusle baue)
Der Architekt hat komisch geschaut als ich mit FHEM/HoBo angefangen habe.