What should you do when things go awry with your scripting?What should you do when things go awry with your scripting?What should you do when things go awry with your scripting?What should you do when things go awry with your scripting?Was sollten Sie tun, wenn bei Ihrem Skripting etwas schief geht? Willkommen zurück!
Wenn Sie gerade erst dabei sind, befinden Sie sich mitten in einer Serie, die darauf abzielt, Menschen den Einstieg in die Verwendung der JMP-Skriptsprache zu erleichtern. Im Gegensatz zu den vorherigen Einträgen in die Serie , Sie müssen die anderen wahrscheinlich nicht lesen, damit dieser einen Sinn ergibt, aber wenn Sie mitspielen und die Hausaufgaben aus den anderen Einträgen machen möchten, finden Sie hier die Links
Ein großes Dankeschön geht auch an Christian Stopp ( @christianstopp ) für den Vorschlag dieses Eintrags in der Serie.
Dieser Teil der Serie ist weitgehend ein eigenständiger Eintrag. Aber im Laufe der Zeit ist dies wahrscheinlich der Punkt, an dem Sie begonnen haben, mit etwas Code herumzuspielen, und möglicherweise die ein oder andere Fehlermeldung gesehen haben. Bevor wir also mit ernsthaftem Code-Gerangel beginnen, wollen wir uns damit befassen, was zu tun ist, wenn die Dinge schiefgehen.
Die häufigsten Fehler in JSL
Justin Chilton ( @Justin_Chilton ) und Wendy Murphrey ( @Wendy_Murphrey ) gehören zu den besten Drehbuchautoren überhaupt JMP . Auf dem Americas JMP Discovery Summit 2020 präsentierten sie (virtuell) einen Artikel mit dem Titel „Die häufigsten JSL-Fehler und wie man sie vermeidet“. Die PowerPoint-Datei für diese Präsentation finden Sie hier Hier auf die Gemeinschaft.
Für den neuen Scripter sind das 14 Seiten aus massivem Gold. Im Kontext dessen, was wir in dieser Serie tun, gehen einige davon etwas über den Rahmen hinaus, werden aber für die nächsten Schritte Ihrer Skripterstellungsreise von unschätzbarem Wert sein. Machen Sie mir einfach einen Strich durch die Rechnung, laden Sie das PDF herunter, legen Sie es irgendwo ab, wo Sie es nicht vergessen, und geben Sie dem Artikel auf der Community-Seite einen Daumen nach oben.
Mikes häufigste JSL-Fehler
Um einen kleinen Einblick in die Arbeit von Justin und Wendy zu geben, möchte ich ein paar Dinge zu ihrer Liste hinzufügen. Diese sind ziemlich einfach und führen in der Regel dazu, dass ein Skript abstürzt, bevor es überhaupt ausgeführt wird (weshalb sie im Discovery Summit-Papier nicht auftauchen).
Kleber
Fehlende Glue-Operatoren sind wahrscheinlich der häufigste JSL-Fehler überhaupt. Wie ich bereits erwähnt habe, ist der Glue-Operator das Semikolon („;“), das Sie am Ende jeder Anweisung in JSL sehen. Wenn Sie Skripte über das Menü mit dem roten Dreieck in einem Skriptfenster speichern (siehe der vorherige Beitrag ), fügt JMP den Kleber dort hinzu, wo er hin muss. Wenn Sie Code manuell schreiben, gibt es einen Trick, mit dem Sie sicherstellen können, dass Sie ihn nicht irgendwo vergessen haben. Klicken Sie mit der rechten Maustaste in den Skripteditor und wählen Sie aus Skript neu formatieren .
Mit diesem Trick werden tatsächlich viele grundlegende Syntaxfehler im Skript erkannt. Es gibt auch eine Tastenkombination, wenn Sie sich im Skript-Editor befinden (diese funktioniert jedoch nicht in „Skript-Editor-Boxen“). Ich selbst bevorzuge die Tastenkombination. Für Windows ist es so STRG+M . Für MacOS ist es so CMD+M .
Bevor ich Ihnen nun zeige, wie Sie die Meldungen von Reformat Script entpacken, wenn ein Fehler auftritt, möchte ich den anderen Fehler zeigen, der mich verrückt macht. Da beide einen ähnlichen Debugging-Workflow verwenden, wird dies in einer Sekunde Sinn machen, das verspreche ich.
Klammern
Das Verrutschen (oder Fehlen) Ihrer Klammern (Klammern, Klammern usw.) ist wahrscheinlich der heimtückischste Fehler, den es aufzuspüren gilt. Und ich meine, es ist ein besonders irgendwie frustrierend. In JMP steht Ihnen ein Tool zur Verfügung, das Ihnen beim Aufspüren nicht übereinstimmender Klammerpaare hilft. Wenn Sie den Cursor auf die Außenseite einer Klammer setzen, hebt der Skripteditor diese (und das, was seiner Meinung nach damit zusammenhängt) blau hervor.
Wenn der Skripteditor verwirrt ist oder keine Übereinstimmung findet, wird die Klammer rot hervorgehoben.
Wenn also die blaue Übereinstimmung für eine Klammer nicht dort ist, wo Sie sie erwarten, oder wenn die Klammer rot hervorgehoben ist, liegt wahrscheinlich ein Problem vor.
Wenn Sie Fehlermeldungen wegen fehlender Klammern erhalten, könnten Sie versucht sein, diese so lange am Ende hinzuzufügen, bis der Fehler behoben ist. Lassen Sie mich einfach sagen, dass das eine schlechte Idee ist, und dann zu einigen besseren Strategien für dieses Problem und für das Problem des fehlenden Klebers übergehen. Und bei beiden geht es um die Einrichtung des Skripteditors von JMP.
Erfolgreiches Einrichten (und Verwenden) des Skripteditors
Der JMP-Skripteditor (wir haben ihn gesehen in der vorherige Beitrag ) verfügt über eine Reihe von Funktionen, die die Arbeit mit Code und das Debuggen erleichtern. Ich habe diese in meinen Einstellungen standardmäßig aktiviert und würde Ihnen empfehlen, dasselbe zu tun. Um auf das Dialogfeld „JMP-Einstellungen“ zuzugreifen, wählen Sie Präferenzen entweder über das JMP-Menü (MacOS) oder das Dateimenü (PC).
Die Optionen, die ich wirklich nützlich finde, habe ich im Screenshot hervorgehoben. Das Code-Folding ist praktisch für größere Skripte. Die Zeilennummern und Autovervollständigungsoptionen sind für unsere aktuelle Diskussion wichtiger.
So verwenden Sie das Protokoll
Nachdem wir nun unseren Skripteditor eingerichtet haben, lernen wir, wie man das Protokoll verwendet. Um das Protokoll zu öffnen, gehen Sie zunächst zu Ansicht > Protokoll ( Fenster > Protokoll auf einem Mac). Dadurch wird ein Fenster geöffnet, das einem Skripteditor ähnelt. Er unterscheidet sich vom Skripteditor darin, dass er Folgendes anzeigt Ausgabe und Ergebnisse der im Skripteditor ausgeführten Befehle. Wenn Sie Ihre Ein- und Ausgabe lieber im selben Fenster behalten möchten, können Sie das eingebettete Protokoll im Skripteditor aktivieren, indem Sie mit der rechten Maustaste in den Skripteditor klicken und auswählen Eingebettetes Protokoll anzeigen .
Schauen wir uns an, wie es mit diesem Skript funktioniert:
Das Skript ist ziemlich einfach. Abgesehen von Zeile 2 und den Kommentaren wurde es mit erstellt Skript speichern…im Skriptfenster . Wenn ich renne Skript neu formatieren (auch durch Rechtsklick im Skriptfenster zu finden), erhalte ich die folgende Fehlermeldung:
Im Protokoll erhalten Sie etwas Ähnliches:
Im grauen Bereich sehen Sie, was eingegeben wurde. Darunter sehen Sie eine Meldung über etwas Unerwartetes und einen Vorschlag, was das Problem sein könnte. In diesem Fall geht JMP davon aus, dass Kleber fehlt (;). Außerdem erfahren Sie anhand einer Zeilennummer, wo im Skript die unerwartete Eingabe erfolgte. Da JSL sequentiell (von oben nach unten) ausgeführt wird, bedeutet dies, dass der Fehler irgendwo über Zeile 5 liegt. Da wir die Zeilennummern aktiviert haben, können wir sehen, dass in Zeile 2 der Glue-Operator fehlt, was bedeutet, dass JMP nicht erwartet, dass ein neuer Befehl in Zeile 5 beginnt, und überrascht wird. Nach dem Hinzufügen des Semikolons am Ende von Zeile 2 wird ausgeführt Skript neu formatieren sollte keine Fehler zurückgeben.
Wenn uns ein Teil eines Klammerpaars (z. B. Klammern) fehlt, gehen wir ähnlich wie folgt vor (beachten Sie Zeile 7):
wir würden diese Fehlermeldung erhalten:
mit einer Protokollmeldung:
Diese Nachrichten von JMP sind etwas weniger eindeutig, aber hier erfahren Sie, wie man sie interpretiert. Erstens wissen wir anhand der Fehlermeldung, dass das Problem in der Distribution liegt. Zwischen dem Protokoll und der Fehlermeldung fehlt höchstwahrscheinlich irgendwo eine Klammer. Im Protokoll steht, dass in Zeile 11 etwas Unerwartetes passiert ist (die „Spalte …“ kann manchmal hilfreich sein, aber man muss die Zeichen zählen, um sie verwenden zu können). Die Farbe, die die Klammern hervorhebt, zeigt an, dass dem ersten Paar sein Paar fehlt (beachten Sie die rote Farbe der Klammer neben „Distribution“ in Zeile 5, nachdem Sie den Cursor links davon platziert haben).
Arbeiten Sie mithilfe der Hervorhebung vorwärts, um herauszufinden, wo das fehlende Element hingehört (in diesem Fall Zeile 7). In den meisten Fällen ist das Protokoll ein wirklich nützlicher Einblick in das, was JMP denkt, was gerade passiert. Wenn Sie jedoch Ihre JSL auf Fehler überprüfen oder den Code schrittweise durcharbeiten möchten, gibt es dafür ein anderes Tool.
So verwenden Sie den JSL-Debugger
Der JSL-Debugger ist ein etwas seltsames Biest. Wenn Sie versehentlich auf die Debugger-Schaltfläche geklickt haben:
Sie wissen wahrscheinlich bereits, dass dadurch die Hauptschnittstelle in JMP während der Ausführung blockiert wird. Als ich mit dem Schreiben von Skripten begann, habe ich es wirklich nicht oft verwendet. Nachdem ich nun ein paar Gespräche mit dem Entwicklungsteam darüber geführt habe, kann ich sagen, dass ich damit klarkomme. Lassen Sie uns ein wenig darüber sprechen und was es kann.
Zuerst die Sache mit der Sperrung von JMP. Es ist ein wenig verwirrend, aber in Wirklichkeit wird eine zweite Instanz von JMP erstellt, um das Debuggen auszuführen. Die Hauptinstanz von JMP reagiert nicht, solange der JSL-Debugger aktiv ist. Wenn Sie den JSL-Debugger schließen, erhalten Sie die Kontrolle zurück.
Wenn Sie den JSL-Debugger starten, wird zusätzlich zu einer anderen JMP-Instanz das JSL-Debugger-Fenster angezeigt. Dieses Fenster enthält Ihren Code, Listen der verschiedenen Variablen, ein Protokoll und andere Informationen. Es sieht ungefähr so aus:
Wenn Sie debuggen, können Sie in diesem Fenster sehen und hören, was Ihr Skript in JMP tut. Wenn Sie einen zweiten Bildschirm haben, verschieben Sie ihn dorthin, damit Sie ihn immer sehen können (manchmal kann er hinter anderen Fenstern verborgen bleiben).
Nun könnte ich verrückt werden und alles beschreiben, was Sie mit dem JSL-Debugger tun können, aber in der Dokumentation gibt es ein tolles Kapitel (mit Beispielen!), das Sie finden können Hier .
Es gibt auch ein gutes Blogbeitrag von Melanie Drake ( @Melanie_J_Drake ), der einige der coolen Dinge behandelt, die Sie mit dem JSL-Debugger machen können. Wenn Sie sich also ein wenig mit dem Unkraut befassen möchten, schauen Sie sich diese an. Für unsere Zwecke möchte ich Sie auf diese Schaltflächen aufmerksam machen:
Die ersten beiden führen das Skript aus. Der erste führt das Skript bis zum Ende oder bis zu einem Haltepunkt aus (ein Punkt, an dem Sie die Auswertung stoppen möchten, wenn Sie nicht das gesamte Skript ausführen möchten). Sie können einen Haltepunkt in Ihrem Code festlegen, indem Sie im JSL-Debugger mit der rechten Maustaste neben die Zeilennummer klicken. Neben dieser Zeile wird ein roter Punkt angezeigt (der Haltepunkt muss sich in einer Codezeile befinden, nicht in einem Kommentar!).
Wenn Sie dieses Skript mit dem ersten ausführen würden Laufen Taste würde es bis Zeile 10 laufen und dann anhalten. Ein zweites Drücken der Laufen Die Schaltfläche würde dann das Skript beenden. Der Zweite Laufen Die Schaltfläche führt das gesamte Skript aus, ohne auf Haltepunkte zu achten. Das Rote Stopp-Taste Beendet den Debugger, was nützlich ist, wenn Sie ihn versehentlich geöffnet haben oder Ihre Debugging-Sitzung beendet haben. Der Wiederholen Die Schaltfläche setzt alles zurück, um das Skript erneut auszuführen (z. B. wenn Sie ändern möchten, wo sich ein Haltepunkt befindet, und dann den Code erneut ausführen möchten).
Hausaufgaben
Die Hausaufgaben dieser Woche sind ziemlich leicht. Ich möchte, dass Sie den Skript-Editor einrichten, das Protokoll finden und anfangen, mit dem JSL-Debugger herumzuspielen, indem Sie einige der Beispielskripte aus der Dokumentation verwenden. Sehen Sie sich an, welche Variablen in den Registerkarten unten links im Debugger-Fenster angezeigt werden. Finden Sie auch die Protokoll Klicken Sie unten rechts auf die Registerkarte (damit Sie wissen, wo sie sich befindet).
Nächste Woche werden wir uns mit dem letzten Teil der „Codierung“ befassen, die wir behandeln werden diese Serie .
