Autor Thema: Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)  (Gelesen 1712 mal)

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« am: 18 März 2020, 13:52:19 »
Habe mich mal nach den Nutzern von 99_Utils.pm umgesehen.

88_HMCCUDEV.pm benutzt ziemlich intensiv min/max. Allerdings werden alle Aufrufe - so wie es aussieht - im falschen Kontext abgesetzt.

min/max machen Stringvergleiche

die in 99_Utils ebenfalls vorhandenen minNum/maxNum machen numerische Vergleiche.

nun ruft 88_HMCCUDEV.pm min/max ganz überwiegend (habe noch kein Gegenbeispiel gefunden) im numerischen Kontext auf.

Das kann u.U. ziemlich in die Hose gehen, weil im Stringkontext eben "11" kleiner ist als "2".



Entweder man knickt minNum und ersetzt min durch den Code (weil ich glaube, jeder sieht min intuitiv numerisch), oder 88_HMCCUDEV.pm sollte die min/max Aufrufe durch minNum/maxNum Aufrufe ersetzen.

Ich wäre für ersteres.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #1 am: 18 März 2020, 14:13:28 »
Wie man es vermutlich aus anderen Beitraegen auslesen kann: ich bin konservativ mit globalen Aenderungswuenschen: auch wenn ich gerne FHEM komplett neu schreiben wuerde, ich (und all die anderen Maintainer) haben nicht die Energie es zu tun, vor allem den Support dafuer zu leisten.

Die Semantik von min/minNum behalten wir also erstmal, und damit wird das zu einer Fehlermeldung, und gehoert in dem HomeMatic Forumsbereich.



Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #2 am: 18 März 2020, 14:26:24 »
Wie man es vermutlich aus anderen Beitraegen auslesen kann: ich bin konservativ mit globalen Aenderungswuenschen: auch wenn ich gerne FHEM komplett neu schreiben wuerde, ich (und all die anderen Maintainer) haben nicht die Energie es zu tun, vor allem den Support dafuer zu leisten.

Die Semantik von min/minNum behalten wir also erstmal, und damit wird das zu einer Fehlermeldung, und gehoert in dem HomeMatic Forumsbereich.

Gut, aber wenn gewünscht, kann man minNum/maxNum relativ schnell vom Antlitz der Erde fegen. So viel ist das nicht:

FHEM/Color.pm:  my $m = ::minNum( $r, $g, $b );
FHEM/00_THZ.pm:my $v0min = minNum(15, ($ycurvevalues->[33][1]), ($ycurvevalues->[33][2]), $heatSetTemp);        #lower offset than 15, if out of scale
FHEM/98_logProxy.pm:    $to = minNum( $time, $now );
FHEM/#99_Utils.pm#:sub minNum($@)
FHEM/#99_Utils.pm#:    <li><b>minNum(num1, num2, ...)</b><br>returns the lowest value from a given
FHEM/95_Astro.pm:    my $n = minNum( $next[0], @next );
FHEM/10_SOMFY.pm:                               $updateState = minNum( 100, $updateState );
FHEM/10_SOMFY.pm:                       $newState = minNum( 100, $posRounded );
FHEM/10_SOMFY.pm:  $v = minNum( 100, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:  $v = minNum( 200, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:                       $pos = minNum( 100, $pos );
FHEM/10_SOMFY.pm:                               $newPos = minNum( 100, $pos );
FHEM/10_SOMFY.pm:                                       $newPos = minNum( 200, $pos + $newPos );
FHEM/RESIDENTStk.pm:      minNum( ReadingsVal( $name, "lastLocationLong", 0 ), $currLong )
FHEM/RESIDENTStk.pm:      minNum( ReadingsVal( $name, "lastLocationLat", 0 ), $currLat )
FHEM/98_apptime.pm:    my $nice = minNum(19,keys %prioQueues);
FHEM/99_Utils.pm:minNum($@)
FHEM/99_Utils.pm:    <li><b>minNum(num1, num2, ...)</b><br>returns the lowest value from a given


FHEM/31_HUEDevice.pm:        my $bri  = maxNum($r,$g,$b);
FHEM/31_HUEDevice.pm:      my $f = maxNum($X,$Y,$Z);
FHEM/31_HUEDevice.pm:      my $f = maxNum($r,$g,$b);
FHEM/10_WS980.pm:                               if ($srcValue <= maxNum(0, $limit - $hyst)) {
FHEM/10_WS980.pm:                               } elsif ($srcValue >= maxNum(0, $limit - $hyst)) {
FHEM/00_MQTT2_SERVER.pm:    MQTT2_SERVER_out($hash, pack("CCnC*", 0x90, 3, $pid, maxNum(@ret)), $dump);
FHEM/Color.pm:  my $M = ::maxNum( $r, $g, $b );
FHEM/Color.pm:      my $f = main::maxNum($X,$Y,$Z);
FHEM/Color.pm:      my $f = main::maxNum($r,$g,$b);
FHEM/34_SWAP.pm:            $max_pos = maxNum( $max_pos, int($endpoint->{position}) );
FHEM/34_SWAP.pm:          $len = maxNum( $len, $max_pos+$max_pos_size );
FHEM/00_THZ.pm:   $Simul_heatSetTemp             = sprintf("%.1f", maxNum(5,( $tmp + $a)));
FHEM/00_THZ.pm:   $Simul_heatSetTemp_simplified = sprintf("%.1f", maxNum(5,($tmp + $a1)));
FHEM/00_THZ.pm:$v0min = maxNum(5, nearest_ceil(5, $v0min));                                     #start only from a multiple of 5, but do not go below 5
FHEM/98_Installer.pm:                    my $v = maxNum( 0, @{ $pkgStatus{$area}{$t}{$pkg} } );
FHEM/#99_Utils.pm#:sub maxNum($@)
FHEM/#99_Utils.pm#:    <li><b>maxNum(num1, num2, ...)</b><br>returns the highest value from a
FHEM/31_Aurora.pm:      my $f = maxNum($X,$Y,$Z);
FHEM/31_Aurora.pm:      my $f = maxNum($r,$g,$b);
FHEM/50_HP1000.pm:        return maxNum( 0, @a );
FHEM/10_SOMFY.pm:  $v = minNum( 100, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:  $v = minNum( 200, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:                               $newPos = maxNum( 0, $pos );
FHEM/10_SOMFY.pm:                                       $newPos = maxNum( 0, ($pos - $newPos) );
FHEM/10_SOMFY.pm:                                       $newPos = maxNum( 0, $pos - $newPos );
FHEM/10_SOMFY.pm:    my $nstt = maxNum($nowt+$utime-0.01, gettimeofday()+.1 );
FHEM/RESIDENTStk.pm:      maxNum( ReadingsVal( $name, "lastLocationLong", 0 ), $currLong ) -
FHEM/RESIDENTStk.pm:      maxNum( ReadingsVal( $name, "lastLocationLat", 0 ), $currLat ) -
FHEM/99_Utils.pm:maxNum($@)
FHEM/99_Utils.pm:    <li><b>maxNum(num1, num2, ...)</b><br>returns the highest value from a


Und das Problem betrifft auch andere Module.

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #3 am: 18 März 2020, 19:12:30 »
Ich korrigiere es in HMCCU. Nach dem Motto "wenn es gut werden soll, mach es selbst" baue ich eine eigene Funktion dafür. In jeder Programmiersprache ist min/max numerisch, daher der Fehler.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #4 am: 19 März 2020, 12:07:21 »
Ich korrigiere es in HMCCU. Nach dem Motto "wenn es gut werden soll, mach es selbst" baue ich eine eigene Funktion dafür. In jeder Programmiersprache ist min/max numerisch, daher der Fehler.

Ich wollte Rudolf vorschlagen, dass ich gerne Maintainerschaft für 99_Utils.pm übernehmen kann - aber irgendwie sind die PMs geblockt. Das sieht relativ OS-unabhängig aus (bzw. muss es sein) und wenn man da ansetzen kann allen Modulmaintainern einen guten Grundstock zu liefern, dann wäre das doch ein guter erster Schritt.

Momentan habe ich in meinem Repo

sub _sortAlphNum {
    return [sort { $a cmp $b } @_ ];
}

sub _sortNum {
    return [sort { $a <=> $b } @_ ];
}

sub min {
    return _sortAlphNum(@_)->[0];
}

sub max {
    return _sortAlphNum(@_)->[-1];
}

sub minNum {             
    return _sortNum(@_)->[0];
}

sub maxNum {             
    return _sortNum(@_)->[-1];
}

und die entsprechende Testsuite. Die Bedenken bzgl. CPAN verstehe ich, mittel-langfristig glaube ich aber dass man da noch bessere Wege finden wird, aber bis dahin wäre ich gerne bereit Utils zu einer "netten Toolbox" zu machen.
« Letzte Änderung: 19 März 2020, 12:15:27 von RichardCZ »
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 1 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #5 am: 19 März 2020, 14:18:54 »
Gefixt für HMCCU-Module. Die FHEM min/max Funktionen wurden durch Modul interne Funktionen ersetzt.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20311
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #6 am: 20 März 2020, 10:49:56 »
die min/max geschichten aufzuräumen finde ich gut.

zusätzlich neue eigene routinen in die module einzubauen aber nicht. das widerspricht dem gedanken einer zentralen toolbox.

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Zustimmung Zustimmung x 1 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #7 am: 20 März 2020, 12:53:29 »
die min/max geschichten aufzuräumen finde ich gut.

zusätzlich neue eigene routinen in die module einzubauen aber nicht. das widerspricht dem gedanken einer zentralen toolbox.

Was soll man machen, wenn sich die zentrale Toolbox nicht an Konventionen in verschiedenen Programmiersprachen hält? Sollte sich das in FHEM ändern, bin ich gerne bereit, wieder min und max zu verwenden.

Ich bin RichardCZ sehr dankbar für diesen Thread. Nun weiß ich endlich, woher die teilweise seltsamen Effekte bei der Nutzung meiner Module kommen.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20311
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #8 am: 20 März 2020, 12:56:18 »
erst mal minNum und maxNum verwenden. die gibt es ja schon. zentral und ziemlich lange.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #9 am: 20 März 2020, 14:08:35 »
Gefixt für HMCCU-Module. Die FHEM min/max Funktionen wurden durch Modul interne Funktionen ersetzt.

Das ist halt der Trugschluss in FHEM.

Das sind keine Modul-internen Funktionen, Du hast einfach nur neue Implementierungen in den main Namespace rein.
Somit sind HMCCU_Min/HMCCU_Max nun für alle sichtbar/verfügbar.

Ist aber egal, der Namespace kann das ja ab, solange man brav das "HMCCU_" Präfix, bzw. sein Modulpräfix im Namen verwendet.
Kapselung/Modularität ist dann zwar ein Fremdwort, die Geschichte wird unwartbar, untestbar. Aber auch das ist egal, denn dann
kann man wenigstens unwartbar/untestbar als Argument gegen Änderungen aus der Schublade holen.

Ab jetzt kann halt jeder entweder min, minNum, HMCC_Min und noch ein paar andere Implementierungen ein- und derselben Sache verwenden.

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #10 am: 20 März 2020, 17:20:00 »
Leider ist Perl halt eine sehr antiquierte Sprache, der so ziemlich alle netten Features moderner Programmiersprachen fehlen bzw. man muss einen ziemlichen Aufwand betreiben, um sie zu simulieren. Im Zweifel muss man eben damit Leben.

2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #11 am: 20 März 2020, 18:06:57 »
Leider ist Perl halt eine sehr antiquierte Sprache, der so ziemlich alle netten Features moderner Programmiersprachen fehlen bzw. man muss einen ziemlichen Aufwand betreiben, um sie zu simulieren. Im Zweifel muss man eben damit Leben.

 :) Das ist der alternativste Fakt, seit ich das lezte Mal Donald Trump zugehört habe.

Was fehlt Dir denn genau? Objektorientierung? Introspektion? Asynchronizität? Nenn' mir bitte eines der netten Features von denen Du sprichst, das Dir fehlt.

Nur weil "ihr hier" einen Code produziert, der eher an eine volle Kinderwindel erinnert als an modernes Perl, muss man nicht gleich die Sprache zum Sündenbock machen. Oder man muss - keine Ahnung, das ist dann eher ne Frage an den Psychologen.

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3562
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #12 am: 20 März 2020, 19:23:15 »
Nur weil "ihr hier" einen Code produziert, der eher an eine volle Kinderwindel erinnert
Früher suchten sie dafür den Stein der Weisen, wir machen heute halt aus Scheisse Gold ....  ich versteh nur noch nicht warum die volle Windel bei mir nach über 4 Jahren noch so einen hohen Tragekomfort hat. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #13 am: 21 März 2020, 09:27:21 »
Früher suchten sie dafür den Stein der Weisen, wir machen heute halt aus Scheisse Gold ....  ich versteh nur noch nicht warum die volle Windel bei mir nach über 4 Jahren noch so einen hohen Tragekomfort hat.

Ganz einfach! Weil sie sich nach 4 Jahren perfekt an Körpertemperatur und -Form angepasst hat.
Ich warte immer noch auf ein fehlendes Feature der antiquierten Sprache Perl.

edit:

Das mit der Kinderwindel ist natürlich eine bewusst provokative Formulierung - im wesentlichen als Antwort auf die Behauptung Perl sei ja so antiquiert. Beide Aussagen sind in etwa auf dem gleichen Niveau.

Generell sind pauschalisierende Aussagen "Code ist super", "Code ist scheisse" eher unwahr. Bzw. jemand, der so eine Aussage macht und darauf beharrt sieht die Sache vermutlich zu undifferenziert. Ich hoffe, das unterstellt man mir nicht.

Codequalität ist eine Multidimensionale Angelegenheit und "code ist scheisse" würde bedeuten, der Code ist in allen denkbaren Metriken "schlecht". Das ist selten der Fall. Meist gibt es irgendwas, was der Code gut macht, und etwas was er nicht gut macht.

HMCCU schwächelt beim Namespace handling, dafür gehört es hinsichtlich Funktionsumfang zu den eher weiterentwickelten.
AutoShuttersControl z.B. ist relativ gut beim Namespace, leistet sich aber ein ziemliches eval/require Massaker gleich zu Beginn.

Und so könnte man sich durch die 500+ Module hangeln.
« Letzte Änderung: 21 März 2020, 12:19:59 von RichardCZ »

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #14 am: 21 März 2020, 14:14:51 »
AutoShuttersControl z.B. ist relativ gut beim Namespace, leistet sich aber ein ziemliches eval/require Massaker gleich zu Beginn.

Spielst Du auf die Abfrage der JSON Wrapper an?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #15 am: 21 März 2020, 14:32:04 »
Spielst Du auf die Abfrage der JSON Wrapper an?

Ja klar. Prinzipiell bin ich ein Freund fehlertoleranter Modulnutzung (gucken was da ist und dabei nicht auf die Schnauze fliegen),
aber a) kann man das schon ein wenig prozeduraler gestalten als so eine if-Kaskade, b) wäre DAS eine wünschenswerte zentrale "Utils" Komponente fürs FHEM mit einer API a la:


use_module_prio({
    wanted   => qw(encode_json decode_json),
    priority => qw(JSON::MaybeXS JSON::XS Cpanel::JSON::XS),
});


zum Bleistift.

Rückgabewert Modulname, der geklappt hat, ansonsten undef. Dann kann das (=jedes!) aufrufende Modul entscheiden, ob es weitermacht oder nicht.
Überdies könnte die sub gleich testen, ob das betreffende Modul tatsächlich "wanted" bereitstellt.

Man könnte es auch etwas generischer/komplizierter machen, aber mit Overengineering wollte ich mich eigentlich zurückhalten.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 25628
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #16 am: 21 März 2020, 14:44:07 »
Mach mal bitte einen Patch fertig für die 99_Utils.pm und reiche diesen mit etwas Erklärung bei Rudi ein.
Mich interessiert dann besonders wie meine Implementierung dann ausschauen muss. Aber erstmal schauen wir das der Patch an kommt.
Das sind die angesprochenen kleinen Schritte.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline KernSani

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3388
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #17 am: 21 März 2020, 15:07:45 »
Bei der Gelegenheit könnte man vielleicht auch gleich noch ein „sicheres“ decode_json mitliefern, das Fehler abfängt und loggt.


Gesendet von iPhone mit Tapatalk
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #18 am: 21 März 2020, 15:51:06 »
Mach mal bitte einen Patch fertig für die 99_Utils.pm und reiche diesen mit etwas Erklärung bei Rudi ein.
Mich interessiert dann besonders wie meine Implementierung dann ausschauen muss. Aber erstmal schauen wir das der Patch an kommt.
Das sind die angesprochenen kleinen Schritte.

Für einen Patch ist es noch zu früh, aber so sollte der Code in Grundzügen aussehen:

https://gl.petatech.eu/root/HomeBot/snippets/2

Bei mir tut er zumindest. In der Beschreibung zum Snippet gehe ich noch auf UNIVERSAL (für Methoden) oder exists (einfach für Subroutinen) ein, auf der anderen Seite reden wir hier von einer programmier-API, da sollte der Modulmaintainer schon wissen was er anfordert.

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #19 am: 26 März 2020, 09:07:40 »
Für einen Patch ist es noch zu früh, aber so sollte der Code in Grundzügen aussehen:

https://gl.petatech.eu/root/HomeBot/snippets/2

Bei mir tut er zumindest. In der Beschreibung zum Snippet gehe ich noch auf UNIVERSAL (für Methoden) oder exists (einfach für Subroutinen) ein, auf der anderen Seite reden wir hier von einer programmier-API, da sollte der Modulmaintainer schon wissen was er anfordert.

Nice! Übernehme ich gerne.

Zum Thema Perl und modern. Ich möchte jetzt hier keinen Glaubenskrieg der Programmiersprachen-Jünger vom Zaun brechen. In Perl kann man fast alle Features neuerer Sprachen zumindest teilweise simulieren. Das passiert ja auch z.B. beim Thema Objektorientierung, auch wenn es weit vom Komfort von C++ oder Swift entfernt ist. Wünschen würde ich mir z.B. eine eingebaute, durchgängige Typensicherheit (auch bei skalaren Typen)  (ja, auch das kann man simulieren), Templates usw. Gerade die Typensicherheit würde eine Menge Fehler vermeiden.
in vielen Sprachen ist z.B. Min/Max als template Function definiert. Zusammen mit Typensicherheit gibts keine Probleme mehr bei der Verwendung mit Strings, Integer oder whatever.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3387
    • HMCCU
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #20 am: 26 März 2020, 09:11:17 »
Bei der Gelegenheit könnte man vielleicht auch gleich noch ein „sicheres“ decode_json mitliefern, das Fehler abfängt und loggt.


Gesendet von iPhone mit Tapatalk

Besser wäre es, das ganze JSON Modul zu entsorgen und neu zu schreiben. Decode_json ist ja nur die Spitze des Eisbergs
Just my 2 ct.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5616
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #21 am: 26 März 2020, 09:19:28 »
Das hätte ich fertig (siehe JsonMod). Könnte man ne Lib draus machen
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse
Zustimmung Zustimmung x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #22 am: 27 März 2020, 18:44:42 »
Um zum eigentlichen Thema (min/max) zurückzukehren:

Hätte man jemanden gefragt der sich mit sowas auskennt.  ;) Bzw. wäre dieser jemand da gewesen, dann

https://forum.fhem.de/index.php/topic,109570.0.html
-> siehe Module::CoreList -> siehe https://metacpan.org/pod/List::Util -> siehe min/max/minstr/maxstr

Ganz ohne CPAN, ganz ohne eigenes neues Rad. Mit der richtigen Nomenklatur, mit Testcases, gewartet von 3. Seite ohne dass man einen Finger krumm machen muss.

« Letzte Änderung: 27 März 2020, 18:48:04 von RichardCZ »

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Generell falsche Nutzung von min/max
« Antwort #23 am: 10 April 2020, 11:26:07 »
Also diese ganze min/max Geschichte ist in FHEM komplett aus dem Ruder gelaufen.

Verwendung von min(

FHEM/98_Dooya.pm:                $updateState = min( 100, $updateState );
FHEM/98_Dooya.pm:            $newState = min( 100, $posRounded );
FHEM/98_Dooya.pm:            $pos = min( 100, $pos );
FHEM/98_Dooya.pm:                $newPos = min( 100, $pos );
FHEM/98_Dooya.pm:                    $newPos = min( 200, $pos + $newPos );

FHEM/42_SYSMON.pm:        my $cnt  = min( $cnt1, $cnt2 );

FHEM/98_feels_like.pm:    my $T_utci = T_UTCI( $T, $H, min( $W, $max_W ), $P, $T_tmrt );

FHEM/95_PostMe.pm:            my $deltas = min( 3600 * $deltah + 60 * $deltam, 86400 );

FHEM/89_FULLY.pm:    my $repeatCommand = min( AttrVal( $name, 'repeatCommand', 0 ), 2 );
FHEM/89_FULLY.pm:    my $ping          = min( AttrVal( $name, 'pingBeforeCmd', 0 ), 2 );
FHEM/89_FULLY.pm:    my $repeatCommand = min( AttrVal( $name, 'repeatCommand', 0 ), 2 );
FHEM/89_FULLY.pm:    my $ping          = min( AttrVal( $name, 'pingBeforeCmd', 0 ), 2 );
FHEM/89_FULLY.pm:    my $waitAfterPing = min( AttrVal( $name, 'waitAfterPing', 0 ), 2 );


-> Alle ausschliesslich numerisch, benutzen aber die String-Variante

Der definiert lieber seine eigene (numerisch):

FHEM/SHC_datafields.pm:sub min($$) {
FHEM/SHC_datafields.pm:    my $len       = min( $length_bits, 8 - $bit );
FHEM/SHC_datafields.pm:        $len  = min( $length_bits - $src_start, 8 );


Ich finde keine einzige Verwendung von min, wo der Aufrufende mit einem alphanumerischen Kontext rechnet.

=> FHEM würde "richtiger" werden, wenn man einfach min die Semantik von minNum geben würde.

Machen wir die Gegenprobe:

FHEM/Color.pm:    my $m = ::minNum( $r, $g, $b );
FHEM/00_THZ.pm:    my $v0min = minNum(
FHEM/98_logProxy.pm:        $to = minNum( $time, $now );
FHEM/94_PWM.pm:    $newpulseAvg2 = sprintf( "%.02f", $newpulseAvg2 / minNum( 2, $cntAvg ) )
FHEM/94_PWM.pm:    $newpulseAvg3 = sprintf( "%.02f", $newpulseAvg3 / minNum( 3, $cntAvg ) )
FHEM/94_PWM.pm:    my $maxPulse     = ( ( int(@a) > 5 ) ? minNum( $a[5], 1.00 ) : 1.00 );
FHEM/95_Astro.pm:        my $n = minNum( $next[0], @next );
FHEM/10_SOMFY.pm:                $updateState = minNum( 100, $updateState );
FHEM/10_SOMFY.pm:            $newState = minNum( 100, $posRounded );
FHEM/10_SOMFY.pm:    $v = minNum( 100, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:    $v = minNum( 200, maxNum( 0, $v ) );
FHEM/10_SOMFY.pm:            $pos = minNum( 100, $pos );
FHEM/10_SOMFY.pm:                $newPos = minNum( 100, $pos );
FHEM/10_SOMFY.pm:                    $newPos = minNum( 200, $pos + $newPos );
FHEM/RESIDENTStk.pm:      minNum( ReadingsVal( $name, "lastLocationLong", 0 ), $currLong )
FHEM/RESIDENTStk.pm:      minNum( ReadingsVal( $name, "lastLocationLat", 0 ), $currLat )
FHEM/98_apptime.pm:        my $nice  = minNum( 19, keys %prioQueues );
FHEM/93_PWMR.pm:          minNum( $MaxPulse, ( ( $deltaTemp * $factor )**2 ) + $factoroffset )
FHEM/93_PWMR.pm:        $PVal = minNum( 1, sprintf( "%.2f", $PVal ) );
FHEM/93_PWMR.pm:        $IVal = minNum( 1, sprintf( "%.2f", $IVal ) );
FHEM/93_PWMR.pm:        $DVal = minNum( 1, sprintf( "%.2f", $DVal ) );
FHEM/93_PWMR.pm:        $newpulsePID = minNum( $MaxPulse, sprintf( "%.2f", $newpulsePID ) );
FHEM/93_PWMR.pm:        $IVal = minNum( 1, sprintf( "%.4f", $IVal ) );
FHEM/93_PWMR.pm:        $DVal = minNum( 1, sprintf( "%.4f", $DVal ) );
FHEM/93_PWMR.pm:        $newpulsePID = minNum( $MaxPulse, sprintf( "%.2f", $newpulsePID ) );


Ok. Mit anderen Worten, es gibt im ganzen FHEM keinen einzigen min Aufruf, der mit einem alphanumerischen Kontext rechnet. Natürlich nicht, weil landläufig verstehen die Leute unter "Aal" was anders als "lexikalisch minimales Element meines kleinen Lexikons".

Der schnellste Weg das aufzuräumen?

GROB (muss):

* man haut sub min( aus Utils raus.
* man importiert List::Util qw(min) in den main:: Namespace (also z.B. in Utils)

FEIN (nice to have):

* man benennt überall minNum -> min
* man haut minNum aus Utils raus

Tja, hätte man sowas wie "Janitors", beim Linux Kernel, dann könnten die das machen und man müsste nicht die Modulautoren belästigen.
Aber hat man nicht.

Sollte man im kollektiv-demokratischen Prozess hier in FHEM irgendwann zu der Einsicht gelangen, dass die Linux Kernelentwickler nicht
komplett pillepalle sind und dass "Janitors" eine gute Idee sind, dann mache ich gerne solche Aufräumarbeiten.

Da schon die "Macht" eines Moderators hier im Forum nicht das Richtige für mich ist, dann vielleicht die "Macht" eines Müllmanns?

Ok, man müsste dann für solche Maßnahmen natürlich die altbackene Regel des "keiner fasst des anderen Ringelp Module an." lockern,
aber hey: Fortschritt! Vorwärts immer! Rückwärts nimmah!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #24 am: 10 April 2020, 12:03:01 »
Du uebersiehst vermutlich, dass min/max fuer die Enduser gebaut wurde, fuer Verwendung in at/notify/etc, die meisten koennen eine Zahl nicht von einem String unterscheiden, und sind durch etliche Themen/etc geimpft, bei Zahlen minNum zu verwenden.

Die erwaehnten Probleme mit den Modulen kann man per Fehlermeldung im passenden Forumsbereich regeln.
Fuer eine Semantikaenderung muesste ich schon von der Mehrheit der Entwickler ueberstimmt werden.
Und dass Du eine Mehrheit fuer eine Janitor-Rolle kriegst, das wage ich zu bezweifeln :)

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #25 am: 10 April 2020, 12:50:24 »
Du uebersiehst vermutlich, dass min/max fuer die Enduser gebaut wurde, fuer Verwendung in at/notify/etc, die meisten koennen eine Zahl nicht von einem String unterscheiden, und sind durch etliche Themen/etc geimpft, bei Zahlen minNum zu verwenden.

Übersehe ich nicht. Ich gehe einfach davon aus, dass die Statistik weiterhin Gültigkeit hat, also dass repräsentative Umfragen auch repräsentativ sind.
Du weisst schon: kleine Stichprobe -> Rückschluss aufs große Ganze.
Wenn also schon die Entwickler verarscht wurden, gehe ich davon aus, dass das auch bei den Usern passiert ist.

Man kann ja minNum als Fassade für min behalten.

Zitat
Die erwaehnten Probleme mit den Modulen kann man per Fehlermeldung im passenden Forumsbereich regeln.
Fuer eine Semantikaenderung muesste ich schon von der Mehrheit der Entwickler ueberstimmt werden.
Und dass Du eine Mehrheit fuer eine Janitor-Rolle kriegst, das wage ich zu bezweifeln :)

Ich werde natürlich niemanden auf Knien bitten mir gnädig zu gewähren meine Freizeits-Kapazität einzubringen. Ich kann auch genüsslich zuschauen wie Leute auf dem Müllberg leben.

Aber ich finde es schon klasse wie reagiert wird, wenn ich schwarz auf weiss nicht unerhebliche Bugs in nicht unerheblicher Menge aufzeige.

"Hätte man anders & anderswo melden sollen"
"Soweit ist alles in Ordnung"

Kein Wunder, dass FHEM seit Jahrzehnten praktisch bugfrei ist.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22522
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #26 am: 10 April 2020, 13:52:39 »
FHEM ist weder Bugfrei, noch perfekt, aber ich versuche erst vorhandene Probleme zu loesen, und nicht selbst welche auszudenken, damit ich die dann auch noch loesen kann.

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #27 am: 10 April 2020, 15:35:15 »
FHEM ist weder Bugfrei, noch perfekt, aber ich versuche erst vorhandene Probleme zu loesen, und nicht selbst welche auszudenken, damit ich die dann auch noch loesen kann.

Das ist ja alles redlich, aber ich habe mir die o.g. Probleme nicht ausgedacht, die sind schon da gewesen. Ich zeige nur mit dem Finger drauf.

Aber hey, wenn jetzt jemand

$markise = min (9, 11);

macht und er bekommt 11 zurück, dann definieren wir das einfach als Feature, bzw. raten ihm minNum zu verwenden. Natürlich nach all dem Supportaufwand den wir (pardon: ihr) hatten um diese kontraintuitive Situation geradezubiegen. Immer und immer wieder.

Zitat
und sind durch etliche Themen/etc geimpft, bei Zahlen minNum zu verwenden.

Ich frage mich ja mit welchem Aufwand diese Impfung aufrechterhalten wird.

Alles kein Problem Rudolf, stell einfach nur auf die konservative Art sicher, dass die o.g. Bugs im Code verschwinden (also min -> minNum umbenennen). Wenn das wenigstens konsistent ist, kann man dann irgendwann immer noch einen Regex-Replacer drüberjagen.

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1191
  • Ein paar Wochen afk
    • Private Website
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #28 am: 12 April 2020, 21:31:28 »
$markise = min (9, 11);

YMMD. Mach bitte unbedingt weiter.
Maintainer von:
holidays · 59_Twilight · contrib/sacha_gloor · Buienradar

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3970
    • Meine Seite im fhemwiki
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #29 am: 12 April 2020, 23:11:31 »
Ich werde natürlich niemanden auf Knien bitten mir gnädig zu gewähren meine Freizeits-Kapazität einzubringen. Ich kann auch genüsslich zuschauen wie Leute auf dem Müllberg leben.

Aber ich finde es schon klasse wie reagiert wird, wenn ich schwarz auf weiss nicht unerhebliche Bugs in nicht unerheblicher Menge aufzeige.

Kein Wunder, dass FHEM seit Jahrzehnten praktisch bugfrei ist.

Bugfrei ist FHEM sicher nicht...

Ich finde es gut, dass Du Probleme aufzeigst und speziell auch modulübergreifend denkst. Ich finde den Ton aber einfach zu rauh. Ich vermute bei einigen hier könntest Du viel mehr erreichen, wenn die Aussagen weniger aggressiv wären. Bei "leben auf dem Müllberg" als Vergleich zu FHEM-Modulentwicklungen finde ich
mich nicht wieder.

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 592
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #30 am: 12 April 2020, 23:34:29 »
Ich finde es gut, dass Du Probleme aufzeigst und speziell auch modulübergreifend denkst. Ich finde den Ton aber einfach zu rauh. Ich vermute bei einigen hier könntest Du viel mehr erreichen, wenn die Aussagen weniger aggressiv wären.

Ich bin nicht hier um Eier zu schaukeln - ihr Memmen!  ;D
Das ist alles pure Berechnung. Man muss auch serialisieren können. Stell' Dir vor mir würden alle auf einmal danken.
Abgesehen davon glaube ich das gesuchte Wort war "assertiv" und nicht "aggressiv".
Nachdem wir ja auch schon mit "arrogant" durch sind, bezichtigt mich vielelicht noch jemand des Tourette Syndroms. Verdammte Schei*e!
(https://www.youtube.com/watch?v=fFn0llYqM8w8)

Leute - es ist auch meine Freizeit und ich habe viel Spaß. Seht es bitte lockerer.


Zitat
Bei "leben auf dem Müllberg" als Vergleich zu FHEM-Modulentwicklungen finde ich  mich nicht wieder.

Du - ein Messie findet seine Wohnung auch vollkommen i.O.
Da kommt man in der Regel ohne externen Einblick nicht aus - und dessen Wahrheitsgehalt ist komplett unabhängig davon ob er gefällt oder nicht.
« Letzte Änderung: 12 April 2020, 23:51:12 von RichardCZ »

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3970
    • Meine Seite im fhemwiki
Antw:Falsche Nutzung von min/max in 88_HMCCUDEV.pm (u.a.)
« Antwort #31 am: 13 April 2020, 11:03:50 »
Ich bin nicht hier um Eier zu schaukeln - ihr Memmen!  ;D
Das ist alles pure Berechnung. Man muss auch serialisieren können. Stell' Dir vor mir würden alle auf einmal danken.
Abgesehen davon glaube ich das gesuchte Wort war "assertiv" und nicht "aggressiv".
Nachdem wir ja auch schon mit "arrogant" durch sind, bezichtigt mich vielelicht noch jemand des Tourette Syndroms. Verdammte Schei*e!
(https://www.youtube.com/watch?v=fFn0llYqM8w8)

Leute - es ist auch meine Freizeit und ich habe viel Spaß. Seht es bitte lockerer.


Du - ein Messie findet seine Wohnung auch vollkommen i.O.
Da kommt man in der Regel ohne externen Einblick nicht aus - und dessen Wahrheitsgehalt ist komplett unabhängig davon ob er gefällt oder nicht.

Wie gesagt nicht mein Stil und ich sehe auch eher Dich bei der Bezichtigung vorne - aber das ist off topic und ich bin hier raus
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können