ScriptEngine II (v. 0.6.1)

[Namenloser]

[OT]
Wow, sieht ziemlich geil aus, wenn ich das mal so sagen darf!
Vor allem die Beleuchtungs- und Schatteneffekte finde ich sehr gelungen.
[/OT]

[littleDave]

Es ist vollbracht :arrow: Version 0.5.2.0

Wie vor kurzem Angekündigt kommt hier nun ein großes Update. Die neue Multi-Threading-Funktion hat intern einige extreme Einschnitte mit sich gebracht und ich hoffe, dass alles funktioniert. Die Thread-Geschichte habe ich mehrere Tage lang geprüft sie und sollte funktionieren. Ob wirklich alles perfekt synchronisiert ist, kann ich nur hoffen - ich habe mir jedenfalls sehr viel Mühe gegeben. Die grundlegenden Threading-Funktionen habe ich erfolgreich unter Delphi 7, Delphi 2010 und Lazarus getestet.

• Neuerungen
  • Multi-Threading ist jetzt innerhalb eines Scriptes möglich. Man kann nun innerhalb eines Scripts eigene Threads erstellen und Script-Quelltext in diesen Threads ausführen lassen
  • Neuer Namespace: System.Threading
  • Neue Klasse: System.Threading.TThread
  • Neue Klasse: System.Threading.TExecutionContext
  • Neue Klassen in System.Threading: TCriticalSection, TMutex, TEvent, Monitor
  • Neues Record in der System-Unit: System.TGuid
  • Neues Record in der System-Unit: System.TVersion
• Änderungen
  • Record-Vergleiche sollten nun funktionieren. Da aus Performance-Gründen nur ein roher Speicher-Vergleich erstellt wird, funktionieren Record-Vergleiche, bei denen die Records strings enthalten, nicht. Der Compiler gibt jedoch eine Warnung bei solchen Vergleichen an.
  • Der interne Programmablauf der RunTime hat sich auf Grund des Threading-Supports sehr geändert. Ich hoffe aber, dass alles weiterhin funktioniert
  • Statische Variablen werden jetzt nicht mehr unten im Stack sondern in einem seperaten Speicher abgelegt
• Bug-Fixes
  • Kleines Problem bei der record-Deklaration behoben: bei abgeleiteten Typen als Record-Variablen - z.B. bei LongInt (ist von integer abgeleitet) wurde die finale Record-Größe im Speicher falsch berechnet.

Noch ein paar kurze Worte:

• Ich habe das PDF im Download mit der Threading-Geschichte erweitert. Darin sind jetzt ein paar grundlegende Sachen niedergeschrieben.
• Falls wer in der Beispiel-IDE Threading ausprobieren will: das eingebaute Konsolen-Fenster (also Console.Write..., usw) sind thread-safe implementiert.
• Ein empfohlenes Script: wenn ihr die Beispiel-IDE öffnet, könnt ihr mal das Projekt "Projects\ThreadingPrimeNumber\ThreadedPrime.sproj ect" öffnen und laufen lassen. In diesem Script wird die Anzahl der Primzahl zwischen 0 und 750000 berechnet. Beim Start könnt ihr auswählen, ob nur ein Thread alles berechnen soll, oder ob sich die Arbeit 15 Threads teilen sollen.
• In der IDE werden jetzt nicht mehr alle Packages automatisch geladen. Jedoch könnt ihr, während das Program läuft, neue Packages hinzufügen oder vorhanden deaktivieren. Dafür gibt es einen neuen Tab auf der linken Seite.
• Falls wem in seinem Programm die Threads innerhalb eines Scriptes ein Dorn im Auge ist, so kann man die komplette Threading-Geschichte natürlich auch deaktivieren. Dafür gibt es in der Datei "ScriptEngine.inc" ein neues Define, mit dem man den Threading-Namespace komplett raus schmeißen kann.

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

Grüße

[Dolvik]

Hallo littleDave,

jetzt legst du ja ein ordentliches Tempo vor. Die Geschichte mit Multithreading ist echt klasse! Kann man sicher mal gebrauchen.

Weiterhin viel Gelingen und gutes Voranschreiten mit deinem Game.

Dolvik

[DXArc]

Hallo

an alle die Software und /oder Komonenten als Open Source für Delphi anbieten: Die MPL ist schon in Ordnung.

GPL und LGPL sind für Delphi nicht ohne weiteres anwendbar! Bitte mal beim ZEOS Projekt schauen. Dort wird für die letzte Version eine abgewandelte LGPL eingesetzt, damit die Library
in kommerziellen Projekten einsetzbar ist. Hintergrund ist, dass man bei einer Single-Exe immer Code einbauen muss (auch wenn DLLs benutzt werden). Diesen müsste man aber abändern können.

Notfalls muss dann der Autor der Software einen Linker oder eben die IDE zur Verfügung stellen. Und Delphi jedem Kunden schenken lohnt sich vielleicht nicht.
Daher wenn LGPL, dann macht bitte eine eine abgeänderte Version daraus.

Und GPL macht eigentlich nur Sinn, wenn es um die eigene Verwendung, aber nicht um eine mögliche Weitergabe geht. Bei Lazarus/Freepascal sieht das natürlich anders aus.

Trotzdem natürlich Dank an alle, die sich engagieren.

[littleDave]

Neue Version :arrow: Version 0.5.3.0

Nach einer längeren Update-Pause habe ich mal wieder die aktuellste Version veröffentlicht. Da die DP mein Zip irgendwie nicht haben wollte, habe ich im ersten Post jetzt den Download-Link von SourceForge.net angegeben.

Diesmal ist der ChangeLog wieder etwas länger:

• Neuerungen
  • Die Geschwindigkeit vom Compiler und vom Linker extrem verbessert: der Compiler braucht jetzt nur noch 1/10 der Zeit zum kompilieren
  • Im Script kann man jetzt Inline-Dokumentation einfügen. Dafür muss man einfach vor der Deklaration ein Kommentar mit drei Slashes ("///") hinzufügen. Dabei kann man beliebig viele Zeilen für die Dokumentation verwenden - jede Zeile muss dabei nur mit den drei Slashes anfangen. Zudem gibt es jetzt eine neue Code-Completion-Klasse, mit der die Inline-Dokumentation angezeigt werden kann. In der Beispiel-IDE ist diese auch eingebaut - einfach mal den Cursor zu dem entsprechenden Identifier bewegen und Strg+Alt+Space drücken.
  • Der Typ von Rückgabewerten von Funktionen kann jetzt auch als "Strong-Name" angegeben werden (UnitName.Typ)
  • Der Typ properties kann jetzt auch als "Strong-Name" angegeben werden (UnitName.Typ)
  • Der Typ Parametern von Properties kann jetzt auch als "Strong-Name" angegeben werden (UnitName.Typ)
  • Compiler versucht jetzt nach manchen Fehler im Script trotzdem fortzufahren, um bessere Code-Completion zu ermöglichen
  • Code-Completion ist jetzt auch mit partiellen Units möglich (neue überladene Methode in den entsprechenden Klassen)
  • Neues Keyword: sealed. Klassen können jetzt als "Sealed" deklariert werden, damit man nicht mehr von der Klasse ableiten kann.
  • Neue Exception: EUnknownException. Diese Exception wird geworfen, wenn eine Unbekannte Exception aufgetreten ist (also eine in der Script-Engine nicht registrierte Exception)
  • Neue Typen in der System-Unit: int8, int16, int32, uint8, uint16 and uint32
  • Ein paar weitere Helfer-Methoden für die Standart-Typen eingebaut
  • Neues Record in der System.Diagnostics - Unit: TStopwatch (zum Zeit messen)
• Änderungen
  • Inkompatible-Typen-Warnung bei Klassen ist jetzt ein Compiler-Fehler
  • Der Filter zum Finden der korrekten überladenen Methode verbessert
  • Methoden in Records können nun nicht mehr als virtual, abstract, etc. deklariert werden
  • Ein paar Klassen in der System-Unit geändert (sollte in den Scripts nicht bemerkbar sein)
  • Überladene Methoden müssen nun nicht mehr alle den selben oder überhaupt einen Rückgabewert haben. Sie müssen zwar weiterhin vom selben Typ sein (statisch oder nicht statisch), aber der Rückgabewert ist nun nicht mehr das Problem
  • Die Random-Funktionen habe der Übersicht halber aus der Klasse "System.Math" ausgelagert in eine neue Klasse: "System.Random". Dort sind jetzt alle Random-Funktionen drinnen - mit einer etwas anderen Deklaration: statt "Math.Random(x)" muss man jetzt "Random.Next(x)" schreiben.
• Bug-Fixes
  • Fehler in RunTime behoben: Multiplikation von int32 mit einem Single oder Double lieferte ein falsches Ergebnis
  • Script-Funktionen "System.StringEncoding.AsUTF8", "System.StringEncoding.AsUnicode", "Systeml.StringEncoding.AsString" habe nicht funktioniert
  • Compiler-Bug im inherited-Ausdruck behoben: die Stack-Größe wurde falsch berechnet
  • Manchmal wurden rekursive uses-Deklaration nicht erkannt
  • Memory-leak in der RunTime behoben: Methoden-Aufrufe im Script über einen Methoden-Pointer haben 8 Byte zu viel Arbeitsspeicher angefordert
  • "Deprecated" - Erkennung wurde nicht für Methoden-Parameter und Rückgabewert-Typen ausgeführt
  • Rückgabewert-Typen wurden zwischen interface und implementation nicht überprüft
  • Das Suchen von Konstanten hat nicht immer funktioniert
  • Fehler in der RunTime-internen RTTI bei records behoben
  • Fehler im RunTime-Cache behoben
  • Finalization-Reihenfolge war bei partiellen Units nicht korrekt
  • Stack-Element des Self-Pointers war falsch bei Methoden, die im Script über Methoden-Pointer aufgerufen wurden
  • Fehler im Linker behoben: Optimierer von Operationen und Vergleichen hat nicht immer korrekt gearbeitet
  • Fehler in System.TTimeSpan.FromString() behoben
  • Compiler-Fehler in der "on [x]: [ExceptionClass] do" - Anweisung behoben
  • Fehler in statischen Variablen von Klassen und Records behoben

Ich habe das ganze leider noch nicht mit FreePascal und mit Delphi 2010 testen können - ich hoffe, dass alles trotzdem funktioniert.

Grüße

[Florian Hämmerle]

Oja :D
Mein aktuelles Projekt freut sich das zu hören (und ich natürlich auch). Wirklich tolle Arbeit die du da leistest!

Weiter so.

Was sind eigentlich deine Ziele bis 1.0.0.0?

mfg Florian

[littleDave]

Danke für das Lob :-) *freu*

Meine Ziele bis 1.0.0.0 ... hm :gruebel: weiß ich noch nicht - obwohl: arrays ;-).

Also konkrete Ziele habe ich nicht. Ich bin aber auch schon sehr zufrieden mit der aktuellen Version. Ich will eigentlich nur eine gute, schnelle und Objekt-Orientierte Script-Sprache mit Object-Pascal-Dialekt schreiben, mit der man kleine und größere Aufgaben erledigen kann. Zum Teil habe ich das auch bereits geschafft - ich habe zum einen ein sehr einfaches Script (ok, Multi-Threaded 8-), aber das ist nur nebensächlich), mit dem ich mir die Anzahl der Quelltextzeilen in allen .pas-Dateien in einem Ordner sowie den Unterordnern holen kann. Zum anderen entwickle ich nebenbei noch ein Spiel, in der die Script-Engine die komplette Programm-Logik ausmacht.

Was als nächstes sicher noch kommen wird ist der Typ "AnsiString", der ab Delphi 2009 doch etwas wichtiger geworden ist. Aber sonst habe ich keine konkrete Road-Map, fast immer nur das, was ich gerade brauche ;-).

[Florian Hämmerle]

Auch gut.
SE2 ist ja jetzt schon so mächtig, dass man damit Spiele programmieren kann. Da mach ich mir wegen der Geschwindigkeit keine großen Sorgen mehr ;).
Dann hoff ich mal, dass du schon bald wieder was neues brauchst, arrays finde ich persönlich nicht so wichtig (kann man alles auch über TList machen).

mfg Florian

[littleDave]

Ich habe eben noch schnell einen kleine Fehler im Compiler ausgebessert. Neue Version ist auf SourceForge bereits hochgeladen. Download-Links ist der alte.

Gruß

[mleyen]

Hey, grandios was sich mit der SE2 alles machen lässt. :shock: :thumb:

Hier mal meine Vorschläge/Kritik/Fragen: :-D
- Ist es ein großer Aufwand den Typ Char einzubaun? Denn so muss man in jedem Script einen string auf len(1) prüfen.
- 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?
- Könntest du evtl den Uses-Cleaner von CNPack vor Releases drüberlaufen lassen?

(btw: Hast du die H2443-Warnung abgestellt? ^^ Das die erste Version mit immer der gleichen Compilerwarnung :wink: )

Danke, macht echt Spass damit zu experimentieren. Compilerzeit mal eben so gezehntelt... :lol:

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

[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

[littleDave]

Neue Version :arrow: Version 0.5.5.0

Ich habe diesmal wieder einige Änderungen am Script-Code in der Script-System-Unit vorgenommen. Genauer gesagt habe ich die Convert-Klasse komplett neu geschrieben. Die Routinen "IntToStr", "IntToStrDef", usw. haben jetzt einen anderen Namen. Daher kann es zu notwendigen Anpassungen am Script-Quelltext kommen.

Die Benutzung der Convert-Klasse ist nun komplett an .NET angelehnt. Um einen String z.B. in einen Integer umzuwandeln, schreibt man nun

Delphi-Quellcode:

System.Convert.ToInt32('12345');

. Die "ToInt32" gibt es dabei in sehr vielen überladenen Varianten, also z.B. für floats, strings mit Default-Wert, usw. Allgemein funktioniert die Konvert-Klasse wie folgt:

System.Convert.[Optional: Try]To[Ziel-Typ]([Quell-Typ])

wobei Ziel-Typ z.B. Int32, Int64, Single, Double, String, usw. ist.

Als positiven Ausgleich dafür habe ich die Performance der RunTime nochmal verbessert. Dadurch konnte die Auführungszeit von Scripten um bis zu 30% gesenkt werden.

• Neuerungen
  • Neuer Typ: "System.UInt64"
  • Convert-Routinen für "System.UInt64"
  • Neue Op-Codes für das Laden von Integers, Floats, Strings und Pointer in den Stack -> großer Performanceschub in der RunTime
• Änderungen
  • Die Convert-Klasse ist nun komplett neu erstellt. Daher heißen die Methoden-Namen nun anders, wodurch wahrscheinlich einige Anpassungen am Script-Quelltext nötig sein werden.
  • Verbesserungen des Optimizers im Linker. Durch neue Optimierungsstufen ist der Byte-Code und somit auch die Ausführgeschwindigkeit sehr verbessert worden.
  • Eine weitere Stufe zum Filtern der am besten passenden overloaded-Methode im Compiler eingebaut
• Bug-Fixes
  • Das finden der besten überladenen Methode hatte ein Problem mit var-Parametern. Diese wurden nicht korrekt berücksichtigt.
  • Fehler beim automatischen generieren von Getter- und Setter-Methoden für properties in externen Klassen behoben
  • Fehler beim @-Statement für Methoden-Pointer, wenn kein "Self" mit angegeben wurde.

Download-Link ist im ersten Post.

Grüße

[toms]

Im Indy+Thread Demo erhalte ich eine Fehlermeldung Could not add the unit "System.Xml" (Linie 5)

[littleDave]

Du musst in der IDE die Packages "installieren". In den Packages sind die jeweiligen Units. Um das zu machen, musst du in der IDE im linken PageControl die Seite "Packages" öffnen. Dort sind alle "Package-DLLs" aufgelistet, die im Moment geladen sind. Einfach einen Rechtsklick und man kann weitere DLLs hinzufügen oder vorhandene entfernen. Um zu sehen, welche Unit in welchen Package ist, gibt es unten im PageControl mit den Seiten "Messages", "Debug Output", etc. einen weiteren Tab: "Registered Packages". Dort kann man sich dann alle Units der Packages anschauen.

Lange Rede, kurzer Sinn: füge im "Packages"-Tab die DLLs "libXML.dll" und "libIndy.dll" hinzu und schon sollte es gehen. :-)

[toms]

Zitat:

Zitat von littleDave (Beitrag 1056126)

Lange Rede, kurzer Sinn: füge im "Packages"-Tab die DLLs "libXML.dll" und "libIndy.dll" hinzu und schon sollte es gehen. :-)

Alles klar, vielen Dank.

PS: http://www.delphipraxis.net/rdf.php existiert nicht mehr.

[littleDave]

Zitat:

Zitat von toms (Beitrag 1056127)

PS: http://www.delphipraxis.net/rdf.php existiert nicht mehr.

Oh, danke für den Hinweis. Ich habe das Beispiel lange nicht mehr angeschaut :oops: - ich habe daher mal eine aktuelle Version erstellt. Einfach kopieren und im Editor einfügen.

Delphi-Quellcode:

program Project1;

uses
  System.Threading,
  System.Xml,
  Net.Indy;

type
  { Feed Query Data }
  TFeedQuery = record
  private
    FURL      : string;
    FUsesUTF8 : boolean;
  public
    class function Create(URL: string; UsesUTF8: boolean): TFeedQuery;
  
    property URL      : string read FURL;
    property UsesUTF8 : boolean read FUsesUTF8;
  end;
  
class function TFeedQuery.Create(URL: string; UsesUTF8: boolean): TFeedQuery;
begin
  result.FURL := URL;
  result.FUsesUTF8 := UsesUTF8;
end;

type
  { Execution Thread }
  TMyExecution = class(TExecutionContext)
  private
    FData  : string;
    FError : boolean;
    FQuery : TFeedQuery;
  protected
    procedure Execute; override;
    function  ExtractTitles: string;
  public
    constructor Create(Query: TFeedQuery); virtual;
  end;
  
constructor TMyExecution.Create(Query: TFeedQuery);
begin  
  inherited Create;
  FQuery := Query;
end;

function   TMyExecution.ExtractTitles: string;
var s: string;
    iStart, iStop: integer;
    tmp : string;
begin
  s := Self.FData;
  iStart := s.IndexOf('<title>');
  while iStart > 0 do
  begin
    iStop := s.IndexOf('</title>');
    if iStop > 0 then
    begin
      tmp := XML.Decode(s.Copy(iStart + string('<title>').Length, iStop - iStart - string('<title>').Length));
      if Self.FQuery.UsesUTF8 then
         result := result + StringEncoding.ToString(StringEncoding.AsUTF8(tmp)) + #13#10 
      else
         result := result + tmp + #13#10;
      s := s.Copy(iStop + string('</title>').Length);  
      iStart := s.IndexOf('<title>');  
    end else
      iStart := 0;
  end;  
end;

procedure  TMyExecution.Execute;
var http: TIdHTTP;
begin
  http := TIdHTTP.Create;
  try
    http.HandleRedirects := True;
    try
      Self.FData := http.Get(Self.FQuery.URL);   
      Self.FData := Self.FData
                   .Replace(#10, #13#10);
    except
      on e: EException do
      begin
        Self.FError := True;
        Self.FData := e.ToString;
      end;
    end;  
    
  finally
    http.Free;
  end;
end;  

function SelectFeedSource(var Query: TFeedQuery): boolean;
begin
  result := True;
  Console.WriteLine('Press [d] for Delphi, [s] for Spiegel, [h] for Heise, [esc] to cancel');
  while true do
  begin
    case Console.ReadKey.ToUpper of
    'D' :
      begin
        Query := TFeedQuery.Create('http://www.delphipraxis.net/external.php?type=RSS2', False);
        break;
      end;
    'S' :
      begin                                                
        Query := TFeedQuery.Create('http://www.spiegel.de/schlagzeilen/tops/index.rss', False);
        break;
      end;
    'H' :
      begin                                       
        Query := TFeedQuery.Create('http://www.heise.de/newsticker/heise.rdf', True);
        break;
      end;   
    Strings.FromASCIIIndex(KeyCodes.Escape) :
      begin
        result := False;
        exit;
      end;
    end;
  end;
end;

{ Main APP }
var t     : TThread;
    c     : TMyExecution;
    Query : TFeedQuery;
begin      
  if not SelectFeedSource(Query) then
     exit;
     
  repeat
    Console.Clear;
    c := TMyExecution.Create(Query);
    try
      t := TThread.NewThread(c);
      try      
        t.Start;
        
        Console.WriteLine('Connecting ' + Query.URL);
        Console.Write('Waiting ');
        while (t.State <> ThreadState.Finished) do
        begin               
          Console.Write('.');
          TThread.Sleep(100); 
          TThread.Sleep(100);
          TThread.Sleep(50);
        end;
        Console.Clear;
        if c.FError then
        begin
          Console.ForegroundColor := Colors.Red;
          Console.WriteLine(c.FData);
          Console.ForegroundColor := Colors.White;
        end
        else
          Console.WriteLine(c.ExtractTitles);
      finally
        t.Free;
      end;
    finally
      c.Free;
    end;
    
    Console.WriteLine;       
    if not SelectFeedSource(Query) then
       exit;
       
  until False;
end.

[omata]

Wieso muss der Code so unschön sein?

Delphi-Quellcode:

{ Main APP }
:
:
begin
  while SelectFeedSource(Query) do begin
:
:       
  end;
end.

[littleDave]

Weil es meine Programmiersprache ist :mrgreen: (hast ja recht ...)

[littleDave]

Neue Version :arrow: Version 0.6

Ist wurde mal wieder Zeit für einen größeren Versionssprung. Neu dabei ist unter anderem die for-in-Schleife, hier mal (wie immer) die Übersicht:

• Neuerungen
  • Die for-in-Schleife ist nun im Script möglich. Der benötigte Enumerator und dessen Aufbau ist im PDF beschrieben.
  • Enumeratoren für TList, TStrings, TIntegerList, TInt64List und TFloatList hinzugefügt
  • Der Index von for-Schleifen kann jetzt lokal im Schleifenkopf definiert werden:
    Delphi-Quellcode:

    for var i: integer := 0 to 10 do ;

  • Die Inhaltsvariable von for-in-Schleifen kann ebenfalls lokal definiert werden:
    Delphi-Quellcode:

    for var s: string in AList do ;

  • Die Script-Engine kann jetzt mit direkten Funktionspointern zu externen Methoden umgehen. Das schaut z.B. so aus:
    
    Delphi-Quellcode:

    type
      TMyCallback = procedure(SomeArg: integer); external; // wichtig: muss als external definiert sein, stdcall etc. ist erlaubt
    
    function GetCallbackEntryPoint: Pointer; external; // liefert den direkten Funktionspointer
    
    var t: TMyCallback;
    begin
      t := GetCallbackEntryPoint;
      t(1234); // Funktion wird ausgeführt
    end;

  • DLL-Methoden können jetzt direkt im Script definiert und importiert werden. Die RunTime hat zudem ein eingebautes Sicherheitsfeature, mit dem gesteuert werden kann, ob eine Funktion importiert werden kann. Dies ist Standard-mäßig verboten, im PDF ist aber beschrieben, wie man das erlaubt.
    
    Delphi-Quellcode:

    procedure Sleep(dwMilliseconds: DWORD); external 'kernel32.dll' name 'Sleep'; stdcall;
    
    begin
      Sleep(1000);
    end;

  • Neue Unit: System.Interop.Windows: Bietet die Klasse "TDynamicLinkLibrary" an, mit der man Funktionspointer aus DLLs dynamisch laden kann. Der gerade genannte Sicherheitsaspekt ist für diese Methode ebenfalls von Bedeutung.
    
    Delphi-Quellcode:

    uses
      System.Interop.Windows;
    
    type
      TSleep = procedure(dwMilliseconds: DWORD); external; stdcall;
    
    var Sleep: TSleep;
        Lib  : TDynamicLinkLibrary;
    begin
      Lib := TDynamicLinkLibrary.Create('kernel32.dll');
      try
        Sleep := Lib.FindMethod('Sleep');
        if @Sleep <> nil then
           Sleep(1000);
      finally
        Lib.Free;
      end;
    end.

• Änderungen
  • Compiler-Geschwindigkeit sowie Linker-Geschwindigkeit etwas verbessert
  • "exit", "break" oder "continue" ist jetzt innerhalb eines finally-end-Blockes verboten (wie in Delphi auch)
• Bug-Fixes
  • try-except-Block und try-finally-Block komplett neu geschrieben. Es gab einige Probleme mit den Anweisungen "exit", "break" und "continue" innerhalb eines try-Blockes.
  • interne Größe von set-of-Typen hängt jetzt ebenfalls von der Anzahl der Elemente in der Aufzählung ab. Dies ist jetzt kompatibel zu Delphi, was vor allem in Records Probleme machen konnte
  • Compiler hat innerhalb es "uses"-Blockes das Script nicht korrekt validiert
  • Funktionsaufrufe mit Rückgabewert über einen Funktionspointer haben nicht korrekt funktioniert
  • Fehler in der RunTime beim OpCode "JIZ" und "JNZ" behoben

Download-Link ist im ersten Post.

Grüße

[Florian Hämmerle]

NICE (:

Freut mich zu hören, dass sich in der SE2 immer noch so viel tut. Weiter so (:
wenn das hier jetzt facebook wäre, würde ich mal "gefällt mir" klicken ;)

mfg Florian

[implementation]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1064658)

wenn das hier jetzt facebook wäre, würde ich mal "gefällt mir" klicken ;)

Sowas sollte man hier wirklich mal einführen :gruebel:
Oder einen Danke-Button wie in der EE.

[WorstNightmare]

Hi,

ich denke gerade darüber von RemObjects PascalScript auf deine ScriptEngine umzusteigen, aus dem einfachen Grund weil hier overloading unterstützt wird. Eines stört mich jedoch: Die Scripts müssen immer einen program-Header haben, in PascalScript konnte man den abschalten (über CompilerOptions). Kannst du das auch abschaltbar machen? Der verschwendet bei mir nur Platz, da ich ihn eh immer NPCScript oder so nennen würde und die Scripts über Dateinamen identifiziert werden.

Edit: Und gibt es irgendwo Inc() und Dec()? Wenn nein, warum nicht?

Edit 2: So, läuft ganz gut jetzt. Allerdings habe ich noch einen Feature-Wunsch:
Meine Scripts terminieren die Runtime aus sich heraus und wenn ich direkt nach Abort() Finalize() und Free() aufrufe, knallt es. Daher brauche ich ein Notify-Event, irgendwie OnAborted oder so in der Runtime. Im finally ganz unten in TSE2ExecutionContext.Call dann so aufrufen:

Delphi-Quellcode:

    if FDoAbort and Assigned(FOnAborted) then
      FOnAborted(TObject(FExecutionData.RunTime));

[littleDave]

Hallo WorstNightmare,

sorry für die späte Antwort, bin bisher nicht dazu gekommen

Zitat:

ich denke gerade darüber von RemObjects PascalScript auf deine ScriptEngine umzusteigen, aus dem einfachen Grund weil hier overloading unterstützt wird. Eines stört mich jedoch: Die Scripts müssen immer einen program-Header haben, in PascalScript konnte man den abschalten (über CompilerOptions). Kannst du das auch abschaltbar machen?

Ja, ich werde schauen, was sich da machen lässt. Wird jedoch noch etwas dauern, da ich mich endlich dazu überwunden habe und im Moment arrays einbaue. Ich bin dabei gerade mitten in der Implementierungs- und Testphase. Dadurch wäre es im Moment nicht so gut, den halbfertigen Code herauszugeben. Bis dahin kannst du ja vor dem Übergeben an den Compiler folgendes schreiben:

Delphi-Quellcode:

function CompileScript(const Source: string): TSE2PE;
begin
  result := Compiler.Compile('program program1; ' + Source + ' begin end.';
end;

Zitat:

Edit: Und gibt es irgendwo Inc() und Dec()? Wenn nein, warum nicht?

Diese Routinen habe ich zum einen aus Zeitgründen, zum anderen aus Featuregründen noch nicht drinnen (ich will eigentlich keine "Compiler-Magic" einbauen).

• Zeitgrund: für jeden Typ müssen die Routinen alle manuell deklarieren muss (also für byte, integer, etc. - jeweils mit und ohne Parameter).
• Feature-Grund: für ein einfaches "+1" eine einzelne Funktion aufrufen ist doch etwas overhead, daher wollte ich warten, bis ich "inline" - Methoden eingebaut habe.

Bei "pred()" und "succ()" hört der Spaß dann aber auf - die kommen mir nicht in die System-Unit :twisted: (ich finde die total unübersichtlich)

Zitat:

Edit 2: So, läuft ganz gut jetzt. Allerdings habe ich noch einen Feature-Wunsch:
Meine Scripts terminieren die Runtime aus sich heraus und wenn ich direkt nach Abort() Finalize() und Free() aufrufe, knallt es. Daher brauche ich ein Notify-Event, irgendwie OnAborted oder so in der Runtime. Im finally ganz unten in TSE2ExecutionContext.Call dann so aufrufen:

Delphi-Quellcode:

    if FDoAbort and Assigned(FOnAborted) then
      FOnAborted(TObject(FExecutionData.RunTime));

Das versteh ich nicht, wieso das nötig sein sollte. Gehe ich richtig in der Annahme, dass du im Script einen Methode aufrufst, die die RunTime beenden und schließen soll? Das kann nicht funktionieren! denn so ziehst du dem Script die RunTime unter den Füßen weg und knallt somit auf den Boden. Die RunTime darf nicht von einer Funktion heraus gelöscht werden, wenn diese aus der RunTime heraus aufgerufen wird.

[EugenB]

Hi :)

Zitat:

Zitat von littleDave (Beitrag 1072265)

Zitat:

Edit: Und gibt es irgendwo Inc() und Dec()? Wenn nein, warum nicht?

Diese Routinen habe ich zum einen aus Zeitgründen, zum anderen aus Featuregründen noch nicht drinnen (ich will eigentlich keine "Compiler-Magic" einbauen).

Wäre sowas nicht "einfach" durch ne Helper-Klasse besser realisiert?

IntVar.Inc;
IntVar.Dec;

Oder geht sowas nicht bei einfachen Variablen?

Btw, schön zu hören das es bald Arrays gibt, obwohl man jetzt sowieso alles mit Listen machen würde (ich zumindest :)

Btw2, ist es möglich / auf der Todo Liste, dass man Generics nutzen kann?

Gruß
Eugen

[WorstNightmare]

Mein RTTI-ClassImporter fügt jetzt einfach noch nach der Klasse, mit der das Script aufs Hauptprogramm zugreift, Inc und Dec für Integer ein. Ich hatte einfach keine Lust das in allen 250 Scripts mit + bzw - 1 zu ersetzen.

Zum Abbrechen der Runtime:
Das habe ich dann auch schnell festgestellt^^
Deswegen möchte ich ja, dass wenn ich Abort aufrufe, ich benachrichtigt werde wenn es fertig mit Abbrechen ist und dann Free aufrufen kann. Eine andere Möglichkeit habe ich nicht, denn das Hauptprogramm weiß nicht automatisch, wann das Script fertig ist (die Teile haben eine Methode, die bei jedem Script unterschiedlich oft aufgerufen wird).

[WorstNightmare]

Alle meine Scripts laufen jetzt schon seit längerer Zeit mit dieser Engine und ich muss sagen, ich bin sehr zufrieden.

Es gibt allerdings ein mittelschweres Problem: Der Speicherverbrauch.

Für ein simples Script wie dieses [Link] fallen knapp 5 (!) MB Speicher an, sobald Compile() ausgeführt wurde. Das Problem an diesen Event-Scripts ist, dass sie für jeden Channel-Server (wovon es durchschnittlich 6 gibt) extra instanziert werden müssen und die ganze Zeit aktiv sein müssen, da sie oft auch zeitgesteuerte Aufträge haben und Variablen über einen längeren Zeitraum speichern. Momentan gibt es zwar nur dieses eine, wenn allerdings später 15 vorhanden sind ist dieser extreme Verbrauch echt nicht mehr tragbar.

Ich bin nicht ganz sicher warum für ein 600 Byte langes Script plötzlich 4,5 MB verbraucht werden, könnte es mit der verwendeten Unit zusammenhängen? Diese setzt sich aus den Klassen TEventInstance und TEventManager aus dieser Datei und TScriptMapleCharacter zusammen. In der letzteren Datei ist auch der RTTI Class-Importer.

[littleDave]

Es gibt mehrere Caching-Systeme in der Script-Engine, die ich kurz erläutern will.

• Compiler-Cache
  Der Compiler-Cache (TSE2UnitCacheMngr) hilft für die schnellere Re-Compilierung von Scripts. Er ist vergleichbar mit .DCU-Dateien in Delphi. Dort drinnen stehen relativ viele Informationen, d.h. es kann sehr schnell zur 5 MB Speicherverbrauch kommen. Auf den Manager kann ohne Probleme verzichtet werden, da er nur optional ist. Nachteil ist dann aber, dass bei jedem Compile() alle Script-Units erneut kompiliert werden müssen. Eine Zwischenlösung gibt es aber: die Klasse "TSE2UnitCacheMngr" bietet ein (noch undokumentiertes) Event an ("OnGetCacheStream"), in dem man einen Stream angeben kann, in der der Compiler-Output hinein- bzw. heraus-serialisiert wird. Dort könnte man z.B. einen TFileStream übergeben, womit der RAM entlastet wird. Setzt man in dem Event den Parameter "Cache" auf "nil", wird automatisch ein TMemoryStream angelegt und verwendet.
  
  Die Script-Engine ist beim kompilieren zwar nicht die langsamste, aber wirklich schnell ist sie nicht. Das liegt daran, dass ich eher darauf Wert gelegt habe, die fertig kompilierten Scripts zu speichern und diese dann schnell zu laden. Die fertig kompilierten Scripts sind relativ klein und können so zum einen schnell geladen werden und zum anderen verbrauchen diese nicht so viel RAM.
• RunTime-Cache (pro RunTime-Instanz)
  Die RunTime hat auch einen Memory-Cache, der die Ausführungsgeschwindigkeit erhöht. Dieser Cache vermindert das ständige Abfragen und Freigeben von RAM vom/zum Betriebssystem, in dem es einen fixen Memory-Block anfragt und mit diesem arbeitet. Falls für ein Script mehr Arbeitsspeicher benötigt wird als in diesen Block passen, greift SEII wieder auf "GetMem()" und "FreeMem()" zurück.
  
  Die Größe dieses Caches ist in 3 Stufen einstellbar. Komplett aus - klein - und groß. Diese Konfiguration ist über die Datei "ScriptEngine.inc" zu lösen und somit während der Laufzeit nicht änderbar.
• RunTime-Helper-Cache (pro Thread innerhalb eines RunTime-Objekts)
  Zusätzlich zum Memory-Cache gibt es noch einen Cache für die Verwaltungsobjekte innerhalb der Script-RunTime. Dieser Cache ist Thread-Bezogen, da er für den Execution-Stack der RunTime verwantwortlich ist.
  
  Dieser Cache ist nicht deaktivierbar, ist jedoch sehr klein (ca. 2,5 kb)

Ich hoffe, ich konnte dir mit der Beschreibung etwas weiterhelfen.

Wegen dem Implementierungsfortschritt: die Arrays sind soweit drinnen und funktionieren auch fast ohne Probleme (gibt noch ein paar Baustellen). Jedoch habe ich im Moment wenig Zeit, wodurch sich der Release leider etwas verzögert. Vielleicht bringe ich zur Überbrückung auch noch ein Zwischen-Release heraus, in der die Arrays noch deaktiviert sind, da ich doch noch ein paar kleine Fehler entdeckt habe.

Gruß
David

[Denstern]

Hallo an Alle. Zuerst muss ich sagen: SUPER Sache!!! Und grooooßßßßesss Lob an David!!!! 8-)
So ein SciptEngine ist gerade das was ich schon lange gesucht habe. Ich habe aber eine Frage diesbezüglich:
Im wesentlichen brauche ich nur ein Zugriff vom Hauptprogramm auf die Script-Funktionen.

Frage 1): Gibt es ein allgemeiner Aufruf einer Funktion? (ohne Benutzung von TSE2RunAccess.FindMethod ?) Bei mir ist es der Fall dass die Funktionen im Script vom Anwender Definiert
werden und ich diese dann zur Laufzeit aufrufen will.

Frage 2): Kann man auf Funktionen mit den Arrays für solche zwecke verwenden? Ich habe eigentlich in den ParamTypes kein Array gefunden.

Ich hoffe ihr könnt mir Helfen.

Danke im Voraus,
Denis.

[littleDave]

Neue Version :arrow: Version 0.6.1

Vor längerer Zeit habe ich ja eine neue Version angekündigt. Nun ist es soweit - wobei ich gleich sagen muss: arrays sind immer noch nicht fertig eingebaut. Somit ist das hier eher ein Bug-Fix-Release sowie eine experimentelle Version für arrays. Es ist noch nicht alles drinnen aber ich habe Arrays jetzt erstmal nicht deaktiviert.

Falls also wer die Arrays mal ausprobieren will, es geht noch nicht alles. Zudem gibt es folgende wichtige Einschränkung: man kann arrays nicht "inline" deklarieren, also folgendes geht NOCH NICHT:

Delphi-Quellcode:

var t: array of integer;

. Stattdessen muss man immer vorher den Array-Typ deklarieren:

Delphi-Quellcode:

type TIntArray = array of integer;

.

• Neuerungen
  • Basis-Array-Implementation eingebaut
  • Die Funktionen "System.Inc()" sowie "System.Dec()" sind jetzt vorhanden
• Veränderungen
  • Performance bei Conditional-Jumps verbessert
  • Byte-Code-Optimizer erweitert und verbessert
• Bug-Fixes
  • Fehler beim Aufrufen von überladenen Methoden mit var-Parameter behoben
  • Das Forwarden von Klassen war im Compiler nicht komplett - somit war die erstellte Klasse im Code nicht verwendbar. Dies trat in normalen Units nicht auf, da man da die Deklaration zuerst abschließen musste - in der "program" - Datei jedoch war das nicht zwingend notwendig.
  • Fehler beim Finden der korrekten, überlandenen Methode behoben, falls zwei verschiedene Klassentypen als Parameter-Varianz ausschlaggebend waren
  • Fehler bei break/continue innerhalb von try-except-Blöcken, die sich innerhalb eines try-finally-Blocks befanden, behoben
  • Fehler bei exit innerhalb eines try-finally-Blocks unter bestimmten Umständen
  • Fehler beim Aufrufen von Script-Methoden aus dem Delphi-Programm heraus mit double-var-Parametern (Danke an Denstern)

Download-Link ist im ersten Post.

Grüße

[Piethan]

Morgen David,

ich möchte mich in deine ScriptEngine einarbeiten, dabei plane ich Funktionen zu schreiben, welchen ich die Parameter als Array (

Delphi-Quellcode:

type TMyRecordList = array of TMyRecord;

) übergeben möchte.

Folgenden Aufruf hatte ich daher von Seite der Delphi-Anwendung gedacht:

Delphi-Quellcode:

Method := RunTime.CodeAccess.FindMethod('get_Test', 'Records', [pmIn, pmResult], [btArray,btDouble]);
     if Method <> nil then
         ShowMessage(FloatToStr(RunTime.Call(Method, [MyRecordList])));

In der ScriptEngine sieht die Definition wie folgt aus:

Delphi-Quellcode:

type TMyRecordList = array of TMyRecordList;

implementation

function get_Test(MyRecordList: TMyRecordList): double; export;
begin
result:= MyRecordList[0].dbl_Betrag * 3.5;
end;

Die unit Records habe ich sowohl für Delphi und der ScriptEngine geschrieben. Da du ja bei den Arrays noch in der Entwicklung bist, interessiert mich, ob ich etwas falsch verstanden habe oder ob mein Weg so noch nicht möglich ist?

LG
Dirk