Sysygy Script Engine - Version 0.99h

[littleDave]

Hallo liebe DP'ler

Ich meld mich mal wieder mit ner neuen Komponente :)

http://www.godlikesoft.de/images/ext...ngine-Logo.jpg

Einleitung
Nach dem Release meines Sysygy Image Viewers hab ich erstmal eine kleine Pause von dem Projekt gebraucht. Daher hab ich mich dazu entschlossen, meine Script-Engine, die ich bereits in dem Projekt verwende, weiter zu machen und allen zur Verfügung zu stellen.

Allgemeines
Sysygy Script Engine ist eine Skript-Sprache die den Dialekt Pascal benutzt. Es werden bei weitem nicht alle Features der Delphi-Sprache unterstützt, aber immerhin ein kleiner Teil. Beim kompilieren erstellt der Parser Byte-Code, denn dann von einem Interpreter ausgeführt wird.
Durch die Einbindung einer Script-Sprache ist es Möglich, ein Programm von Benutzern erweiterbar zu machen, ohne dass das Hauptprogramm neu kompiliert werden muss. Dadurch wird ein enormes Spektrum an neuen Möglichkeiten eröffnet.
Man kann mit der Script-Sprache z.B. aufwendige, mathematische Funktionen berechnen, die einen einfachen Matheparser überfordern würden. Denn dadurch, dass Ergebnisse in Variablen zwischengespeichert werden können und diese dann mit if-Anweisungen verschieden weiterbearbeitet werden können, kann man z.B. verschachtelte Funktionen erstellen, die nicht an das Programm gebunden sind sondern vom Benutzer während der Laufzeit des Programms geändert werden können (z.B. ein Funktionszeichner).
Ebenfalls ist es möglich, dass sich ein Programm selbst dynamisch anpasst: bei manchen Gelegenheiten ist es extrem schwer, bestimmte Situationen im Code zu verarbeiten. Möglich ist es zwar immer, doch manchmal kann der Aufwand extrem groß sein. An dieser Stelle könnte das Programm z.B. dynamisch neuen Quelltext erstellen, der dann von der Script-Sprache ausgeführt wird.
Sehr hilfreich wird eine Script-Sprache, wenn man z.B. ein Programm per "Fernwartung" erweitern oder ausbessern möchte und man nicht so einfach an die Datei herankommt. Dann kann es z.B. ausreichen, ein neues/verbessertes Script einfach an das Programm zu schicken und somit die Funktionalität erweitern/ausbessern.
Das mag jetzt zwar so klingen, als könnte man ganz einfach in einen PC eindringen - doch man sollte bedenken: das Script kann nur Funktionen ausführen, welche das Programm der ScriptEngine bereits zur Verfügung stellt. (Übertrieben) gesagt kann man nicht aus einer 2 KB-Exe ein Monsterprogramm machen. Ein kleines Beispiel wäre: ich habe eine StringListe, die sortiert werden soll. Die Vergleichsfunktion der einzelnen Zeilen lager ich in ein Script aus, das den Vergleich übernimmt. Das Script kann dann nur die Vergleichsfunktion beeinträchtigen aber z.B. nicht die Liste leeren.

Was unterstützt die Script-Sprache

• Standard-Delphi-Typen: boolean, byte, shortint, word, smallint, integer, cardinal, int64, pointer, single, double, string, record (char kann über byte oder über string gelöst werden)
• Variablen- und Typendeklarationen
• uses-deklarationen
• (natürlich) Kommentare im Script: //, (* *), { }
• procedures und functions mit Parametern (optional auch var-Parameter)
• direkter Aufruf von Delphi-Funktion aus dem Script heraus
• Aufruf von einzelnen Script-Funktionen aus dem Programm heraus
• try-finally und try-except Blöcke
• Byte-Code in Stream speichern und später Ausführen
• for, while und repeat-schleife
• if und case-Anweisung (case auch mit strings)
• Operatoren: and, or, xor, mod, shl, shr, not
• "Klassen" mit Vererbung (wird weiter unten genauer erleutert)
• Compiler-Anweisungen: {$IFDEF} {$IFNDEF} {$ELSE} {$DEFINE} {$UNDEF} {$INCLUDE} {$WARNINGS}
• Lesen und schreiben von Script-variablen aus dem Program heraus
• Code-Vervollständigung von SynEdit
• Call-Stack zur Fehlerfindung aufrufbar

Was wird noch nicht unterstützt
Hier mal eine kurze Liste mit Featuren, die ich noch plane einzubauen:

• 64-Bit-Typen (erledigt mit Version 0.98b) (extended und currency sind nicht geplant)
• arrays
• @ und ^ - Operator (da bin ich mir noch nicht sicher, ob die überhaupt gebraucht werden)
• set und set of - Typen (erledigt mit Version 0.99h)
• try-except und try-finally - Blöcke (kann noch etwas länger dauern) (erledigt mit Version 0.99d)
• einzelne Funktionen im Script aus dem Programm heraus aufrufen (bisher kann nur das komplette Script ausgeführt werden) (erledigt; Feature eingeführt mit Version 0.99b)
• Variablen umcasten (erledigt mit Version 0.99h)
• div-Operator (Divisionen funktionieren schon, aber bitte unter "Enschränkung" nochmal genauer nachlesen) (hat sich erledigt, da "/" jetzt ordentlich funktioniert; letzte Änderung: Version: 0.99a)
• Properties in den Script-Klassen erlauben

Sysygy "Klassen" vs Delphi Klassen ;-)
In der Script Engine ist es möglich, externe procedures und functions zu deklarieren. Um diese besser und übersichtlicher zusammenzubringen und den OOP-Gedanken nachzugehen hab ich mich dazu entschlossen, externe Methoden in Klassen zusammenfassen zu können. Dabei unterstützten diese "Pseudo"-Klassen auch Vererbung.
An einem Beispiel kann man das ganz gut erklären:
Nehmen wir an, ich habe in Delphi folgende Komponente, die ich in der Script-Sprache verfügbar machen will:

Delphi-Quellcode:

type
  TMyClass = class(TComponent)
  private
    FSomeThing : string;
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  
    function GetSomeThing: string;
  end;

Jetzt kann man in der Script-Sprache eine Pseudo-Klasse erstellen, mit deren Hilfe man auf diese Klasse zugreifen kann.
Script-Code

Delphi-Quellcode:

unit myClassUnit;

uses Classes; // für TComponent

type
  TMyClass = class(TComponent)
  public
    function Create(AOwner: TComponent): TMyClass;
    function GetSomeThing;
  end;

Diese Klasse speist man jetzt in einen Exporter, der daraus eine Delphi-Unit erstellt (ist mit dabei). Diese Delphi-Unit bindet man dann in das Delphi-Projekt ein - den Rest übernimmt die Script-Sprache. Ein Script könnte jetzt z.B. so aussehen:

Delphi-Quellcode:

program Test;

uses myClassUnit;

var p: TMyClass;
    s: string;
begin
  p := p.Create; // hier ist ein großer Unterschied zu Delphi
  
  s := p.GetSomeThing;
  if p.ComponentCount = 0 then // da die Klasse von TComponent abgeleitet ist
    exit;
end;

Die Klassen in der Script-Engine sind also sozusaggen nur eine Zusammenfassung von externen Methoden. Es können keine Variablen oder Script-Interne Methoden hinzugefügt werden. Das will ich aber noch ändern, jedoch dauert das eine ganze weile.

Bisherige Einschränkungen

• Man kann zwar schon Unterroutinen in Funktionen schreiben, jedoch kann man in jeder Routine nur auf die routineinternen Parameter, Variablen und auf die globalen Variablen zugreifen. Der Compiler spuckt eine Fehlermeldung aus, wenn man auf Variablen von "Parent"-Funktionen zugreifen will.
• Bisher gibt es den Operator div nicht. Alle Divisionen werden mit dem / ausgeführt. Ob das Ergebniss ein float oder ein Integer ist, hängt dann von den Parametern ab. Wenn man jetzt die Integerdivision 1000 / 3 macht, kommt der Integerwert 333 raus - 1000.0 / 3.0: float-Wert mit 333,33333 usw. (bitte nächsten Punkt auch beachten)
• Da intern sowie extern das Casten von integer auf float noch nicht möglich ist, gibt es eine Funktion "ToFloat(i: integer): single, die Integer-Variablen in eine Float-Variable umwandeln. Dass ist z.B. bei Divisionen mit Variablen, bei denen das Ergebniss ein float sein soll, praktisch. Das werd ich aber auf jeden fall noch ändern. (der Aufruf von "ToFloat" ist ab sofort obsolet)
• Variablennamen und Funktionsnamen können sich [noch] überschneiden, will heißen: man kann noch einer Funktion den gleichen Namen wie einer Variable geben. Beim Aufruf wird man aber immer nur die Funktion bekommen, egal wo die Variable deklariert ist.
• Ein Funktions/Variablen-Name darf nur einmal vorkommen (das ist nicht neu) - dabei werden die Funktionen der per uses eingebundenen Units mitgezählt (neu) - Man kann jede Funktion/Variable nur einmal definieren - aber nur innerhalb einer Unit. In mehrere Units können jetzt die gleichen Funktionsnamen/Variablen sein. Mann greift dann über UnitName.VariablenName drauf zu

So, genug der negativen Sachen :mrgreen:

Was muss ich zusätzlich noch an Komponenten installieren?
Die Script-Sprache an sich braucht keine zusätzlichen Komponenten - es werden nur die Klassen benutzt, die bereits bei Delphi mit dabei sind. Auch die mitgelieferten Demos (bis auf eine) kommen mit den Komponenten aus. Jedoch werden für die Kompilierung der Haupt-GUI zwei große Sachen benötigt:

• SynEdit für die Haupt-GUI und für die eine Demo (Code-Vervollständigung-Demo): http://synedit.sourceforge.net/
• JEDI-Component-Library (JVCL) für die Haupt-GUI: http://www.delphi-jedi.org/
• Da ich die TCoolBar und die TToolbar-Komponente in der Haupt-GUI verwende, ist die GUI unter Win95 wahrscheinlich nicht lauffähig (die Script-Engine an sich ist dadurch nicht betroffen). Für diese Komponenten wird die Datei COMCTL32.DLL in der Version 4.70 oder höher benötigt.

Wie installiere ich die Sysygy Script Engine?
Der Parser sowie der Interpretor sind Komponenten mit relativ wenig properties. Von daher ist eine Installation eigentlich nicht vorgesehen. Am besten, ihr kopiert die Quelltexte in einen beliebigen Ordner und fügt diesen in den Suchpfad von Delphi dazu. Ein fertiges Package wird jedoch nicht mitgeliefert.

Welche Delphi-Version muss ich haben?
Also garantieren kann ich für nichts. Ich hab die Script-Sprache mit Delphi 7 erstellt, von daher sollte alles, was neuer als D7 ist, damit klar kommt. Ich weiß nicht, wie weit runter man mit den Delphi-Versionen gehen kann. Jedoch sollte es schon möglich sein, Funktionen als overloaded zu deklarieren.

Sysygy Script Engine + FreePascal
Mit Version 0.99e hab ich es geschafft, die Script-Engine FreePascal-kompatibel zu machen. Ich habe (bis auf ein paar einzelne Scripts) nicht viel ausprobiert, aber es hat alles bisher geklappt. Da ja FPC auf sehr vielen Plattformen funktioniert, weiß ich nicht, ob wirklich alles unterstützt wird. x86-CPUs sollten ziemlich sicher funktionieren, bei x86-64Bit-Systemen weiß ich nicht, ob alles funktioniert.
Die die LCL ja nicht 100%ig kompatibel mit der VCL ist, sind einige Funktionen der Include-Dateien uSygInc*.pas nicht mit eingebunden. Zwar erscheinen diese Funktionen noch im Script, jedoch führt ein Aufruf zu einer Exception. Ich werde aber noch die neuen Includes {$IFDEF FPC} und {$IFDEF DELPHI} in die Header mit einbauen und somit die nicht verfügbaren Funktionen für das Script unsichtbar machen - jedoch dauert das noch etwas.
Bisher gibt es noch Probleme mit den Units uSygIncGraphics und uSygIncWinCRT, die anderen sollten aber funktionieren.

Wie benutze ich die Komponenten?
Ich habe ein paar Demoprogramme in den Download mit hinein gepackt, an denen man (hoffentlich) gut sehen kann, wie man die Komponenten am einfachsten benutzt. Hier ist aber mal der grundlegende Aufbau zur Benutzung

Delphi-Quellcode:

uses
  uSygParser,  // für TSygScript_Parser
  uSygRunTime; // für TSygScript_RunTime

var Compiler : TSygScript_Parser;   // das Objekt muss natürlich vorher erstellt werden
    Executor : TSygScript_RunTime;  // ... und das Objekt sollte auch vorher erstellt werden

function CompileAndExecute(ScriptSource: string): boolean;
begin
  // Ergebniss vorinitalisieren
  result := False;
  // Script kompilieren
  if Compiler.ParseScript(ScriptSource) then
  begin
    // ByteCode im Executor speichern
    Executor.FillData(Compiler.OutputData);
    // Script ausführen
    Executor.Run;
    result := True;
  end;
end;

Was ist in den Download dabei?

• Der komplette Source-Code der Script-Sprache
• 7 Demo-Programme, die die einzelnen Features und ihre Anwendung zeigen
• eine vorkompilierte Version der Haupt-GUI
• ein kleiner Massen-Datei-Umbenenner, der die Script-Engine für die neuen Dateinamen benutzt (als Anwendungsbeispiel)

Lizenz:
Das "Hauptprogramm" sowie die Komponente ist unter der BSD-Lizenz lizenziert. Der Lizenztext liegt ebenfalls nochmal im Hauptordner der zip-Datei sowie als Header in jeder .pas-Datei.
Falls jemand eine andere Lizenz haben will, bin ich gerne bereit, eine einzelne, personengebundene Lizenz nach Absprache zu erstellen.

Und nun ...
... wünsch ich viel Spaß beim ausprobieren ;-) und freu mich auf eure Meinungen.

Change-Log

Version: 0.99h (15.10.2008)

• Direkte Type-Casts sind jetzt möglich [z.B. Pointer(cardinal(25) + integer(GetPointer))]
• Enum-Types sind jetzt möglich [z.B. type TTest = (ttEins, ttZwei, ttDrei);]
• OnError-Event in Interpretor geändert: CallStack wird jetzt als Parameter übergeben. Das liegt daran, dass das OnError-Event bei try-finally und try-except Blöcken verzögert ausgegeben wird und dann die Abfrage von CallstackTrack im OnError-Event dann nicht mehr an der wahren OnError-Position ist.
• Kleines Problem mit cardinals behoben
• Problem mit - behoben: es musste immer ein Leerzeichen vor einem Minus sein, wenn eine Zahl angegeben wurde, sonst gab es eine Fehlermeldung
• Constanten können jetzt auch ein - haben
• Identifier-Expression verbessert/ausgebaut:
• TKlasse(Identifier).Funktion funktioniert jetzt
• Unitname.Variablenname sowie Unitname.Funktionsname funktioniert jetzt
• Es können jetzt mehrere Variablen/Funktionen den gleichen Namen haben - solange sie in verschiedenen Units deklariert sind. Über UnitName.Identifier kann dann auf die verschiedenen Variablen/Funktionen zugegriffen werden
• Fehler im not-Operator behoben: der Operator hatte die falsche Priorität
• Fehler in Operatoren "*/ mod and shr shl" behoben
• Fehler in Vergleichsoperatoren behoben: komplexere Vergleiche ohne genügend Klammern lieferten ein falsches Ergebniss
• Fehler in Vergleichsoperatoren behoben: grundlegende Vergleiche funktionierten zwar, jedoch konnte es passieren, dass das Negieren von Vergleichen nicht funktionierten
• RunTimerOnError-Event: Parameter verändert

Version: 0.99g (06.08.2008)

• Kleiner Fehler im Parser: int64-Typen wurden nicht zu int32-Typen umgewandelt, falls erforderlich
• Code-Completion-Display etwas verbessert
• Geschwindigkeit von TSygScript_RunTime.LoadFromStream extrem verbessert
• Memory-Leak im Parser behoben
• ein paar kleine Probleme mit Records behoben
• manche Variablen wurden bei verschachtelten Funktionen ungültig

Version: 0.99f (24.07.2008)

• Im Interpretor kann man jetzt mit Hilfe von Properties schnell Script-Variablen abrufen bzw. ändern
• Die Angabe der Unit beim Registrieren von Methoden bzw. beim Lesen von Variablen ist jetzt optional. Es kann auch einfach ein Leerstring übergeben werden - dann wird die erste Variable genommen, die den gesuchten Namen hat
• Das Script wurde beim Aufruf von Run nochmals intialsiert, obwohl "InitializeRun" bereits aufgerufen wurde
• Kompiliergeschwindigkeit verdoppelt. Das kompilieren von langen Scripts mit vielen uses-Units dauert jetzt nicht mehr so lange
• Fehler bei exit-Anweisung in verschachtelten try-finally-Blöcken behoben -> es wurde nur die letzte finally-Anweisung aufgerufen
• Die Continue-Anweisung funktioniert jetzt auch in while und repeat - Schleifen korrekt
• Kleiner Memory-Leak entfernt
• Kritischer Fehler im Parser und im Interpretor behoben: beim Aufruf von tieferen Unterlementen (z.B. Application.MainForm.Caption - Application.MainForm an sich funktionierte bereits) wurden Variablen im Script-Stack überschrieben.
• Schwerer Fehler mit der Script-String-List behoben. Bei bestimmten Unit-Konsterlationen wurden die falschen Strings im Script verwendet

Version: 0.99e (18.07.2008)

• ScriptEngine mit Lazarus kompilierbar :-)
• Zwei neue Script-Compiler-Defines: {$IFDEF FPC} wenn Lazarus/FPC benutzt wird und {$IFDEF DELPHI} wenn Delphi benutzt wird
• Einige Funktionen der VCL gibt es in der LCL nicht, daher sind diese auch nicht in der Script-Engine verfügbar. Die Klassen behinhalten zwar auch diese Funktionen, beim Aufruf wird aber eine Exception ausgelöst, wenn die entsprechende Funktion unter Lazarus nicht verfügbar ist.
• Der Aufruf von Script-Funktionen aus dem Programm heraus funktioniert jetzt auch, wenn das Script währenddessen schon läuft
• Die Parameter von TSygScript_Parser.FindFunction, TSygScript_Parser.Call abgeändert
• var-Parameter beim Aufruf von Script-Funktionen aus dem Programm heraus funktioniert jetzt. Dabei muss beim Aufruf einfach ein Pointer auf die Variable übergeben werden
• In der Unit WinCRT können jetzt Events registriert werden. Ein Demo-Script ("EventTestProgram.scs") für die Verwendung ist mit dabei
• Das Beispielscript "TimeInformation.scs" etwas überarbeitet

Version: 0.99d (16.07.2008)

• try-finally und try-except-Blöcke eingeführt
• Neue Funktion in der System-Unit: RaiseException(msg: string);
• Neue Funktion in der System-Unit: Assert(Condition: boolean; msg: string);
• Neues Beispiel-Script für das Hauptprogramm: "ClearTempData" (löscht alle, für ein Source-Release unrelevanten, Dateien, die von Delphi erstellt wurden)
• Resourcen-Schutz-Blöcke (try-finally) in die anderen Demo-Programme eingefügt
• Windows-uses aus den Units entfernt, die die "Windows.pas" nicht benutzen. Falls die Windows.pas benutzt werden muss, wird diese per {$IFDEF WIN32} eingebunden
• CopyMemory ersetzt durch "System.Move"
• Alte Debug-Anweisungen im Parser gelöscht
• Fehlermeldungen des Compilers in const-strings ausgelagert und etwas überarbeitet

Version: 0.99c (12.07.2008)

• Kleiner Fehler im Parser und im Interpretor behoben: LoadFromStream/SaveToStream hat eine Untermethode aufgerufen, die fehlerhaften Code drinnen hatte
• Demo 4: Quelltext der Demo war noch nicht auf die neuen UnitNamen aus Version 0.99b umgestellt

Version: 0.99b (10.07.2008)

• In dieser Version haben sich einige externen Sachen (z.B. Funktionsnamen, Unitnamen, ...) geändert! Daher ist ein Update auf diese Version mit etwas Aufwand verbunden! Natürlich versuche ich solche groben Änderungen nicht zu machen; doch machmal hab ich keine andere Wahl.
• Hauptprogramm: Toolbar eingebaut
• Sinnvollere Unit-Namen vergeben
• Einige Komponenten und Funktionen umbenannt
• Aufbau vom Interpretor etwas verändert
• Fehler im Interpretor im Operator disc behoben
• Einzelne Script-Funktionen jetzt aufrufbar
• Fehler bei Doubles in Records behoben
• Größe des ByteCode-Streams verringert
• Fehler in Records behoben: beim Aufruf von externen Funktionen, die ein Record mit einer String-Variable als Parameter hatten, wurde zu wenig Speicherplatz benutzt und es gab eine Exception
• Fehler in Records behoben: beim Aufruf von externen Funktionen, die ein Record mit einer Single-Variable als Parameter hatten, wurde zu viel Speicherplatz benutzt und die Daten wurden ungültig
• Code-Completion setzt die Property "GenerateCode" jetzt automatisch wieder zurück
• Es gibt jetzt eine overloaded-procedure von ParseScript, bei der man den Script-Quelltext als Parameter mitliefern kann
• TPoint und TRect in die Unit "System" verschoben
• drei neue Script-Unit hinzugefügt: Forms, Menus, StdCtrls (weitere werden noch folgen)
• Fehler in der uses-Deklaration behoben: identifiers aus weiteren uses-Units wurden nicht gefunden
• Neue Demo hinzugefügt: Diese Demo zeigt, wie man einzelne Script-Funktionen aus dem Programm heraus aufruft
• Neue overloaded-function im Interpretor: CallStackTrace kann jetzt auch ohne StringList ausgeführt werden. Der Inhalt der StringList (inc. Zeilenumbrüche) wird dann als Strings-Result-Wert zurückgegeben

Version: 0.99a (03.07.2008)

• Code-Minimierung eingeführt: die Code-Minimierung reduziert den erstellen Byte-Code, in dem er unbenutzte Stellen löscht
• Call-Stack jetzt erstellbar (zum Debuggen)
• Kleiner Fehler im RunTime-Stack behoben (Ausführung wurde nicht beeinträchtigt)
• Hauptprogramm: Export-Funktion durch Ausnutzung von neuen Features sehr viel schneller gemacht
• Hauptprogramm: InstructionList-Viewer erweitert
• Neue Script-Demo für das Hauptprogramm: TimeInformation.scs
• Kleiner Fehler in der Code-Completion behoben
• Konstanten werden nicht mehr im Stack gespeichert
• Doppelte Einträge in der Runtime-StringList werden jetzt vermieden
• kleiner Fehler im automatischen Type-Cast behoben: integer -> float wurde zu spät ausgeführt -> starke Rundungsfehler
• ehemalige Debug-NOOPs im Code entfernt

Version: 0.99 (23.06.2008)

• kleiner Operator-Fehler im Interpretor beseitigt
• ToFloat ist jetzt endlich obsolet
• Return-Address-Typ geändert (ist für einen Stack-Trace wichtig, den ich später einbauen werde)
• Neues Demoprogramm: ein Massen-Datei-Umbenenner, der den neuen Dateinamen anhand eines Scripts erstellt
• Neue Funktion: "InitializeRun" in "TSygScript_RunTime": muss aufgerufen werden, wenn das Script mehrmals verwendet werden soll, ohne dass der ByteCode neu geladen werden soll (die Verwendung wird im neuen Demo-Programm gezeigt)
• Formatierung in der Code-Completion verändert
• kleinerer Download da die Demos nun nicht mehr vorkompiliert sind
• ein paar kleine Bugs behoben

Version: 0.98b (18.06.2008)

• 64-Bit-Typen hinzugefügt (int64, double)
• TDateTime auf double geändert
• Neue Funktionen in SysUtils: DiscSpace, DiscFree, FileSize
• Viele Funktionen auf int64 bzw double geändert
• Automatisches casten zwischen den Variablen (ToFloat sollte immer noch verwendet werden)
• Viele Bugs beim Ausführen von Delphi-Methoden behoben (viele waren mit single-Typen)
• GetVariable und SetVariable im Interpretor können nun auch mit double/int64 umgehen
• extended aus der Typendeklaration entfert (sorgt sonst nur für Verwirrung)
• rtlVclOptimize herausgenommen
• Geschwindigkeit des Stacks erhöht
• fehlende Funktion im Release-Paket hinzugefügt (hat anscheindend noch niemand gemerkt)

Version: 0.98a (13.06.2008)

• Initial release

[Matze]

Hallo,

ich habe nur den Screenshot angesehen und frage mich, wozu du IsValidDate geschrieben hast. Du nutzt die Funktion DaysInMonth aus der DateUtils.pas nehme ich an. Dort befindet sich jedoch ebenso die Funktion IsValidDate (dort ist "dein" Code auf wenige Zeilen reduziert). Wozu also doppelt implementieren? :gruebel:
Und "exit" zu nutzen ist nicht die saubere Art, das geht normalerweise auch anders.

Grüße

[littleDave]

Zitat:

Zitat von Matze

ich habe nur den Screenshot angesehen und frage mich, wozu du IsValidDate geschrieben hast. Du nutzt die Funktion DaysInMonth aus der DateUtils.pas nehme ich an. Dort befindet sich jedoch ebenso die Funktion IsValidDate (dort ist "dein" Code auf wenige Zeilen reduziert). Wozu also doppelt implementieren? :gruebel:

Dieses Script kenn die Unit DateUtils.pas nicht. Von daher ist die Methode IsValidDate nicht doppelt deklariert. DaysInMonth ist auch weiter oben deklariert.

Zitat:

Zitat von Matze

Und "exit" zu nutzen ist nicht die saubere Art, das geht normalerweise auch anders.

Das war nur zum testen der "exit"-Funktion da. Es ist ja auch nur ein Beispiel-Script ;-)

[Matze]

Achso, das war ein Beispiel deines Editors. Ich dachte irgendwie, das sei ein Code-Auszug deines Projekts. :oops:
Ich hätte doch in den Source gucken sollen. *g*

[mimi]

nicht schlecht. Ich hoffe du bekommst die Script-Engine fertig.
Evlt. teste ich sie mal in Lazarus ob sie da auch läuft.

Du sagst du nutzt nur Delphi Standard Funktionen ?
Dann sollte es eigentlich keine größeren Probleme geben. Mal sehen.

[littleDave]

Zitat:

Zitat von mimi

nicht schlecht. Ich hoffe du bekommst die Script-Engine fertig.

Danke erstmal für dein Feedback :-)

Mal schauen wie lange ich noch für die Fertigstellung brauche. Die 64-Bit-Typen sollten nicht so das Problem darstellen. Auch die Set und die Set of Typen dürfen nicht so lange dauern. Die Try-Finally und die Try-Except-Blöcke werden aber wahrscheinlich noch etwas dauern, da ich noch nicht genau weiß, wie ich das genau anstellen soll - nicht vom Parser her, sondern eher Byte-Code vom Interpretor. Da muss ich mal schauen, wie ich das am besten löse.

Zitat:

Zitat von mimi

Evlt. teste ich sie mal in Lazarus ob sie da auch läuft.

Du sagst du nutzt nur Delphi Standard Funktionen ?
Dann sollte es eigentlich keine größeren Probleme geben. Mal sehen.

Das wäre sehr nett, wenn du das mal ausprobieren könntest.

[MSSSSM]

ich finde die rtlvclOptimize nicht...

kA

mfg

BibPfad von SynEdit hinzugefügt

[toms]

Zitat:

Zitat von MSSSSM

ich finde die rtlvclOptimize nicht...

rtlvclOptimize

[alzaimar]

Als Vorlage bzw. zum drüberschauen: DWS (Delphi Web Script) Ein Delphi-Interpreter, der den kompletten Sprachumfang von Delphi(7) unterstützt.

[littleDave]

Zitat:

Zitat von MSSSSM

ich finde die rtlvclOptimize nicht...

:oops: die hab ich nur zu Testzwecken noch drinnen gehabt. Ist im neunen Release nicht mehr drinnen.

Zitat:

Zitat von alzaimar

Als Vorlage bzw. zum drüberschauen: DWS (Delphi Web Script) Ein Delphi-Interpreter, der den kompletten Sprachumfang von Delphi(7) unterstützt.

Hab ich mir mal runtergeladen und schaut nicht schlecht aus. Mal schauen ob ich mir das ein oder andere abschauen kann ;-). Mir ist klar, dass es sehr gute Script-Sprachen gibt, ich hab meine hauptsächlich deswegen gemacht, weil mich das Thema sehr interessiert hat und weil ich durch das Projekt (bzw. Teilprojekt) sehr viel lernen konnte. Aber danke für den Hinweis :thumb:. Zwar ist diese Komponente komplett anders aufgebaut (kompiliert die eigentlich in Byte-Code oder führt die Komponente den Source im Immediate-Mode aus (hab noch nicht so genau reingeschaut)?

@All:
Ich hab eine neue Version hochgeladen. Es sind einige Bugsfixes und die ersten Neuerungen drinnen (int64 und double sind jetzt vorhanden). Den kompletten Change-Log sowie den Download gibts im ersten Post.

Grüße

[littleDave]

Schade, dass das hier langsam zum Monolog wird :( (mag mich keiner :shock: oder ist die Komponente total für den Popo :glaskugel:)
Aber ich lass mich dadurch nicht abhalten und hab ne neue Version hochgeladen. Den Change-Log sowie den Download gibts wie immer im ersten Post.

Grüße
Dave

[Neutral General]

Hi,

Also ich bin schon recht interessiert an deiner Komponente. Vorallem wegen:

Zitat:

Byte-Code in Stream speichern und später Ausführen

In meinem aktuellen Projekt werde ich nämlich eine Scriptsprache brauchen ;)
Hatte mir mal Pascalscript angeschaut, aber der bietet oben genanntes Feature meines Wissens nicht und ich denke ich würde sogar deine benutzen, WENN sie Properties unterstützen würde.

Diese Get- und Set-Methoden sind mir da etwas zu lästig.

Wobei ich sage muss, dass ich mir bisher nur die Beispiele angeschaut habe und noch nicht selbst was ausprobiert habe.

Gruß
Neutral General

[littleDave]

Zitat:

Zitat von Neutral General

Zitat:

Byte-Code in Stream speichern und später Ausführen

In meinem aktuellen Projekt werde ich nämlich eine Scriptsprache brauchen ;)
Hatte mir mal Pascalscript angeschaut, aber der bietet oben genanntes Feature meines Wissens nicht [...]

Doch, das kann sie:

Torry.net Component Description

Compilation to a file for later use

Ich hätte diese Komponente wahrscheinlich auch für meine Engine genommen, doch mir war 1. die Einbindung nicht einfach genug und 2. wollt ich soviel wie möglich selbst machen. Daher ist meine Komponente überhaupt erst entstanden. Außerdem hab ich versucht, die Einbindung nicht zu schwer zu machen - es reichen eigentlich 6 5 Zeilen Quelltext:

Delphi-Quellcode:

if Compiler.ParseScript(Memo1.Text) then 
begin 
  Executor.FillData(Compiler.OutputData); 
  Executor.Run;
end;

Durch den eingebauten Unit-Manager muss man sich nicht mal mehr um externe Methoden kümmern, das wird alles automatisch im Hintergrund gemacht.

Zitat:

Zitat von Neutral General

und ich denke ich würde sogar deine benutzen, WENN sie Properties unterstützen würde. Diese Get- und Set-Methoden sind mir da etwas zu lästig.

:) Da werd ich mir mal Properties vornehmen müssen, oder? Wobei ich den Mehraufwand als sehr gering einschätzen würde. Nehmen wir an, du willst folgende Klasse im Script zur verfügung stellen:

Delphi-Quellcode:

type
  TMyObject = class(TObject)
  private 
    FData : string;
  protected
    procedure SetData;
  public
    property Data: string read FData write SetData;
  end;

Dann würde ein Import-Script folgendermaßen ausschauen:

Delphi-Quellcode:

type
  TMyObject = class(TObject)
  public
    function  Data: string;
    procedure SetData(value: string);
  end;

Aber ich schau, dass ich auch properties in die Importer-Klassen im Script einbaue.

[Edit]An aktuelle Gegebenheiten etwas angepasst[/Edit]

[Neutral General]

Hi,

Ja es geht mir nicht so sehr um den Aufwand, aber ich fände es lästig im Scriptcode dann immer die Get/Set-Methoden aufrufen zu müssen. Da ist

Property := Value;
Value := Property;

um einiges gemütlicher als

SetProperty(Value);
Value := GetProperty;

Würde mich freuen, wenn dus einbauen würdest :)

Gruß
Neutral General

[littleDave]

Ok, habs gerade auf meine ToDo-Liste gesetzt. Mal schauen, ob ich es noch diese Woche schaffe. In 4 Wochen sind Uni-Prüfungen, von daher hab ich im Moment nicht mehr so viel Zeit. Aber zwischendurch muss ich mich auch mal ablenken bzw. meinen Kopf lüften - da bietet sich Delphi natürlich super für an ;-)

[mimi]

schaut euch doch mal das hier an:
http://www.delphigl.com/forum/viewtopic.php?t=7570
was haltet ihr davon ?

[littleDave]

Es gibt mal wieder eine neue Version der Komponente. Ich hab zwar nicht allzuviel an der Komponente arbeiten können, aber ein wenig ging schon. Der komplette Change-Log sowie der Download ist wie immer im 1. Post.
@Neutral General:
Leider haben es die Properties nicht nicht in dieses Release geschafft. Ich weiß nicht, wie lange es insgesammt noch dauert, bis ich die fertig habe. Ich bin mir noch nicht ganz einig darüber, wie ich die von der Deklaration her in das Script einbauen soll. Top-Priorität ist für mich im Moment, dass man einzelne Funktionen des Scripts aus dem Programm heraus aufrufen kann. Dafür hab ich jetzt mit den Debug-Informationen einen Grundstein gesetzt, doch fertig ist das ganze noch nicht. Sobald das dann funktioniert, kommen die Properties - versprochen.

[Neutral General]

Alles klar, es eilt zur Zeit auch nicht, lass dir ruhig Zeit ;)

[Benedikt]

Hallo,

also ich habs grad mal nur kurz getestet, weil ich seit einiger Zeit überlege, in einem Projekt von mir die Möglichkeit zu geben, mit PascalScript Scripting-Möglichkeiten für die Nutzer zu gewähren. Momentan realisiere ich dass über ActiveScript mit JS und VB, aber erstens wäre mir ein Pascal-Dialekt viel lieber und zweitens wäre eine solche Lösung unabhängig von den Gegegebenheiten.
Aber jetzt hab ich grad mal deine Komponente ausprobiert, und sie gefällt mir richtig gut und ist ja wirklich super simpel. Also wenn ich mich dazu entschließe, dann werd ichs mal damit ausprobieren und dann nochmal Feedback geben ;)

MfG Benedikt

[littleDave]

Zitat:

Zitat von Benedikt

Aber jetzt hab ich grad mal deine Komponente ausprobiert, und sie gefällt mir richtig gut und ist ja wirklich super simpel.

Danke, das freut mich :D. Es gibt zwei Punkte, die ich gerne von die wissen würde:
1.: hast du bereits selbst Scripts erstellt und wenn ja, sind dir irgendwelche Probleme/Bugs aufgefallen?
2.: wenn du die demos angeschaut hast: findest du die Erklärungen im Quelltext ausreichend/schlecht/gut usw? Sind die Beispiele gut/schlecht einfache/schwer ...? Gerade das ist für mich extrem wichtig. Der Einstieg sollte so schnell und einfach wie möglich sein. Es wäre sehr nett von dir, wenn du mir kurz beschreiben würdest, ob und wie gut du Beispiele gefunden hast.

Zitat:

Zitat von Benedikt

Also wenn ich mich dazu entschließe, dann werd ichs mal damit ausprobieren und dann nochmal Feedback geben ;)

Das ist sehr schön! Bug-Reports sind bei einer solchen Komponente extrem wichtig, da ich ja nicht alles Testen kann - die Möglichkeiten einer ScriptEngine sind ja groß, dass man als einzelner nicht alles Testen kann.

Grüße
Dave

[littleDave]

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

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

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

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

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

Grüße
Dave

[alzaimar]

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

Delphi-Quellcode:

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

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

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

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

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

Tolle Arbeit! :thumb:

[rotfc]

Zitat:

Zitat von alzaimar

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

Delphi-Quellcode:

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

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

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

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

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

Tolle Arbeit! :thumb:

Moin littleDave,

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

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

Null Ahnung warum ich hier gerade was eintippe!

[littleDave]

Zitat:

Zitat von alzaimar

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

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

Zitat:

Zitat von alzaimar

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

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

Zitat:

Zitat von alzaimar

Der Funktionsaufruf mit Parametern geht sehr einfach:

Delphi-Quellcode:

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

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

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

Delphi-Quellcode:

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

Zitat:

Zitat von alzaimar

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

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

Zitat:

Zitat von alzaimar

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

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

Zitat:

Zitat von alzaimar

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

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

Zitat:

Zitat von rotfc

Moin littleDave,

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

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

Null Ahnung warum ich hier gerade was eintippe!

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

[alzaimar]

Zitat:

Zitat von littleDave

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

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

[littleDave]

Zitat:

Zitat von alzaimar

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

Ahhh, ok - erklärt alles :stupid:

[mimi]

Zitat:

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

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

[littleDave]

Zitat:

Zitat von mimi

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

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

Zitat:

Zitat von mimi

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

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

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

[mimi]

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

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

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

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

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

[littleDave]

Zitat:

Zitat von mimi

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

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

Zitat:

Zitat von mimi

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

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

Zitat:

Zitat von mimi

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

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

Zitat:

Zitat von mimi

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

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

[mimi]

So, wie versprochen habe ich es versucht unter Lazarus zum laufen zu bringen, was leider nicht geht,
weil die LCL anscheind kein CopyMemory kennt.

Ich habe es unter Linux versucht.
Was genau macht diese Methode ? kann man die auch noch anders Schreiben ?
weil MoveMemory wird auch nicht gefunden.
SygScript_Runtime_unit
in dieser Unit traten die Fehler auf.
Es währe außerdem noch schön, wenn du von vornerein die Windows unit nur mit Komplier schalter einbinden könntest.
die musste ich in allen Units rauß nehmen.

Evlt. gibt es ja noch eine andere Lösung für das Problem, ich habe ein neues Projekt angefangen, und mir ein Beispiel von dir angeschaut und folgende unit hinzugefügt:

Delphi-Quellcode:

uses
  Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs,
  SygScript_Constants_unit, SygScript_Parser_unit, SygScript_Runtime_unit;
  ;

brauche ich wirklich alle ?

[littleDave]

Zitat:

Zitat von mimi

So, wie versprochen habe ich es versucht unter Lazarus zum laufen zu bringen, was leider nicht geht,
weil die LCL anscheind kein CopyMemory kennt.

Ich habe es unter Linux versucht.
Was genau macht diese Methode ? kann man die auch noch anders Schreiben ?
weil MoveMemory wird auch nicht gefunden.
SygScript_Runtime_unit
in dieser Unit traten die Fehler auf.
Es währe außerdem noch schön, wenn du von vornerein die Windows unit nur mit Komplier schalter einbinden könntest.
die musste ich in allen Units rauß nehmen.

Ich werd mir in absehbarer Zeit mal Lazarus installieren und versuchen, das Problem zu beheben.

Zitat:

Zitat von mimi

Evlt. gibt es ja noch eine andere Lösung für das Problem, ich habe ein neues Projekt angefangen, und mir ein Beispiel von dir angeschaut und folgende unit hinzugefügt:

Delphi-Quellcode:

uses
  Classes, SysUtils, LResources, Forms, Controls, Graphics, Dialogs,
  SygScript_Constants_unit, SygScript_Parser_unit, SygScript_Runtime_unit;
  ;

brauche ich wirklich alle ?

Also anhand der Unit-Namen merk ich schon, dass du noch ein altes Package hast. In der neusten Version heißen die Unitnamen anders (würde dann so aussehen: uSygConstants, uSygParser, uSygRunTime).

Also wenn du nur kompilieren willst, brauchst du nur die uSygParser. Fürs Ausführen brauchst du nur die uSygRunTime. Wenn du dann noch die bereits konvertierten Units auch zur Verfügung stellen willst, musst du die auch noch einbinden.

Hier ist mal das einfachste Beispiel:

Delphi-Quellcode:

uses
  uSygParser,  // für TSygScript_Parser
  uSygRunTime; // für TSygScript_RunTime

var Compiler : TSygScript_Parser;   // das Objekt muss natürlich vorher erstellt werden
    Executor : TSygScript_RunTime;  // ... und das Objekt sollte auch vorher erstellt werden

function CompileAndExecute(ScriptSource: string): boolean;
begin
  // Ergebniss vorinitalisieren
  result := False;
  // Script kompilieren
  if Compiler.ParseScript(ScriptSource) then
  begin
    // ByteCode im Executor speichern
    Executor.FillData(Compiler.OutputData);
    // Script ausführen
    Executor.Run;
    result := True;
  end;
end;

[mimi]

leider lässt sich uSygRunTim halt nicht kompelieren.
Ich denke CopyMemory müsste als eigene Funktion geben.
Lazarus unter Windows zu Installieren ist ein Kinderspiel inzwischen auch unter Linux.... Allerdings unter Linux nur die 0.9.24 die "svn" Version musst du per Hand Kompilieren.

Ich könnte mir auch vorstellen bei meinem GamePack deine Scrip Sprache zu verwenden.
Z.B. das jeder ganz einfach 2D Spiele schreibe kann ohne Delphi oder Lazarus *G*.

Vorrausgesetzt das es damit geht... nochmal zu klassen: in wie weit werden sie unterstütz ?
das währe für mein GamePack eine Voraussetzung. z.b. erben und Methoden und Eigenschaften und Events und sowas...
Die Idee währe aber gar nicht mal so schlecht....

[extrem]

Bei mir lief die Demo 2 manchmal instabil.
Spätestens wenn ich 3X Ctrl+F9 und dann F9 gedrückt habe, gab es die Fehlermeldung:

Project Project1.exe raised exception class EAccessViolation with message 'Access violation at address 00404448 in module 'PROJECT1.EXE'. Read of address 00C1C654'. Process stopped. Use Step or Run to continue. :roll:

[littleDave]

Zitat:

Zitat von mimi

leider lässt sich uSygRunTim halt nicht kompelieren.
Ich denke CopyMemory müsste als eigene Funktion geben.
Lazarus unter Windows zu Installieren ist ein Kinderspiel inzwischen auch unter Linux.... Allerdings unter Linux nur die 0.9.24 die "svn" Version musst du per Hand Kompilieren.

Ich hab vor ca. 1 Jahr mal ein kleines Programm in meinem damaligen Praktikum mit Lazarus erstellt - daher kenn ich das schon etwas. Nur ich installier nicht immer gerne alles sofort, bin da mittlerweile etwas vorsichtier. Außerdem fehlt mir im Moment etwas die Zeit dazu.

Zitat:

Zitat von mimi

Vorrausgesetzt das es damit geht... nochmal zu klassen: in wie weit werden sie unterstütz ? das währe für mein GamePack eine Voraussetzung. z.b. erben und Methoden und Eigenschaften und Events und sowas...
Die Idee währe aber gar nicht mal so schlecht....

Also 99% der Klassen können mit der Script-Wrapper-Methode importiert werden. Das Erben von Methoden und Eigenschaften funktioniert dank dem OOP-Design automatisch.

Was ich aber noch nicht funktioniert sind Events. Was du wahrscheinlich willst ist, einem Klassenevent im Script eine Scriptfunktion zuzuweisen - das funktioniert noch nicht. Ich hab leider auch noch keine genaue Idee, wie ich das genau realisieren kann. Aber bisher ist das noch nicht möglich.

Zitat:

Zitat von extrem

Bei mir lief die Demo 2 manchmal instabil.
Spätestens wenn ich 3X Ctrl+F9 und dann F9 gedrückt habe, gab es die Fehlermeldung:

Project Project1.exe raised exception class EAccessViolation with message 'Access violation at address 00404448 in module 'PROJECT1.EXE'. Read of address 00C1C654'. Process stopped. Use Step or Run to continue. :roll:

Danke für den Hinweis. Ich werds mir morgen mal in Ruhe anschauen, was dann genau schief geht. Vielen dank für den Hinweis :thumb:

[littleDave]

Ich hab den Fehler, den mir extrem hier genannt hat gefunden und behoben. Im neuen Release (Version 0.99c) ist der Fehler nicht mehr drinnen. Download der neuen Version und den ChangeLog (diesmal wieder etwas kürzer :zwinker:) gibts im ersten Post.

Grüße

[rotfc]

Zitat:

Zitat von littleDave

Zitat:

Zitat von alzaimar

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

Ahhh, ok - erklärt alles :stupid:

Sorry, littleDave und alzaimar für mein #23 :oops:

Vielen Dank an alzaimar für sein beruhigendes #25!

(*
Trotzdem @alzaimar:
"Schaun mer mal, dann seh' ma scho'."?
Besser:
"Schaun mer mal, dann seh(n)'mer scho'.

Das erste "wir" = "mer" sollte zum zweiten "wir" = "ma" (bei Dir) passen, oller Preusse ;-)

LG
Roland
*)

[extrem]

Da es ein eindeutiges Schuldeingeständnis war, musste ich leider diesen Vorfall den zuständigen Behörden melden. :stupid:

[rotfc]

Olle Petze!

[littleDave]

So, um mal wieder vom OT wegzukommen :zwinker:, hab ich mal wieder eine neue Version hochgeladen.

Diesmal gibt es wieder eine sehr wichtige Erweiterung: try-finally und try-except - Blöcke. Dies Blöcke können natürlich auch verschachtelt werden, klar ;-). Was jedoch nicht unterstützt wird ist die on e:[ExceptionTyp] do - Anweisung im except-Teil. Exception-Klassen beherrscht die Script-Sprache nicht. Aber ich schau, dass ich das auch noch einbaue.

Außerdem arbeite ich im Moment daran, die ScriptEngine auch FPC-kompatibel zu machen. Ich hab zwar FPC [noch] nicht installiert, aber das kommt noch. Was ich jetzt aber schon mal gemacht habe: ich habe die "uses Windows" - Deklaration aus dem Quelltext verbannt. Falls jedoch die Unit Windows benutzt werden muss, hab ich sie mit {$IFDEF WIN32} eingebunden.
Außerdem hab ich die Funktion "CopyMemory" aus der "uSygRunTime" durch die Pascal-Funktion "Move" ersetzt. Ich weiß jetzt zwar nicht, ob "Move" in FPC bereits unterstützt wird, jedoch ist dies wahrscheinlicher als dass die Windows-Funktion "CopyMemory" unterstützt wird ;-)

Und jetzt mal was ganz besonderes: ich hab seit dem letzten Release kein Bug mehr gefunden :shock: - hoffentlich bleibt das so (also das mit "kein Bug vorhanden sein" natürlich, nicht das "keinen Bug finden" ;-))

Den Download gibt (wie immer) im ersten Post

Grüße
Dave