Sysygy Script Engine - Version 0.99h

[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 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 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.

[littleDave]

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 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 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.

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

[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 ) gibts im ersten Post.

Grüße

[rotfc]

Zitat von littleDave:

Zitat von alzaimar:

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

Ahhh, ok - erklärt alles

Sorry, littleDave und alzaimar für mein #23

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.

[rotfc]

Olle Petze!

[littleDave]

So, um mal wieder vom OT wegzukommen , 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 - 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