In der Tiefe: Validierungskonzept

[Tessi]

Frage wurde hier behandelt:
https://knx-user-forum.de/eibpc/1914...tml#post218949

[Tessi]

Hallo allerseits,

da es hier ja um das Validierungsschema geht, hole ich für meine aktuelle Frage diesen Thread noch einmal wieder hoch (statt einen neuen anzulegen):

Soweit ich es gelesen und behalten habe, steht im Handbuch bei keiner Funktion ein Hinweis, ob sie bei Parameteränderungen erneut ausgewertet wird, oder nicht, demnach würde ich erwarten, das alle gemäß Kapitel Validierungsschema reagieren:
Funktionen zur Verarbeitung werden durch ihre Argumente invalid, Funktionen zu zur Ausgabe und Zeitfunktionen dagegen nicht.

Aber zu welcher Kategorie gehören stringcast() und stringset()?

In der Referent werden sie unter Stringfunktionen geführt, die würde ich normalerweise unter Verarbeitungsfunktionen einstufen.
Andererseits ist es sicherlich nicht immer erwünscht, das stringcast() und vor allem stringset() ausgeführt werden, sobald sich einer der Parameter ändert...

Ich würde mir wünschen, das bei jeder Funktion explizit angegeben wird, ob sie invalid wird, oder nicht.

[Tessi]

Michael dachte auch, dass die Visu des eibPCs für die Kunden unwichtig sei.

Ah, ja, ich erinnere mich so dunkel, ist schon ein Weilchen her...
Aber die Motivation doch eine zu entwickeln und zu verbessern ist unschlagbar: Man zahlt Aufpreis dafür...

[enertegus]

Die Hoffnung stirbt immer zuletzt...
Aber es fällt mir schwer zu glauben, das uns hier eine vorhandene Lösung einfach vorenthalten wurde und noch wird, das entspricht nicht meinem bisher gewonnenem Eindruck.

Naja vorhandene Lösung ist das eben nicht, was wir haben. Wir haben eine moeglichkeit, tiefer ins System zu blicken als ihr, das stimmt. Das auf einen Level zu heben, dass man es hier anbieten kann, oh, da wäre noch viel Arbeit notwendig. Es ist also keine böse Absicht.

[saft6luck]

Irgendwie bin ich jetzt zu dumm um das zu verstehen...

Michael dachte auch, dass die Visu des eibPCs für die Kunden unwichtig sei.

[Tessi]

Ich verstehe nicht ganz, warum du glaubst für oder gegen eine entsprechende Lösung zu argumentieren? Sollen wir uns jetzt streiten über Dinge, die wir nur vermuten können?

Das der Debugger verbesserungswürdig ist, ist wohl jedem klar, oder? Hast du also bessere Ideen, dann her damit. Ansonsten würde ich die Diskussion über meine Ideen gerne einstellen, die Wünsche bleiben. Abgesehen davon hab ich auch Angst vor Breakpoints, was sich da plötzlich für Einsichten ergeben könnten???

Und wenn Michael um die Ecke kommt und eine Lösung hat? Aber dem schein nicht so zu sein.

Die Hoffnung stirbt immer zuletzt...
Aber es fällt mir schwer zu glauben, das uns hier eine vorhandene Lösung einfach vorenthalten wurde und noch wird, das entspricht nicht meinem bisher gewonnenem Eindruck.

Nichts ist perfekt, da macht der Debugger keine Ausnahme. Das sich Perfektion aber nicht rechnet und daher von keinem Unternehmen angestrebt wird, ist sicherlich auch kein Geheimnis mehr, nur aussprechen darf man das wohl immer noch nicht, sonst ist man der Böse...

Ebensowenig möchte ich mich streiten, ich hatte lediglich den Wunsch, meine Gedanken und und Sichtweisen zur Diskussion zu stellen und zu sehen, wie weit meine Vermutungen von anderen geteilt oder ggf. auch widerlegt werden (können).

Das war dies Mal wohl eher kontraproduktiv...

Hi, hi, das Zauberwort heißt hier wohl: Visualisierung!

Irgendwie bin ich jetzt zu dumm um das zu verstehen...

[saft6luck]

Ich schätze: Null.

Hi, hi, das Zauberwort heißt hier wohl: Visualisierung!

[saft6luck]

Aber wie viele EibPCs müsste Enertex dazu mehr verkaufen und wie viele werden es nur wegen verbesserter Debugmöglichkeiten dann tatsächlich sein? Wer von denen, die noch keinen EibPC haben, würden ihn sich zulegen wenn der Debugger verbessert wird, und auch nur dann?

Ich verstehe nicht ganz, warum du glaubst für oder gegen eine entsprechende Lösung zu argumentieren? Sollen wir uns jetzt streiten über Dinge, die wir nur vermuten können?

Das der Debugger verbesserungswürdig ist, ist wohl jedem klar, oder? Hast du also bessere Ideen, dann her damit. Ansonsten würde ich die Diskussion über meine Ideen gerne einstellen, die Wünsche bleiben. Abgesehen davon hab ich auch Angst vor Breakpoints, was sich da plötzlich für Einsichten ergeben könnten???

Und wenn Michael um die Ecke kommt und eine Lösung hat? Aber dem schein nicht so zu sein.

[enertegus]

Ich schätze mal: Zu wenige um die Entwicklung rentabel zu machen...

Ich schätze: Null.

[enertegus]

Das Problem im Code ist ein (sicher unschönes) Verhalten der Verschachtelten if-Abfrage beim Initialisieren (siehe die vorigen mails): Einfach gesprochen: Jede if-Abfrage wird beim Initalisierungsvorgang auf einmal ausgewertet, egal ob verschachtelt oder nicht. Wir haben das auf dem Radar fürs nächste Relase.

Da bin ich ja ne Antwort schuldig: Das ist nun eben gefixt - war ein harter Knochen...

[Tessi]

Das brauchst du mir nicht erklären

Aber nicht jedem Leser hier ist das auch so klar.

Trotzdem wird aber genauso auf Programmebene entwickelt, denn am Ende wird der Kunde Kommandos eingeben, weswegen die erstellten Funktionen auch im globalen Zusammenspiel laufen müssen.

Das kann Enertex aber auch mit dem C-Debugger machen, mit dem sie auch die Kommandos analysieren, wir können das nicht, denn wir bekommen weder die Sourcen, noch haben wir die zusätzliche Hardware (BDM oder gar Emulator) und Öffnen des Gehäuses geht mit Garantieverlust einher.

Wenn man aber nicht jeden im Support oder bei der Entwicklung mit einem BDM oder Emulator ausstatten will, implementieren findige Köpfe kostengünstige Varianten.

Das kostet auch Geld, und bei kleinen Unternehmen mit sehr überschaubarer Mitarbeiterzahl kann ein Emulator und ein paar BDMs immer noch billiger sein...

Ich stelle mir grad vor, jeder iPhone Entwickler müsste sich ein BDM anschaffen, um debuggen zu können. Aber: Ganz im Gegenteil, da kann man bis auf Assembler-Ebene über USB in Echtzeit debuggen. Und da reicht USB1.1!

Deren Verkaufserfolg ist auch eng mit einer großen Zahl an Apps von vielen Hobbyprogrammieren verknüpft, da amortisieren sich die Entwicklungskosten für solche Tools recht schnell.
Aber wie viele EibPCs müsste Enertex dazu mehr verkaufen und wie viele werden es nur wegen verbesserter Debugmöglichkeiten dann tatsächlich sein? Wer von denen, die noch keinen EibPC haben, würden ihn sich zulegen wenn der Debugger verbessert wird, und auch nur dann?
Ich schätze mal: Zu wenige um die Entwicklung rentabel zu machen...
Und das auf Anwenderebene bei Enertex intern schon was gibt, das über das im EibStudio verfügbare hinausgeht, glaube ich eher nicht...
Falls ich mich da aber irre, würde ich mich natürlich schon sehr freuen, wenn Enertex das auch dem ambitionierten Anwender zugänglich machen würde.

[saft6luck]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

Das brauchst du mir nicht erklären
Trotzdem wird aber genauso auf Programmebene entwickelt, denn am Ende wird der Kunde Kommandos eingeben, weswegen die erstellten Funktionen auch im globalen Zusammenspiel laufen müssen.

Yep, so isses.

Wenn man aber nicht jeden im Support oder bei der Entwicklung mit einem BDM oder Emulator ausstatten will, implementieren findige Köpfe kostengünstige Varianten.

Ich stelle mir grad vor, jeder iPhone Entwickler müsste sich ein BDM anschaffen, um debuggen zu können. Aber: Ganz im Gegenteil, da kann man bis auf Assembler-Ebene über USB in Echtzeit debuggen. Und da reicht USB1.1!

[enertegus]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

Yep, so isses.

[Tessi]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

[saft6luck]

OK, Breakpoints und Debug-Code sind besser als nichts, ...

Ehrlich gesagt ist das der Grund für die Anfrage.

aber ob wirklich hilfreich genug, um den zusätzlichen Entwicklungsaufwand inklusive langer Beta-Tests zu rechtfertigen? Irgend jemand muss prüfen, ob das alles auch korrekt arbeitet. Und das ist sicher nicht trivial.

Irgendwie sollte Michael ja auch mal im eibPC Fehler aufgespürt haben. Evtl. hat er ja die eine oder andere Möglichkeit bereits implementiert? Immerhin ist das ja nicht nur für den Kunden, sondern auch für die Enertex Softwareentwicklung und den Support interessant.