Sysygy Script Engine - Version 0.99h

[littleDave]

Trotz der fortgeschrittenen Stunde hab ich mich noch entschlossen, die aktuelle Version der Script-Engine hochzuladen. Diesmal hat sich einiges geändert und einige nützlichen Sachen sind mal wieder dazugekommen :zwinker:.

Da die Unit-Namen und manche Funktionsnamen etwas unglücklich gewählt wurden, hab ich mich dazu entschlossen, diese umzubenennen. Die Unitnamen fangen jetzt einheitlich mit einem u für Unit an und danach folgt ein Syg. Danach folgen dann noch kurze und präzise(re) Namen, die den Inhalt der Unit wiederspiegeln.
Die Script-Includes haben nach dem Syg noch ein Inc darstehen. Somit erkennt man sofort, was wo drinnen ist.

Ein weiteres neues Feature ist die Möglichkeit, Script-Funktionen direkt aus dem Programm heraus aufzurufen. Dabei ist es kein Problem, ob die Script-Funktion auf globale Variablen zugreift oder nicht. Was allerdings noch nicht funktioniert sind var-Parameter für den Funktionsaufruf aus dem Programm heraus. Das Script bzw. die Funktion läuft zwar wunderbar, aber die Werte in den Varparameter werden nicht wieder an das Hauptprogramm zurückgegeben. Ich weiß noch nicht, wie ich das am besten Anstellen soll - nicht von der Script-Engine her, das funktioniert schon, sondern eher wie ich den Aufruf aus dem eigentlichen Programm heraus handhaben soll. Im Moment werden die Parameter für jede Funktion einfach als array of const übergeben und dann endsprechend ausgewertet.
Was dafür aber funktioniert ist, dass die Rückgabewerte der Scriptfunktion auch ans Hauptprogramm weitergegeben werden. Die Aufruffunktion des Interpretors gibt dabei den Typ Variant zurück, der dann das result der Funktion enthällt.
Da Variants ja keine Pointer haben dürfen, werden Pointer als cardinal-Wert im Variant gespeichert.

Da ich mich mal drann gewagt habe, den Inhalt der Delphi-Unit StdCtrls auch für die Script-Sprache zur Verfügung zu stellen, ist mir aufgefallen, dass die Zeit fürs kompilieren sehr zunimmt (wenn man StdCtrls in die uses-Deklaration einbindet, kann man mit einer Kompilierzeit von ca. 1 Sekunde rechnen). Zwar hat diese Zeit keinen Einfluss auf die spätere Ausführungsgeschwindigkeit, doch etwas nervig ist das ja schon. Ich schau mal, ob ich da nich noch etwas mehr Speed rausholen kann.

Den kompletten Download und den kompletten ChangeLog gibts (wie immer :zwinker:) im ersten Beitrag.

Grüße
Dave

[alzaimar]

Moin (gähn), ich finde Deine Energie und Deine Leistung bewundernswert.
Kennst Du FastScript? Dort könntest Du dir weitere Anregungen holen. Die haben viele Sachen (interne Klassen etc.) ähnlich gelöst wie Du (man kann dort keine wirklichen Klassen implementieren, sondern nur Wrapper bauen). Der Funktionsaufruf mit Parametern geht sehr einfach:

Delphi-Quellcode:

Script.Call('MyFunction',VarArrayOf([Param0, Param1, Param2]));

Das VarArrayOf könnte man -von mir aus- auch noch weglassen.

So eine Skriptsprache ist eigentlich zu 99% dazu gedacht, ein Customizing zu vereinfachen. Klassen sind dort fehl am Platze (als softwaretechnische Herausforderung solltest Du das natürlich implementieren).

Dann finde ich, das eine Skriptsprache nicht unbedingt typstreng sein muss, so wie es Delphi ist. in einer Skriptsprache muss ich auch nicht unbedingt Variablen deklarieren. Die Skriptengine soll dem Anwender ja die Arbeit so leicht wie möglich machen, und da sind Deklarationen nur lästig :zwinker: . PAXscript ist so ein Kandidat.

Ich will Dir nur Denkanstöße geben und nicht etwa sagen "Öööh, gibts doch alles schon".

Tolle Arbeit! :thumb:

[rotfc]

Zitat:

Zitat von alzaimar

Moin (gähn), ich finde Deine Energie und Deine Leistung bewundernswert.
Kennst Du FastScript? Dort könntest Du dir weitere Anregungen holen. Die haben viele Sachen (interne Klassen etc.) ähnlich gelöst wie Du (man kann dort keine wirklichen Klassen implementieren, sondern nur Wrapper bauen). Der Funktionsaufruf mit Parametern geht sehr einfach:

Delphi-Quellcode:

Script.Call('MyFunction',VarArrayOf([Param0, Param1, Param2]));

Das VarArrayOf könnte man -von mir aus- auch noch weglassen.

So eine Skriptsprache ist eigentlich zu 99% dazu gedacht, ein Customizing zu vereinfachen. Klassen sind dort fehl am Platze (als softwaretechnische Herausforderung solltest Du das natürlich implementieren).

Dann finde ich, das eine Skriptsprache nicht unbedingt typstreng sein muss, so wie es Delphi ist. in einer Skriptsprache muss ich auch nicht unbedingt Variablen deklarieren. Die Skriptengine soll dem Anwender ja die Arbeit so leicht wie möglich machen, und da sind Deklarationen nur lästig :zwinker: . PAXscript ist so ein Kandidat.

Ich will Dir nur Denkanstöße geben und nicht etwa sagen "Öööh, gibts doch alles schon".

Tolle Arbeit! :thumb:

Moin littleDave,

kennst Du Alzheimer (gähn)? Da verbuchstabelt man schon mal was oder vergisst einiges, oder?
Lässt sich ALLES sowieso mit Java erledigen?

Hab' gerade eben die Scriptsprachenkritik von "alzaimar" vergessen, Dank Alzheimer?

Null Ahnung warum ich hier gerade was eintippe!

[littleDave]

Zitat:

Zitat von alzaimar

Moin (gähn), ich finde Deine Energie und Deine Leistung bewundernswert.
[...]
Tolle Arbeit! :thumb:

Danke für dein Feedback :thumb: :) Freut mich das zu lesen!

Zitat:

Zitat von alzaimar

Kennst Du FastScript? Dort könntest Du dir weitere Anregungen holen. Die haben viele Sachen (interne Klassen etc.) ähnlich gelöst wie Du (man kann dort keine wirklichen Klassen implementieren, sondern nur Wrapper bauen).

Vom Namen her kenn ich die schon, doch angeschaut hab ich mir das noch nicht. Wollt mir gerade mal die Demos herunterladen, doch nachdem dann erstmal eine Installation aufgepoppt ist, lass ich das erstmal lieber - ich will doch für ein einfaches Demo-Programm nicht irgendwas installieren :?. Vielleicht ein anderes mal ;-)

Zitat:

Zitat von alzaimar

Der Funktionsaufruf mit Parametern geht sehr einfach:

Delphi-Quellcode:

Script.Call('MyFunction',VarArrayOf([Param0, Param1, Param2]));

Das VarArrayOf könnte man -von mir aus- auch noch weglassen.

Is ja lustig, bei mir schauts wirklich fast so ähnlich aus - mal ein kleines Beispiel:

Delphi-Quellcode:

function CustomStrToInt(value: string): integer;
begin
  // der zweite String-Parameter ('') ist nur die Unit, in der die Funktion deklariert
  // ist. Er kann aber auch weggelassen werden
  result := FRunTime.Call('MyStrToInt', '', [value]);
end;

Zitat:

Zitat von alzaimar

So eine Skriptsprache ist eigentlich zu 99% dazu gedacht, ein Customizing zu vereinfachen. Klassen sind dort fehl am Platze (als softwaretechnische Herausforderung solltest Du das natürlich implementieren).

An sich hast du ja recht - streng genommen dürfte ein Skript auch keine neuen Resourcen erstellen. Aber gerade die Herausforderung ist ein großer Ansporn. Doch es wird wirklich extrem schwer und sehr lange dauern - falls ich es schaffe - eigene Klassen im Script zu erstellen.

Zitat:

Zitat von alzaimar

Dann finde ich, das eine Skriptsprache nicht unbedingt typstreng sein muss, so wie es Delphi ist. in einer Skriptsprache muss ich auch nicht unbedingt Variablen deklarieren. Die Skriptengine soll dem Anwender ja die Arbeit so leicht wie möglich machen, und da sind Deklarationen nur lästig :zwinker: . PAXscript ist so ein Kandidat.

Naja, dann würd ich aber zu sehr vom Dialekt Pascal entfernen und ich wollt ja eine sehr ähnliche Syntax erstellt.

Zitat:

Zitat von alzaimar

Ich will Dir nur Denkanstöße geben und nicht etwa sagen "Öööh, gibts doch alles schon".

Anders hab ich deinen Post auch nicht interpretiert :-), aber ist sehr schön, dass du das nochmal betonst.

Zitat:

Zitat von rotfc

Moin littleDave,

kennst Du Alzheimer (gähn)? Da verbuchstabelt man schon mal was oder vergisst einiges, oder?
Lässt sich ALLES sowieso mit Java erledigen?

Hab' gerade eben die Scriptsprachenkritik von "alzaimar" vergessen, Dank Alzheimer?

Null Ahnung warum ich hier gerade was eintippe!

Irgendwie werd ich aus diesem Post nicht gerade schlau :gruebel: Sinn? Inhalt? 7 Uhr ist vielleicht doch noch etwas früh!?!

[alzaimar]

Zitat:

Zitat von littleDave

Irgendwie werd ich aus diesem Post nicht gerade schlau :gruebel: Sinn? Inhalt? 7 Uhr ist vielleicht doch noch etwas früh!?!

Drögen am Mörgen vertreibt Kümmer und Sörgen. :stupid:

[littleDave]

Zitat:

Zitat von alzaimar

Drögen am Mörgen vertreibt Kümmer und Sörgen. :stupid:

Ahhh, ok - erklärt alles :stupid:

[mimi]

Zitat:

Naja, dann würd ich aber zu sehr vom Dialekt Pascal entfernen und ich wollt ja eine sehr ähnliche Syntax erstellt.

Gerade die Syntax ist toll. Das es Pascal ist, evlt. sogar bald "Object Pascal".
Sag mal bescheid wenn du sie Fertig hast *G*....

[littleDave]

Zitat:

Zitat von mimi

Gerade die Syntax ist toll. Das es Pascal ist, evlt. sogar bald "Object Pascal".

Naja, ein wenig Object Pascal ist ja durch die Klassen-Wrapper schon drinnen. Aber noch wichtige Sachen wie arrays, set (of)-Typen und die try-finally/except-Blöcke sind ja noch nicht drinnen. Eigene Klassen steht von der Prioritätsliste her extremst weit unten und im Moment glaube ich, dass ich das auch nicht so schnell ändern werde.

Zitat:

Zitat von mimi

Sag mal bescheid wenn du sie Fertig hast *G*....

Hm, was ist "fertig"? Sobald alle Features von Delphi drinnen sind? - Dann würd ich sagen - niemals. Die Script-Engine funktioniert ja schon, kann man ja an den Demos/Beispielskripten im Hauptprogramm/in meinem Sysygy Image Viewer ja schon sehen. Im Moment erweitere ich die Script-Engine eigentlich ja nur.

Was mich auch gerade wundert: die Zip-Datei wurde bisher schon 39x runtergeladen aber (bis auf das ausversehen eingebaute rtlvclOptimize) sind noch keine Erfahrungs/Fehlerberichte gekommen. Klar - nicht jeder braucht ständig eine Script-Engine in seinem Programm, doch ich würde die Komponente gerne weiter verbessern und es ist ja - wie ich vorher bereits mal gesagt habe - unmöglich für mich, alles zu testen. Also wenn jemand einen Fehler gefunden hat oder irgendwas nicht so funktioniert, wie man es erwarten würde, dann wäre ich extrem froh darüber, wenn ihr mir das Problem zukommen lassen würdet.

[mimi]

Ich habe mir sie zwar runter geladen, aber bisher nur die Beispiele angeschaut die Dabei sind.
Ich habe aber vor sie zu testen, bisher habe ich in keines meiner Projekte eine Scrip Sprache eingebaut.

Aber ich könnte mir bei einigen Projekten vorstellen das es sin machen würde. Z.B. bei meiner Editor Komponente.
Als eine art PlungIn Schnittstelle. Aber wie genau ich das mache weiß ich noch nicht.

Naja, ich meinte mit "Fertig" natürlich nicht alles was Delphi kann, sondern evlt. "nur" alles was in "Object Pascal"
drin ist, ich glaube das ist ein kleiner unterschied oder ?

Wenn die Syntax vorhanden ist, reicht das erstmal... für mich, schön währe halt so einige Standard Units.. wie halt Classes wegen der TStringList oder aber auch constr wegen TObjectList.... aber ob ich sowas in einem Script brauche weiß ich noch nicht.

Aber ein Test würde ja nicht schaden, dann währe auch geklärt ob die Script Sprache auch unter Lazarus läuft, oder nicht. Wenn ja währe es nicht schlecht.

[littleDave]

Zitat:

Zitat von mimi

Ich habe mir sie zwar runter geladen, aber bisher nur die Beispiele angeschaut die Dabei sind.
Ich habe aber vor sie zu testen, bisher habe ich in keines meiner Projekte eine Script Sprache eingebaut.

Ist ja kein Problem. Ich will ja niemanden zu etwas zwingen ;-). Ich meinte nur, falls jemand man einen Fehler findet dass er dann am besten nicht zögern sollte, ihn zu melden.

Zitat:

Zitat von mimi

Naja, ich meinte mit "Fertig" natürlich nicht alles was Delphi kann, sondern evlt. "nur" alles was in "Object Pascal" drin ist, ich glaube das ist ein kleiner unterschied oder ?

Also "Object Pascal" kann extrem viel und hat auch viele hilfreiche Funktionen - ich würd den Sprachumfang von Object Pascal nicht unterschätzen.

Zitat:

Zitat von mimi

Wenn die Syntax vorhanden ist, reicht das erstmal... für mich, schön währe halt so einige Standard Units.. wie halt Classes wegen der TStringList oder aber auch constr wegen TObjectList.... aber ob ich sowas in einem Script brauche weiß ich noch nicht.

Also von den Delphi-Units sind folgende (z.T. nur teilweise) bereits konvertiert: SysUtils, Classes, Controls, Graphics, Forms (das Application-Object ist in einer seperaten Unit namens Application), StdCtrls. Aber natürlich ist man darauf nicht beschränkt - man kann ja selbst noch eigene Units importieren.

Zitat:

Zitat von mimi

Aber ein Test würde ja nicht schaden, dann währe auch geklärt ob die Script Sprache auch unter Lazarus läuft, oder nicht. Wenn ja währe es nicht schlecht.

Ich hab halt gerade kein Lazarus zur Hand bzw. installiert. Daher wäre es sehr schön, wenn du das mal kurz ausprobieren könntest. Das wäre sehr nett.