Peer Review von Richards Gewurschtel

Begonnen von RichardCZ, 31 März 2020, 22:17:53

Vorheriges Thema - Nächstes Thema

Christoph Morrison

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.

RichardCZ

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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

CoolTux

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.
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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RichardCZ

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?
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

CoolTux

"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)
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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RichardCZ

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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

herrmannj

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 ?

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

RichardCZ

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.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

RichardCZ

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".
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

justme1968

#70
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

RichardCZ

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)

Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

rudolfkoenig

Das wuerde auch die Regexps (Notify, FileLog, etc) der Benutzer betreffen, und wir muessten den Herrschaften beibringen, wo man ␞ auf der Tastatur findet.

KernSani

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
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...