Ich melde das hier wegen
FHEM/DevIo.pm rudolfkoenig Sonstiges
DevIo kann derzeit IMHO gar nicht compilieren. Gemerkt habe ich das erst nach einer Migration bei mir DevIo -> HomeBot::IO
https://gl.petatech.eu/root/HomeBot/-/blob/4e7ad071569015698f1d58d97d73519a8746a22b/lib/HomeBot/IO.pm
Nachdem das Teil im privaten Namespace ist, klappt auch ein perl -c compile check. Wie dem auch sei:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/DevIo.pm#L118
anser -> answer
edit:
Ah - jetzt verstehe ich warum das Teil compiliert. Es fehlt ein use strict; use warnings;
bei der Gelegenheit kann man auch gleich das $r == "" in Zeile 116 drüber fixen.
Danke fuer den Hinweis, habe use strict hizugefuegt und gemeldete Fehler/Warnungen entfernt.
Hallo Rudolf,
#use warnings;
führt bei mir zu vielen Log-Einträgen auch im laufenden Betrieb:
2020.04.13 11:03:18.481 1: PERL WARNING: Subroutine DevIo_setStates redefined at /opt/fhem/FHEM/DevIo.pm line 20.
2020.04.13 11:03:18.490 1: PERL WARNING: Subroutine DevIo_DoSimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 31.
2020.04.13 11:03:18.495 1: PERL WARNING: Subroutine DevIo_SimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 67.
2020.04.13 11:03:18.498 1: PERL WARNING: Subroutine DevIo_SimpleReadWithTimeout redefined at /opt/fhem/FHEM/DevIo.pm line 91.
2020.04.13 11:03:18.503 1: PERL WARNING: Subroutine DevIo_TimeoutRead redefined at /opt/fhem/FHEM/DevIo.pm line 107.
2020.04.13 11:03:18.509 1: PERL WARNING: Subroutine DevIo_SimpleWrite redefined at /opt/fhem/FHEM/DevIo.pm line 130.
2020.04.13 11:03:18.516 1: PERL WARNING: Subroutine DevIo_Expect redefined at /opt/fhem/FHEM/DevIo.pm line 161.
2020.04.13 11:03:18.577 1: PERL WARNING: Subroutine DevIo_OpenDev redefined at /opt/fhem/FHEM/DevIo.pm line 224.
2020.04.13 11:03:18.586 1: PERL WARNING: Subroutine DevIo_SetHwHandshake redefined at /opt/fhem/FHEM/DevIo.pm line 492.
2020.04.13 11:03:18.594 1: PERL WARNING: Subroutine DevIo_CloseDev redefined at /opt/fhem/FHEM/DevIo.pm line 503.
2020.04.13 11:03:18.597 1: PERL WARNING: Subroutine DevIo_IsOpen redefined at /opt/fhem/FHEM/DevIo.pm line 551.
2020.04.13 11:03:18.602 1: PERL WARNING: Subroutine DevIo_Disconnected redefined at /opt/fhem/FHEM/DevIo.pm line 563.
2020.04.13 11:03:32.494 1: PERL WARNING: Subroutine DevIo_setStates redefined at /opt/fhem/FHEM/DevIo.pm line 20.
2020.04.13 11:03:32.502 1: PERL WARNING: Subroutine DevIo_DoSimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 31.
2020.04.13 11:03:32.506 1: PERL WARNING: Subroutine DevIo_SimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 67.
2020.04.13 11:03:32.509 1: PERL WARNING: Subroutine DevIo_SimpleReadWithTimeout redefined at /opt/fhem/FHEM/DevIo.pm line 91.
2020.04.13 11:03:32.514 1: PERL WARNING: Subroutine DevIo_TimeoutRead redefined at /opt/fhem/FHEM/DevIo.pm line 107.
2020.04.13 11:03:32.520 1: PERL WARNING: Subroutine DevIo_SimpleWrite redefined at /opt/fhem/FHEM/DevIo.pm line 130.
2020.04.13 11:03:32.528 1: PERL WARNING: Subroutine DevIo_Expect redefined at /opt/fhem/FHEM/DevIo.pm line 161.
2020.04.13 11:03:32.580 1: PERL WARNING: Subroutine DevIo_OpenDev redefined at /opt/fhem/FHEM/DevIo.pm line 224.
2020.04.13 11:03:32.589 1: PERL WARNING: Subroutine DevIo_SetHwHandshake redefined at /opt/fhem/FHEM/DevIo.pm line 492.
2020.04.13 11:03:32.596 1: PERL WARNING: Subroutine DevIo_CloseDev redefined at /opt/fhem/FHEM/DevIo.pm line 503.
2020.04.13 11:03:32.599 1: PERL WARNING: Subroutine DevIo_IsOpen redefined at /opt/fhem/FHEM/DevIo.pm line 551.
2020.04.13 11:03:32.604 1: PERL WARNING: Subroutine DevIo_Disconnected redefined at /opt/fhem/FHEM/DevIo.pm line 563.
2020.04.13 11:04:18.483 1: PERL WARNING: Subroutine DevIo_setStates redefined at /opt/fhem/FHEM/DevIo.pm line 20.
2020.04.13 11:04:18.493 1: PERL WARNING: Subroutine DevIo_DoSimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 31.
2020.04.13 11:04:18.497 1: PERL WARNING: Subroutine DevIo_SimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 67.
2020.04.13 11:04:18.500 1: PERL WARNING: Subroutine DevIo_SimpleReadWithTimeout redefined at /opt/fhem/FHEM/DevIo.pm line 91.
2020.04.13 11:04:18.505 1: PERL WARNING: Subroutine DevIo_TimeoutRead redefined at /opt/fhem/FHEM/DevIo.pm line 107.
2020.04.13 11:04:18.511 1: PERL WARNING: Subroutine DevIo_SimpleWrite redefined at /opt/fhem/FHEM/DevIo.pm line 130.
2020.04.13 11:04:18.518 1: PERL WARNING: Subroutine DevIo_Expect redefined at /opt/fhem/FHEM/DevIo.pm line 161.
2020.04.13 11:04:18.572 1: PERL WARNING: Subroutine DevIo_OpenDev redefined at /opt/fhem/FHEM/DevIo.pm line 224.
2020.04.13 11:04:18.581 1: PERL WARNING: Subroutine DevIo_SetHwHandshake redefined at /opt/fhem/FHEM/DevIo.pm line 492.
2020.04.13 11:04:18.588 1: PERL WARNING: Subroutine DevIo_CloseDev redefined at /opt/fhem/FHEM/DevIo.pm line 503.
2020.04.13 11:04:18.592 1: PERL WARNING: Subroutine DevIo_IsOpen redefined at /opt/fhem/FHEM/DevIo.pm line 551.
2020.04.13 11:04:18.597 1: PERL WARNING: Subroutine DevIo_Disconnected redefined at /opt/fhem/FHEM/DevIo.pm line 563.
2020.04.13 11:04:33.463 1: PERL WARNING: Subroutine DevIo_setStates redefined at /opt/fhem/FHEM/DevIo.pm line 20.
2020.04.13 11:04:33.472 1: PERL WARNING: Subroutine DevIo_DoSimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 31.
2020.04.13 11:04:33.477 1: PERL WARNING: Subroutine DevIo_SimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 67.
2020.04.13 11:04:33.480 1: PERL WARNING: Subroutine DevIo_SimpleReadWithTimeout redefined at /opt/fhem/FHEM/DevIo.pm line 91.
2020.04.13 11:04:33.485 1: PERL WARNING: Subroutine DevIo_TimeoutRead redefined at /opt/fhem/FHEM/DevIo.pm line 107.
2020.04.13 11:04:33.490 1: PERL WARNING: Subroutine DevIo_SimpleWrite redefined at /opt/fhem/FHEM/DevIo.pm line 130.
2020.04.13 11:04:33.498 1: PERL WARNING: Subroutine DevIo_Expect redefined at /opt/fhem/FHEM/DevIo.pm line 161.
2020.04.13 11:04:33.581 1: PERL WARNING: Subroutine DevIo_OpenDev redefined at /opt/fhem/FHEM/DevIo.pm line 224.
2020.04.13 11:04:33.600 1: PERL WARNING: Subroutine DevIo_SetHwHandshake redefined at /opt/fhem/FHEM/DevIo.pm line 492.
2020.04.13 11:04:33.617 1: PERL WARNING: Subroutine DevIo_CloseDev redefined at /opt/fhem/FHEM/DevIo.pm line 503.
2020.04.13 11:04:33.621 1: PERL WARNING: Subroutine DevIo_IsOpen redefined at /opt/fhem/FHEM/DevIo.pm line 551.
2020.04.13 11:04:33.636 1: PERL WARNING: Subroutine DevIo_Disconnected redefined at /opt/fhem/FHEM/DevIo.pm line 563.
Welches Modul DevIo.pm ständig nachlädt, weiss ich noch nicht, aber die use Warnings in DevIo.pm auszukommentieren stoppt die Meldungsflut.
Gruß, Ansgar.
Kanst Du mir verraten, wie man das Problem nachstellt? Ich sehe das bei mir nicht.
Hallo Rudolf,
ZitatKanst Du mir verraten, wie man das Problem nachstellt? Ich sehe das bei mir nicht.
leider nicht.
Ich wüßte derzeit nicht, wie ich in DevIo raus bekommen kann, wer es gerade nachlädt?!?
Gruß, Ansgar.
"attr global stacktrace" ?
Hallo Rudolf,
Zitat"attr global stacktrace" ?
spuckt leider nicht mehr aus, es bleibt bei den Warnings.
Gruß, Ansgar.
Benutzt du devio in irgendeiner myUtils?
Hallo Rudolf,
ich hätte da einen Verdächtigen mit global verbose 5 im Angebot:
2020.04.13 11:55:55.311 4: BlockingCall (FRITZBOX_Readout_Run_Web): created child (30960), uses telnetPort to connect back
2020.04.13 11:55:55.345 4: FRITZBOX FritzBoxStatus: Readout_Start.755 Fork process FRITZBOX_Readout_Run_Web
2020.04.13 11:55:55.366 1: PERL WARNING: Subroutine DevIo_setStates redefined at /opt/fhem/FHEM/DevIo.pm line 20.
2020.04.13 11:55:55.375 1: PERL WARNING: Subroutine DevIo_DoSimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 31.
2020.04.13 11:55:55.381 1: PERL WARNING: Subroutine DevIo_SimpleRead redefined at /opt/fhem/FHEM/DevIo.pm line 67.
2020.04.13 11:55:55.385 1: PERL WARNING: Subroutine DevIo_SimpleReadWithTimeout redefined at /opt/fhem/FHEM/DevIo.pm line 91.
2020.04.13 11:55:55.391 1: PERL WARNING: Subroutine DevIo_TimeoutRead redefined at /opt/fhem/FHEM/DevIo.pm line 107.
2020.04.13 11:55:55.398 1: PERL WARNING: Subroutine DevIo_SimpleWrite redefined at /opt/fhem/FHEM/DevIo.pm line 130.
2020.04.13 11:55:55.407 1: PERL WARNING: Subroutine DevIo_Expect redefined at /opt/fhem/FHEM/DevIo.pm line 161.
2020.04.13 11:55:55.475 1: PERL WARNING: Subroutine DevIo_OpenDev redefined at /opt/fhem/FHEM/DevIo.pm line 224.
2020.04.13 11:55:55.485 1: PERL WARNING: Subroutine DevIo_SetHwHandshake redefined at /opt/fhem/FHEM/DevIo.pm line 492.
2020.04.13 11:55:55.495 1: PERL WARNING: Subroutine DevIo_CloseDev redefined at /opt/fhem/FHEM/DevIo.pm line 503.
2020.04.13 11:55:55.499 1: PERL WARNING: Subroutine DevIo_IsOpen redefined at /opt/fhem/FHEM/DevIo.pm line 551.
2020.04.13 11:55:55.505 1: PERL WARNING: Subroutine DevIo_Disconnected redefined at /opt/fhem/FHEM/DevIo.pm line 563.
2020.04.13 11:55:55.564 4: Connection accepted from telnetPort_127.0.0.1_60876
2020.04.13 11:55:55.572 5: Cmd: >{BlockingRegisterTelnet($cl,12)}<
2020.04.13 11:55:55.579 4: FRITZBOX FritzBoxStatus: Readout_Run_Web.1339 Prepare query string for luaQuery.
2020.04.13 11:55:55.583 5: FRITZBOX FritzBoxStatus: Web_Query.4727 Request data via API luaQuery.
2020.04.13 11:55:57.012 5: FRITZBOX FritzBoxStatus: Web_Query.4735 Response: 200 OK
Gruß, Ansgar.
- DevIo wird von vielen Modulen (56 an der Zahl) per require reingeholt, bei 20 mit use.
- die erwaehnten Warnungen gibt es, wenn bei use oder require unterschiedliche Pfadangaben gemacht werden.
- die meisten verwenden $attr{global}{modpath}/FHEM/DevIo.pm, es gibt aber auch $main::attr{global}{modpath}/FHEM/DevIo.pm und DevIo.pm.
- um den Aufruhr wg. sinnlosen Fehlermeldungen niedrig zu halten, habe ich "use warnings" aus DevIo.pm entfernt.
- ich meine use DevIo ist die richtige Loesung, ich habe meine Module, die require mit Pfad verwendet haben (CUL, ZWDongle und autocreate) umgebaut.
- damit das Problem gefixt wird, habe ich das SVN pre-commit Hook erweitert, so dass require.*modpath.*DevIo.pm untersagt, und use empfohlen wird.
Hallo Rudolf,
in fhem.pl steckt noch ein require "$attr{global}{modpath}/FHEM/DevIo.pm" in der Funktion fhemFork()
sub
fhemFork()
{
my $pid = fork;
if(!defined($pid)) {
Log 1, "Cannot fork: $!";
stacktrace() if($attr{global}{stacktrace});
return undef;
}
return $pid if($pid);
# Child here
# Close FDs as we cannot restart FHEM if child keeps TCP Serverports open
foreach my $d (sort keys %defs) {
my $h = $defs{$d};
$h->{DBH}->{InactiveDestroy} = 1
if($h->{DBH} && $h->{TYPE} eq 'DbLog'); #Forum #43271
TcpServer_Close($h) if($h->{SERVERSOCKET});
if($h->{DeviceName}) {
require "$attr{global}{modpath}/FHEM/DevIo.pm";
DevIo_CloseDev($h,1);
}
}
$SIG{CHLD} = 'DEFAULT'; # Forum #50898
$fhemForked = 1;
return 0;
}
Gruß, Ansgar.
Danke, habs geaendert.
Hallo Rudolf,
noch als Rückmeldung, das require "$attr{global}{modpath}/FHEM/DevIo.pm" in fhemFork() in fhem.pl hat die Warnings geworfen.
Ich kann sie durch Wechsel zwischen den Versionen require "$attr{global}{modpath}/FHEM/DevIo.pm" und require "DevIo.pm"; ein- und ausschalten (mit aktivem use warnings; in DevIo.pm).
Gruß, Ansgar.
PS: Die übrigen DevIo.pm Änderungen habe ich zuvor auch nachgezogen.
Zitat von: rudolfkoenig am 13 April 2020, 08:49:47
Danke fuer den Hinweis, habe use strict hizugefuegt und gemeldete Fehler/Warnungen entfernt.
73_PRESENCE.pm 20782 2019-12-19 10:51:06Z markusbloch
DevIo.pm 21659 2020-04-13 10:08:36Z rudolfkoenig
Hallo Rudi,
das Hinzufügen von "use strict" führt dazu, dass nach einem FHEM-Update PRESENCE nicht mehr funktioniert.
Can't use string ("PRESENCE_DoInit") as a subroutine ref while "strict refs" in use at FHEM/DevIo.pm line 250. Kommentiert man das "use strict" in DevIo.pm aus, ist (vorläufig) alles wieder gut.
Danke fuer den Hinweis, ich habe die Zeile in einem "no strict refs" Klammer gesetzt, hoffentlich reicht das.
Scheint zu funktionieren, auf jeden Fall verhält sich meine Testinstallation damit nun unauffällig.
70_KODI.pm scheint mit use strict auch Probleme zu haben: https://forum.fhem.de/index.php?topic=110174
Hier mal eine kleine Analyse welche Module alle einen String als Callback übergeben
00_DFPlayerMini.pm
00_SIGNALduino.pm
32_withings.pm
36_LaCrosseGateway.pm bin ich mir unsicher da anonymous sub
36_PrecipitationSensor.pm bin ich mir unsicher da anonymous sub
98_Hyperion.pm
Vorschlag:
use strict wird für 3 Monate wieder entfernt und wir geben den Maintainern damit Zeit Ihre Module gerade zu ziehen.
Grüße
Ich habe die Zele 237 auch in einem "no strict refs" Klammer gesetzt, und fhemupdate.pl angestossen.
Guten Morgen Rudi,
Aber bleibt doch nicht so, oder? Ich meine wir arbeiten schon darauf hin das ganze sauber hin zu bekommen?
Grüße
Marko
No strict refs ist imho 'sauber' (wenngleich es sicher den akademischen Weg gibt. )
ZitatAber bleibt doch nicht so, oder? Ich meine wir arbeiten schon darauf hin das ganze sauber hin zu bekommen?
Ich bin (noch?) nicht ueberzeugt, dass Funktionsamen als Callback verboten werden muessen: ich sehe keine Nachteile, aber klare Vorteile.
Zitat von: rudolfkoenig am 14 April 2020, 10:27:41
Ich bin (noch?) nicht ueberzeugt, dass Funktionsamen als Callback verboten werden muessen: ich sehe keine Nachteile, aber klare Vorteile.
Ein Verbot von Funktionsnamen als Callback ist auch nicht meine Intension. Ich dachte mehr daran das ganze use strict sicher zu machen.
Mir würde da nur eine Prüfung zu einfallen. Ich arbeite aber noch am Verständnis des ganzen :)
Aber lange Rede kurzer Splint, ich schaue ob ich Dir da etwas anbieten kann.
Zitat von: CoolTux am 14 April 2020, 09:56:25
Aber bleibt doch nicht so, oder? Ich meine wir arbeiten schon darauf hin das ganze sauber hin zu bekommen?
In guter alter FHEM-Tradition heißt "sauber" dann
no strict refs gleich vorne hin geklatscht, der Interpreter nervt nicht mehr und keine macht sich die Mühe zu verstehen, warum etwas ein Problem ist oder sein könnte.
Ich zitiere mal Perldoc zu strict (https://perldoc.perl.org/strict.html):
Zitat
The strict pragma disables certain Perl expressions that could behave unexpectedly or are difficult to debug, turning them into errors.
Was ist daran "akademisch", herrmannj? strict hat man nicht erfunden weil alle irgendwie dumm oder böse sind, sondern weil andere, besser und länger Perl programmierende Leute bemerkt haben, dass es Stellen gibt, die problematisch sind, weil sie eben anfällig für Fehler sind. Weise Menschen lernen aus den Fehlern anderer.
Weise Menschen waegen die Argumente fuer und wieder ab, und entscheiden.
Und werden nicht hektisch, wenn die Mehrheit laut schreit, oder weil Unfehlbare das so gesagt haben.
Christoph, lass doch bitte die Polemik und außerdem ist Deine Kritik _hier_ objektiv auch komplett falsch. Ja ich verstehe worauf Du hinaus willst.
Schaust Du aber in den patch dann siehst Du dass in der Zeile unmittelbar oberhalb des callbacks steht: 'no strict refs' und direkt darunter steht 'use strict'. Weise Menschen haben das pragma 'no strict refs' genau für diesen Fall eingebaut. Wenn wir, was ich begrüßen würde, konstruktiv über schöner reden dann sähe das für mich so aus:
{
no strict 'refs';
$callback->($hash,$r) if($callback);
};
strict ist lexically scoped.
Akademisch: mit verschiedenen Konstruktionen kann man die Notwendigkeit von 'no strict refs' wegbekommen die Funktionalität aber beibehalten. Das ist jetzt in meinen Augen aber Kosmetik, so ist es sauber gerade weil eben niemand "no strict refs gleich vorne hin klatscht". Kinners, lasst die Kirche im Dorf.
Ich habe mir das nun mal eine Stunde lang angeschaut und aktuell halte ich persönlich die derzeitige Lösung als in Ordnung.
Man kann noch eine Prüfung einbauen aber das würde dann auch nur in einem no strict 'refs' enden und sogar eine Zeile mehr Code verlangen.
Daher. Danke Rudi für die schnelle Reaktion!
Nur für mich zum Verständnis: also die Übergabe der Funktionen als Strings in DevIo_OpenDev ist nicht mehr erwünscht/erlaubt mittelfristig? Werde es dann gerne entsprechend ändern.
Zitat von: vbs am 14 April 2020, 12:21:15
Nur für mich zum Verständnis: also die Übergabe der Funktionen als Strings in DevIo_OpenDev ist nicht mehr erwünscht/erlaubt mittelfristig? Werde es dann gerne entsprechend ändern.
Also wenn ich das so alles korrekt verstanden habe wird erwartet das $callback eine Codereferenz ist. Da ja
$calback->(...) ausgeführt wird.
Korrigiert mich bitte jemand wenn ich das falsch verstanden habe.
Ist dem nicht der Fall dann meckert ein use strict rum.
Ich hoffe, es zählt als offizielle Quelle, aber das Wiki (https://wiki.fhem.de/wiki/DevIo) sagt eindeutig:
"$callback: Der Name (als Zeichenkette) oder die Referenz auf eine Modulfunktion, welche aufgerufen werden soll um evtl. Fehlermeldunge..."
Die Variante mit String wird sogar als erstes erwähnt. Aber wie gesagt: ich mache alles mit, wenn ihr mir sagt, dass das nicht mehr so sein soll.
@vbs: Ich habe z.Zt. noch keine ueberzeugende/ausrechende Argumente (und damit auch keine Plaene), um strings / Funktionsnamen zu untersagen.
An bestimmten Stellen, wie InternalTimer waere das kontraproduktiv, weil man damit DiagnoseFunktionen wie fhemdebug timerList sinnlos werden.
Man koennte evtl. die Funktionalitaet von timerList auch ohne funktionsNamen implementieren, ich sehe aber keine Vorteile, nur den Aufwand.
@CoolTux: eine CodeReferenz wird nicht "erwartet", nur use strict besteht darauf. Es wird irgendetwas erwartet, was man als Funktion aufrufen kann.
Danke Rudi für die Info.
Hallo Rudolf,
in DevIoTS habe ich die Änderungen auch mal alle eingepflegt, da mangels Funktionsnutzung $anser auch rein geflutscht war. Nebenbei ist mir darüber fhemFork mit den DevIo_CloseDev aufgefallen, was ich auch gleich mit berücksichtigt habe.
ZitatAn bestimmten Stellen, wie InternalTimer waere das kontraproduktiv, weil man damit DiagnoseFunktionen wie fhemdebug timerList sinnlos werden.
Man koennte evtl. die Funktionalitaet von timerList auch ohne funktionsNamen implementieren, ich sehe aber keine Vorteile, nur den Aufwand.
Hier mal ein Vorschlag für fhemdebug_timerList (der auch 97_timerTS.pm berücksichtigt ;) ), da auch bei Timern Funktionsreferenzen statt Funktionsnamen möglich sind (und ich es auch so nutze) und es schön ist, deren Namen zu sehen:
sub
fhemdebug_timerList($)
{
my ($param) = @_;
my @res;
my $tt;
my $cv;
my $tfnm;
for my $h (@intAtA) {
$tt = $h->{TRIGGERTIME};
if (ref($h->{FN}) ne "") {
$cv = svref_2object($h->{FN});
$tfnm = $cv->GV->NAME; # get function name
}
else {
$tfnm = $h->{FN}; # just function string/name
}
push(@res, sprintf("%s.%05d %s%s",
FmtDateTime($tt), int(($tt-int($tt))*100000), $tfnm,
$h->{STACKTRACE} ? $h->{STACKTRACE} : ""));
}
if (defined(@intAtTS)) { # for 97_timerTS.pm
for my $h (@intAtTS) {
$tt = $h->{TRIGGERTIME};
if (ref($h->{FN}) ne "") {
$cv = svref_2object($h->{FN});
$tfnm = $cv->GV->NAME; # get function name
}
else {
$tfnm = $h->{FN}; # just function string/name
}
push(@res, sprintf("%s.%05d %s%s",
FmtDateTime($tt), int(($tt-int($tt))*100000), $tfnm,
$h->{STACKTRACE} ? $h->{STACKTRACE} : ""));
}
}
return join("\n", @res);
}
Perl Internals Kenner könnten die Performance Unterschiede zwischen Funktionsnamen und Funktionsreferenzen aufzeichnen.
Gruß, Ansgar.
Dane fuer den Hinweis, ich habe timerList mit svref_2object erweitert.
Zitat von: rudolfkoenig am 14 April 2020, 12:49:53
@vbs: Ich habe z.Zt. noch keine ueberzeugende/ausrechende Argumente (und damit auch keine Plaene), um strings / Funktionsnamen zu untersagen.
Wobei sich die Frage stellt ob die Argumente objektiv nicht überzeugend waren, oder Du sie nur nicht als solche erkannt hast.
Insbesondere wenn sie von "Unfehlbaren" kommen. Pffff. Nicht mit uns.
Das Schlüsselwort lautet
Symbolic ReferencePBP Seite 230 - 231
"Never use symbolic references" (*)
Das ist eine ziemlich nicht-relativierende Aussage.
Häte man die Fahrradkette
$hash->{DefFn} = \&Meinetwegen_Define;statt
$hash->{DefFn} = "Meinetwegen_Define";genommen, dann hätte man auch nicht diesen ganzen Sotter mit no warnings 'refs';
Überdies hoffe ich, dass in der Diskussion nicht der Anfang vergessen wird: dass nämlich der fehlende "use strict" einen ziemlichen Hammer-Bug kaschiert hat. Jahrelang?
(*) Ich danke aber für die Gelegenheit mir diese 2 Seiten nun nochmal durchgelesen haben zu können und wünsche jedem genug Englischverständnis um Conways Seitenhiebe zu erfassen.
Hallo Richard,
Zitatnämlich der fehlende "use strict" einen ziemlichen Hammer-Bug kaschiert hat. Jahrelang?
$anser: Nein, Monatelang. Seit Mai 2019. Aber auch das spricht für "use strict" im regulären Code.
$r == "": existierte etwa 5 1/2 Jahre lang.
Rudolf hat das auch (in diesem Fall zu schnell) eingesehen, denn es steht ja nun im Code drin, mit eben den anderen Fixes und notwendigen Ausnahmen, um es kompatibel zu halten (weil und obwohl es wegen des überhasteten "use strict" über alles richtig gerummst hat).
Aus meiner Sicht mehr zu kritisieren, ist die Existenz/Notwendigkeit der Funktion "DevIo_TimeoutRead" an sich.
Denn dieses busy-waiting auf irgendwas vom Device ist Gift für die Koexistenz mit anderen Instanzen von Modulen.
Für den timeout müsste mindestens eine (scharfe) Begrenzung rein, damit nutzende Modulentwickler gezwungen werden, sich was besseres, als die Nutzung dieser Funktion auszudenken, wenn eine Antwort vom Device länger als ein paar wenige ms dauern kann.
So gesehen sind solche fies versteckten Bugs in solchen unliebsamen Funktionen sogar positiv, denn der geneigte Nutzer wird vielleicht doch direkt einen besseren Pfad suchen, statt die Bugs in der Funktion zu suchen und zu beheben. ;)
Nicht umsonst sind Module (eher Debugging Hilfen), wie 98_apptime.pm und 98_freezemon.pm mal entstanden, um u.a. busy-waiting Probleme mit anderen Modulen aufzudecken.
Und bei apptime lag der Fokus darauf, die Ungenauigkeiten und Rechenzeiten von FHEM Timern sichtbar zu machen und nicht darauf, einfach und narrensicher nutzbar zu sein.
Und apptime klinkt sich, mangels anderer Möglichkeiten, "schmutzig" aber pragmatisch durch Überschreiben von FHEM Systemfunktionen ins System ein, was eine Deiner Fragen eventuell beantwortet.
Vielen Dank für so manchen erklärenden Hinweis zu Perl. Das weckt Erinnerungen an viele Stunden des Grübelns über unerklärliches Verhalten von Perl Code. Und da kommen sicher noch einige hinzu, denn manchmal kann man gar nicht so krumm denken, wie Perl teilweise gestrickt ist.
Kannst Du eventuell was zu "Perl Internals Kenner könnten die Performance Unterschiede zwischen Funktionsnamen und Funktionsreferenzen aufzeichnen" beitragen?
Ich suche auch gerne (am liebsten technisch und nicht nur empirisch begründete) Mikrosekunden aber auch gerne Speicherplatz für das Eichhörnchen.
Gruß, Ansgar.
Zitat von: noansi am 17 April 2020, 17:37:30
Und apptime klinkt sich, mangels anderer Möglichkeiten, "schmutzig" aber pragmatisch durch Überschreiben von FHEM Systemfunktionen ins System ein
Freezemon ist genauso schmutzig nur noch extensiver :-D
Gesendet von iPhone mit Tapatalk
Hallo Richard,
ok, ich weiß, es gehört nicht ganz hierher, aber hier habe ich Schreibrechte.
Du wendest hier https://forum.fhem.de/index.php/topic,109584.msg1039610.html#msg1039610 (https://forum.fhem.de/index.php/topic,109584.msg1039610.html#msg1039610) kompromisslos return undef; -> return; an, getreu PBP.
Wie prüfst Du automatisiert den Kontext in der Funktionsnutzung über den gesamten FHEM Code, um nicht auf so was https://perlmaven.com/how-to-return-undef-from-a-function (https://perlmaven.com/how-to-return-undef-from-a-function) unter "When implicit return breaks our code" reinzufallen?
Nicht, dass ich ein konkretes Beispiel in den FHEM Modulen wüßte, wo das zum tragen kommt. Aber genau diese Unsicherheit ist bedenkenswert, zumal noch wesentlich schwerer zu diagnostizierende Fehler rauskommen könnten, wie in diesem Thread?
Gruß, Ansgar.
Da ich im Developer Forum keine Schreibrechte habe, aber beruflich IT-Projekte mache, möchte ich hier mal sagen, dass ich es wohltuend finde, dass solche Diskussionen zur Codequalität, Sicherheit und entsprechende Maßnahmen jetzt endlich mal wahrnehmbar vorangetrieben werden. Die Denkweise, Hauptsache die Funktionalität ist für den User da, ist in den Zeiten von Angriffen über vernetzte Systeme nun mal leider von vorgestern. Fast jeder von uns nutzt irgendwo in seiner Installation einen Service aus dem Internet, der Daten bereitstellt oder auch mehr.
Danke und bitte nicht nachlassen. :)
Bitte keine Nebelkerzen: keiner wird wegen "no strict ref" oder perl WARNING Zugriff auf eine FHEM Installation kriegen, und Sicherheitsprobleme wurden auch bisher nicht mit hoher Prioritaet behandelt.
Da hofft man was Nettes zu sagen und wird gleich des Werfens von Nebelkerzen bezichtigt. Thats the old way. ::)
Und die Sicherheit einer Anwendung besteht nicht darin, dass ich mich um Sicherheitprobleme nach ihrem offenbar werden kümmere. Ich gehe mal davon aus, dass Dir das "nicht" aus Versehen in den zweiten Halbsatz reingerutscht ist. ;)
ZitatUnd die Sicherheit einer Anwendung besteht nicht darin, dass ich mich um Sicherheitprobleme nach ihrem offenbar werden kümmere.
Das ist auch eine Unterstellung. CSRF habe ich eingefuehrt und viele Stunden Support geleistet, ohne dass jemand deswegen je ein Problem gemeldet hat. Das staendige Nerven von nicht gesetzten Passwort, oder das vereinfachte Umschalten auf HTTPS kam auch nicht, weil es eine Meldung gab. Das Pruefen auf non-local IP waere wegen den neuen Vorschlaegen auch nicht eher gekommen.
Ich erwaehne das, damit bei einem unbedarften Leser nicht der Eindruck entsteht, dass Sicherheitsaspekte bis jetzt vernachlaessigt wurden.
Rudolf, Du willst mich anscheinend falsch verstehen. Was ich sagen wollte war: Du hast von Sicherheitsproblemen geschrieben, Sicherheit beginnt für mich bei der Umsetzung von Coding Best Practices, die sich Leute mal ausgedacht haben um Anwendungen stabiler und sicherer zu machen. Und daher ist es schön, dass jetzt mal mit Perl::Critic draufgeschaut wird und zumindest die Sachen mit hoher Severity angegangen werden.
ZitatSicherheit beginnt für mich bei der Umsetzung von Coding Best Practices
Stimmt, wir haben dann eine unterschiedliche Vorstellung von Sicherheit.
Vermutlich stammt deine Vorstellung daher, dass z.Bsp. im C mit Verwendung von snprintf bestimmte Sicherheitsprobleme vermieden werden koennen.
Mir ist nicht bekannt, dass perlcritic Fehler dieser Klasse findet.
Zitat von: noansi am 17 April 2020, 17:37:30
Kannst Du eventuell was zu "Perl Internals Kenner könnten die Performance Unterschiede zwischen Funktionsnamen und Funktionsreferenzen aufzeichnen" beitragen?
Ich denke,
(*{$main::{$func_name}}{CODE})->(@args)versus
$func_ref->(@args)spricht eine ziemlich deutliche Sprache.
Zitat von: noansi am 17 April 2020, 19:44:30
Du wendest hier https://forum.fhem.de/index.php/topic,109584.msg1039610.html#msg1039610 (https://forum.fhem.de/index.php/topic,109584.msg1039610.html#msg1039610) kompromisslos return undef; -> return; an, getreu PBP.
Wie prüfst Du automatisiert den Kontext in der Funktionsnutzung über den gesamten FHEM Code
Gar nicht. Wer eine Funktion im List-Kontext aufruft ohne ein explizites "scalar" davor und erwartet, dass die Funktion sich diametral entgegengesetzt zu "wantarray" verhält: Darwin Award.
Zitat
Aber genau diese Unsicherheit ist bedenkenswert
Nicht für mich. Ich kann mir im HoBo Repository "mutig" erlauben. Noch ist diesbezüglich auch nix um die Ohren geflogen. Nicht dass ich am "um die Ohren fliegen" Mangel hätte.
Hinsichtlich Sicherheit ... da sind wir noch lange nicht. Irgendwelche lustigen Passwörter kann ich schon setzen, aber wenn ein Angreifer bei der Passworteingabe mal eben meinen beliebten "Krieg und Frieden" reinzünden darf, und FHEM auf einem System läuft mit Perl < 5.14 dann kann ich mir das Passwort auch in eine beliebige Körperöffnung stecken.
Aber egal, diese Diskussion werde ich jetzt weder anfangen, noch fortführen, weil es dafür viel zu früh ist. Noch gibt es keinen robusten Code (daran arbeite ich), noch gibt es nicht den Hauch von "tainted"-Sensitivität (guggsu da: https://perldoc.perl.org/perlsec.html), noch gibt es explizite und vehemente Aversion gegen CVE advisories. Ich lade auch nicht mit einem Hubschrauber ein Tesla Model S auf Sentinel Island ab um den Einheimischen zu "helfen". Alles zu seiner Zeit.
Hi, ich finden nun die Conclusio nicht. Ich will HMLAN einchecken und mit verweis auf diesen Threat wird es abgelehnt.
Wa muss ein IO Modul nun beachten um es einchecken zu können?
Statt "require $attr{global}{modpath}/FHEM/DevIo.pm" sollte man "use DevIo" verwenden.
Tut mir leid, wenn die Fehlermeldung nicht aussagekraeftig genug ist.
So weit war ich schon. use DevIo ist schon lange drin.
Dass ich das Reqiure ausbauen muss ist nicht klar.
=> mit use und ohne require geht es immer noch nicht.
das "use" steht nicht wie üblich am File-Anfang sondern im Initialize...
schwere Geburt... nach 20x Einchecken ist es nun drin.
danke