Debugging

Jack

@jey-cee Ja, mir ist das Problem mit den Speicherbereichen und dem Kompilat (Kompilierter Code. Schreibt man das nicht so?) durchaus klar. -Der Javaskript Adapter hier im IOBroker kann das?- Aber wenn man die Logik schreibt, würde ein solcher Adapter meiner Meinung nach durchaus sinn machen. Ist der Code fertig, [strgC] [strgV] und man hat einen funktionierenden Code in Javascript. - Dann braucht eh keiner mehr das "Debugging". Und wenn was geändert wird, zurück in die Entwiklungsumgebung kopieren, basteln, und wenns geht, wieder rausnehmen.

DJMarc75

@jack sorry aber das hat in der Kategorie "Einsteigerfragen" wenig zu suchen.... das ist voll Nerd und bring Einsteiger hier nicht weiter und bestimmt sehr durcheinander !

... meine Meinung - kann mich aber wie oft auch täuschen !!!

paul53

@jack sagte: damit Debugging in (kleinen) Javaskripten im großen und ganzen überflüssig ist.

Das gezeigte sind Interpreter, die zyklisch abarbeiten. Node.js kompiliert aber und Javascript arbeitet Ereignis gesteuert.

EDIT: Dein Logo (RS-Flipflop) gefällt mir.

cash

@jack Ich verstehe es trotzdem nicht. Was habe ich davon zu wissen wie die Variablen gefüllt werden? Je nach Script haben Variablen in Ihren langen Scriptläufen unterschiedliche Stände…

Nochdazu sind Scripte abhängig von anderen Scripten oder Zuständen, die man auch nicht so einfach nachstellen kann oder will. Deshalb passieren manche Tests in Reallife. Und wie was das mit den Notfallübungen die so schön funktionieren und in Reallife fast immer durch einen dummen Zufall dann doch nicht so laufen wie gedacht :-)

Noch dazu kann es Fehler beim Adapter geben um ein debugging in Scripten kommt man nach meiner Meinung nicht drumherum und unleserlicher wird das Script dadurch auch nicht. Ich kommentiere auch noch fleißig einzelne Bereiche so das viele Scripte hinterher 500 oder auch 1000 Zeilen haben. Das ganze kann man lesen. Auch nach 2 Monaten kann ich problemslos kleine Anpassungen an den div. Scripten vornehmen…. Oft baue ich zwar debugging bewußt ein nutze es aber tortzdem nicht wenn ich mir erstmal denke das es so läuft… was es dann auch in 9 von 10 Fällen so tut.

Jack

@djmarc75 Sollte ja auch zur Vereinfachung der Fehlersuche dienen. Ist ja die Kategorie " Anregungen - Wünsche - Verbesserungsvorschläge"... Und Punkto Nerd, hier -IOBroker/Javascript- bin ich Einsteiger...

Wenn das hier wo anders besser hin passt, bitte Verschieben (lassen), oder auch löschen, sollte es sowieso keine Möglichkeit geben, so etwas umzusetzen...

Homoran

@jack sagte in Debugging:

Und Punkto Nerd, hier -IOBroker/Javascript- bin ich Einsteiger...

aber das Thema ist definitiv kein Einsteigerniveau

wo darf's denn hin?
Skripte oder allgemein?

OliverIO

@jack

also generell debugging wird man immer machen müssen. keiner ist so perfekt, egal in welcher sprache, das man immer ein perfektes ergebnis erhält ohne irgend einen fehler zu machen. egal in welcher programmiersprache oder syntaxlogik

blockly versucht ja, dem nutzer zumindest die möglichkeiten der syntax unter die arme zu greifen, in dem er nur syntaktisch korrekten code erzeugen kann.
leider hilft das bei der logik manchmal nicht immer weiter.

ich gebe dir recht, in blockly ist das mit dem debugging nur mit individuellem variablen-output möglich.
selbst google hat da keine besserein ideen
https://www.youtube.com/watch?v=N0ahsEvo45M

in javascript selbst (also browser javascript und nodejs) ist direkt ein debugger protokoll eingebaut, welches genau die von dir oben genannten informationen liefert (step-by-step-ausführung, breakt-points, auch conditional breakpoints, inspection, etc.)
nodejs
https://nodejs.org/en/docs/guides/debugging-getting-started/
chrome und edge: über die web developer tools

für die skripte im javascript-adapter müsste das theoretisch auch klappen,
da die skripte in einer jeweiligen javascript VM ausgeführt werden.
ausprobiert habe ich das nie.
auch gibt es noch eine Erweiterung für vs code, mit der man skripte in vscode entwickeln kann und dann wieder mit iobroker synchronisieren kann.

ich selbst entwickle meine iobroker skripte auch lieber in vs code. für die iobroker spezifiischen befehle mach ich mir dann individuell wrapper, die die funktionalität simulieren. endgültig getestet wird dann im iobroker

Jack

@paul53 Ja, ich weis. Es sind 2 Verschiedene Welten (OT <=> IT) immerhin arbeite "ich" mit Software von "euch". Aber hier im IOBroker, hätte ich schon gedacht, das man - wie soll ich sagen?

on(["fhem.0.SZ_D2.state"],
    function (obj) {
        var sDim = getState("fhem.0.SZ_D2.state").val;
        if (sDim == "off") {
            setState('zigbee.0.001788010b9af0de.brightness', 0);
            return;
        }

Und nicht darunter sondern (wie auf meinen Bildern rechts daneben):

on([TRUE],
    function (obj) {
        var sDim = "dim 40";
        if (sDim == "off") {
/* von hier bis ende Komentar ist ausgegraut, da FALSE
            setState('zigbee.0.001788010b9af0de.brightness', 0);
            return;
*/
        }

Man nimmt im Grunde die Daten aus den IOBroker Objekten, und ersetzt sie hier. Einfach damit man gleich sieht was man tut.

Ich dachte ja nicht daran etwas am Javascripting zu ändern, sondern das erstellen der Scripts zu vereinfachen.

Jack

@homoran Keine Ahnung... Ich wollte damit keine Diskusion ins rollen bringen. - War "nur" eine "Idee".
Aber wohl "Skripte"

OliverIO

@jack sagte in Debugging:

Es sind 2 Verschiedene Welten (OT <=> IT)

ist es das tatsächlich? in einer Welt in der immer mehr von "Software defined xyz" geredet wird, ist das doch alles bereits zusammen.

Homoran

@jack sagte in Debugging:

Ich wollte damit keine Diskusion ins rollen bringe

Warum nicht?
konstruktive Diskussionen sind immer gut!

@jack sagte in Debugging:

Aber wohl "Skripte"

erledigt
bevor es für echte Noobs zu abschreckend wird 😀

paul53

@jack sagte: nicht darunter sondern (wie auf meinen Bildern rechts daneben):

Wie soll ein kompiliertes Programm Rückgriff auf den Editor erhalten?

Jack

PAUSE!

Ich arbeite das hier mal wie ich es von SPSen gewohnt bin, von oben nach unten ab. -Und dann wieder von vorne.

Jack

@paul53 sagte in Debugging:

Das gezeigte sind Interpreter, die zyklisch abarbeiten. Node.js kompiliert aber und Javascript arbeitet Ereignis gesteuert.

Danke für das Kompliment :) - Ich Programmiere Maschinen. Keine Software.

Auch in der Automatisierung wird vieles kompiliert, und man muss in den Kompiler-Optionen angeben wie "Tief?" man dann einblick haben möchte. -Aber es geht- Es geht auch auf die Resourcen, aber wie gesagt, braucht man es ja auch nur zum entwickeln. wenn die Sache läuft, dann läuft sie ja.

Jack

@cash sagte in Debugging:

@jack Ich verstehe es trotzdem nicht. Was habe ich davon zu wissen wie die Variablen gefüllt werden? Je nach Script haben Variablen in Ihren langen Scriptläufen unterschiedliche Stände…

Klar. Aber wenn die Variable per Du nicht den passenden Wert hat, ist klar das sie irgendwo davor eben falsch befüllt wurde.

Und wenn Du jetzt "einfach in Deinem Code hoch scrollst", bis zur vorherigen Verwendungsstelle, siehst Du warum sie dort einen "Falschen" Wert bekommen hat.

Jack

@oliverio sagte in Debugging:

also generell debugging wird man immer machen müssen. keiner ist so perfekt, egal in welcher sprache, das man immer ein perfektes ergebnis erhält ohne irgend einen fehler zu machen. egal in welcher programmiersprache oder syntaxlogik

in javascript selbst (also browser javascript und nodejs) ist direkt ein debugger protokoll eingebaut, welches genau die von dir oben genannten informationen liefert (step-by-step-ausführung, breakt-points, auch conditional breakpoints, inspection, etc.)

Wären OT's perfekt würden sie die von mir gezeigten Screenshots auch nicht brauchen :))

Es ist ja "Debugging" aber eben ohne wieder Code schreiben zu müssen. Man kann einfach nach sehen. - Das ist ja auch genau DER Vorteil. -

In den "Neueren" Steuerungen gibt es auch sogenannte "Haltepunkte" die (Vermutlich) das Gleiche bewirken. Aber auch genau hier gibt es einen wesentlichen Unterschied:

So ein "breakt-point"/"Haltepunkt" stoppt das Programm an gewünschter Stelle, um zu analysieren.
Macht man das zu Hause mit dem Licht, leuchtet es zB. weiter, oder geht aus.
Macht man das mit einer Produktionsmaschine die mit 2000U/min fährt, war das keine gute Idee...

paul53

@paul53 sagte: nicht darunter sondern (wie auf meinen Bildern rechts daneben):

Du möchtest also einen Skripteditor mit eingebautem Interpreter?
In ioBroker sind Skripteditor und Skriptausführung strikt getrennt.

Jack

@oliverio sagte in Debugging:

@jack sagte in Debugging:

Es sind 2 Verschiedene Welten (OT <=> IT)

ist es das tatsächlich? in einer Welt in der immer mehr von "Software defined xyz" geredet wird, ist das doch alles bereits zusammen.

Ui, bitte ja nicht böse sein! Aber ein Beispiel:

Wir haben einen voll automatischen Kran, der aufgetürmtes Gut ein-/um-/auslagert.
Da jedes Lastspiel (Gut nehmen, hochziehen, zu Punkt x/y bewegen, absetzen, hochziehen) den Kran altern lässt (wie jeder Kilometer beim Auto), sind wir bemüht darauf zu achten, möglichst nur notwendiges Gut zu befördern.
Das ist einem Softwareentwickler (meist) nicht klar wenn nicht egal.
Das Fazit: Der Kran muss die oberen beiden Güter umlagern, damit das von ihm "gewünschte" ausgelagert werden kann, obwohl es das gleich Gut gewesen wäre, nur mit einer neueren Nummer.

Ist jetzt sicher nicht die beste Erklärung, aber ich hoffe sie verdeutlicht den Unterschied.

Jack

@homoran sagte in Debugging:

@jack sagte in Debugging:

Aber wohl "Skripte"

erledigt
bevor es für echte Noobs zu abschreckend wird 😀

Verstehe die Anspielung? echt nicht... :confused:

Homoran

@jack sagte in Debugging:

Verstehe die Anspielung? echt nicht...

ist keine Anspielung!

aber das Thema ist recht nerdig und nicht für Einsteiger ins Smarthome der adäquate Level.

Community Forum

NEWS

Debugging

Support us

749

32.6k

82.2k

1.3m