[Patch] Scripte laden ohne Ballast

[CHDKLover]

Hallo rudi,
tut mir leid, aber ich hab noch einen kleinen Bug gefunden.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

print("-1")--[[

@param b test

Kommentar

--]]print("0")



sleep(1000)

Erstellt in 0.005 Sekunden, mit GeSHi 1.0.8.9

Der Parameter wird aber richtig ausgelesen.
Ergebnis des Strippers:

Code: Alles auswählen

print("-1")
Kommentar
sleep(1000)

CHDKLover

[msl]

Hallo,

eine bedingte Kompilierung für diesen Teil wäre schon sinnvoll. Es steht ja nun auch eine Testumgebung für den (Windows-)PC bereit.

Gruß msl

[CHDKLover]

Hallo rudi,
vielleicht sollte man gar nicht den Anspruch haben alle Kommentare zu entfernen. Vor allem, wenn sie so verwendet werden, wie in meinem letzten Beispiel. Die Hauptsache ist, das das nicht unbrauchbar wird.
Es Könnte ja auch einen Vorteil haben nicht alle Kommentare zu entfernen um später bewusst den Stripper zu umgehen.

CHDKLover

[rudi]

Hallo CHDKLover,

jetzt wird es problematisch.

Kommentare innerhalb der Programmzeile können leicht mit Zeichenketten verwechselt werden. Bei den Möglichkeiten von LUA habe ich schon die wildesten Sachen gesehen. Mit diesem einfachen Stripper ist das eher nicht lösbar. Dann muss ein komletter Parser her.

Was spricht eigentlich dagegen ordentlichen geschriebenen Programm-Code?

Es Könnte ja auch einen Vorteil haben nicht alle Kommentare zu entfernen um später bewusst den Stripper zu umgehen.

Das funktioniert aber nur, wenn die Laderoutine ein "fallback"-Abschnitt hätte - aktuell nicht mehr implementiert.

In diesem Zusammenhang sehe ich jetzt ein anderes Problem.
Tritt bei der Abarbeitung des Scriptes ein Fehler auf, dann stimmen die Zeilennummern nicht mehr!
Von uBasic sind wir das gewohnt, aber zur Fehlersuche bei der Scriptentwicklung - ganz schlecht.

Mir fallen zwei Lösungsmöglichkeiten ein:
1. Einen Schalter ins Script-Menü
2. Nicht benötigte Zeilen nur zu Leerzeilen machen.

Gruß rudi

[msl]

Hallo rudi,

ich bin für Punkt 2. Das ist eine gute Idee!

Eine weitere Menü-Einstellung erschwert für den "normalen" Anwender den Umgang mit einem Skript. Wenn es zu Problemen kommt, hat vielleicht einer den Schalter aktiviert, ein anderer nicht. Daraus ergeben sich dann weitere Nachfragen. Mal davon abgesehen, dass ein weiterer Menüpunkt auch Arbeitsspeicher braucht.

Ich denke, alle Eventualitäten der Kommentarmöglichkeiten könnten sicherlich beachtet werden. Ist das aber wirklich notwendig? Da sollte dann eher schnelle Abarbeitung und schlanker Programmcode im Vordergrund stehen.

Gruß msl

[CHDKLover]

Hallo rudi,

Kommentare innerhalb der Programmzeile können leicht mit Zeichenketten verwechselt werden.

Ja das sehe ich auch so, desswegen sollten wir solche Kommentare einfach stehen lassen.

Es Könnte ja auch einen Vorteil haben nicht alle Kommentare zu entfernen um später bewusst den Stripper zu umgehen.

Das funktioniert aber nur, wenn die Laderoutine ein "fallback"-Abschnitt hätte - aktuell nicht mehr implementiert.

Ich denke wenn man die Kommentare innerhalb einer Programmzeile nicht löscht kann man auch Kommentare bewusst vor dem Stripper "verstecken".

Wenn ein Kommentar nach dem trim der Zeile nicht am Anfang beginnt sollte man ihn ignorieren. Das Ende eines Kommentars kann man natürlich nicht so rangehen, den muss man wahrscheinlich besser suchen. Hat man ein Kommentarende gefunden aber kein passenden Anfang, dann ignorieren.

CHDKLover

[rudi]

Hallo,

bisher sind doch alle Kommentare sauber geschrieben worden, und werden richtig verarbeitet. Auch der Programmierer muss sich an Richtlinien halten. Ich sehe nicht wirklich Handlungsbedarf. Wie ist eure Meinung?

In der Zwischenzeit habe ich einen dritten Weg für das Zeilennummern-Problem umgesetzt.

Mein Vorschlag: Ein neuer Parameter "@nostrip".

Dieser Parameter bewirkt, dass das Script nicht gestrippt wird. Der Stripper entfernt nur die Parameterzeile @nostrip und fügt das für uBasic erforderliche "newline" erforderlichenfalls hinzu. Daher erfordert der neue Parameter auch keine weiteren Änderungen im CHDK-Quelltext.

Nachteil für ungepatchte Kameras: @nostrip führt bei uBasic zum Syntax-Error. LUA-Scripte sind davon nicht betroffen.

In welcher Zeile des Scriptes der Parameter steht ist egal. Platziert man "@nostrip" in der letzten Zeile, wird zur Entwicklungszeit von Scripten immer die richtige Zeilennummer angezeigt. Funktioniert das Script fehlerfrei, dann löscht man den Parameter und das Script wird gestrippt.

Ein weiter Vorteil - bei Fehlern beim Strippen wird versucht das komplette Script zu laden.

Patches und CMD ab sofort im ersten Beitrag.

Gruß rudi

[msl]

Hallo,

Auch der Programmierer muss sich an Richtlinien halten.

Sehe ich auch so.

Mein Vorschlag: Ein neuer Parameter "@nostrip".

Im ersten Augenblick dachte ich, nein das macht es noch komplizierter. Es erschwert den Umgang mit einem Skript nur. Noch einmal darüber nachgedacht finde ich die Idee aber gut. Das Manko Syntx-Fehler bei ungepatchten CHDK-Versionen ist unproblematisch. Dieser Parameter wird ja sicherlich nicht standardmäßig eingesetzt. Er dient lediglich einer Art Kontrolle, mit der man einen möglichen Fehler der NoStrip-Funktion ausschließen möchte.

Für mich ist die wichtigste Eigenschaft dieser Funktion, dass die Zeilennummern erhalten bleiben. Nur so kann man dann auch mit anderen über ein Skript diskutieren, ohne erst hinterfragen zu müssen, ob es wirklich Zeile x war, in der ein Problem auftrat. Wenn die Kamera eine Fehlermeldung ausgibt, müssen die Zeilennummern immer identisch sein, egal ob gestrippt oder nicht. Das ist sonst nicht vermittelbar!

Gruß msl

[rudi]

Hallo,

die Lua-Kommentare lassen mir keine Ruhe. Ein neuer @-Parameter ist nicht so optimal. Daher stelle ich hier einen weiteren Lösungsanstz vor.

Dieser ist zur Zeit nur als Technologie-Vorschau anzusehen. Der Grund zeigt sich vor allem bei der Verarbeitung von Lua-Scripten.

Beschreibung:

Lua- und uBasic-Scripte werden getrennt behandelt.
Die Parameterauswertung wird in jedem Fall mit einem getrennten, temporären Parameter-Speicher durchgeführt.

uBasic:
Bei uBasic werden alle nicht benötigten Zeilen (Parameter und REM-Zeilen) durch eine Leerzeile ersetzt.
Dadurch bleiben die Zeilennummern erhalten. Leerzeichen und Tabulatoren am Anfang und Ende werden entfernt. Der Speichervorteil bleibt bei 10-20%.

Lua:
Lua-Scripte werden direkt beim Laden compiliert -> kein Kommentar-Problem!
Ein Parameter-Speicher ist nun unumgänglich, denn die Parameter gehören nicht zu Lua, sondern sind eine Funktionalität des CHDK.

Sollte im Lua-Script ein Syntaxfehler sein, kann es nicht compiliert werden!
In diesem Fall wird es, wie bisher, als Script geladen. Es werden nur Leerzeichen und Tabulatoren am Anfang und Ende entfernt. Damit ist es ebenfalls kleiner, aber die Zeilennummern für die Syntax-Fehlermeldung bleiben bestehen und abgearbeitet kann es sowieso nicht werden. Zur Sicherheit bleiben alle Kommentar- und Parameter-Zeilen unverändert. Die Anzeige der Fehlermeldung erfolgt aber erst beim Starten des Scripts.

Zur Optimierung könnte man hier die komplette Parameterverarbeitung unterlassen.

Bemerkung zum Lua-Interpreter:

Der Lua-Interpreter ist eine "virtuelle Maschine" und kennt 35 unterschiedliche Befehle. Beim Compilieren wird das Lua-Script in einen Zwischencode übersetzt, der nur aus Elementen dieser 35 Befehle besteht.
Daraus ergibt sich auch, dass eine Lua-Scriptzeile üblicherweise aus mehreren Interpreter-Befehlen zusammensetzt und somit der compilierte Zwischencode größer als das eigendliche Script ist (bei meinen Tests bis zu 100%).
Es müssen grundsätzlich alle Lua-Scripte vor der Ausführung compiliert werden.

Nun zu den derzeitigen Nachteilen:

Die Parameterverarbeitung erfolgt z. Z. in der script.c unabhängig an zwei Stellen und ist daher nicht konsistent.

uBasic:
Der uBasic-Interpreter kommt mit Leerzeilen am Scriptanfang nicht klar. Eine Lösung ist im Patch enthalten (siehe Abschnitt tokenizer.c).

Lua:
Der Speicherbadarf des compililierten Scriptes ist größer als der des Ausgansscriptes. Dieser wird jedoch in jedem Fall zur Ausführung benötigt.
Aber!!! das compilierte Script wird erst beim Starten mit dem Auslöser in den Lua-Interpreter geladen und ausgeführt. Dabei erstellt der Lua-Interpreter eine eigene Kopie davon. Somit ist das compilierte Script im Speicher doppelt abgelegt. Ein Ausweg ist, das geladene Script nach der Übergabe an den Lua-Interpreter aus dem Speicher zu löschen. Soll das Script ein weiteres Mal gestartet werden, will die derzeitige Implementierung das Script erneut in den Lua-Interpreter laden. Das wäre dann aber nicht mehr im Speicher. Ein erneutes Laden und Compilieren von der Speicherkarte würde somit notwendig werden.

Um aus dem Konzept ein Patch werden zu lassen muss die Laderoutine für Scripte einschließlich der Parameterverarbeitung in der script.c verändert werden. Weiterhin ist die Initialisierung des Lua-Interpreters aus der kbd.c in die script.c zu verschieben. Probleme erwarte ich dabei keine, da die kbd.c sich bereits jetzt beim Starten von Scripten auf die script.c stützt.
Fehlerhafte Lua-Scripte würden dann die Fehlermeldung schon beim Laden anzeigen. Wie sollte das aussehen?

Ein Testprogramm zur Scriptumwandlung beim Laden habe ich wieder beigefügt. Es arbeitet in der Kommandozeile und erwartet als Parameter die Script-Datei. Als Ergebnis werden die Datei PROG.TXT (gestripptes uBasic oder compiliertes Lua) und wenn @-Parameter im Script sind, auch PARAM.TXT erzeugt. Hinweis: Der unter Windows erzeugte Zwischencode kann nicht auf der Kamera ausgeführt werden.
Wegen des Vorschaustadiums habe ich keine Quellen beigelegt.

Gruß rudi

[CHDKLover]

Klasse rudi,
das hört sich nach einem sehr interessanten Konzept an! Damit geht man allen Problemen implizit aus dem Weg die mit lua Kommentarzeilen zu tun haben. Eine Abspaltung der Skriptparameter in ein separates Konstrukt finde ich praktisch. Aber dann muss es für lua und uBasic ein und das selbe Strukt sein.

Nachfolgend meine ersten Gedanken zum Konzept:

• Wenn ich mich richtig erinnere wird bisher das Skript direkt beim Einschalten der Kamera versucht zu laden, was den Kamerastart verzögert. Sollte man nicht vielleicht generell erst ein Skript in den Hauptspeicher laden, wenn es ausgeführt werden soll? Ein Parsen der Skriptparamer könnte man zusätzlich noch veranlassen, wenn man sich im Skriptkonfigurationsmenü befindet. Diese Herangehensweise würde zwar die Startverzögerung eines Skriptes negativ beeinflussen, aber nicht die Einschaltzeit der Kamera. Somit könnte man Zeit sparen, wenn man nur ein Schnappschuss machen möchte, ohne ein Skript zu verwenden. Außerdem währe so auch die Ausgabe bei einem Skriptfehler wie gehabt in der Konsole zu realisieren.
  
• Wurde ein lua Skript bereits Kompiliert, so kann man dies bei weiteren Starts getrost auslassen. Denn das Skript wird sich im vorhergehenden Lauf nicht selbst (Quellcode) modifiziert haben!?
  
• Die Behandlung der uBasic Scripte klingt logisch, zum umgehen der Leerzeilen am Anfang rufst du in deinem Patch "tokenizer_next()" auf, würde es nicht nach dem Strippen reichen nur "current_token = get_next_token();" aufzurufen?
  
  Möglicherweise so:
  
  Syntax: [ Download ] [ Verstecken ]

  Syntax: [ Download ] [ Zeigen ]

  Benutze C Syntax Highlighting

  void tokenizer_init(const char *program)
  {
    ptr = program;
    current_line = 1;
    while ((current_token=get_next_token())==TOKENIZER_CR && !tokenizer_finished());
  }

  Erstellt in 0.003 Sekunden, mit GeSHi 1.0.8.9

CHDKLover

[rudi]

Hallo CHDKLover,

Eine Abspaltung der Skriptparameter in ein separates Konstrukt finde ich praktisch. Aber dann muss es für lua und uBasic ein und das selbe Strukt sein.

Ja. Die Parameter werden in einem eigenen Puffer gespeichert, welcher nur beim Laden im Script-Menü existiert und für Lua/uBasic gleich ist.

Sollte man nicht vielleicht generell erst ein Skript in den Hauptspeicher laden, wenn es ausgeführt werden soll?

Das ist bestimmt sinnvoll.
Als Gegenargument fallen mir nur der Script-Autostart und die Parameter-Speicherung ein.
Ich bitte um weiter Wortmeldungen anderer Nutzer.

... würde es nicht nach dem Strippen reichen nur "current_token = get_next_token();" aufzurufen?

Nein.
Diese Variante erzeugt eine Endlosschleife, denn get_next_token ermittelt den nächsten Token ab "ptr" und merkt sich die folgende Startposition in "nextptr". Wenn du tokenizer_next() nicht verwenden möchtest, dann könnte das so aussehen:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze C Syntax Highlighting

void tokenizer_init(const char *program)

{

  ptr = program;

  current_line = 1;

  current_token=get_next_token(); //nextptr initialisieren

  while (current_token==TOKENIZER_CR && !tokenizer_finished()) {

    ptr = nextptr;  //Startpunkt für get_next_token setzen

    current_token = get_next_token();

  }

}

Erstellt in 0.004 Sekunden, mit GeSHi 1.0.8.9

Bemerkung:

Solche Endlosschleifen stellen sich bei der A590 wie folgt dar:
1. Die Kamera reagiert auf keine Tasten mehr.
2. Nach etwa geschätzten 20 Sekunden wird das Display dunkel.
3. Die Kamera schaltet sich ab ohne das Objektiv einzufahren.

Gruß rudi

[msl]

Hallo,

Die Idee, ein Skript prinzipiell erst in den Hauptspeicher zu laden, wenn es gebraucht wird, ist sehr gut. Damit muss aber eine Lösung für Autostart-Skripte gefunden werden. Diese Funktion darf nicht verloren gehen! Das gleiche gilt für die Parameterspeicherung.

Die Parameter werden doch für die Parameterspeicherung auf der SD-Karte abgelegt. Kann man das nicht besser ausnutzen?

Gruß msl

[CHDKLover]

Hallo,
den Autostart für Skripte sehe ich so wie einen sehr frühen Start. Oder worin liegt der Unterschied? Somit müsste das CHDK das Skript eben gleich nach dem Start in den Arbeitsspeicher laden und es anschließend ausführen.

Bei der Parameterspeicherung kenn ich mich zu wenig aus. Aber ich dachte die Parameter sind mit in der CHDK-Config gespeichert. Also solange man das Skript-Konfigurationsmenü nicht aufruft, gibt es an den Parametern keine Veränderungen, somit bleibt die Config so wie sie ist. Veränderungen müssten gleich gespeichert werden.

CHDKLover

[rudi]

Hallo,

Damit muss aber eine Lösung für Autostart-Skripte gefunden werden. Diese Funktion darf nicht verloren gehen! Das gleiche gilt für die Parameterspeicherung.

Nein msl, das ist nicht der Plan. Ich bin immer bemüht die Benutzerschnittstelle ohne Änderungen oder Einschränkungen abzubilden.

Ich wollte wissen, ob es Einwände gibt das Script erst nach betätigen des Auslösers zu laden.

Mir könnte es auch gefallen Scripte auf ein bestimmten Mode festlegen zu können. Damit wäre ein Script-Start eines REC-Mode-Scriptes im PLAY-Mode nicht möglich.

Grundlegende Änderungen geben auch Spielraum für Neuerungen. Ich erwarte jetzt eure Wünsche.

Gruß rudi

[msl]

Hallo,

es ist immer etwas schwierig, euch (CHDKLover und rudi) Coding-Gurus zu folgen.

Das wird auch ein Grund (neben der allgemeinen Bequemlichkeit) sein, dass es hier keine weiteren Diskussionsteilnehmer gibt. Deshalb will ich mal versuchen, einen Ãœberblick zu verschaffen, um was es hier eigentlich geht.

*********************

Der Ist-Zustand:

Bisher wird ein Skript, sobald es im Skriptmenü ausgewählt wurde, inklusive aller Kommentarzeilen in den Arbeitsspeicher der Kamera geladen. Dabei erfolgt auch ein Eintrag in die Konfiguration. Dadurch wird dieses Skript auch bei jedem Neustart der Kamera wieder in den Arbeitsspeicher geladen. Als nicht unerheblicher Nebeneffekt verzögert sich dadurch auch der Kamerastart.

Um den Arbeitsspeicher nicht zu sehr zu belasten, wird auf eine umfangreiche Kommentierung im Skript verzichtet. Das hat aber zur Folge, dass das Skript für andere Anwender sich erst mühsam in das Skript einarbeiten müssen.

Diverse Kameras sind nicht gerade üppig mit Arbeitsspeicher ausgestattet. Da macht sich dieser Ist-Zustand besonders negativ bemerkbar. Es kann zu unerklärlichen Abstürzen führen.

Der Soll-Zustand:

Ein Skript soll erst bei Skript-Start (Auslöser drücken) in den Speicher geladen werden. Dabei werden alle Kommentarzeilen weggelassen (Spart Speicher). CHDK startet schneller, weil das Skript beim Einschalten der Kamera nicht vorgeladen wird. Skripte können umfangreich kommentiert werden, ohne dass der Arbeitsspeicher belastet wird.

Bedingungen

- Fehlermeldungen müssen für die richtige Zeile (Skript inkl. Kommentierung) ausgegeben werden.
- Autostartskripte sind weiterhin nutzbar.

Als nachteilig würde sich bemerkbar machen, dass der Skriptstart etwas langsamer erfolgt, weil das Skript erst geladen wird.

*********************

Ich wäre auf alle Fälle für diese Veränderungen.

Da rudi nun einmal dabei ist, könnten noch andere Dinge im Zusammenhang mit dem Skriptstart organisiert werden. Da sind nun alle User gefragt.

Mir könnte es auch gefallen Scripte auf ein bestimmten Mode festlegen zu können. Damit wäre ein Script-Start eines REC-Mode-Scriptes im PLAY-Mode nicht möglich.

Ehrlich gesagt sehe ich da bisher keinen Vorteil, lasse mich aber gern vom Gegenteil überzeugen. Aus meiner Sicht ist das im Skript selbst machbar. Hinsichtlich PTP-Interface sehe ich sogar Nachteile.

Ich erwarte jetzt eure Wünsche.

Was mich schon immer stört, ist dieses "default script". Das ist so überflüssig wie ein Kropf. Ich könnte mir gut vorstellen, dass man statt dessen eine Art Vorzugs- oder Lieblingsskript aus einen speziellen Ordner laden lässt. Alternativ wäre auch ein einfaches Intervall-Skript als "default script" denkbar.

Vielleicht gibt es noch andere Vorschläge, was die Skript-Handhabung betrifft.

Gruß msl