ScriptEngine II (v. 0.6.1)

[littleDave]

Oh, ich habe irgendwie den letzten Post übersehen :oops:

Zitat:

Zitat von mleyen (Beitrag 1039924)

Ist es ein großer Aufwand den Typ Char einzubaun? Denn so muss man in jedem Script einen string auf len(1) prüfen.

Ist schon leider etwas Aufwand. Denn es gibt einige Stellen, die für neue Typen angepasst werden müssen. Ich muss mal schauen, wie ich das am besten hin bekomme

Zitat:

Zitat von mleyen (Beitrag 1039924)

Der kompilierte Script-binärstream wächst mit größeren Scripts schnell an. Da lässt sich aber aufgrund der vielen Nullen schnell mal 1MB auf 40KB komprimieren. Kann man an der Größe irgendwas drehen, ohne die Runtimeperformance einzuschränken?

Ja, das Script-File kann sehr groß werden, 1MB habe ich jedoch noch nicht geschafft. Man könnte vielleicht noch das ein oder andere Byte herausholen, jedoch wirkt sich das sehr negativ beim Laden des Scriptes aus. Das Auslesen des Binary-Files ist übriges streaming-fähig, es wird kein .Seek, .Size oder .Position benutzt. Daher kann man auch sehr schnell und ohne Probleme ein zLibStream beim Speichern und Laden übergeben.

Zitat:

Zitat von mleyen (Beitrag 1039924)

Könntest du evtl den Uses-Cleaner von CNPack vor Releases drüberlaufen lassen?

Die Uses-Liste ist manuell gemacht und sollte eigentlich passen. Deswegen noch das CNPack-Installieren will ich eigentlich nicht.

Zitat:

Zitat von mleyen (Beitrag 1039924)

E: Achja bei der IDE wäre ein Parameter, um ein Script direkt zu laden, praktisch.

Es kommt bald noch viel besser. Ich bastel mir gerade eine eigene RunTime-Library zusammen. Damit kann man dann aus dem Script eine .exe machen, wobei natürlich nur der kompilierte ByteCode an die Echse angehängt wird. Ich habe als Test bereits eine komplette Forms-Anwendung, Multi-Threaded mit einer IdHTTP-Komponente drinnen. Die Exe ist ganze 31 kb groß (ok, die RunTime hat noch 3 MB, aber die wird ja nur einmal pro Rechner gebraucht ;-).

@All: Neue Version :arrow: Version 0.5.3.1

Eine kleine Bugfix - Version

• Neuerungen
  • Der Typ "System.TObject" hat jetzt eine neue virtuelle Methode: ".ToString"
  • "System.Console.WriteLine" hat jetzt einen neuen Parametertyp: TObject (ruft die ".ToString" - Methode auf)
• Änderungen
  • Class-Var-Deklaration gilt jetzt nur noch für die erste Variable
  • System.Diagnostics.TStopwatch erweitert
  • Man kann jetzt nur noch den Constructor von externen Klassen aufrufen, wenn dieser deklariert wurde
• Bug-Fixes
  • Unit-Cache-Bug mit Records behoben
  • Set-Of-Typen hatten manchmal keine interne Größe, wodurch man sie nicht als Variable in Records oder Klassen hinzufügen konnte
  • Exception-Handling innerhalb von Case-Statements funktionierte wegen einem Compiler-Bug nicht
  • Der Aufruf von Script-Methoden über das Native-Interface (TMethod-Cast) funktionierte nicht mit var-Parametern

Download-Link ist im ersten Post.

Grüße

[littleDave]

Neue Version :arrow: Version 0.5.3.2

Eine kleine Bugfix - Version

• Bug-Fixes
  • Ein kleiner Compiler-Fehler, wenn innerhalb eine Schleife in einem case-Statement break oder continue aufgerufen wurde

Download-Link ist im ersten Post.

Grüße

[WladiD]

Hi littleDave,

nachdem ich soeben den Daumen bei sourceforge gehoben habe, wollte ich meinen Lob auch an dieser Stelle ausschreiben:

Die ScriptEngine II ist ein beachtliches One-Man-Project. Konsistent, sauber und schnell. Respekt! :thumb:

Da du es selbst verwendest (z.B. in Gael), bin ich guter Dinge, dass du sie nicht so schnell fallen lässt und wir uns über stete Weiterentwicklung freuen dürfen.

Diesen Thread verfolge ich schon seit längerem, hatte aber bisher keine Verwendung dafür. Doch das hat sich vor ein paar Tagen geändert.

Für mein AnyiQuack-Projekt (ehemals AccessQuery) habe ich eine Easing-Suite geschrieben, in der ich alle Easing-Funktionen validiere. Da es doch etwas mühselig war, nach jeder Änderung an der jeweiligen Funktion das Projekt zu kompilieren, habe ich nun deine Script-Engine drin. Jetzt kann ich ruck-zuck Änderungen an den Ease-Functions vornehmen und den Code quasi 1:1 in das Projekt übernehmen, wenn es passt.

Falls es dich interessiert, hänge ich einen Screenshot Anhang 32129 und die Anhang 32130 an. Die kompletten Source-Codes sind bei Sourceforge drin (Link siehe oben).

Als eine mögliche Erweiterung für die Zukunft würde ich mir die Unterstützung von anonymen Methoden wünschen. Dass die Umsetzung dieses Features etwas heikel ist, ist mir durchaus bewusst.

Weiter so und mfg

[littleDave]

Hallo WladiD

sorry für die späte Antwort - ging bei mir leider nicht früher :-(

Danke natürlich für das Lob :-) das freut mich wirklich. Ich bin auch guter Dinge, dass die SEII nicht so schnell aufgeben werde ;-). Dein Projekt schaut auch nicht schlecht aus. Ich habe mir das auch mal angeschaut und habe manchmal auch Verwendung für einen Funktionszeichner - und dieser reicht mir bisher wirklich vollkommen aus :thumb:. Das i-Tüpfelchen wäre für deine Sandbox noch die Code-Completion. Denn Quelltext kannst du dir in der IDE in der Unit uFormCodeEditor in der Klasse "TCodeEditor" abschauen. Aber wie gesagt - ich finde es jetzt schon sehr gut.

Zitat:

Zitat von WladiD (Beitrag 1050239)

Als eine mögliche Erweiterung für die Zukunft würde ich mir die Unterstützung von anonymen Methoden wünschen. Dass die Umsetzung dieses Features etwas heikel ist, ist mir durchaus bewusst.

Es gibt noch einige offene Punkte, aber ich werde die anonymen Methoden [leider relativ weit hinten] in meine ToDo-Liste aufnehmen.

@All: Neue Version :arrow: Version 0.5.3.3

Auf Grund von ein paar von mir bisher nicht beachteten Problemen bei partiellen Klassen, musste ich diese leider etwas beschränken. Das liegt nicht daran, dass ich das nicht will, sondern weil es so wie bisher nicht funktioniert hat. Sobald das Problem behoben ist, werde ich die partiellen Klassen wieder so wie im Moment benutzbar machen.

• Neuerungen
  • Properties können nun auf Variablen von Parent-Klassen verweisen
  • Neue Klasse in System: "System.TMultiCastEvent": mit dieser Klasse kann man mehrere Subscriber an ein Event binden
• Änderungen
  • Linker-Performance verbessert
  • Unit-Cache-Performance verbessert
  • RunTime-Comparison-Code verringert
  • Ein paar kosmetische Änderungen in der System-Unit (erster Buchstabe von Typen sollte nun überall groß sein, usw.)
• Bug-Fixes
  • Seltener Bug beim Schreiben von Werten in globale Variablen behoben
  • Ein weiteren Bug im try-except/finally-Block behoben
  • Bugfix in Vergleich-Routine in der RunTime
  • String-Vergleiche mit verschiedenen String-Typen haben in der RunTime nicht funktioniert
  • Compiler-Bug bei der Deklaration von Methoden-Parameter behoben
  • Klassen können nun nicht mehr von nicht-vollständigen Klassen abgeleitet werden (forwarded classes)

Download-Link ist im ersten Post.

Grüße

[WladiD]

Hi littleDave,

kein Problem wegen der verspäteten Antwort, kenne den Zeitfaktor leider auch viel zu gut.

Die Codevervollständigung habe ich mir vorher auch schon angeschaut, bin aber auf die Schnelle (innerhalb von 10 Min.) nicht durchgestiegen und daher schnellstens verworfen. Auch wird diese Art von Code-Editor eh nur ein paar Math.*-Funktionen und Operatoren benötigen, daher lasse ich das vorerst. Aber wer weiß, vielleicht habe ich irgendwann nichts besseres zu tun.

Dass du für die Easing-Suite eine Verwendung hast, überrascht und freut mich zugleich. Seit dem letzten Post habe ich sie erweitert, man kann jetzt jede Funktion über Bewegung (EaseReal-Tab) visualisieren, man hat noch mehr Modifikatoren (emInSnakeInverted und emOutSnakeInverted), und eine (für mich) nützliche Lookup-Table mit beliebigen Werten/Schritten. Hänge die aktuelle Version mal an, vielleicht wird es an Mehrwert für dich gewinnen.

mfg

[littleDave]

Neue Version :arrow: Version 0.5.4.0

Diesmal habe ich die Patch-Version mal wieder etwas erhöht ;-). Wie vor etwas längerer Zeit angekündigt, habe ich den Delphi 2009+ - Support mal wieder verbessert. Das Äußert sich nun daran, dass es in der Script-Engine drei neue String-Typen gibt: AnsiString, PAnsiChar und PWideChar. Dadurch ist es nun endlich auch in den Unicode-Versionen von Delphi möglich - AnsiString-Methoden ohne Probleme in die ScriptEngine zu integrieren. In der SEII sind die String-Typen jetzt wie folgt gemapped:

• SEII string -> string der kompilierten RunTime (RunTime wurde mit D7 kompiliert, dann AnsiString, mit D2010 UnicodeString)
• SEII PChar -> PChar der kompilierten RunTime (RunTime wurde mit D7 kompiliert, dann PAnsiChar, mit D2010 PWideChar)
• SEII AnsiString -> AnsiString der kompilierten RunTime
• SEII WideString -> WideString der kompilierten RunTime
• SEII PAnsiChar -> PAnsiChar der kompilierten RunTime
• SEII PWideChar -> PWideChar der kompilierten RunTime

Kompilierte RunTime heißt in diesem Kontext: das Delphi-Programm, welches das kompilierte Programm der ScriptEngine ausführt.

ChangeLog:

• Neuerungen
  • Neuer Typ: "System.AnsiString"
  • Neuer Typ: "System.PAnsiChar"
  • Neuer Typ: "System.PWideChar"
  • Neue Klasse: "System.AnsiStrings"
  • Klasse "System.StringEncoding" - Erweitert, so dass auch AnsiString verfügbar ist
  • Neue Helper-Klasse: "System.TAnsiStringHelper"
  • Neue Funktion in "System.Strings": "System.Strings.DefaultEncoding": liefert das interne Encoding der RunTime für den Typ "System.String" und "System.PChar".
  • Delphi XE als Compiler-Define eingeführt -> da sich intern zwischen D2010 und D-XE nicht so viel geändert hat, sollte alles funktionieren (ist jedoch nicht getestet)
  • Methoden-Pointer können nun auf andere EventTypen gecastet werden -> dies führt zu einer weniger strengen Parameterprüfung.
• Änderungen
  • Properties mit Parametern können nun auch direkt hinter aufgerufen werden. Bisher musste man auf Grund eines Compiler-Bugs den Rückgabewert in eine Variable zwischenspeichern - das geht jetzt auch direkt
    
    Vorher:
    
    Delphi-Quellcode:

    var t : TIrgendwas;
      tmp : TIrgendwas;
    begin
      tmp := t.Items[0];
      tmp := t.Items[1];
      tmp.Items[2] := nil;
    end;

    Nun auch so möglich:
    
    Delphi-Quellcode:

    var t: TIrgendwas;
    begin
      t.Items[0].Items[1].Items[2] := nil;
    end;

• Bug-Fixes
  • Ein paar Bugs in "System.Console" behoben: das interne String-Encoding hat bei D2009+ bei manchen Methoden nicht funktioniert
  • Ein paar Bugs im internen String-Handling der RunTime behoben

Download-Link ist im ersten Post.

Grüße

[toms]

Vielen Dank für das Update! :-D


Unter Delphi XE gibt es noch folgende Hinweise/Warnungen:

Zitat:

[DCC Warning] uSE2IncDateTime.pas(1771): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1771): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1779): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1779): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1787): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1787): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1795): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1795): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncSCriptInfo.pas(48): W1000 Symbol 'DecimalSeparator' is deprecated: 'Use FormatSettings.DecimalSeparator'
[DCC Warning] uSE2IncSCriptInfo.pas(53): W1000 Symbol 'DecimalSeparator' is deprecated: 'Use FormatSettings.DecimalSeparator'
[DCC Hint] uSE2ExecutionContext.pas(218): H2164 Variable 'r4' is declared but never used in 'TSE2ExecutionContext.Process'

Unter Delphi 2009:

Zitat:

[DCC Hint] uSE2Types.pas(1827): H2443 Inline function 'AnsiSameStr' has not been expanded because unit 'Windows' is not specified in USES list
[DCC Hint] uSE2PEData.pas(826): H2443 Inline function 'AnsiSameStr' has not been expanded because unit 'Windows' is not specified in USES list
[DCC Hint] uSE2RunAccess.pas(197): H2443 Inline function 'AnsiSameText' has not been expanded because unit 'Windows' is not specified in USES list

[littleDave]

Hallo toms,

danke für die Warnungs-Liste für Delphi XE / D2009

Zitat:

[DCC Warning] uSE2IncDateTime.pas(1771): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1771): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1779): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1779): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1787): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1787): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform
[DCC Warning] uSE2IncDateTime.pas(1795): W1000 Symbol 'GetLocaleFormatSettings' is deprecated: 'Use TFormatSettings.Create(Locale)'
[DCC Warning] uSE2IncDateTime.pas(1795): W1002 Symbol 'GetLocaleFormatSettings' is specific to a platform

Oh, da habe ich eine Testfunktion ausversehen noch im Quelltext drinnen. Die muss eigentlich raus :oops:. Beim nächsten Release werden die überladenen Funktionen für "DateTime.TimeToStr", "DateTime.DateToStr" und "DateTime.FormatDateTime" mit dem Language-Id-Parameter wieder ausfliegen. Daher BITTE NICHT benutzen.

Zitat:

[DCC Warning] uSE2IncSCriptInfo.pas(48): W1000 Symbol 'DecimalSeparator' is deprecated: 'Use FormatSettings.DecimalSeparator'
[DCC Warning] uSE2IncSCriptInfo.pas(53): W1000 Symbol 'DecimalSeparator' is deprecated: 'Use FormatSettings.DecimalSeparator'

Ok, für Delphi XE werde ich schauen, dass ich das so umsetze. Hoffentlich rate ich dann richtig, da ich kein XE habe.

Zitat:

[DCC Hint] uSE2ExecutionContext.pas(218): H2164 Variable 'r4' is declared but never used in 'TSE2ExecutionContext.Process'

Komisch - warum zeigt mir Delphi 2010 und Delphi 7 diesen Hinweis nicht an :gruebel: - werde ich löschen.


Unter Delphi 2009:

Zitat:

[DCC Hint] uSE2Types.pas(1827): H2443 Inline function 'AnsiSameStr' has not been expanded because unit 'Windows' is not specified in USES list
[DCC Hint] uSE2PEData.pas(826): H2443 Inline function 'AnsiSameStr' has not been expanded because unit 'Windows' is not specified in USES list
[DCC Hint] uSE2RunAccess.pas(197): H2443 Inline function 'AnsiSameText' has not been expanded because unit 'Windows' is not specified in USES list

Die Unit Windows will ich eigentlich so weit wie möglich vermeiden (wegen FreePascal). Naja, da werde ich wohl ein {$IFDEF WINDOWS} in die Uses-Liste hinzufügen müssen. Was mich aber auch wieder wundert: warum sagt mir Delphi 2010 diese Hinweise nicht :gruebel:

(wahrscheinlich habe ich bei mir in den Projektoptionen irgend ein Häkchen nicht gesetzt)

Danke nochmal für die Liste, toms.

[mleyen]

Zitat:

Zitat von littleDave (Beitrag 1054617)

Was mich aber auch wieder wundert: warum sagt mir Delphi 2010 diese Hinweise nicht :gruebel:

(wahrscheinlich habe ich bei mir in den Projektoptionen irgend ein Häkchen nicht gesetzt)

Zitat:

Zitat von mleyen (Beitrag 1039924)

(btw: Hast du die H2443-Warnung abgestellt? ^^

Bei mir in 2010 hatte er sie auf jeden Fall angezeigt.
Man konnte im Debugmode wenn eine Exeption autritt sagen "Diesen Exception-Typ nicht mehr anzeigen". Ist mir auch Mal unter ziemlich bösen Umständen an die Gurgel gegangen. :|

[littleDave]

Neue Version :arrow: Version 0.5.4.1

Mir ist in der letzten Version ein etwas größerer Fehler unterlaufen, daher schiebe ich schnell noch dieses Update hinterher:

• Neuerungen
  • Der "Self" - Parameter ist in Klassenmethoden nun nicht mehr notwendig. Nun kann man auf alle Felder, Methoden und Properties einer Klasse ohne vorheriges "Self." zugreifen. Die Code-Completion-Klasse ist für dieses Feature ebenfalls bereits erweitert.
  • Bei Properties von externen Klassen kann der Compiler jetzt optional automatisch einen entsprechenden Getter und Setter erstellen. Das erspart einiges an Tipp-Arbeit beim importieren der externen Klassen. Hier mal ein Beispiel.
    Vorher:
    Delphi-Quellcode:

    type
      TTest = class(TExternalObject)
      private
        function GetCaption: string; external;
        procedure SetCaption(value: string); external;
      public
        property Caption : string read GetCaption write SetCaption;
      end;

    Nacher:
    Delphi-Quellcode:

    type
      TTest = class(TExternalObject)
      public
        property Caption : string read and write;
      end;

    Hier mal die Deklaration für die einzelnen Property-Typen:
    • Read-Only:
      Delphi-Quellcode:

      property [Name]: [Typ] read;

    • Write-Only:
      Delphi-Quellcode:

      property [Name]: [Typ] write;

    • Read-Only:
      Delphi-Quellcode:

      property [Name]: [Typ] read and write;

    
    Das ganze geht natürlich auch für parametrisierte Properties:
    Delphi-Quellcode:

    type
      TTest = class(TExternalObject)
      public 
        property Items[index: integer]: string read and write;
      end;

• Änderungen
  • Test-Code aus der System-Unit entfernt: alle DateTime-Aufrufe mit einer LanguageId sind entfernt
• Bug-Fixes
  • In Klassenmethoden können nun auch Variablen deklariert werden, deren Name in der Klasse für ein Feld, eine Methode oder eine Property benutzt wurden.
  • Der Zugriff auf nicht-statische Klassen/Record Variablen von einem statischen Element aus wurde nicht abgefangen
  • Kritischer Fehler behoben: bei der Deklaration von einer String-Variable innerhalb eines Records kam es zu einer Zugriffsverletzung innerhalb des Compilers

Download-Link ist im ersten Post.

Grüße