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.:
    Delphi-Quellcode:

    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

[igel457]

Hallo.

Erstmal ein dickes Lob für diese tolle Bibliothek, ich lese mir gerade deine vorbildhaft gestaltete Anleitung durch und spiele vielleicht mal noch ein wenig damit herum.

Was mir jedoch seltsam erscheint ist, dass du das Ganze unter eine CreativeCommons-Lizenz veröffentlicht hast - eigentlich sind diese ja gerade nicht für Software sondern Kunst (Texte, Musik, Bilder, Videos) geeignet.

Auch das "Keine Bearbeitung: der Quelltext darf nur unverändert weitergegeben werden" finde ich seltsam - wenn ich das Ganze nun in ein Opensource-Spiel integriere und dabei einige Dinge verbessere, warum darf ich dann diese Verbesserungen nicht der Öffentlichkeit (also auch dir) zurückgeben? Wenn ich die Script-Engine jedoch in ein Closed-Source-Spiel einbinde, dann kann ich umschreiben, was ich möchte und darf das dann veröffentlichen. Das ganze widersetzt sich a) dem Sinn von OpenSource und b) glaube ich dem, was du erreichen möchtest.
Zum Beispiel werde ich nicht in der Lage sein, deine Script-Engine in Andorra 2D zu integrieren und muss mir dann leider wohl eine andere Lösung suchen.

Warum veröffentlichst du es nicht unter einer Lizenz wie der GPL/LGPL und verkaufst kommerzielle Lizenzen?

Sonst wiederhole ich nochmal: Klasse Arbeit, weiter so! :thumb:

Andreas

[littleDave]

Zitat:

Zitat von igel457

Erstmal ein dickes Lob für diese tolle Bibliothek, ich lese mir gerade deine vorbildhaft gestaltete Anleitung durch und spiele vielleicht mal noch ein wenig damit herum.

Danke für das Lob, war auch einiges an Arbeit.

Zitat:

Zitat von igel457

Was mir jedoch seltsam erscheint ist, dass du das Ganze unter eine CreativeCommons-Lizenz veröffentlicht hast - eigentlich sind diese ja gerade nicht für Software sondern Kunst (Texte, Musik, Bilder, Videos) geeignet.

Auch das "Keine Bearbeitung: der Quelltext darf nur unverändert weitergegeben werden" finde ich seltsam - wenn ich das Ganze nun in ein Opensource-Spiel integriere und dabei einige Dinge verbessere, warum darf ich dann diese Verbesserungen nicht der Öffentlichkeit (also auch dir) zurückgeben? Wenn ich die Script-Engine jedoch in ein Closed-Source-Spiel einbinde, dann kann ich umschreiben, was ich möchte und darf das dann veröffentlichen. Das ganze widersetzt sich a) dem Sinn von OpenSource und b) glaube ich dem, was du erreichen möchtest.
Zum Beispiel werde ich nicht in der Lage sein, deine Script-Engine in Andorra 2D zu integrieren und muss mir dann leider wohl eine andere Lösung suchen.

Warum veröffentlichst du es nicht unter einer Lizenz wie der GPL/LGPL und verkaufst kommerzielle Lizenzen?

Wegen der Lizenz bin ich mir selbst noch nicht so ganz zufrieden. Also GPL/LGPL finde ich persönlich nicht so wirklich gut, da ich auch Freeware-Programme das Framework nutzen können sollen, ohne den Quelltext mit frei geben zu müssen bzw. ohne dass das Framework in eine externe Library ausgelagert werden muss. Unter der BSD-Lizenz will ich das nicht stellen, denn wenn Leute mit dem Framework Geld verdienen, dann will ich auch was von dem Kuchen abhaben :twisted:.

Aber mit fällt gerade was ein: das Framework wird grundsätzlich erstmal unter LGPL oder GPL freigegeben. Mit kurzer Absprache kann man auch eine andere Lizenz haben - was bei kommerziellen Einsatz einen gewissen Obolus kostet. Ich werd mir das noch überlegen (vielleicht noch ein/zwei Kommentare abwarten) - aber vielleicht heute Abend schon die Lizenz ändern.

Zitat:

Zitat von igel457

Sonst wiederhole ich nochmal: Klasse Arbeit, weiter so! :thumb:

Danke für das Lob - das freut mich :-)

[himitsu]

Wegen der Lizenz, da hatte ich vor 'ner Weile auch mit zu kämpfen und am Ende ist das hier rausgekommen

MPL v1.1 , GPL v3.0 or LGPL v3.0


Kannst dir ja gern nochmal die Beiträge durchlesen
http://www.delphipraxis.net/internal...t.php?t=109739

Ansonsten gibt es noch massenhaft Themen dazu [dp]Lizenz*[/dp]
(oder einfach z.B. Begriffen=Lizenz und Autor=himitsu, da ich in einigen anderen Themen auch schon drin rumgepostet hab)
und in meinem himXML-Thread versteckt sich auch eine kleine Diskusion dazu (so zwischendurch ab Seite 4 oder so)


Mann oh mann, soviele ScriptEngines hier in der DP, da weiß man bald garnicht mehr, welche man nehmen soll :mrgreen:

[kalmi01]

Hi,

habe die Demos mal unter D2009 compiliert:

• uSE2Linker.pas(157): W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString'
  uSE2Linker.pas(207): W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString'
  uSE2Linker.pas(274): E2010 Inkompatible Typen: 'AnsiChar' und 'Char'
  uSE2Linker.pas(897): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
  uSE2Linker.pas(898): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
  uSE2Linker.pas(898): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
  uSE2Linker.pas(981): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
  uSE2Linker.pas(982): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'
  uSE2Linker.pas(982): W1057 Implizite String-Umwandlung von 'AnsiString' zu 'string'

wobei lediglich in Zeile 274 das

Delphi-Quellcode:

Chr(d)

in

Delphi-Quellcode:

AnsiChar(d)

geändert werden musste.

Gruss
Michael

[littleDave]

Zitat:

Zitat von kalmi01

habe die Demos mal unter D2009 compiliert:

• uSE2Linker.pas(157): W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString'
  ...

wobei lediglich in Zeile 274 das

Delphi-Quellcode:

Chr(d)

in

Delphi-Quellcode:

AnsiChar(d)

geändert werden musste.

Gruss
Michael

Danke fürs Testen :-)

Delphi 2009/2010 wird offiziell nicht unterstützt, da ich keine Möglichkeit habe, es zu testen. Werde die Zeile aber natürlich ersetzen.

Grüße

[kalmi01]

Zitat:

Zitat von littleDave

Delphi 2009/2010 wird offiziell nicht unterstützt, da ich keine Möglichkeit habe, es zu testen. Werde die Zeile aber natürlich ersetzen.

ist schon klar, aber :

Zitat:

Zitat von littleDave

Mit Delphi 2009/2010 hab ich die Script-Engine nicht ausprobiert, jedoch wurden alle Strings, die auch wirklich Ansi-Strings seien sollen, als solche deklariert.

deshalb wollte ich einfach mal ne Rückmeldung geben.

[littleDave]

Zitat:

Zitat von kalmi01

Zitat:

Zitat von littleDave

Delphi 2009/2010 wird offiziell nicht unterstützt, da ich keine Möglichkeit habe, es zu testen. Werde die Zeile aber natürlich ersetzen.

ist schon klar, aber :

Zitat:

Zitat von littleDave

Mit Delphi 2009/2010 hab ich die Script-Engine nicht ausprobiert, jedoch wurden alle Strings, die auch wirklich Ansi-Strings seien sollen, als solche deklariert.

deshalb wollte ich einfach mal ne Rückmeldung geben.

So war das nicht gemeint - es war nur ein Hinweis. Ich finds wunderbar, dass du mir das gesagt hast.

Nochmal eben zum Lizenz-Problemchen
Ich habe nochmal genauer drüber nachgedacht, wie ich das mit der Lizenz jetzt mache. Ich finde den Vorschlag von himitsu mit den Mehrfachlizenzen wirklich gut und ich habe ihn auch im Endeffekt genau so umgesetzt: MPL, LGPL oder GPL. Das mit dem Verkaufen von kommerziellen Lizenzen hab ich mir dabei auch durch den Kopf gehen lassen und fand die Idee für mich nicht mehr so wirklich gut.

Wenn jemand das Framework wirklich gut findet, dann bin ich eigentlich auch schon mit einem Kommentar, Verbesserungsvorschlägen oder einer Spende (z.B. Beerware) total zufrieden.

Ich hab den Anfangspost sowie alle Positionen mit den Lizenzen (die mir gerade eingefallen sind) im Download angepasst.

Grüße

[Vasco da Gama]

Hi, ich wollte deine Engine mal wie in der .pdf Datei beschrieben ausprobieren.
vor punkt 2.4 scheitere ich, ich zitiere:

Zitat:

Wenn das Programm jetzt ausgeführt wird, werden zwar keine Fehlermeldungen mehr angezeigt, jedoch wird auch keine Zahl angezeigt. Das liegt jetzt aber nicht daran, dass das Script nicht ausgeführt wird – im Gegenteil. Es liegt nur daran, dass die Output-Methode der Script-Engine-Console noch nicht gesetzt ist. Doch das kann man schnell ändern.

Allerdings bekomme ich bei folgendem Code:

Delphi-Quellcode:

unit testunit;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs,
  uSE2Compiler, // für den Compiler
  uSE2UnitCacheMngr, // für den Unit-Cache-Manager
  uSE2Errors, // für TSE2ErrorType
  uSE2Reader, // wird zum Lesen der Daten benutzt
  uSE2PEData, // die ByteCode-Daten
  uSE2RunTime; // für die RunTime

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    procedure CompilerError(Sender: TObject; ErrorType: TSE2ErrorType; ErrorUnit, ErrorText: string; ErrorPos, ErrorLine: integer; UserData: TObject);
    procedure CompilerNeedUnit(Sender: TObject; const Name: string; const Readers: TList);
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
var
  Compiler : TSE2Compiler;
  RunTime : TSE2RunTime;
  PEData : TSE2PE;
begin
  Compiler := TSE2Compiler.Create;// den Compiler erstellen
  try // hier wird der Quelltext des Scripts compiliert
    Compiler.OnGetFile := CompilerNeedUnit;
    Compiler.OnCompilerError := CompilerError;
    PEData := Compiler.Compile(
              'program MyScript;'
              +#13#10+ 'uses MyUnit;'
              +#13#10+ 'var i: integer;'
              +#13#10+ 'begin'+#13#10+ ' i := Add(2, 4);'
              +#13#10+ ' Console.WriteLine(i);'
              +#13#10+ 'end.'+#13#10); // falls das compilieren erfolgreich war, ist PEData ungleich nil
    if PEData <> nil then
    begin
      try // hier wird die RunTime erstellt, die das kompilierte
          // Script ausführt
        RunTime := TSE2RunTime.Create;
        try
          // zuerst muss das kompilierte Script übergeben werden
          RunTime.AppCode := PEData; // nun muss die RunTime initialisiert werden
          RunTime.Initialize; // hier wird das Script ausgeführt
          RunTime.Run; // nun noch die RunTime stoppen
          RunTime.Finalize; // wenn wir folgende Zeile nicht einfügen
          // RunTime.AppCode := nil
          // wird das Objekt PEData automatisch von der RunTime
          // freigegeben.
          // Da wir das aber selbst machen, fügen wir die Zeile ein RunTime.AppCode := nil;
        finally
          // die RunTime freigeben
          RunTime.Free;
        end;
      finally
        // das kompilierte Skript freigeben
        PEData.Free;
      end;
    end;
  finally // den Compiler freigeben
    Compiler.Free;
  end;
end;

procedure TForm1.CompilerError(Sender: TObject; ErrorType: TSE2ErrorType; ErrorUnit, ErrorText: string; ErrorPos, ErrorLine: integer; UserData: TObject);
begin
  // nur Fehler anzeigen
  if ErrorType = petError then // Fehlernachricht anzeigen
    ShowMessage('Compiler error: '+#13#10+ Format('[%s] [Zeile %d]: %s', [ErrorUnit, ErrorLine, ErrorText] ) );
end;

procedure TForm1.CompilerNeedUnit(Sender: TObject; const Name: string; const Readers: TList);
begin
  // falls der Compiler die Unit "MyUnit" haben will
  if SameText(Name, 'MyUnit') then
  begin
    // dann wird er Quelltext der Unit hinzugefügt
    // dazu muss in der Liste "Readers" ein Objekt vom
    // Typ "TSE2Reader" hinzufügen. Jedoch ist "TSE2Reader"
    // eine abstrakte Klasse. Vom Reader sind zwei Versionen
    // bei der Script-Engine mit dabei:
    // - ein StringReader, mit dem man direkt den Quelltext als
    // string übergeben kann
    // - ein StreamReader, mit dem man den Stream mit dem Quelltext
    // auslesen kann
     // da hier direkt ein String benutzt wird, wird der TStringReader
     // benutzt
     Readers.Add( TSE2StringReader.Create(
        // nun übergibt man im Constructor direkt den Quelltext
        // der Unit "MyUnit"
        'unit MyUnit;'+#13#10+
        'interface'+#13#10+
        '  function Add(const i1, i2: integer): integer;'+#13#10+
        'implementation'+#13#10+
        '  function Add(const i1, i2: integer): integer;'+#13#10+
        '  begin result := i1 + i2;end;'+#13#10+
        'end.' ) );
     end;
end;

end.

Bei Programmstart eine Fehlermeldung:
Erste Gelegenheit für Exception bei $7572FBAE. Exception-Klasse EInvalidPointer mit Meldung 'Ungültige Zeigeroperation'. Prozess TestProject.exe (1676)

So sagt mir das zumidest der Debugger ;)

Ich hoffe du kannst mir helfen.

mfG

[littleDave]

Zitat:

Zitat von Vasco da Gama

Hi, ich wollte deine Engine mal wie in der .pdf Datei beschrieben ausprobieren.
vor punkt 2.4 scheitere ich, ich zitiere:

Zitat:

Wenn das Programm jetzt ausgeführt wird, werden zwar keine Fehlermeldungen mehr angezeigt, jedoch wird auch keine Zahl angezeigt. Das liegt jetzt aber nicht daran, dass das Script nicht ausgeführt wird – im Gegenteil. Es liegt nur daran, dass die Output-Methode der Script-Engine-Console noch nicht gesetzt ist. Doch das kann man schnell ändern.

Allerdings bekomme ich bei folgendem Code:

Delphi-Quellcode:

//...

Bei Programmstart eine Fehlermeldung:
Erste Gelegenheit für Exception bei $7572FBAE. Exception-Klasse EInvalidPointer mit Meldung 'Ungültige Zeigeroperation'. Prozess TestProject.exe (1676)

So sagt mir das zumidest der Debugger ;)

Ich hoffe du kannst mir helfen.

mfG

Das liegt bei deinem Quellcode bei Zeile 65f - die schaut bei dir so aus:

Delphi-Quellcode:

  // Da wir das aber selbst machen, fügen wir die Zeile ein RunTime.AppCode := nil;
finally

müsste aber so aussehen:

Delphi-Quellcode:

  // Da wir das aber selbst machen, fügen wir die Zeile ein 
  RunTime.AppCode := nil; // <---
finally

[Vasco da Gama]

Danke, mein Problem ist, dass ich bei solchen Projekten, gerne mal den Code kopiere, dann in mein Projekt einfüge und dort durchlese, anstatt es abzuschreiben.

Allerdings werden bei meinem Adobe Reader 8 die Leerzeilen und -zeichen beim Code-Abschnitt ignoriert :roll:

Danke nochmal
mfG
VdG

[_x_]

Die Script-Engine funktioniert unter Linux mit Lazarus einwandfrei.
Ich musste nur kleinere Änderungen bei den Includes machen (statt \ den hier / :wink: ).
Außerdem funktioniert der Performance-Counter nicht. Da er Windows-Api funktionen nützt.
Aber sonst läuft alles Tadellos! :thumb:


mfg _X_

[Florian Hämmerle]

Da hast du dir ja was echt Tolles aus den Fingern (oder sollte man besser sagen Tasten) gszogen. :)

Noch ne Frage zur Lizenz: Bleibt das jetzt so, dass ich für ein Freeware-Projekt die Script-Engine gratis verwenden und bei Bedarf auch ändern darf?

Schöne Grüße, Florian

[littleDave]

Zitat:

Zitat von _x_

Die Script-Engine funktioniert unter Linux mit Lazarus einwandfrei.

Das ist sehr gut zu hören - vielen Dank auch fürs ausprobieren :-)

Zitat:

Zitat von _x_

Ich musste nur kleinere Änderungen bei den Includes machen (statt \ den hier / :wink: ).
Außerdem funktioniert der Performance-Counter nicht. Da er Windows-Api funktionen nützt.
Aber sonst läuft alles Tadellos! :thumb:

Ja, bei den Includes war ich etwas schlampig - aber das werd ich noch ändern. Zum Performance-Counter: den hatte ich nur zum Testen eingebaut und ist nicht wirklich wichtig - von daher kann man ihn eigentlich auch wieder löschen

Zitat:

Zitat von Florian Hämmerle

Da hast du dir ja was echt Tolles aus den Fingern (oder sollte man besser sagen Tasten) gszogen. :)

Danke für das Lob :-) Das freut mich :cheer:

Zitat:

Zitat von Florian Hämmerle

Noch ne Frage zur Lizenz: Bleibt das jetzt so, dass ich für ein Freeware-Projekt die Script-Engine gratis verwenden und bei Bedarf auch ändern darf?

Schöne Grüße, Florian

Also du kannst dir eine von den drei Lizenzen aussuchen. Für Freeware ist die MPL wahrscheinlich das richtige. Dort kannst du den Quelltext nach belieben ändern, musst ihn aber nicht veröffentlichen (so wie ich das bisher verstanden habe)


Ich habe in den letzten Tagen mich mal hingesetzt und ein paar Helper-Klassen für einige Datentypen geschrieben. Wer Helper-Klassen nicht kennt: damit kann ich Klassen/Typen mit Funktionen erweitern, ohne die Vererbung zu nutzen. Als Beispiel möchte ich noch schnell ein Beispiel-Script zeigen, bei dem ich die Erweiterungen für den Typ String getestet habe:

Delphi-Quellcode:

program Project1;
var s: string;
    p: string;
begin
  s := 'Hallo, wie gehts';
  if s.StartsWith('Hallo') then
    if s.EndsWith('gehts') then
      if s.Length > 10 then
      begin
        p := s.Copy(6, 5);
        s := s.Replace(p, '', [rfReplaceAll, rfIgnoreCase]);
      end;
        
  Console.WriteLine(s);  // Ausgabe: "Hallo gehts"
  Console.WriteLine(p);  // Ausgabe: " , wie"
  Console.ReadKey;     
end.

Ich weiß noch nicht, ob ich das Update dieses Wochenende noch hin bekomme, da ich noch die Helper-Klassen und die partiellen Klassen in das PDF noch mit hineinschreiben will.

[_x_]

Zitat:

Zitat von littleDave

Zitat:

Zitat von _x_

Die Script-Engine funktioniert unter Linux mit Lazarus einwandfrei

Das ist sehr gut zu hören - vielen Dank auch fürs ausprobieren :-)

Nichts zu Danken :)

Zitat:

Zitat von littleDave

Zum Performance-Counter: den hatte ich nur zum Testen eingebaut und ist nicht wirklich wichtig - von daher kann man ihn eigentlich auch wieder löschen

Wäre in manchen fällen sicher trotzdem interessant :gruebel:

mfg _X_

[toms]

Unter Delphi 6 lässt es sich nicht kompilieren. Einige Funktionen sind in der SysUtils.pas noch nicht vorhanden.

[littleDave]

Zitat:

Zitat von toms

Unter Delphi 6 lässt es sich nicht kompilieren. Einige Funktionen sind in der SysUtils.pas noch nicht vorhanden.

Wenn das nicht zu viele seien sollten, wäre es super, wenn du mir eben ne Liste schreiben würdest - dann schmeiß ich diese per Compiler-Switch heraus.

[_x_]

In der PDF gibt es die Variable "MyScriptProject", von welchem Type ist die?

mfg _X_

[littleDave]

Zitat:

Zitat von _x_

In der PDF gibt es die Variable "MyScriptProject", von welchem Type ist die?

mfg _X_

Diese Variable hat erstmal keinen Typ und ist als Pseudo-Code anzusehen. Ich glaub, ich hab das nicht rein geschrieben - sorry. Es sollte nur eine grobe Funktionalität zeigen, die mit den Methodennamen beschrieben werden sollte.
-> Man muss den Typ leider selbst erstellen.

[_x_]

Ach so.

Unter Linux gibt es auch ein paar Probleme mit dem Cache-Manager.
Wo genau das Problem liegt, kann ich aber noch nicht sagen.

mfg _X_

[littleDave]

Ich habe gerade ein Problem gefunden, bei dem auch der Cache-Manager betroffen ist - vielleicht liegt es daran:

In der Datei "uSE2Consts.pas" findet man folgende Zeile:

Delphi-Quellcode:

class procedure TSE2StreamHelper.WriteString(Stream: TStream;
  const s: string);
var len: cardinal;
begin
  len := length(s);
  Stream.Write(len, SizeOf(len) * SizeOf(char)); // <-- hier ist ein fehler
  Stream.Write(s[1], len);
end;

Diese muss man durch folgende Zeilen ersetzen

Delphi-Quellcode:

class procedure TSE2StreamHelper.WriteString(Stream: TStream;
  const s: string);
var len: cardinal;
begin
  len := length(s);
  Stream.Write(len, SizeOf(len));
  Stream.Write(s[1], len * SizeOf(char)); // <-- muss nur eine Zeile weiter drunter
end;

[littleDave]

Ich hab gerade eine neue Version hochgeladen :arrow: Version 0.3.3.0

Zum einen hab ich den Bug, den ich gerade beschrieben habe beseitigt. Zudem hab ich noch ein Problem behoben, der mit aktivierten Range-Check aufgetreten ist (Danke an _X_ für den Hinweis).

Es gibt auch eine neue Unit: "uSE2IncHelpers.pas". Bindet man diese Unit ein, sind ein paar Helper-Klassen für die Typen TDateTime, String, Pointer, Single, Double und TColor eingebaut. Die Helper-Funktionen sind auch in der eingebauten IntelliSense-Funktion verfügbar.

Hier mal zwei, drei Beispiele, die mit den Helper-Klassen möglich sind:

Delphi-Quellcode:

var time: TDateTime;
    str : string;
    ptr : pointer;
    dbl : double;
    res : boolean;
begin            
  res := dbl.IsNan;
  res := ptr.Assigned;
  res := (str.IndexOf('h') > 10) and (str.EndsWith('hey'));
  res := (time.Month > 2) and (time.DayOfYear > 128);
end.

Um die Helper-Klassen zu benutzen muss man nur die Unit "uSE2IncHelpers" in die Uses-Liste der Anwendung aufnehmen.

Leider hab ich es noch nicht geschafft, die Helper-Klassen sowie die partiellen Klassen in das PDF mit aufzunehmen - ich werd es aber noch nachholen.

Grüße

[toms]

Zitat:

Zitat von littleDave

Zitat:

Zitat von toms

Unter Delphi 6 lässt es sich nicht kompilieren. Einige Funktionen sind in der SysUtils.pas noch nicht vorhanden.

Wenn das nicht zu viele seien sollten, wäre es super, wenn du mir eben ne Liste schreiben würdest - dann schmeiß ich diese per Compiler-Switch heraus.

Zitat:

[Error] uSE2IncStrings.pas(306): Undeclared identifier: 'LeftBStr'
[Error] uSE2IncStrings.pas(328): Undeclared identifier: 'MidBStr'
[Error] uSE2IncStrings.pas(345): Undeclared identifier: 'PosEx'
[Error] uSE2IncStrings.pas(350): Undeclared identifier: 'PosEx'
[Error] uSE2IncStrings.pas(366): Undeclared identifier: 'RightBStr'

Diese Funktionen lassen sich leicht nachbauen (anstatt diese per Compiler-Switch herauszuschmeißen)

[_x_]

Unter Linux bekommt man in der Unit uSE2PerfMonitor kleine Probs mit Uses Windows; Bitte ein {$IFNDEF FPC} reinmachen.

mfg _X_

[EugenB]

Ich freu mich das es endlich das die Version der ScriptEngine gibt :stupid:

Aber leider schade das man keine Antwort per PN bekommt :(

Anyway, weiter so , endlich mal ne OOP Scriptsprache =)

[littleDave]

Zitat:

Zitat von toms

Zitat:

Zitat von littleDave

Zitat:

Zitat von toms

Unter Delphi 6 lässt es sich nicht kompilieren. Einige Funktionen sind in der SysUtils.pas noch nicht vorhanden.

Wenn das nicht zu viele seien sollten, wäre es super, wenn du mir eben ne Liste schreiben würdest - dann schmeiß ich diese per Compiler-Switch heraus.

Zitat:

[Error] uSE2IncStrings.pas(306): Undeclared identifier: 'LeftBStr'
[Error] uSE2IncStrings.pas(328): Undeclared identifier: 'MidBStr'
[Error] uSE2IncStrings.pas(345): Undeclared identifier: 'PosEx'
[Error] uSE2IncStrings.pas(350): Undeclared identifier: 'PosEx'
[Error] uSE2IncStrings.pas(366): Undeclared identifier: 'RightBStr'

Diese Funktionen lassen sich leicht nachbauen (anstatt diese per Compiler-Switch herauszuschmeißen)

Vielen Dank für die Liste - die nächste Version wird die Funktionen nachgebaut drinnen haben. Danke für die Mühe

Zitat:

Zitat von _x_

Unter Linux bekommt man in der Unit uSE2PerfMonitor kleine Probs mit Uses Windows; Bitte ein {$IFNDEF FPC} reinmachen.

mfg _X_

Ist in der aktuellen Version bereits so eingebaut - es wird auch ein Konfigurations-File geben mit dem man das Kompilieren der Script-Engine einstellen kann.

Zitat:

Zitat von EugenB

Ich freu mich das es endlich das die Version der ScriptEngine gibt :stupid:
[...]
Anyway, weiter so , endlich mal ne OOP Scriptsprache =)

Danke für das Lob :-) Freut mich, dass sie ankommt.

Zitat:

Zitat von EugenB

Aber leider schade das man keine Antwort per PN bekommt :(

Oh, ist meine Nachricht nicht gesendet worden :gruebel:? Komisch ... hol ich aber gleich nach.

[himitsu]

Zitat:

Zitat von littleDave

Vielen Dank für die Liste - die nächste Version wird die Funktionen nachgebaut drinnen haben.

mach die einfach ein nur dann rein, wenn auch nötig ... es muß in aktuellen Versionen ja nicht unbedingt doppelter Ersatz-Code vorhanden sein :angel:

Delphi-Quellcode:

{$IF not Declared(PosEx)}
  function PosEx(...): string;
  begin
    ...
  end;
{$IFEND}

bzw.

Delphi-Quellcode:

interface
  {$IF not Declared(PosEx)}
    function PosEx(...): string;
    {$DEFINE INCLUDE_POSEX}
  {$IFEND}

implementation
  {$IFDEF INCLUDE_POSEX}
    function PosEx(...): string;
    begin
      ...
    end;
  {$ENDIF}

[add]
OK, man könnte es auch von der Delphi-Verion abhängig machen, aber so ist es wohl einfacher ... also wenn man nicht ständig gucken muß, wann was eingeführt wurde usw.

[littleDave]

Zitat:

Zitat von himitsu

mach die einfach ein nur dann rein, wenn auch nötig ... es muß in aktuellen Versionen ja nicht unbedingt doppelter Ersatz-Code vorhanden sein :angel:

Ich habs so gelöst:

Delphi-Quellcode:

{$IFNDEF DELPHI7UP}
function PosEx(....)
begin
  (...)
end;
{$ENDIF}

// Aufruf:
{$IFDEF DELPHI7UP}
  result := StrUtils.PosEx(....);
{$ELSE}
  result := PosEx(...);
{$ENDIF}

Das Define "DELPHI7UP" wird per Include-File gesetzt, dass in jede Unit der Script-Engine eingebunden wird.

Zitat:

Zitat von himitsu

Delphi-Quellcode:

{$IF not Declared(PosEx)}
  function PosEx(...): string;
  begin
    ...
  end;
{$IFEND}

:shock: geht das wirklich - also das "IF not Declared(PosEx)"? Ich dachte, per Compiler-Switch kann man generell nicht auf Delphi-Elemente zugreifen bzw. überprüfen, ob etwas bereits vorhanden ist :gruebel:

Zitat:

Zitat von himitsu

OK, man könnte es auch von der Delphi-Verion abhängig machen, aber so ist es wohl einfacher ... also wenn man nicht ständig gucken muß, wann was eingeführt wurde usw.

Ich habs jetzt so gelöst, da ich das "declared" nicht kannte.

[toms]

Es läuft soweit unter Delphi 2010, es gibt jedoch einige Warnungen.

[himitsu]

Zitat:

Zitat von littleDave

:shock: geht das wirklich - also das "IF not Declared(PosEx)"? Ich dachte, per Compiler-Switch kann man generell nicht auf Delphi-Elemente zugreifen bzw. überprüfen, ob etwas bereits vorhanden ist :gruebel:

Also Funktionen aufrufen oder auf Variableninhalte zugreifen geht natürlich nicht,
aber die "Funktionen" Declared (für Funktionen, Klassen, Konstanten und Variablen) und Defined für Compilerschalter geht.

Ich weiß jetzt nur nicht in welcher Delphiversion das {$IF ...} eingeführt wurde.

Delphi-Quellcode:

{$DEFINE Schalter1}

// dieses 
{$IFDEF Schalter1}
  {$IFDEF Schalter2}
    ...
  {$ENDIF}
{$ENDIF}

// ist das Gleiche wie das
{$IF Defined(Schalter1) and Defined(Schalter2)}
  ...
{$IFEND}

// und dann gibt es noch sowas

{$IF not Declared(xyz)} {$MESSAGE Hint 'xyz gibt es nicht'} {$IFEND}

const xyz = 5;

{$IF Declared(xyz)} {$MESSAGE Hint 'jetzt schon'} {$IFEND}

{$IF xyz = 5} {$MESSAGE Hint 'xyz ist 5'} {$IFEND}

[add]
die D2010-Warungen sollten so wohl auch schon in/ab D2009 kommen

[Florian Hämmerle]

Hat deine Scriptsprache bzw. deine Scripengine schon einen Namen? Deine erste Engine hieß ja SY.... .
Arbeitest du schon in einem deiner Projekte mit der neuen Scriptsprache (Widget-Engine oder ähnliches)?

mfg Florian

[littleDave]

Zitat:

Zitat von toms

Es läuft soweit unter Delphi 2010, es gibt jedoch einige Warnungen.

Ich hab mir jetzt die Trial von Delphi 2010 heruntergeladen und die ScriptEngine darin kompiliert. Ich habe alle Warnungen behoben und ein paar Tests gemacht. Bisher gab es keine Probleme mehr mit Delphi 2010 - somit sollte man die ScriptEngine ab der neuen Version (ist bereits online) auch mit Delphi 2009/2010 benutzen können.

@himitsu
Das $IF scheint ja sehr mächtig zu sein :shock:. Mal schauen, ob ich das benutzen kann ;-) Danke für die Infos

Zitat:

Zitat von Florian Hämmerle

Hat deine Scriptsprache bzw. deine Scripengine schon einen Namen? Deine erste Engine hieß ja SY.... .

Ja, einen Namen hat die schon: ScriptEngine II ;-).

Zitat:

Zitat von Florian Hämmerle

Arbeitest du schon in einem deiner Projekte mit der neuen Scriptsprache (Widget-Engine oder ähnliches)?

Also die Script-Engine ist schon produktiv in einem Projekt drinnen, jedoch hab ich das bisher in der DP noch nicht veröffentlicht - das dauert auch noch eine Weile. Wer aber mehr wissen will, kann sich meinen Gael Development Blog anschauen - ist mal wieder was mit OpenGL ;-).

Die Widget-Engine befindet sich gerade noch im Winterschlaf ;-). Jedoch will ich die neue Script-Sprache auch in die Widget-Engine einbauen. Zuvor muss ich mir aber erst ein Interface für die Widget-Engine überlegen und vielleicht die ein oder andere Veränderung machen.

@All: Es gibt eine neue Version der Script-Engine :arrow: Version: 0.3.4.0
Ich habe gerade eine neue Version der Script-Engine hochgeladen. Diesmal hab ich einiges verbessert:

• Delphi 2010 Support
  Dank toms hab ich die Script-Engine jetzt auch kompatibel mit Delphi 2010 (und somit auch mit 2009) gemacht. Um das zu Testen, hab ich mir zudem noch die Trial heruntergeladen. Bisher gab es mit D2010 keine Probleme.
• Delphi 6 Support
  Dank toms hab ich die 4 Funktionen, die in Delphi 6 nicht vorhanden waren, durch eigene ersetzt. Somit sollte die Script-Engine jetzt auch mit Delphi 6 funktionieren - jedoch hab ich keine weiteren Tests gemacht, da ich kein Delphi 6 habe.
• FreePascal Support
  Ich habe (hoffentlich) alle Windows-spezifischen Teile in FreePascal deaktiviert. Somit sollten nun keine Probleme mehr vorhanden sein.
• Konfiguration
  Ich habe die Datei "ScriptEngine.inc" extrem aufgepeppt. Jetzt findet man in der Include-Datei einen Konfigurations-Abschnitt, mit dem man die Script-Engine beim kompilieren des Delphi-Projektes ein wenig anpassen kann. Ich hoffe, ich habe alle Defines genügend beschrieben
• Erweiterung bei der Script-Engine
  Ich habe die Helper-Klassen von Single und Double noch um ein paar weitere Funktionen erweitert. Zudem gibt es ein neues Keyword in der ScriptEngine: deprecated. Mit diesem Keyword kann man Typen, Variablen, Klassen oder Funktionen als Veraltet markieren. Nach dem Keyword kann man noch einen String eingeben, der dann der Compiler-Warnung hinzugefügt wird.
• IntelliSense
  Ich habe den Inhalt, der in der IntelliSense-Klasse ausgegeben wird, erweitert. Somit werden jetzt auch Unit-Namen und die Basis-Typen von Klassen und von eigenen Typen angezeigt.
• Dokumentation
  Ich habe nun endlich Partielle Klassen und Class Helper mit in das PDF mit aufgenommen. Zwar sind die Abschnitt nicht sehr lang, doch ich hoffe, dass es verständlich rübergekommen ist.
• Mitgelieferte IDE
  Ich habe nun meine aktuelle IDE mit in den Download gepackt. Damit könnt ihr mal etwas rumspielen. Den Quelltext muss ich noch etwas überarbeiten und liefere ihn somit erst etwas später nach.

Grüße

Edit - falsche Version
Ich hab leider die falsche Version hochgeladen :oops: Alle, die sich das Paket vor dem 30.09.2009 23:30 Uhr heruntergeladen haben, haben leider eine alte Version. Ich hab gerade die richtige hochgeladen - Sorry. In der alten Version gab es noch ein Problem mit partiellen Klassen.

[littleDave]

So, es gibt (schon wieder ;-)) ein kleines Update :arrow: Version 0.3.4.1

Dies ist nur eine Bugfix-Version und bringt keine neuen Features. Folgendes hab ich verbessert:

• IntelliSense
  Die Unitnamen werden beim IntelliSense-Fenster jetzt nur dann angezeigt, wenn sie erlaubt sind.
• Klassen-Ableitung
  Mann kann nun nicht mehr eine rekursive Klassendeklaration angeben (gab einen Stack-Overflow-Error)
• Klassen forwarden
  Es gab einen kleinen Parser-Fehler, wenn man Klassen forwarden wollte

Grüße

[littleDave]

Es gibt mal wieder ein Update :arrow: Version 0.3.5.0

Folgendes hat sich verändert:

• Bug fixes
  • FindMethod hat den Rückgabetyp nicht überprüft
  • Kritischer Fehler in String-Umwandlung: man konnte keine verschiedenen String-Typen benutzen
• IDE
  • Konsolen-Fenster hat nicht mehr das Hauptformular als Parent (gab Probleme mit Windows 7)
  • Beim "Save Project" kommt jetzt der normale Windows-Dialog
  • Neues Demoprojekt: NativeCallTest
• Neue Features
  • Script-Funktionen können jetzt auch zu TMethod gecastet werden (Beispiel im PDF)
  • Funktions-Pointer der importierten Methoden werden jetzt nur einmal pro TSE2PE-Instanz gesetzt

SVN
Auf Drängen von EugenB hab ich ein SourceForge-Projekt für die ScriptEngineII erstellt ;-). Somit kann man sich jetzt immer den aktuellsten Quelltext per SVN herunterladen.

Nativer Script-Methoden-Aufruf
Wie bereits gesagt kann man jetzt die Script-Methoden auch "nativ" aufrufen. Um das mal etwas zu verdeutlichen hier mal ein Beispiel:

Sagen wir mal, ich will folgende Script-Methode dem FormResize-Event zuweisen:

Delphi-Quellcode:

var
  formWidth, formHeight : integer;

procedure MyFormResize(Sender: TObject);
begin
  formWidth := TForm(Sender).Width;
  formHeight := TForm(Sender).Height;  
end;

Bisher musste man immer eine Wrapper-Funktion bauen, die folgendermaßen aussehen konnte:

Delphi-Quellcode:

// ....
  Self.OnResize := MyCustomHandler;
// ...

procedure TForm1.MyCustomHandler(Sender: TObject);
var Method : Pointer;
begin
  Method := Self.FRunTime.CodeAccess.FindMethod('MyFormResize', '', [pmIn], [btObject]);
  if Method <> nil then
     Self.FRunTime.Call(Method, [Sender]);
end;

Dann wurde bei jedem Event erst die Funktion "MyCustomHandler" ausgeführt, in der dann die Script-Funktion ausgeführt wurde.
Nun kann man wie folgt machen

Delphi-Quellcode:

// ....
  Self.OnResize := MyCustomHandler;
// ...

procedure TForm1.SetEventHandler;
var Method : Pointer;
    MyEvent: TNotifyEvent;
begin
  Method := Self.FRunTime.CodeAccess.FindMethod('MyFormResize', '', [pmIn], [btObject]);
  if Method <> nil then
  begin
    MyEvent := TNotifyEvent( Self.FRunTime.ScriptAsMethod(Method, nil) );
    Self.OnResize := MyEvent; // <-----
  end;
end;

Jetzt wird bei jedem OnResize-Event automatisch die Script-Funktion ausgeführt.

Man kann die Events zwar noch (!!!) nicht in der Script-Engine selber setzten, da man noch keine Methoden als Typ deklariert kann. Aber sobald man das machen kann, kann man die Events dann auch in der Script-Engine selber setzen.

Natürlich kann man nicht nur normale Funktionen "nativ" ausführen. Man kann auch Klassen-Methoden so aufrufen - aber ich hab das alles im PDF beschrieben.

Grüße

[_x_]

Eine Frage: Ist die IDE auch unter Linux lauffähig?

mfg _X_

[littleDave]

Zitat:

Zitat von _x_

Eine Frage: Ist die IDE auch unter Linux lauffähig?

mfg _X_

Mit Wine sollte es funktionieren. Ich hab bei mir kein Linux, daher kann ich es auch nicht ausprobieren. Hab im Moment nicht mal Lazarus drauf, da ich am Wochenende die Windows 7 Final installiert habe (MSDN-AA ist schon was geilen :-) - ist bisher schon viel besser als Vista).

An sich ist es ja nur ein Beispiel. Der Quelltext ist zwar immer noch nicht verfügbar :oops: kommt aber noch

[_x_]

Unter Wine geht die IDE.

Wenn du die JVCL verwendest, (tust du doch, glaub ich, oder? ), kannst du Linux leider abschreiben.

mgh _X_

[EugenB]

Hey^^,

danke für den SVN ^^

Habe mal die Demos nach Lazarus konvertiert damit man auch mal so kurz testen kann ^^, und dabei herrausgefunden, das Convert.IntToStr nicht funktioniert

SEII-Code:

Delphi-Quellcode:

Console.WriteLine(Convert.IntToStr(32));

Gibt nur eine leere Zeile aus :(


Weißt du vllt woran es liegt?

Lazarus 0.9.29 (letzter Snapshot)
FPC 2.2.4

Bisher noch keine anderen Bugs gefunden ^^

MfG,
Eugen

[littleDave]

Zitat:

Zitat von _x_

Unter Wine geht die IDE.

Wenn du die JVCL verwendest, (tust du doch, glaub ich, oder? ), kannst du Linux leider abschreiben.

mgh _X_

Ja, in der IDE verwende ich die TJvTabBar ... mal schauen, vielleicht kann ich das noch etwas abstrakter gestalten ;-)

Zitat:

Zitat von EugenB

Hey^^,

danke für den SVN ^^

Kein Problem ;-)

Zitat:

Zitat von EugenB

Habe mal die Demos nach Lazarus konvertiert damit man auch mal so kurz testen kann ^^, und dabei herrausgefunden, das Convert.IntToStr nicht funktioniert

SEII-Code:

Delphi-Quellcode:

Console.WriteLine(Convert.IntToStr(32));

Gibt nur eine leere Zeile aus :(

Weißt du vllt woran es liegt?

Lazarus 0.9.29 (letzter Snapshot)
FPC 2.2.4

Ja, ich glaub ich weiß woran das liegt. Hab das Problem heute auch schon gefunden, da ich den aktuellen Source testen wollte. Das Problem liegt an der Calling-Convention von FPC (soweit ich das mitbekommen habe). In FreePascal werden strings als Rückgabewert von Funktionen auch im EAX-Register zurückgeliefert. Jedenfalls funktioniert es, wenn ich den EAX-Wert nach dem Aufruf einer Funktion auslese. Also eine Lösung ist gefunden, jedoch muss ich die noch weiter ausprobieren ;-).

Zitat:

Zitat von EugenB

Bisher noch keine anderen Bugs gefunden ^^

MfG,
Eugen

Das ist gut :-)

[littleDave]

Eine neues Update ist da :arrow: Version 0.4.0.0

Änderungen

• Packages
  Man kann jetzt eigene Script-Units oder externe Klassen in DLLs auslagern und diese dann nahtlos in die Script-Engine einfügen. Was jedoch wichtig ist: bei Packages sollte die DLL mit der gleichen Delphi-Version erstellt worden sein wie das Hauptprogramm.
  
  Leider hab ich noch keine Demo für Packages erstellt, jedoch hab ich bereits die drei Testpackages für die IDE mit in den Download gepackt. Mit diesen Packages hat man Zugriff auf Streams und einige Listen.
  
  In der IDE gibt es einen Package-Viewer, mit dem man die geladenen Packages anzeigen kann.
• FreePascal
  Bei FreePascal ist die Call-Convention etwas anders als in Delphi. Dies hat vor allem Strings als Rückgabewert beeinflusst: sie sind nicht angekommen. Dieses Problem sollte nun behoben sein.
• Memory Leak unter FreePascal behoben (dank an EugenB)
• Linker
  Der Linker speichert die benutzen Methoden jetzt in einem Baum. Dadurch ist das kompilieren etwas langsamer (ca. 0.1 sek), jedoch werden jetzt nur wirklich die Methoden mit in den finalen ByteCode hineinkopiert, die auch benutzt werden. Das Schlüsselwort export funktioniert weiterhin.
• Tools
  Es gibt jetzt einen Unit-Importer, mit dem man Delphi-Klassen einfacher der Script-Engine hinzufügen kann. Dafür muss man nur den Interface-Teil der entsprechenden Unit in eine neue Unit in der IDE kopieren. Nachdem sich das neue Script kompilieren lässt (z.B. nachdem man hinter jeder Funktion/Procedure/Methode das Schlüsselwort "external" schreibt), wählt man unter "Project" -> "Generate Unit" -> "Application Unit" aus. Dann wird ein neuer Tab in der IDE geöffnet, dessen Inhalt man einfach komplett in die Zwischenablage kopiert und in eine neue Unit in Delphi einfügt.
• Sonstiges
  Ein paar Bugs bzw. ein paar zu strenge Regeln im Parser behoben
• Neue Klasse in der System-Unit: TPersistent

Grüße