Sysygy Script Engine - Version 0.99h

[littleDave]

Es gibt mal wieder was neues zu berichten: eine neue Version ist wiedermal online (auch wenn das hier langsam zum Tagebuch wird, sind doch ein paar Neuerungen mit drinnen :zwinker:)

Die Script-Engine ist jetzt auch unter FPC kompilierbar :). Zu den Einschränkungen gibt es im ersten Post einen neuen Abschnitt Sysygy Script Engine + FreePascal
Außerdem ist jetzt nun möglich, Parameter als var-Parameter im Script-Funktionsaufruf aus dem Programm heraus zu benutzen. Dafür muss in dem array of const einfach der Pointer auf die Variable übergeben werden, den Rest macht die Script-Engine selber.

Den Download sowie den aktuellen ChangeLog gibts im ersten Post

Grüße
Dave

[littleDave]

Servus miteinander,

ich hab mal wieder eine neue Version hochgeladen - diesmal ohne viel Neuerungen - aber dafür mit vielen Bug-Fixes:

Der erste wichtige Fehler war eine fehlerhafte Behandlung von Exit-Anweisungen in verschachtelten try-finally-Blöcken. Wenn im tiefsten try-finally-Block die Funktion "exit" aufgerufen wurde, sprang das Programm nicht durch alle finally-Anweisungen sondern nur in den letzten finally-Block - das ist jetzt behoben

Dann hab ich mich weiter mit den try-Blöcken beschäftigt und bin auf einen schon sehr alten Fehler gestoßen: Wenn in einer repeat-until oder in einer while do-schleife die Anweisung "continue" aufgerufen wurde, hat sich das Script sofort beendet - ohne Fehlermeldung. Das ist jetzt behoben, die continue-Anweisung funktioniert jetzt auch in while/repeat Schleifen.

Dann ist mir noch ein sehr kritischer Fehler aufgefallen: bei verschachtelten Element-Aufrufen mit mehr als einer Ebene (also z.B. Application.MainForm.Caption) wurden Variablen im Script-Stack überschrieben. Das passierte aber nur, wenn die zuletzt aufgerufene Methode eine procedure und keine function ist.
In diesem Zusammenhang ist mir gleich noch ein kleiner Fehler in einer Anweisung im Interpretor aufgefallen, die ich natürlich ebenfalls sofort behoben habe

Da ich in Version 0.99a die Script-String-Liste, die die einzelnen Strings des Scripts beinhaltet, verbessert habe, kam ein Fehler zum Vorschein, der vorher nicht aufgetreten ist: Die Auswahl des Strings in uses-Units wurde nicht korrekt ausgeführt. Somit war die String-Ausgabe fehlerhaft. Das ist jetzt auch behoben.

So, das wars auch schon wieder - ach ja: Download und ChangeLog ist im ersten Post zu finden

Grüße
Dave

[littleDave]

Juhu, der 4. Post hintereinander :cheer: :cheer: :cheer: :cheer: ;-)

Es gibt mal wieder was neues zu Berichten. Es hat diesmal zwar nur indirekt mit der Script-Engine zu tun, aber doch ein wenig.

Um die Script-Engine an sich besser testen zu können, hab ich ein "kleines" Test-Projekt geschrieben, dass die Script-Engine sehr intensiv benutzt: Es ist ein HTTP-Server, bei dem die Seiteninhalte, wie z.B. mit php, dynamisch erstellt werden. Den dynamischen Part übernimmt dabei komplett die Script-Engine.
Die Seite an sich ist ein "Multi-Blogger", d.h. es ist ein Server, bei dem jeder Benutzer einen eigenen Blog erstellen können. Jeder Blog kann dabei beliebig viele Kategorien haben. Diese Kategorien werden dann nochmal in Unterkategorien unterteilt, in denen dann die einzelnen Posts hineingeschrieben werden.
Der Server speichert dabei seine Daten in eine selbst geschriebene Datenbank, die ich mal geschrieben hatte.

Ich bin mir noch nicht sicher, in welcher Form ich das Projekt freigeben will (Freeware oder OpenSource).

Der eigendliche Grund dieses Posts ist, dass der Server im Moment online ist und frei benutzt werden kann. Für alle, die nicht extra einen Account anlegen wollen (ohne Account nix los), hab ich einen Gast-Account erstellt. Benutzername und Passwort ist jeweils gast (Passwort muss klein geschrieben werden).

Falls ihr euch traut, euch zu registrieren :twisted: - euer Passwort wird als MD5 in der Datenbank gespeichert. Außerdem werde ich die Datenbank sowieso irgendwann löschen. Wer mir traut (muss ja nicht euer Root-Passwort sein ;-)), kann sich ja registrieren - für die Anderen ist der Gast-Account da. Wäre schön, wenn sich der ein oder andere mal 5 min die Zeit nimmt und sich das anschaut.
Ach ja, natürlich könnt ihr auch euren Eigenen Test-Blog erstellen, Beiträge kommentieren usw - auch mit dem Gast-Account.

Was ich gerne von euch wissen würde, ist: Besteht interesse an dem Programm? Sind Fehler vorhanden?

Hier die URL: http://littledave.globedns.info
Der Server ist heute bis ca. 23:00 Uhr online, dann das ganze Wochenende erstmal nicht, dann ab nächste Woche wieder tagsüber.

[ConstantGardener]

Hallo LittleDave,

also ich hab mir den MultiBlogger mal kurz angeschaut und finde das System und Design echt nett. :thumb:

Ist wirklich ganz interessant. Wie hast Du das ganze aufgebaut (Welcher Server, Hoster etc. pp) ??

grüsse

ConstantGardener

[littleDave]

Der Server ist ein einfacher idHTTPServer. Der Request wird dann an die Script-Engine übergeben, die dann daraus den Inhalt der Seite erstellt. Wenn die Script-Engine fertig ist, ist der Inhalt der HTTP-Seite in einem String, der dann wieder vom HTTP-Server ausgelesen und danach gesendet wird.

Das Design ist nicht von mir, ist ein Freeware-Template (Link steht auf der Seite ganz unten rechts)

Der Server läuft hier lokal auf meinen Rechner. Die IP-Addresse wird über globedns.info bekanntgegeben.

Was bei diesem Projekt auch noch sehr wichtig für mich war, ist die Performance. Die Website wird meistens innerhalb von 2-5 Millisekunden erstellt, wobei die Script-Engine dabei ca. 1.000 bis 5.000 Zeilen Script-Quelltext abackert.

Hier ist mal der grobe Ablauf eines Requests:
- der idHTTP-Server parsed den Header aus HTTP und übergibt ihn an die Anwendung
- Anhand des Document-Request wird die Script-Datei ausgewählt, die die Seite erstellen soll
- Die Request-Parameter werder dann an den Script-Interpretor übergeben
- Das Script wird ausgeführt
- Das Ergebniss des Scripts wird wieder ausgelesen und an den idHTTP-Server übergeben
- der idHTTP-Server sendet dann die Daten

In einem Script kann natürlich komplett auf die eingebaute Datenbank zugegriffen werden, Such-Queries gestartet und ausgewertet werden und Einträge verändert werden.

Der Server an sich kann nur "Script auswählen - Daten übergeben und wieder auslesen - Senden". Den Rest übernimmt die Script-Engine.

[littleDave]

Da ich im Moment die Script-Engine ausführlich in meinem "Testprojekt" Multi-Blogger ausprobiere, finde ich ab und zu auch noch ein paar Fehler - daher hab ich jetzt mal wieder eine neue Version hochgeladen. Erstmal ich die Geschwindigkeit der Routine "TSygScript_RunTime.LoadFromStream" extrem verbessert. Dies ist besonders bei langen Scripts bemerkbar (bei meinem Projekt hat ein Script ca. 20.000 Instructions, diese werden jetzt innerhalb von wenigen Millisekunden geladen - ohne die Optimierung waren es ca. 1-2 Sekunden).
Zum anderen ist mir ein Memory-Leak im Parser aufgefallen, den ich sofort behoben habe.

Da ich in mein "Testprojekt" (ein HTTP-Server, der die einzelnen Seiten mit Hilfe dieser Script-Engine erstellt) schon sehr viel Arbeit hineingesteckt habe, wollt ich es eigentlich auch noch veröffentlichen. Im Moment komm ich ganz gut vorran und es ist auch schon fast alles lauffähig. Doch ein paar Sachen fehlen noch. Falls sich jemand bereits jetzt dafür interessiert, kann er sich

hier (http://littledave.globedns.info)

schonmal alles anschauen und etwas herumspielen (der Gastaccount, den ich in Post #43 vorgestellt habe, existiert nicht mehr, da nun einiges auch ohne Account möglich ist)

[littleDave]

Man ist der letzte Update lange her. Aber die Entwicklung hat währenddessen nicht geschlafen, sie war nur langsamer. Jedenfalls hab ich mal wieder die aktuellste Version hochgeladen in der sich einige Veränderungen und Verbesserungen befinden.

An alle, die noch nicht so ganz wissen, wozu diese Script-Engine gut ist: ich habe bereits folgende Projekte damit realisiert:

• Desktop Widget Engine (aktuellstes Projekt, nutzt die Script-Engine intensiv)
• Multi Blogger HTTP Server (mein Testprojekt für diese Script-Engine)
• Sysygy Image Viewer (ich hab die Script-Engine eigendlich für dieses Projekt erstellt, jedoch befindet sich in diesem Programm eine Uralt-Version)

Download ist im ersten Post zu finden

[EugenB]

Moin,

irgendwie bin ich grade im Script-Wahn :-D, zuerst hab ich Pascal Script probiert aber irgendwie sind da noch soviele Fehler, dann hab ich schon fast vergessen das es diese Script Engine noch gibt ;)

Da ich FPC nutze, musste ich in dieser Datei: uSygConstants

diesen Teil:

Delphi-Quellcode:

procedure TSygScript_List.SetCount(value: Cardinal);
var i: integer;
begin
  for i:=Count to value-1 do
    Add(nil);
end;

auch unter das {$IFNDEF FPC} packen

dann konnte ich es schon mal Compilieren :)

Da es noch keine Arrays gibt haste wohl diese TIntegerList hinzugefügt oder? ist ganz hilfreich, jedoch wie kann man die Werte neu setzen? ich fand dazu keine Funktion, also hab ich diese mal eben hinzugefügt:

Delphi-Quellcode:

procedure TIntegerList_SetItem(Self: TIntegerList; index: integer; Item: Integer);
begin
  Self.Items[index] := Item;
end;

das selbe auch für TFloatList ;)

Deine Script Engine ist eine richtige Alternative zum Pascal Script.

Was meinste wann diese Sachen funktionieren werden?
Arrays
Class Properties
Gleichnamige Funktionen ( welcher aber verschiedene Parameter haben zB. x(a: Integer); x(a: Float); x(a,b : Integer); etc

Wie füge ich Funktionen hinzu, auch wenn ich den UnitName nicht weiß?

Delphi-Quellcode:

procedure TForm1.ParserOnAddCustomFunctions(Sender: TObject; UnitName: string);
begin
   if(UnitName='myprogram')then
   begin
      TSygScript_Parser(Sender).AddFunction(@MyWriteLn, 'procedure WriteLn(s: string); register;');
   end;
end;

Wenn ich das ohne UnitName='my...' mache bekomme ich nen Fehler das WriteLn schon existiert, gibt es vllt ne Funktion zum zu gucken ob diese Funktion schon existiert? oder wie löst man es am besten.

Ich finde diese Engine besser als das Pascal Script, auch wenn die obigen Wünsche noch(?^^) nicht implementiert sind, zB Array ist bei Pascal Script vorhanden, jedoch gibts damit noch probleme, Class Properties funktionieren jedoch nur bei Variablen also vom Programm her hinzugefügte, jedoch kann man in Pascal Script keine Klassen im Script erstellen, wieder ein Pluspunkt :), Gleichnamige Funktionen gibt es auch unter PS nicht, und Funktionen mit zB. Parameter mit gleichen Typen werden richtig aufgerufen

Ich würde vorschlagen das du die Scipt Engine auf einen SVN Server packst, dann könnte man immer nen aktuellen Code bekommen und man könnte leichter Patches erstellen :)

Weiter so :)

[mschnell]

Hi Dave,

Hast Du Deinen Bytecode komplett neu erfunden, oder hast Du eine Vorlage benutzt ?

Gibt es eine Beschreibung für den Bytecode ?

(Ich möchte u.U,. den Bytecode-Interpreter in C implementieren, um auf einem Prozessor, für den es keinen Object-Pascal-Compiler gibt, Delphi-Code laufen zu lassen. )

Gruß und Dank,

-Michael

[EugenB]

Ich bins mal wieder xD

Wie kann ich dem Script eine vorhandene Variable / Klasse zuweisen? zb. Self:TForm ?

[Geri]

Hallo Dave

Zuerst mal alle Achtung vor diesem Projekt!

Fürs Verständnis aber ein paar Fragen:

Ich habe ein Programm bei dem Objekte eine hierarchische Datenstruktur bilden.

Der Aufbau sieht in etwa so aus: Projektgruppe->Projekte->Programme->...

Auf ein Programm kann man z.B. über ProjektGruppe[0].Projekte[1] zugreifen.

Sehr praktisch wäre nun, wenn man per Skript z.B. auf ein Objekt der Klasse TProgramm zugreifen und einzelne Methoden davon aufrufen könnte.

Fall es mit einer Script-Engine überhaupt Sinn macht und funktioniert, wie würde die Vorgehensweise bei Sysygy dann bitte aussehen?

Der Download von Deiner hat leider nicht geklappt Dave.

Vielen Dank für die Inputs

Geri

[EugenB]

Btw:

Zitat:

Zitat von EugenB

Ich bins mal wieder xD

Wie kann ich dem Script eine vorhandene Variable / Klasse zuweisen? zb. Self:TForm ?

In einem Beispiel wird das schon erklärt, sorry ^^

Paar Bugs:

Wie kann ich ne Klasse im Script erstellen? zb das funktioniert nicht:

Delphi-Quellcode:

type
    TMyClass = Class
    public
          procedure FormPaint(Sender: TObject);
    end;

procedure TMyClass.FormPaint(Sender: TObject);
begin

end;

Zitat:

[Error] myprogram(12): Procedure "tmyclass" already exists
Could not compile the script

Oder wie kann ich Variablen in Klassen nutzen? in Records funktioniert es, in Klassen nicht

Delphi-Quellcode:

program myprogram;

uses
    Classes, Forms;

type
    TTestRec = record
       FVar: String;
    end;

    TMyClass = Class
    private
        FMyVar: String;
    public
        function Create():TMyClass;
    end;

Zitat:

[Error] myprogram(13): "end", "public" expected, but found scsIdentifier instead
[Error] myprogram(13): "end" expected, but found scsIdentifier instead
[Error] myprogram(13): ";" expected, but found : instead
[Error] myprogram(13): "=" expected, but found ; instead
[Error] myprogram(14): scsIdentifier, "(", "set", "class", "record", "type" expected, but found public instead
Could not compile the script

Dann hätte ich noch nen Bug-Fix:

Unit: uSygIncGraphics
Zeilen: 688-692
Neuer Code:

Delphi-Quellcode:

function TBrush_Bitmap(Self: TBrush): TBitmap;
// function TBrush.Bitmap(Self : pointer) : TBitmap;
begin
  result := {$IFDEF FPC}TBitmap(Self.Bitmap){$ELSE}Self.Bitmap{$ENDIF};
end;

Anscheinend ist Dave im Urlaub xD

@Geri
wieso regelst du nicht zb. die ProjektGruppen, Projekte etc im Main Programm, dann sagst du nur diese unitX ist das ProjektX, und dann wenn du genau dieses Projekt brauchst rufste die unitX mit der Script Engine auf?

[Geri]

Hallo Eugen

Vielen Dank für Deinen Hinweis. Das "Main"-Formular führt eine Referenz auf den Projektgruppenmanager. Dieser verwaltet eine Liste an Projekten. Jedes Projekt ist eine wie eine Projektgruppe ein Klasse mit Methoden und Eigenschaften.

Die Struktur sieht in etwa so aus:

Delphi-Quellcode:

TfrmMain = class(TForm)
            ... CreateForm(...);
            
           public
             mProjectGroup:TProjectGroup;  
           end;

TProjectGroup = class(TComponent)
                     ProjectList:TList;
                     Constructor creaet(...);
                     procedure CreateNewProject):TProject; // erzeuge ein Objekt der Klasse TProject und füge es in ProjectList ein.
                     ....
                  end;

TProject = class(TComponent)
                  ...... 
                  public
                    Wert1, Wert2:Integer;
                    procedure SetWert1(aWert1:Integer); 
                    ....                  
                  end;

Im Script würde ich dann z.B gerne

Delphi-Quellcode:

  ...
  ThistProjecd:=mProjectGroup.CreateProject);
  ThisProject.SetWert1(1235);
  ...

Anstatt der Referenz ThisProject könne ich auch gut mit dem Listenindex leben..:)
Geht so was, ich weiss nicht ob diese Aufgabe für eine script-Engine Sinn macht, für mich wäre es aber sehr praktisch.

Beste Grüsse

Geri

[EugenB]

Das müsste die Script Engine schaffen

jage mal TProjectGroup und TProject durch das ImportTool, diese setzt du dann unter uses

im Script selbst

musste dann uses uProjects (zb)

bei var

mProjectGroup : TProjectGroup exports;

machen

kurz bevor du das Script "Run'st" musste mit SetVariable ( kA welche parameter , einfach mal gucken ^^) diese Variable setzen und schon kannste mProjectGroup im Script nutzen

Hoffe es ist das was du meintest und man kann es verstehen ^^

MfG,
Eugen

[Geri]

Hallo zusammen

@Eugen: Vielen Dank für Deine Hinweise. Ich werde mal versuchen diesen Weg in die Tat umzusetzen :) Kannst du mir bitte sagen, von welchem import-tool du sprichst? Ich bin die Demos mal durchgangen. Ein Tool habe ich nicht gefunden :)

Wenn ich richtig verstehe muss ich folgndermassen vorgehen:

1.) Units zuerst auf irgendeine Art importieren damit sie die Script-Engine kennt. (Importtool???)
2.) Im Skript eine Variable vom Typ TProjectGroup (z.B. ProjectGroup1:TProjectGroup) definieren.
3.) Auf Methoden und Eigenschaften der Klasse ProjectGroup und TProject zugreifen - Stimmts?
z.B.

Delphi-Quellcode:

var ProjectGroup1:TProjectGroup;
    Project1: TProject;
begin
  ProjectGroup1:=GetProjectGroupReference(); // Referen von der Mainform holen
  if Assgined(ProjectGroup1) then 
  begin
    Project1:=ProjectGroup.GetProject(0);             
    if Assigend(Project1) then Project1.SetProjectName('Testproject 0');
  end; 
end;

Habe ich das richtig verstanden? :)


@Dave
Ich bin absolut begeistert! Gibt es zu dieser Library auch eine Beschreibung oder ein Tutorial. Das wäre sehr praktisch, denn wenn man das Konzept versteht, dann kann man die Libary besser nutzen.
Ja, jedenfalls eine super Sache und ich werde mal schauen, ob ich es schaffe, diese Engine für mein Programm zu nutzen.

Beste Grüsse

Geri

[EugenB]

zu 1.) Main Programm -> deine Unit laden -> Project -> Export to Delphi Unit
zu 2.) genau, das Beispiel von dir müsste ich auch mal testen ^^ ist leichter als mit export usw^^
zu 3.) genau

Wobei ich nicht weiß ob Assigned in der Engine vorhanden ist

Und die Projekte sollen dann auch noch mal ausführbare Scripts sein?

Wird langsam zeit das sich Dave mal meldet *g*.

[Geri]

Hallo Eugen

Die Klasse Projekt enhält Methoden, welche im Programm bestimmte Aktionen ausführt.
Der Inhalt eines Projektes selbst ist kein Script.

Das Script wäre deshalb sehr praktisch, weil der Benutzer bestimmte Abläufe, die er immer wieder ausführt automatisieren könnte (ähnlich einem Macro).

Ich versuche gerade mein Glück :)

Beste Grüsse

Geri

[littleDave]

Hallo an alle,

sorry das ich so lange nicht mehr online war - ich habe im Moment sehr viel zu tun und hatte mein Delphi in den letzten 3 Monaten ca. 1 Woche mal gestartet :-(. Aber ich will mir wieder etwas Zeit für meine Lieblingsprache nehmen.

Bevor ich auf eure Beiträge eingehe, habe eine gute und eine schlechte Nachricht für euch:
Die Schlechte: Die Sysygy Script Engine werde ich nicht mehr weiterentwickeln :-(. Das Ding ist vom Quelltext her zu unübersichtlich und die Einbindung zu umständlich.

Die Gute Nachricht: Ich arbeite gerade an einer neuen Script Engine :-)

Die neue Script-Engine wird einiges Anders und Besser machen, da ich viel aus dieser Script-Engine gelernt habe: Ich hab mal schnell eine Liste von Sachen zusammengeschrieben, die ich einbauen WILL:

• Schnellerer und besserer Compiler (bereits 70% der Features des alten Compilers fertig eingebaut)
• Caching von bereits kompilierten Units (so wie in Delphi die .DCU - Dateien)
• Einen Linker, der einen Optimizer behinhaltet (zu 70-80% fertig)
• Eine kleinerer Byte-Code-Aufbau
• Eine schnellere RunTime-Engine (ist schon zu ca. 40% fertig)
• Richtiger Unit-Aufbau (unit ... interface ... implementation ... initialization ... finalization ... end.)
• Object-Pascal!!! (eigene Klassen im Script erstellen) (noch nicht angefangen)
• Records und Arrays (noch nicht angefangen)
• Methoden überlaben (funktioniert schon)
• Methoden forwarden (funktioniert schon)
• Ein etwas anderer Unit-Aufbau (nicht vom Quelltext her, sondern von der Benutzung von Units):
  Ich arbeite zur Zeit sehr viel in C# und ich finde das generelle Design von .NET und den Klassen nicht schlecht. Ich hab mir gedacht, dass Units (wie die Namespaces in .NET) über mehrere Dateien gehen können
• Statische Methoden (class procedure und class function) (funktioniert schon)
• und noch so einiges mehr ...

Das ist schon eine sehr lange List und sehr komplexe Liste die ich nicht so schnell abarbeiten kann. Jedoch bin ich noch sehr optimistisch, dass ich das hinbekomme.

Zitat:

Zitat von EugenB

irgendwie bin ich grade im Script-Wahn :-D, zuerst hab ich Pascal Script probiert aber irgendwie sind da noch soviele Fehler, dann hab ich schon fast vergessen das es diese Script Engine noch gibt ;)

Danke für die Blumen :-)

Zitat:

Zitat von EugenB

Da ich FPC nutze, musste ich in dieser Datei: uSygConstants

diesen Teil:
...
auch unter das {$IFNDEF FPC} packen
dann konnte ich es schon mal Compilieren :)

Ja, den FPC-Support hab ich leider etwas schleifen lassen

Zitat:

Zitat von EugenB

Was meinste wann diese Sachen funktionieren werden?
Arrays
Class Properties
Gleichnamige Funktionen ( welcher aber verschiedene Parameter haben zB. x(a: Integer); x(a: Float); x(a,b : Integer); etc

Arrays: wird es in der neuen Engine geben
Class properties: wird es in der neuen Engine geben
Overloading methods: wird es in der neuen Engine geben (funktioniert bereits)

Zitat:

Zitat von EugenB

Wie füge ich Funktionen hinzu, auch wenn ich den UnitName nicht weiß?

Delphi-Quellcode:

procedure TForm1.ParserOnAddCustomFunctions(Sender: TObject; UnitName: string);
begin
   if(UnitName='myprogram')then
   begin
      TSygScript_Parser(Sender).AddFunction(@MyWriteLn, 'procedure WriteLn(s: string); register;');
   end;
end;

Wenn ich das ohne UnitName='my...' mache bekomme ich nen Fehler das WriteLn schon existiert, gibt es vllt ne Funktion zum zu gucken ob diese Funktion schon existiert? oder wie löst man es am besten.

Die "AddFuntion" - Method ist noch von ganz früher, daher wollte diese nicht mehr verwendet werden. Am besten, du erstellst eine eigene Unit, die dann per Uses eingebunden wird.

Zitat:

Zitat von EugenB

Ich würde vorschlagen das du die Scipt Engine auf einen SVN Server packst, dann könnte man immer nen aktuellen Code bekommen und man könnte leichter Patches erstellen :)

Die neue Version werd ich wahrscheinlich in ein SVN Packen, das ist jedoch jetzt noch zu früh

Zitat:

Zitat von mschnell

Hast Du Deinen Bytecode komplett neu erfunden, oder hast Du eine Vorlage benutzt ?

Gibt es eine Beschreibung für den Bytecode ?

Der ByteCode ist von mir frei erfunden und hat auch leider keine Beschreibung. Jedoch hab ich das für die neue Version besser geplant und umgesetzt - der ByteCode wird dann besser zu verstehen sein.

Zitat:

Zitat von mschnell

(Ich möchte u.U,. den Bytecode-Interpreter in C implementieren, um auf einem Prozessor, für den es keinen Object-Pascal-Compiler gibt, Delphi-Code laufen zu lassen. )

Auch wenn ich das sehr interessant finde würd ich im Moment sagen: bitte warte, bis ich die neue Version veröffentlicht habe, da hat sich alles geändert und den Aufwand wäre umsonst, wenn du umsteigen wollen würdest (was ich dir bereits jetzt für später empfehlen würde)

@Geri:
Wenn das Problem noch aktuell ist, will ich dir noch schnell mal ne grobe Anleitung schreiben:

• Nimm die Deklaration deiner Klassen (der Teil, der in Delphi im Interface-Teil steht) und kopier ihn in die Zwischenablage
• Im Download-Paket gibt es im Ordner "main program\bin" eine vorkompilierte Exe, die einen Exporter zur Verfügung stellt. Einfach öffnen
• Dort erstellst du einen neue Unit und setzt den Unit-Namen auf irgendwas (also "unit [der Name]; begin; end;")
• Dann fügst du Zwischenablage ein und löscht alles, was im Private oder im Protected-Teil steht - darauf hast du von der Script-Engine sowieso keinen Zugriff
• Ersetze jeden Constructor durch eine Funktion, die als Return-Wert die entsprechende Klasse hat ("function Create: TKlasse")
• Lösche den destructor aus dem Script-Quelltext
• Passe gegebenfalls den Quelltext an, so dass er sich kompilieren lässt
• Gehe auf "File" - "Open" und öffne die Datei "FormatDelphiExportFunction.scs"
• Wechle wieder zurück auf deine gerade bearbeitet Unit und wähle unter "Project" - "Export to Delphi Unit"
• Beantworte die Frage mit ja
• Kopiere den kompletten Quelltext, der in dem neuem Tab erstellt wurde und kopiere ihn in die Zwischenablage
• Erstelle in deinem Delphi-Projekt eine neue Unit füge den Quelltext aus der Zwischenablage ein
• Passe die Unit an, bis sie sich kompilieren lässt - FERTIG

Nun solltest du die Klassen in deinem Script verwenden können (uses-Einbindung nicht vergessen)

Am besten schaust du dir nochmal die Beispiele an, die mit beim Download dabei sind

Viele Grüße

[EugenB]

Huhu

gibt es schon irgendwelche Updates, nutzbare Versionen o.ä?

MfG
Eugen

[littleDave]

Zitat:

Zitat von EugenB

Huhu

gibt es schon irgendwelche Updates, nutzbare Versionen o.ä?

MfG
Eugen

Hallo EugenB

Also benutzbare Versionen gibt es noch nicht. Aber ich komme gut vorran. Ich kann ja mal schnell nen Status-Update machen:

Also der Compiler ist schon sehr weit fortgeschritten. Ich habe schon einen Unit-Cache eingebaut, was die Compile-Performance schon mal extrem verbessert: wenn man ein Script kompiliert, werden alle benutzen Units erstmal kompiliert. Sind diese erfolgreich kompiliert, werden diese Daten in einen Binärstream (im Moment im Speicher) gespeichert. Wird das Script jetzt nochmal neu kompiliert, werden die verwendeten Units nicht nochmal kompiliert sondern direkt aus dem Cache geladen. Dadurch schaff ich es, relativ "einfache" Scripts in ca. 20 ms zu kompilieren. Das ist natürlich sehr Vorteilhaft für die Code-Completion. Diese habe ich jetzt auch noch erweitert, so dass es jetzt eine Code-Completion und eine Param-Completion gibt (in Delphi Strg+Shift+Leertaste). Das funkioniert bisher ganz prima.

Ein weiterer wichtiger Punkt ist die Run-Performance. Diese hab ich schon mal extrem verbessert. Hier mal eine kleine Tabelle (die einzelnen Test stehen unter der Tabelle), bei der ich die alte Script-Engine mit Pascal Script und mit meiner aktuellen vergleiche (alle Angaben in Sekunden)

Code:

-          Sysygy Script Engine   Pascal Script          ScriptEngine2
Test 1     4,76                   0,8                    0,9
Test 2     7,40                   1,6                    1,89
Test 3     12,75                  2,3                    2,8
Test 4     14,22                  8,44                   4,3
Test 5     26,10                  16,81                  8,7
Test 6     38,17                  25,21                  13,3
Test 7     31,39                  26,27                  11,0
Test 8     66,00                  52,61                  22,0
Test 9     99,10                  79,08                  33,0
-----------------------------------------------------------------------
Gesamt     299,89                 213,12                 97,89

Die einzelnen Test sind die Ausführungsgeschwindigkeiten von unterschiedlichen Scripten.
Test 1

Delphi-Quellcode:

program Test;

var i: integer;
begin
  for i:=0 to 1000000 do ;
end.

Test 2
Wie Test 1, nur zählen bis 2000000

Test 3
Wie Test 1, nur zählen bis 3000000

Test 4

Delphi-Quellcode:

program Test;

var i: integer;
begin
  for i:=0 to 1000000 do
  begin
    if i mod 2 = 0 then begin end;
    if i mod 3 = 0 then begin end;
    if i mod 4 = 0 then begin end;
  end;
end.

Test 5
Wie Test 4, nur zählen bis 2000000

Test 6
Wie Test 4, nur zählen bis 3000000

Test 7

Delphi-Quellcode:

program Test;

var i: integer;
begin
  for i:=0 to 1000000 do
  begin
    if i mod 2 = 0 then begin end;
    if i mod 3 = 0 then begin end;
    if i mod 4 = 0 then begin end;
    if i mod 5 = 0 then begin end;
    if i mod 6 = 0 then begin end;
    if i mod 7 = 0 then begin end;
    if i mod 8 = 0 then begin end;
    if i mod 9 = 0 then begin end;
    if i mod 10 = 0 then begin end;
  end;
end.

Test 8
Wie Test 7, nur zählen bis 2000000

Test 9
Wie Test 7, nur zählen bis 3000000

Wie man Anhand den Zeiten sieht, habe ich die Script-Engine gerade für komplexe Aktionen optimiert. Bei einer einfachen for-Schleife ist Pascal-Script noch ein wenig besser als meine Script-Engine. Sobald ich dann aber was in der for-Schleife mache, ist meine Script-Engine bei weitem schneller als Pascal-Script (und sowieso schneller als meine alte Script-Engine).

Dies erreiche ich vorallem durch einen eingebauten Memory-Manager in die Script-Engine. Dieser Memory-Manager ist dabei nicht ein Carbage Collector für die Script-Variablen - meine Script-Engine wird erstmal keinen Managed-Code benutzen. Ein weiterer Performance-Schub ist der eingebaute Linker, der den erstellen Byte-Code noch optimiert.

Mit dem Standard-Unit-Import komme ich auch schon ganz gut vorran. Bisher habe ich schonmal fast alle Funktionen der Unit Math eingebaut. Auch fast alle String-Operationen sind bereits eingebaut. Ach ja, DateTime wird auch kopmlett unterstützt (inklusive der Unit DateUtils). Da die Script-Engine ermöglicht, Units über mehrere Dateien zu spannen, muss man die einzelnen Units nicht mühsam einbinden.

Hier mal ein kleines Demonstations-Script:

Delphi-Quellcode:

program Test;

var i: integer; 
    d: TDateTime;
begin
  // Aktuelles Datum ausgeben
  d := DateTime.Now;
  Console.WriteLine(DateTime.DateTimeToStr(d));
  
  // Ne Schleife
  for i:=0 to 5 do
    // Overload-Test
    Console.Write(i);
                      
  // Noch ein Overload-Test
  Console.WriteLine();       
  // Eine Funktion aus Math 
  Console.WriteLine(Math.Max(5.0, 10.0));  
  // Eine Convert-Routine
  Console.WriteLine(Convert.BoolToStr(False, True));
  
  // Oder einfach nur nen String
  Console.WriteLine('Ende');  
  
  Console.ReadKey;
end.

Das Ergebnis:

Code:

25.10.2009 16:33:24
012345
10
False
Ende

Also es geht wirklich gut vorran. Was ich jedoch noch nicht gemacht habe ist: records, array, OOP, ... Es wird also noch ne ganze weile dauern, jedoch wenns so gut weitergeht, nicht mehr all zu lange ;-).

So, das war jetzt erstmal nen kleiner Status-Update. Sobald es wieder was wichtiges gibt, werd ich mich wieder melden.

Grüße
Dave

[mimi]

Ist die neue "Script Engine" auch unter FPC benutzbar ? Ich hätte da ein Projekt wo ich sie gerne einbauen würde/könnte.
Wobei das Projekt ist noch sehr am Anfang und es dauert noch einige Zeit. Ich denke die Scrip Sprache könnte ich erst in einigen Monaten einbauen. Wenn überhaupt....

Gerade die Pascal Syntax gefällt mir sehr gut.
Bei meinem Projekt handelt es sich um eine "Text Engine" quasi zwar wie HTML. Nur ist meine "Text Engine" nicht an irgendeine Sprache gebunden.

[igel457]

Hallo little Dave,

ich verfolge deine Scriptengine nun schon seit einer Weile gespannt. Das Projekt hört sich auf jeden Fall hochinteressant an. Vielleicht kann ich die Script Engine ja in Andorra 2D integrieren um so die GUI, Gameplay usw. steuern zu können.

Weiter so,
Andreas

[Florian Hämmerle]

Mal ne Frage: Baut die Komponente auf JvInterpreter auf?

mfg Flö

[littleDave]

Zitat:

Zitat von mimi

Ist die neue "Script Engine" auch unter FPC benutzbar ? Ich hätte da ein Projekt wo ich sie gerne einbauen würde/könnte.
Wobei das Projekt ist noch sehr am Anfang und es dauert noch einige Zeit. Ich denke die Scrip Sprache könnte ich erst in einigen Monaten einbauen. Wenn überhaupt....

Gerade die Pascal Syntax gefällt mir sehr gut.
Bei meinem Projekt handelt es sich um eine "Text Engine" quasi zwar wie HTML. Nur ist meine "Text Engine" nicht an irgendeine Sprache gebunden.

Also im Moment kann ich das noch nicht sagen. Entwickelt wird das Projekt erstmal in Delphi. Aber im Moment greife ich noch nicht auf irgendwelche Units zu, die es nicht in FPC gibt bzw. Platform-Spezifisch sind (z.B. die Unit Windows). Daher muss ich mal schauen. Doch das werd ich erst etwas später in Angriff nehmen. Erstmal muss alles funktionieren ;-)

Zitat:

Zitat von igel457

Hallo little Dave,

ich verfolge deine Scriptengine nun schon seit einer Weile gespannt. Das Projekt hört sich auf jeden Fall hochinteressant an. Vielleicht kann ich die Script Engine ja in Andorra 2D integrieren um so die GUI, Gameplay usw. steuern zu können.

Weiter so,
Andreas

Danke erstmal für dein Feedback :-)

Die aktuelle Version kann man schon ganz gut für eine GUI verwenden (siehe Widget-Engine). Bei der neuen Version werd ich das natürlich auch versuchen. Aber so eine Script-Engine baut man nicht in einer Woche, daher dauert das noch ne Weile.

Zitat:

Zitat von Florian Hämmerle

Mal ne Frage: Baut die Komponente auf JvInterpreter auf?

mfg Flö

Meine Script-Engine ist von der Funktionsweise nicht zu vergleichen mit dem JvInterpretor. Der JvInterpretor führt die Funktionen direkt beim kompilieren aus. Bei mir wird der Quelltext erst kompiliert und somit in Pseudo-Code umgewandelt. Dieser Code wird dann von einem anderen Object (dem Interpretor bzw. die RunTime) ausgeführt. Dies geht extremst viel schneller als die direkte Ausführung, ist dafür aber etwas komplexer zu programmieren. Außerdem benutzt der JvInterpretor sehr oft den Typ "Variant", was die Geschwindigkeit sehr verlangsamt.

Ich will den JvInterpretor nicht schlecht reden - ich find ihn eigendlich nicht schlecht. Jedoch ist er performance-technisch nicht so gut.

Also zu deiner Frage: nein ;-)

Grüße

[Florian Hämmerle]

Im Vergleich zu deiner Engine ist JvInterpreter schlecht.

Aber hast du dann alles von Grund auf alleine programmiert?

mfg Flö

[littleDave]

Zitat:

Zitat von Florian Hämmerle

Im Vergleich zu deiner Engine ist JvInterpreter schlecht.

Aber hast du dann alles von Grund auf alleine programmiert?

mfg Flö

Also programmiert ist alles von mir alleine. Jedoch hab ich mir das nicht einfach aus den Fingern gesogen: ich hab mir vorher ein paar Tutorials aus dem Netz angeschaut - sonst hätt ich das nicht so gut hinbekommen.

[Florian Hämmerle]

Achso. Also keine Erweiterung von irgendwas.

Das gibt doch gleich nochmal :thumb: :thumb:

mfg Flö

[Florian Hämmerle]

Was für Tutorials hast du denn da gelesen? Ich hab bis jetzt nur die bei DGL gefunden (Scriptsprachen-Tutorial 1 & 2).

Kannst du mir da ein paar Links geben bzw. Dateien schicken (falls du es gespeichert hast)?

Viele Grüße, Florian

[Geri]

Hallo Dave

Vielen Dank für dein Feedback. Habe es erst heute gelesen:)

Die Script engine ist für mich immer noch interessant. Du schreibst aber, dass du an einer Neuen Scriptengine dran bist. Hast du schon einen Zeitpunkt für das erste Release und macht es dann besser wenn man auf diese neue Engine wartet?

Vielen Dank nochmals und eine echt tolles Sache!

Geri

[mkinzler]

Zitat:

Du schreibst aber, dass du an einer Neuen Scriptengine dran bist. Hast du schon einen Zeitpunkt für das erste Release und macht es dann besser wenn man auf diese neue Engine wartet?

Bzw wie kompatibel wird die neue zu der (schon hervorragenden) "alten" Engine sein?

[littleDave]

Zitat:

Zitat von Geri

Die Script engine ist für mich immer noch interessant. Du schreibst aber, dass du an einer Neuen Scriptengine dran bist. Hast du schon einen Zeitpunkt für das erste Release und macht es dann besser wenn man auf diese neue Engine wartet?

Zitat:

Zitat von mkinzler

Bzw wie kompatibel wird die neue zu der (schon hervorragenden) "alten" Engine sein?

Also die neue Script-Engine kommt ganz gut vorran - im Momemt bin ich bei der Implementierung von arrays und records. Danach stehen Klassen auf der ToDo-Liste.

Generell wird die Script-Engine nicht sehr kompatibel zu der alten sein. Die Virtual Machine ist komplett neu geschrieben und ist somit nicht von den Daten kompatibel. Jedoch wird die Syntax ebenfalls wieder Pascal sein, somit ist die Sprache an sich sehr kompatibel. Jedoch hab ich die Syntax auch schon erweitert und die Funktionen werden in virtuellen statischen Klassen in der Script-Engine zusammengefasst.

Hier mal ein Beispiel

Delphi-Quellcode:

//alte Script-Sprache
var i: integer;
begin
  i := StrToInt('123');
  WriteLn(IntToStr(i));
end;

// Neue Script-Sprache
var i: integer;
begin
  i := Convert.StrToInt('123');
  Console.WriteLine(Convert.IntToStr(i)); // Entweder so
  Console.WriteLine(i); // oder so - overloaded Methoden werden unterstützt
end;

Jedoch wird man Projekte an die neue Script-Engine etwas anpassen müssen. Die grundlegenden Funktionen bleiben in etwa gleich, jedoch mit etwas anderen Parametern:

Delphi-Quellcode:

var PE: TSE2RunTime;
begin
  PE := Compiler.Compile('program Test; begin end.');
  try
    if PE <> nil then // korrekt kompiliert
    begin
      // z.B.
      PE.SaveToFile('Compiled.dat');

      PE.Initialize; 
      PE.Run;
      PE.Finalize;
    end; 
  finally
    PE.Free;
  end;

  // Oder so
  PE := TSE2RunTime.Create;
  try
    PE.LoadFromFile('Compiled.dat');
    PE.Initialize;
    PE.Run;
    PE.Finalize;
  finally
    PE.Free;
  end;
end;

Wann der erste Release sein wird, kann ich noch nicht sagen - aber ich beeil mich

[mkinzler]

Meine Frage zielte auch eher auf die Anwendung. Das sich intern viel geänder hat, habe ich erwartet.

[Namenloser]

Zitat:

Zitat von igel457

Hallo little Dave,

ich verfolge deine Scriptengine nun schon seit einer Weile gespannt. Das Projekt hört sich auf jeden Fall hochinteressant an. Vielleicht kann ich die Script Engine ja in Andorra 2D integrieren um so die GUI, Gameplay usw. steuern zu können.

Weiter so,
Andreas

Das wäre genial für gescriptete Gegner!

[Florian Hämmerle]

Wird es die Scriptengine auch wieder als OpenSource geben?

mfg Florian

[EugenB]

Gibt es welche Updates?

Oder Testversionen?

Es warten wohl viele auf diese Script-Engine =)

MfG,
Eugen

[littleDave]

Sorry das ich mich in letzter Zeit (bzw. in den letzten 6 Monaten) nicht mehr so oft melde. Das kommt halt davon wenn man nicht mehr Student sondern Azubi ist.

Also ich arbeite immer noch an der Script-Sprache. Jedoch hat sich bei mir ein heftiger Design-Fehler eingeschlichen, der mich dazu zwang, relativ viel neu zu schreiben. Jedoch bin ich langsam wieder auf nem grünen Ast.

Ich kann bereits externe Klassen in die Script-Engine einbinden, externe Objekte erstellen, Funktionen aufrufen und Properties abfragen und setzen. Es ist also schon sehr viel erledigt. Zudem kann ich auch einzelne Script-Funktionen aus dem Programm heraus aufrufen.
Jetzt werd ich mal schauen, dass ich die Classes-Unit einbaue. Dann hat man schonmal nen guten Grundstock. Was jedoch noch nicht funktioniert sind arrays und records. Jedoch denke ich, dass ich es diesmal besser umsetzen werden.

Eine Testversion würd ich ja schon gerne mal hochladen, jedoch bin ich mir nicht mehr so ganz sicher, ob das wirklich gut ist. Nach dem letzten großen Design-Fehler bin ich mir nicht mehr sicher, wieviel sich an den Aufrufen noch ändern wird.

Es gibt noch viel zu tun, jedoch versuch ich in den nächten 2 Monaten was ordendliches fertig zu stellen. Für garantieren kann ich leider nichts.

[EugenB]

:o GuuuuuT,

weiter so =) :stupid:

Also nicht mehr lange und die ScriptEngine unterstützt Classes? also OOP?

MfG,
Eugen

[littleDave]

Naja, so weit bin ich dann noch nicht.

Also ich hab die Script-Engine so aufgebaut, dass ich sie möglichst einfach erweitern kann. Alle wichtigen Eigenschaften wie virtual, overload, override, usw. sind schon als reservierte Worte drinnen und werden auch schon ein wenig benutzt. Jedoch kann man noch keine eigenen Klassen erstellen.

Aber ich will das irgendwie hinbekommen ;-)

[skydiablo]

moin !

bin eben per zufall hier im thread gelandet und wollte es ja nicht glauben ! das beschriebene hier ist die lösung meines prob ! ich habe ein recht großes projekt in delphi mit TjvInterpreter geschrieben... nun wollte ich das ganze ding neu coden, diesmal aber für linux und dafür fpc nutzen. wie sicherlich bekannt ist tjvinterpreter nicht fpc tauglich und so setze ich jetzt mal alles auf dieses pferd hier ! das ist echt klasse und ich freue mich schon auf deine umsetzung...

hast ein weiteren fan der sein nächstes projekt mit deinem code schmücken möchte ;)

greez, sky...

EDIT: so, habe nun doch noch etwas weiter im netz nach scripting möglichkeiten gesucht. nun brauch ich eine doch recht objektive meinung deines interpeter: kannst du dich mit dem RemObjects Pascal Script in functionsumfang, geschwindigkeit und stabilität messen ?

greez & thx, sky...

[littleDave]

Hallo,

ich meld mich mal wieder *g*. In meinem letzten Post (der ja doch schon 2,5 Monate her ist :oops:), hab ich ja angekündigt, dass ich versuche in 2 Monaten was auf die Beine zu stellen. Leider hab ich das Zeitlimit nicht geschafft, da ich mit diesem Post noch keine Version veröffentlichen will.

Aber ich hab mir gedacht - machste mal nen Status-Update - und diesmal ist es wirklich ein gewaltiger Schritt, den ich geschafft habe, denn

.... *trommelwirbel* ...

ich habe es endlich geschafft, dass meine Script-Sprache objekt-orientiertes Arbeiten möglich macht. Im Klartext heißt das, dass man jetzt im Script eigene Klassen erstellen kann (natürlich mit Variablen, Properties, Methoden, Constructor, Destructor, ...) und diese dann im Script verwenden. Dabei unterstützten die Klassen sogar Vererbung (also Zugriff auf Public/Protected-Properties/Methoden von Eltern-Klassen, Methoden überschreiben, usw.).

Am besten ich zeig euch mal ein kleines Script:

Delphi-Quellcode:

program Project1;

type
  TTest1 = class(TObject)
  private
    FABC : integer;
  public
    constructor Create; override;
    procedure Test1; virtual;
    
    property ABC : integer read FABC;
  end;
  
  TTest2 = class(TTest1)
  public
    constructor Create; override;
    procedure Test1; override;
  end;
  
  TTest3 = class(TTest2)
  public                  
    procedure Test1; override;
  end;

{ TTest1 }
  
constructor TTest1.Create;
begin                  
  inherited;               
  Self.FABC := 1024;
  Console.WriteLine('TTest1.Create'); 
end;

procedure TTest1.Test1;
begin            
  Console.WriteLine('TTest1.Test1');
end;

{ TTest2 }

constructor TTest2.Create;
begin                         
  inherited;
  Console.WriteLine('TTest2.Create');
end;

procedure TTest2.Test1;
begin         
  inherited;                      
  Console.WriteLine('TTest2.Test1');
end;

{ TTest3 }
     
procedure TTest3.Test1;  
begin        
  inherited; 
  Self.FABC := 512; // nur sichtbar, da in gleicher Unit
  Console.WriteLine('TTest3.Test1');
end;     

{ Main }

var p: TTest1; // Der Basistyp
begin            
  p := TTest3.Create; // eine abgeleitete Variante davon
  try         
    Console.WriteLine(p.ABC); 
    p.Test1;
    Console.WriteLine(p.ABC);  
  finally
    p.Free;
  end;      
end.

Wenn ich dieses Script ausführe, bekomme ich folgende Ausgabe in der Konsole:

Code:

TTest1.Create
TTest2.Create
1024
TTest1.Test1
TTest2.Test1
TTest3.Test1
512

Das ist jetzt schon etwas schwerer zu lesen, aber wenn man mal mit dem Finger den Ablauf so langgeht, dann kann man das schon ganz gut nachvollziehen.

Die Script-Klassen kann ich auch aus dem Programm heraus erstellen und die Vererbung nutzen. Hier mal ein wenig Pseudo-Code (Pseudo-Code, da die einzelnen Methoden noch ein paar andere Paremter haben, die hierfür erstmal nur stören würden)

Delphi-Quellcode:

var aClass  : Pointer;
    aObject : Pointer;
    method  : Pointer; 

begin
  // erstmal die Klasse suchen, die erstellt werden soll
  aClass := FRunTime.CodeAccess.FindClass('TTest3');
  // dann eine "Instanz" der Klasse erzeugen
  aObject := FRunTime.CreateClass(aClass);
  // dann noch die Basis-Methode suchen
  method := FRunTime.CodeAccess.FindMethod('TTest1.Test');
  // und dann die Methode mit "aObject" als Self-Parameter aufrufen
  FRunTime.Call(method, [aObject]);

  // -> jetzt wird im Script nicht die Funktion TTest1.Test ausgeführt, sondern
  // jetzt wird die Funktion "TTest3.Test" ausgeführt.
end;

Das ganze funktioniert schon sehr gut - jedoch muss ich den Compiler noch viel strenger machen. Zudem muss ich noch den Befehl "reintroduce" einbauen sowie den "inherited" - Befehl erweitern. Außerdem warten noch ein paar Bugs darauf, gelöscht zu werden.

Ich hoffe, dass ein paar Leute eine object-orientierte Script-Sprache brauchen könnten - ich brauch sie auf jeden fall ;-)

Grüße