[Featurewunsch] Zeit- / Datumsfunktionen vervollständigen

[klaus_kraemer]

Bei den Funktionen zur Tageszeit

• hour()
• minute()
• second()

mit der Rückgabe der Werte als u08 beginnt eigentlich alles ganz logisch.

Erwarten würde man dann (ich fiel zunächst natürlich voll darauf herein), mit

• day()
• month()
• year()

analoge Zahlenwerte für das Datum zurück zu bekommen - Pustekuchen...

• dayofweek() bringt dann endlich wieder einen u08 daher.

Für so manchen Steuerungszweck wären die beweglichen Feiertage schön. Nun, der Ostersonntag eines Jahres lässt sich schön berechnen und eigentlich wären die davon abhängigen Feiertage auch kein Problem.

ABER - dazu bräuchte man als FEATUREWUNSCH:

• year() als u16
• dayofyear() als u16
• oder gleich auch noch "easterday()" als Tag innerhalb des Jahres

und vielleicht gleich noch

• monthofyear() [den month(..,..) habt Ihr ja schon verwurschtelt]
• dayofmonth()

wären in diesem Zusammenhang kein direkter Luxus mehr.

Natürlich kann man die Werte aus utc() mit Stringfunktionen und konvertieren gewinnen. Aber ein wenig umständlich ist das doch.

Fromme Wünsche? Oder was meint Ihr?

[klaus]

Natürlich kann man die Werte aus utc() mit Stringfunktionen und konvertieren gewinnen. Aber ein wenig umständlich ist das doch.

Ach, so kompliziert ist das doch nicht. Ich verwende folgenden Code bei mir und rechne dann im Programm bei Bedarf einfach mit den entsprechenden Variablen für Jahr, Monat und Tag.

[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]
 datum = convert(setdate(), $$)
 tag = convert(split(datum, 0u16, 1u16), 0)
 monat = convert(split(datum, 3u16, 4u16), 0)
 jahr = convert(split(datum, 6u16, 9u16), 0u16)
 [/SIZE][/FONT][/SIZE][/FONT]

[klaus_kraemer]

Ach, so kompliziert ist das doch nicht. Ich verwende folgenden Code bei mir und rechne dann im Programm bei Bedarf einfach mit den entsprechenden Variablen für Jahr, Monat und Tag.

[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]
 datum = convert(setdate(), $$)
 tag = convert(split(datum, 0u16, 1u16), 0)
 monat = convert(split(datum, 3u16, 4u16), 0)
 jahr = convert(split(datum, 6u16, 9u16), 0u16)
 [/SIZE][/FONT][/SIZE][/FONT]

Klar, ist keine Quantenphysik. Ich denke jedoch, dass solche Grundfunktionen in den Umfang jeder Programmierung gehören und halt auch eine gewisse logische Fortsetzung von second(), minute(),... bis zum year() bestehen sollte.

[saft6luck]

Passt evtl. zu diesem Beitrag: https://knx-user-forum.de/eibpc/29181-datum.html

Generell ist der Sprachumfang, nennen wir es mal "überarbeitungswürdig"!

Es fehlen Kommandos, die regelmäßige Operationen vereinfachen/verkürzen, z.B. left$(), right$(), genauso wie die angesprochenen Zeitfunktionen, gar nicht zu sprechen von Arrays, switch-case, enum etc.!

Regelmäßiges Feedback ist entweder "kann man per Makro selber schreiben" oder "ist zu gefährlich".

Dies führt leider zu einem ständigen "das Rad neu erfinden", natürlich mit all seinen Problemen (siehe Fragen im angesprochenen Thread). BTW ist das Beispiel von Klaus nicht fehlerfrei.

Für mich ist es der grundlegende Widerspruch der Programmiersprache: Angeblich einfach, momentan aber überwiegend Komplex, sobald die Aufgabe auch nur ein wenig umfangreicher wird, artet es aus.

Und ... es passiert nichts. Meine Frage wurde auch keines Kommentars gewürdigt.

[klaus_kraemer]

Stimmt, zu dem Thread von August 2013 würde es auch passen - ich hab' mir gerade einen komfortablen Radiowecker programmiert, dem jetzt noch die beweglichen Feiertage fehlen. Dazu gehen mir die angesprochenen Funktionen schon ab. Abgesehen davon werden eigene Makro-"Funktionen" den Prozessor weit mehr belasten, als direkt maschinenahe Funktionen

Der neu eingeführte utc() als u64 ist mir auch nicht so verständlich. Wenn schon UNIX-nah dann halt als s64 - es gibt dann kaum Probleme, Zeitdifferenzen zu berechnen.

So hart wie Du Deine Meinung zu den Enertexlern formulierst, würde ich es noch nicht sehen - ich nehme mal an, das ist ein kleines fast schon familiäres Ingenieurbüro, da dauert halt manches ein wenig länger, sobald es nicht der direkten Weiterentwicklung dient. Trotzdem denke ich, es ist an der Zeit, die Programmierumgebung, also sowohl Sprachelemente, aber auch Projektstruktur und EibStudio einem Review zu unterziehen.

[klaus]

BTW ist das Beispiel von Klaus nicht fehlerfrei.

Wo denkst du denn einen Fehler gefunden zu haben? Ich habe mir den Code eben nochmal angesehen und auch im Debugger die Werte abgefragt und da passt eigentlich alles. Dass die Variablen "tag" und "monat" u08 und nicht u16 sind ist beabsichtigt, falls du das meinen solltest.

Klaus

[klaus_kraemer]

Wo denkst du denn einen Fehler gefunden zu haben? Ich habe mir den Code eben nochmal angesehen und auch im Debugger die Werte abgefragt und da passt eigentlich alles. Dass die Variablen "tag" und "monat" u08 und nicht u16 sind ist beabsichtigt, falls du das meinen solltest.

Klaus

Hmm, ich seh' auch keinen Fehler ???

[enertegus]

Und ... es passiert nichts. Meine Frage wurde auch keines Kommentars gewürdigt.

Nun, was genau ist nun der Wunsch? Die Realisierung der obigen Datumsfunktion, der Einbau von enums, switches etc? Ich will da auch nun nicht schon wieder den Changelog Sprungs von V2 auf V3 anbringen, obwohl mir das echt in den Finger juckt. Sicher ist da was "von" Dir dabei.
Ich denke da nur an das eval(): Das haben wir nach seitenlanger Diskussion hier im Forum über Unsinn oder Sinn des Validierungskonzepts eingebaut - nur dass wir/ich hier Ruhe haben. Ich weiß ja seit der L&B: wir sind inzwischen beide der Meinung, dass eval() sinnlos ist. Du magst berechtigt anmerken, dass die Erklärung im Handbuch so schlecht war, dass Du es nicht richtig verstehen konntest. Aber so ist das mit allen andern Featurewünschen auch: Ich sehe Eure Argumente, aber eben auch eine andere Seite und wäge ab, welches Thema als nächstes Präferenz bekommt.

[saft6luck]

Nun, was genau ist nun der Wunsch? Die Realisierung der obigen Datumsfunktion, der Einbau von enums, switches etc?

Das sind nur Beispiele. Der Widerspruch vom Anspruch einer einfachen Programmierung und deren Umsetzung muss endlich aufgelöst werden. Einfach ist nicht "ich kann alles machen", sondern Einfaches muss ich mir nicht erst basteln und Notwendiges führt nicht zum Chaos.

Ich will da auch nun nicht schon wieder den Changelog Sprungs von V2 auf V3 anbringen, obwohl mir das echt in den Finger juckt. Sicher ist da was "von" Dir dabei.

Da hast du auf jeden Fall recht, der eibPC bleibt nicht stehen. Meiner Meinung nach vernachlässigt die Entwicklung des Befehlssatzes leider die Kommandos, die die normale Programmierung "einfacher" machen (und auch lesbarer gehört dazu).

Beispiele:

chr$(): Jeder, der nicht darstellbare Zeichen initialisieren möchte, muss über systemstart() im 0. (?) Zyklus per stringset() einen String schreiben. Wer diese Zeichen bereits bei systemstart() in anderen Strings benötigt muss noch weiter basteln. U.U. müssen sogar Makros angepasst werden.

left$(), right$(): kann man sich über splitstring() basteln. Wie finde ich dann das Ende? EOS oder END (Michael, schau mal im Handbuch nach, was was macht!) oder size(string)-1?

enum: Jeder, der mit dem WebServer arbeitet muss sich IDs ausdenken und darauf achten, dass keine ID doppelt vorkommt (abgesehen vom Wertebereich). Das führt zu regelmäßigem umnummerieren. Enum liegt auf der Hand. Abgesehen davon gibt es noch weitere Anwendungen, wie Konstanten für Freigabevariablen/States etc.

swicht-case: Ja, kann komplexer sein, hilft aber komplexe Lösungen einfach umzusetzen. Man schaue sich nur die Makros an, die Kommunikation auswerten. Endlose if-then Kaskaden, die im besten Fall mit Freigabevariablen, meist aber eher per after()/delay() die Schritte auslösen. Wenig robust und fehleranfällig, CPU-lastig und schlecht zu warten.

Arrays: Mir ist schleierhaft, warum sich arrays angeblich so schwer implementieren lassen, wenn man sie doch im Code (für meine Begriffe äußerst umständlich) nachbilden kann. Einfach geht auf jeden Fall anders.

Aber so ist das mit allen andern Featurewünschen auch: Ich sehe Eure Argumente, aber eben auch eine andere Seite und wäge ab, welches Thema als nächstes Präferenz bekommt.

Bzgl. eval() gebe ich dir schon recht, ohne die ewigen Diskussionen hätte es aber auch kein Kapitel über das Validierungsschema gegeben.
Dies als Beispiel für weitere Wünsche zu verstehen, wird aber den eigentlichen Problemen nicht gerecht.

Selbst wenn all unsere Wünsche Nonsens sind: Man muss sich nur ein beliebiges Monstermakro anschauen, was man da alles durch neue Kommandos unterstützen könnte ...

[klaus_kraemer]

Also ich denke:

switch()...case... und Arrays müssen irgendwann einmal sein. Auch für Anfänger ist das einfacher und unübersichtlicher, als ellenlange If - then - elseif ..... Kaskaden. Ich hatte neulich einen Versuch mit einer Verschachtelungstiefe von 12 if - Grauenhaft, besonders die Fehlermeldungen und Fehlersuche!

Eigene Konstanten definieren zu können wär' auch nicht blöd, wenn die gleich auch noch ins Konstantenfenster integriert werden. Das wäre eine gute Hilfe bei den IDs der Webelemente und den Speicherstellen im Flash.

Generell müssten sich doch Featurewünsche einmal übersichtlich zusammenfassen, kategorisieren (Programmiersprache, Programmierumgebung, Projektstruktur, ...) und vielleicht auch abstimmen lassen - dann herrscht hier weniger Gezeter (einschließlich meinem...)

Nach außen sieht das im Forum oft aus, als wären viele mit dem EibPC unzufrieden, da natürlich nur Probleme angesprochen werden. Ich möchte mal ganz deutlich sagen:

Ich erfreue mich ständig am EibPC und seinen Möglichkeiten, denn damit wird mein Home erst richtig smart! Und mit ein wenig smartem Tuning freute ich mich noch mehr...

[saft6luck]

Nach außen sieht das im Forum oft aus, als wären viele mit dem EibPC unzufrieden, da natürlich nur Probleme angesprochen werden. Ich möchte mal ganz deutlich sagen:

Da gebe ich dir Recht. Es ist nicht so, dass der eibPC schlecht ist, er ist wirklich beachtlich!

Den Versuch wieder aufleben zu lassen, die Wünsche zu sammeln und auch mal eine Lösung vor der Umsetzung gemeinsam zu bewerten, finde ich aber trotzdem nicht schlecht.