ScriptEngine II (v. 0.6.1)

[littleDave]

Hallo liebe DP'ler

ScriptEngineII

ist der Nachfolger meiner letzten ScriptEngine. Da es sich um ein komplettes Remake handelt, sind die beiden jedoch nicht mehr vergleichbar.

Kurzübersicht

• Die Script-Engine bnutzt Object-Pascal als Script-Sprache und unterstützt objekt-orientierte Programmierung.
• Der Quelltext wird in ByteCode übersetzt, der dann von einer optimierten RunTime ausgeführt wird
• Trotz der Möglichkeiten ist das Interface der Komponente sehr klein und übersichtlich gehalten
• Für den Einstieg habe ich eine kleine Doku in Form eines PDFs mit in den Download gepackt

Installation
In der ZIP-Datei befindet sich ein Unterordner "src". Diesen extrahiert ihr einfach in einen Ordner eurer Wahl und fügt diesen Ordner dann in den Bibliothekspfad von Delphi hinzu. Im Quelltextorder befindet sich die Datei "ScriptEngine.inc". Diese Datei kann zum konfigurieren der ScriptEngine benutzt werden. Die einzelnen Defines sind (hoffentlich) ausreichend erklärt.

Benötigte Delphi-Version
Bisher hab ich es nur mit Delphi 7 und mit Lazarus getestet. Unter FreePascal hab ich nur ein paar Tests ausgeführt und diese sind auch korrekt gelaufen. Unter Delphi 2009/2010 hab ich die ScriptEngine ebenfalls erfolgreich getestet.

Besonderheiten

• wenn man innerhalb einer Klassenmethode auf andere Klassenmethoden oder -Variablen zugreifen will, muss man immer "Self" mit angeben
  Update 10.10.2010
  Mit der Version ist 0.5.4.1 ist das nun nicht mehr notwendig!
• Records sind Referenz-Typen

Bisherige Probleme
Im Moment sind noch folgende Probleme vorhanden:

• überladene Methoden haben bisher folgende Einschränkung:
  • sie müssen alle vom selben Typ sein (statisch, nicht statisch)
• der Befehl reintroduce ist noch nicht vorhanden

Lizenz
MPL v1.1 , GPL v3.0 oder LGPL v3.0

Feature-Liste

• Übersicht
  • Object-Pascal als Dialekt
  • Ganzzahltypen: byte, shortint, word, smallint, cardinal, integer, int64
  • Fließkommatypen: single, double
  • Stringtypen: string, UTF8String, WideString
  • Operatoren: + - * / div mod shr shl and or xor not @
  • Vergleich: = < > <= >= <> is
  • Schleifen: for while repeat for-in-do
  • Datenvergleich: if case
  • Spezielle Blocks: try-finally / try-except
  • Konstanten
  • verschachtelte Unit-Namen (z.B. Unit1.SubUnit.SubUnit)
  • Partielle Units
  • Ablaufkontrolle: continue break exit
  • Exception-Handling und Exception-Throw möglich
  • Multi-Threading-Scripts
• Methoden
  • Methodentypen: procedure function constructor destructor
  • Methodenparametertypen: const var
  • Methodenoperatoren: virtual abstract override overload forward
  • Import von DLL-Methoden direkt im Script (z.B.: procedure Sleep(milliSec: DWORD); external 'kernel32.dll' name 'Sleep'; stdcall; )
  • OOP-Features: inherited
  • Spezielle Operatoren: external export
  • Unterstützte Aufrufkonventionen: register pascal stdcall cdecl
  • Methoden-Pointer
  • Events
• Records
  • Abschnitte: private protected public
  • Record-Constanten (const-Deklaration in der record-Deklaration)
  • (statische) Record-Methoden
  • (statische) Record-Variablen
  • (statische) Record-Properties
  • Property-Typen: read+write, read-only, write-only
  • Property-Zugriff: direkt, über Methoden, über Methoden mit Parametern
• Klassen
  • Objekt-Orientierte Programmierung
  • Klassenvererbung
  • Methoden überschreiben
  • Klassen-Sektionen: private protected public
  • Class-Constanten (const-Deklaration in der Class-Deklaration)
  • (statische) Klassenmethoden
  • (statische) Klassenvariablen
  • (statische) Klassenproperties
  • Property-Typen: read+write, read-only, write-only
  • Property-Zugriff: direkt, über Methoden, über Methoden mit Parametern
  • Partielle Klassen (so ähnlich wie bei .NET)
• Class Helpers
  • Es können zu jedem Datentyp beliebig viele "Helfer-Klassen" erstellt werden
  • gleicher Aufbau wie bei normalen Klassen, nur die Deklaration ist etwas anders:
    • TStringHelper = helper for string
  • Class Helpers erweitern eine Klasse/einen Datentyp ohne die Vererbung zu nutzen
• Compiler
  • schneller Compiler
  • eingebauter Unit-Cache für schnelleres kompilieren (so wie Delphi-DCUs)
  • partielle Units – mehrere einzelne Units mit gleichem Namen werden zu einer Unit zusammengefasst
  • Linker zum zusammenstellen und zum optimieren des Byte-Codes
  • IntelliSense / Code-Completion und Parameter-Hints-Unterstützung
  • eingebaut als abstrakte Klasse – für SynEdit bereits vorhanden
  • Speichern des kompilierten ByteCodes in einen Stream
• RunTime
  • schneller ByteCode-Interpreter
  • direkter Aufruf von Delphi-Funktionen
  • Script-Methoden aus dem Programm heraus aufrufbar
  • Script-Methoden als TMethod-Event nativ aufrufbar
  • einfacher Garbage Collector für Script-Klassen (nur falls das Objekt nicht manuell zerstört wurde)
  • eigener Memory-Manager mit Caching für schnelleres Ausführen und für weniger Speicherfragmentierung
  • Exception-Handling
  • Stack-Tracing
• Quelltext
  • durchgehende Namenskonvention (Units starten mit uSE2 und Klassen mit TSE2)
  • bisher keine Memory-Leaks gefunden

Noch ein paar kurze Hinweise
- Diesmal habe ich leider nicht so viele Beispiele mit in den Download hinein gepackt - es werden aber noch ein paar nachgeliefert

SVN
Ich hab für die Script-Engine ein Source-Forge-Projekt erstellt. Dort sind alle Änderungen auch per SVN abrufbar. Wichtige Releases werd ich natürlich weiterhin hier hochladen

Mitgelieferte IDE
Ich habe die kompilierte Version meiner aktuellen IDE mit in das Download-Paket gepackt. Zusätzlich hab ich den Source in den Unterordner IDEsrc gepackt - zusammen mit den drei kompilierten Packages. Mit der IDE kann man ein paar Testprojekte öffnen, die sich im Unterordner "Projects" befinden.

Ich hoffe, euch gefällt die neue Script-Engine und vielleicht kann der eine oder andere sie ja benutzen.

Download
Auf SourceForge.net (ca. 2,6 MB)

Grüße

[sx2008]

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

[EugenB]

Zitat von littleDave:

Sollte behoben sein, denn .....

Version 0.5.0.0

Ja das ist noch besser

Jetzt kann ich es sogar kompilieren, danke!

Ich konnte auch noch die console.pas/consoleform.pas unter FPC kompilieren (dachte erst es würde nicht funktionieren )

Hab ich mich damals verlesen oder sollten Arrays nicht in Version 0.5.0.0 erscheinen

Zitat von sx2008:

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

Genau das funktioniert leider nicht , würde diese auch brauchen um mittels script auf SOAP-Services zuzugreifen, ohne in der Host-Anwendung dieses zu "erstellen" -> oder kennt jemand eine andere Methode um leicht auf SOAP-Services zu zu greifen?

Dann bräuchte man "nur" noch Arrays und Interfaces richtig?

[littleDave]

Zitat von sx2008:

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

Also ich habe bisher keine Probleme damit gehabt. Referenz-Probleme habe ich bisher eigentlich nicht. Ich denke, dass man hier eigentlich komplett auf Interfaces verzichten kann - denn ich sehe im Moment keine Verbesserung, die mir Interfaces bieten würden.

Zitat von EugenB:

Hab ich mich damals verlesen oder sollten Arrays nicht in Version 0.5.0.0 erscheinen

Ist eine kurze Planänderung: ich dachte mir, dass Exception-Handling doch etwas wichtiger ist, als Arrays. Wenn man Listen haben will, kann man sich theoretisch die TList-Klasse aus der Collection-Unit schnappen. Als Datenobjekt erstellt man dann eine Klasse. Dadurch hat man sehr viel mehr Vorteile, als einfach nur ein array of record (z.B. die Vererbung).

Zitat von EugenB:

Genau das funktioniert leider nicht , würde diese auch brauchen um mittels script auf SOAP-Services zuzugreifen, ohne in der Host-Anwendung dieses zu "erstellen" -> oder kennt jemand eine andere Methode um leicht auf SOAP-Services zu zu greifen?

Dann bräuchte man "nur" noch Arrays und Interfaces richtig?

Ich glaube sx2008 meint Interfaces im Delphi-Source. Für Interfaces in den Scripts habe ich mal versucht den Assembler-Code, den Delphi erstellt, versucht zu verstehen. Das Problem ist halt die richtige Zuordnung der Methoden - da habe ich noch kein Konzept für gefunden.

[himitsu]

Zitat von littleDave:

Für Interfaces in den Scripts habe ich mal versucht den Assembler-Code, den Delphi erstellt, versucht zu verstehen. Das Problem ist halt die richtige Zuordnung der Methoden - da habe ich noch kein Konzept für gefunden.

Delphi-Quellcode:

PInterfaceEntry = ^TInterfaceEntry;
TInterfaceEntry = packed record
  IID: TGUID;
  VTable: Pointer;
  IOffset: Integer;
  ImplGetter: Integer;
end;

PInterfaceTable = ^TInterfaceTable;
TInterfaceTable = packed record
  EntryCount: Integer;
  Entries: array[0..9999] of TInterfaceEntry;
end;

TObject:
  function GetInterface(const IID: TGUID; out Obj): Boolean;
  class function GetInterfaceEntry(const IID: TGUID): PInterfaceEntry;
  class function GetInterfaceTable: PInterfaceTable;

Da findestes du schonmal alle Interfaces eines Objektes.
PInterfaceTable

Direkt an der Adresse, wohin der Interfacezeiger zeigt, liegt eine MethodAdressTabelle.

Und die InterfaceMethoden werden einfach über ihren Index aufgerufen.

Delphi-Quellcode:

IInterface = interface
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
end;

Kannst dir ja mal hiervon den ASM-Code anzeigen lassen:

Delphi-Quellcode:

var Intf: IInterface;
begin
  Integer(Intf) := $123;
  Intf._AddRef;

_AddRef ist die 2. Methode des Interfaces.
Es gibt auch keine Vorfahren dieses Interfaces ... deren Methoden würden sonst vorher aufgezählt.
Somit hat die Methode die Adresse, welche bei +4 Byte (Index = 1, da 0-basierendes Array) in dieser Tabelle liegt.

Code:

mov eax, Intf
call TMethod(PPointer(Intf)^ + Index)

Delphi-Quellcode:

ITest = Interface(IInterface)
  Procedure Test;
end;

PS: Wenn nix angegeben ist, dann ist der Standardvorfahr automatisch IInterface.

.Test läge also bei Index 4 aka +12 Byte (0 bis 3 in IInterface und die 4 in ITest)

[littleDave]

@himi: ich habe mir deine Sachen zu den Interfaces noch nicht angeschaut, aber trotzdem sage ich schonmal danke: PInterfaceTable könnte helfen


Zur später Stunde noch ein Update Version 0.5.1.0

• Neuerungen
  • Methoden, die über Methoden-Pointer aufgerufen wurden, sind jetzt ebenfalls im Stack-Trace sichtbar
  • Nun können auch beliebig verschachtelte Records mit der Host-Anwendung ausgetauscht werden
  • Es gibt eine neue "Methode" im Script: sizeof(): Gibt die Anzahl der Bytes aus, die ein Objekt belegt (geht nur mit Typennamen - also sizeof(TPoint))
  • Neue Methode: System.TDateTime.UtcNow (Universal Time) [nur Delphi]
  • Neues Record: System.TTimeSpan: zum Setzen, Bearbeiten und komfortablen Auslesen von Zeitdifferenzen (führt auch noch ein paar Helper-Methoden für TDateTime ein, damit das ganze noch einfacher zu Benutzen ist)
  • Neue Klasse: System.TimeZone: zum Auslesen der aktuellen Zeitzone [nur Delphi]
  • Die bisherigen Helper-Klassen für die Basis-Typen erweitert
• Änderungen
  • Die interne Ausrichtung von Records im Speicher geändert (daher auch Punkt 2 unter Neuerungen)
  • Interne Record-Verwaltung sehr beschleunigt
  • Compilerhinweis zu "Variable ist deklariert, wird aber nicht benutzt" verbessert
  • Byte-Code-Optimizier im Linker etwas erweitert
  • Finalization-Teile der benutzen Units werden jetzt in umgekehrter Initialiserungs-Reihenfolge angearbeitet
• Bug-Fixes
  • Kritischer Fehler bei der Script-RunTime-Type-Information behoben
  • Problem beim finden von Identifiern mit zusätzlichen Unit-Namen behoben (nur verschachtelte Unit-Namen waren unter bestimmten Umständen betroffen)
  • Kleiner Fehler in der Methode "System.DateTime.EncodeDateTime" behoben
  • Kritischer Fehler im Unit-Cache behoben: der finalization-Teil einer Unit wurde zum Initialization-Teil hinzugefügt
  • System.EAccessViolation hatte eine falsche Elternklasse im Script

Der Download befindet sich wie immer im ersten Post ( - oder im SVN)

Grüße

[Dolvik]

Hallo littleDave!

Mal ne Frage. Bei welcher Version glaubst du, dass du Arrays implementiert haben wirst und wie lange schätzt du, bis diese Version veröffentlicht werden kann?

Dolvik

[littleDave]

Das Problem mit arrays ist halt: ich brauche sie im Moment nicht. Daher ist es für mich schwer mich dazu zu überwinden, arrays einzubauen. Zumal man mit TList etwas Ähnliches bekommen kann. Ich kann leider nicht sagen, wann ich arrays einbauen werde. Ich baue lieber Sachen ein, die ich gerade brauche. Natürlich will ich auch irgendwann arrays unterstützen, (da ich jedoch kein großer Fan von arrays bin), dauert das leider noch etwas. Ich welchem Zeitraum kann ich leider auch nicht sagen. Ich habs ja schon mal Versucht indem ich Version 0.5 gesagt habe *hust*. Daher will ich jetzt nicht v0.6, v0.7, v4.0, etc sagen und den gleichen Fehler nochmal machen. Hoffe, dass das etwas nachvollziehbar ist.

Weil ich gerade dabei bin, mach ich mal etwas Werbung für die nächste Version
In der nächsten Version, die bald kommen wird, kann man Multi-Threaded-Scripts erstellen - also eigene Threads im Script erstellen und ausführen. Dafür muss man den Delphi-Quelltext nicht anrühren. Es wird dabei Ähnlich wie in Delphi sein: man muss eine Klasse erstellen, die von einer bestimmten Klasse abgeleitet werden muss. Dort muss dann nur die Execute() - Methode überschrieben werden und fertig. Das ganze schaut dann so aus:

Delphi-Quellcode:

program Test;

uses
  System.Threading;

type
  TMyTest = class(TExecutionContext)
  protected
    procedure Execute; override;
  end;

procedure TMyTest.Execute;
begin
  TThread.Sleep(1000);
end;

var Context   : TMyTest;
    Thread    : TThread;
begin
  Context := TMyTest.Create;
  try
    Thread := TThread.NewThread(Context);
    try
      Thread.Start;
      while not (Thread.State = ThreadState.Finished) do
        { irgendwas } ;
    finally
      Thread.Free;
    end;
  finally
    Context.Free;
  end;
end.

Ist zwar noch nicht final, aber funktioniert schon super. Habe zum Test mal eine Primzahl-Berechnung auf 15 Threads aufgesplittet und hab die Ausführungszeit halbieren können (Dual-Core halt ). Wie gesagt, ist noch nicht fertig, daher dauert das noch ein wenig - jedoch nicht mehr lange

Gruß

[Dolvik]

Hallo littleDave!

Nein ist überhaupt kein Problem, wenn man keine arrays hat. Hab nur das mit v0.5 mitbekommen und wollte wissen ob das noch in der beta-Phase ist oder ob es hinausgeschoben wurde.

Multithreading klingt interessant Freu mich schon aufs Testen.

An was arbeitest du denn gerade für einem Projekt, das die SE2 miteinbezieht?

Dolvik

[littleDave]

Ich arbeite seit längerem an einer 3D-Engine auf OpenGL-Basis. Die Engine an sich ist in Delphi geschrieben, die komplette "Spiellogik" wird dabei von der Script-Engine übernommen. Also vom einfachen Einschalten einer Lampe bis hin zur (späteren) KI- und Spielersteuerung. Die Engine benutzt fast ausschließlich Shader - komplett dynamisches Per-Pixel-Lighting, Realtime-Shadows, Bump/Parallax-Mapping, Depth-of-Field, Deferred Shading, usw. Das ganze ist für relativ starke PCs ausgelegt, daher leiste ich mir auch den "Luxus", die Spiellogik nicht nativ sondern mit der Script-Engine zu realisiern. Da ich SE2 schon ziemlich stark optimiert habe, ist der Performance-Verlust nicht so tragisch.

Hier mal zwei YouTube-Videos: 1. und 2. (falls es dich interessiert)

Gruß

[Dolvik]

Hallo littleDave,

Ist echt gut gemacht! Das die Scriptengine das so schnell hinbekommt hätte ich nicht gedacht. *respekt*
Bin mal gespannt, wie die finale Version des Spiels aussehen wird.

Ich wünsch dir weiterhin viel Glück und gutes Gelingen.

Dolvik

PS: Erstaunlich was du alles schaffst: SE1, SE2, Widgetengine, ImageViewer, Spiel. Übernimm dich nicht