ScriptEngine II (v. 0.6.1)

[littleDave]

Mal wieder ein neues Update :arrow: Version 0.4.1.0

Änderungen

• kleiner Bug in "Convert.IntToStr" behoben: ScriptEngine hat int64 als Parameter erwartet, nativ war aber nur ein integer angegeben
• Compiler überprüft jetzt die Unitnamen
• Compiler zeigt jetzt, wieviel Zeilen Quelltext er kompiliert hat
• Neu: Funktionspointer + Events
  Man kann jetzt entweder im Script selber eigene Events den Klassen hinzufügen (TNotifyEvent ist bereits vorhanden) oder direkt im Script Script-Funktionen (bzw. Klassen-Methoden) an Events von externen Klassen binden.

Ich weiß, das manche schon sehnsüchtig auf den Quelltext der IDE warten - ich verspreche, dass die den bis spätestens nächste Woche Montag veröffentlicht habe - um mir selbst etwas Druck zu machen ;-)

Grüße

[EugenB]

So dieser Montag ist gekommen. Wo ist der Quellcode :-D *druck mach* hehe

Solangsam gefällt mir die ScriptEngine :) die helper klassen und vorallem OOP :)

Nicht mehr lange und ich habe alles Notwendige Importiert, um zB Forms, TCustomControl, TCanvas usw nutzen zu können :), Dann nurnoch hoffen das der Import auch richtig funktioniert wie er soll :)

Weiter so mit der guten Arbeit ;)

MfG,
Eugen

[olee]

Ich wollte dein nettes Programm runterladen, aber der GFI Webmanager der bei uns läuft meldet eine Bedrohung in deinem Archiv und blockt es deswegen.

Zitat:

GFI WebMonitor 4 Secure Download
--------------------------------------------------------------
Downloading: http://www.delphipraxis.net/download.php?id=40712
Filename:SEII (v. 0.4.1.0).zip

Downloading file . . . . . . . . . . success
Size: 1.714 MB.
Scanning with BitDefender . . success
(2009-10-24 14:02)
Scanning with Kaspersky . . . threat detected
(2009-10-24 12:40)
Scanning with Norman . . . . . success
(2009-10-23 18:13)

Result:
Threat detected!
Scanned with Bitdefender Scanned with Norman Kaspersky: AV Engine failure.

Kannst du das bitte mal überprüfen?

MFG

[littleDave]

Lange ists seit dem letzen Update her

Zitat:

Zitat von olee

Ich wollte dein nettes Programm runterladen, aber der GFI Webmanager der bei uns läuft meldet eine Bedrohung in deinem Archiv und blockt es deswegen.

...

Kannst du das bitte mal überprüfen?

Ich hab die exe per UPX gepackt damit der Download nicht so groß ist - aber anscheinend kapieren manche AntiViren-Hersteller noch nicht, dass das nicht automatisch böse ist :wall:. Ich habs mit dem heutigen Update geändert und habe ein nicht-komprimierte exe mit hinein gesetzt.

Endlich wieder ein neues Update :arrow: Version 0.4.2.0

Nach einer etwas längeren Pause hab ich mal wieder eine neue Version hochgeladen. Dank EugenB's PM-Hilfe hab ich ein paar Punkte lösen können:

• Unter FPC konnte man keine Script-Events zuweisen, da FPC eine etwas andere Call-Convetion als Delphi hat. Dies hab ich nun behoben und es sollte nun auch unter FPC möglich sein, Scriptmethoden aus der Script-Engine heraus an externe Objekte zu binden.
• Bei Event-Typen haben die Helper-Klassen nicht funktioniert
• Im Linker gab es einen Bug bei einer Namesüberprüfung - die war nämlich case-sensitive und nicht case-insensitive.

Zudem hab ich nun endlich den Quelltext sowie den Quelltext der Packages mit in das Download-Packet gepackt.

Der Download ist wie immer im ersten Post (und SVN ist eh schon up-to-date)

[EugenB]

Moin

Ich freue mich das diese Bugs gefixt wurden, hatte jedoch noch keine zeit diese zu testen.

Da ich seit Samstag Windows 64 Bit benutze konnte ich SEII unter FPC bisher nicht lauffähig "machen".

Es sind 2 Fehler (vllt sogar mehr aber kamn nur bis zum zweiten^^) nur bei den Assembler funktionen:

- Wechseln von EBP, ESP auf R*; Funktioniert nach paar Recherchen -> lässt sich Compilieren bis ->
- PutOnFPUStackExtended (gibt es vllt eine andere lösung als dieses FLD zu nutzen?)

Da ich von Assembler generell kaum was verstehe (und nie verstehen werde^^) konnte ich da nur das erste Problem lösen.

Werde mir aber so schnell wie möglich Lazarus auf 32Bit umstellen damit ich dann auch endlich mal die Events & Packages testen kann :).

Mal sehen wie lange es dauert bis man die IDE & Packages auch unter FPC kompilieren kann (falls es noch nicht funtkioniert)

MfG,
Eugen

[EugenB]

Soo, habe mir jez die 32Bit Lazarus auf 64Bit Windows installiert, nun kann ich auch ganz normal wieder kompilieren

Die Packages habe soweit auch ganz einfach Konvertiert, soll ich die Patches dir zuschicken? Das selbe für die Samples? damit man nicht immer wieder die Samples neu per hand konvertieren muss ^^

Zu dem bei der IDE kann man diese leider nicht komplett auf Lazarus laufen lassen da zB TSynCompletionProposal (müsste die klasse sein) es bei Lazarus nicht gibt, ich wollte diese mal implementieren =D aber dazu hab ich zuwenig SynEdit erfahrung =D

Vllt eine IDE erstellen die für Delphi als auch für Lazarus (vom Quelltext her) funktionieren würde?

Mhm hätte da noch ne Frage zu den Packages, laut dem Quellcode der IDE werden alle Packages einmal am Start geladen, könnte man es nicht so machen das man die Packages erst lädt wenn diese im Script benötigt werden?

Ich hoffe ich habe mal am Wochenende Zeit mal mehr mit SEII zu arbeiten und zB auch die LCL Sachen als Packages zu konvertieren ;)

Die Events muss ich noch testen. (TODO)^^

Btw, wie wäre es wenn man die Convert-Klasse fast genauso wie in .Net macht ^^ Convert.ToString() welche dann fast für alle Typen den String dazu ausgibt und das selbe für Int, Double usw

Btw 2nd, es fehlt eigentlich nur Arrays OBWOHL man kann ja auch einfach zB TIntegerList nutzen, also wäre es dann nicht vllt besser einfach anstatt arrays im script zu implementieren die Listen nutzen?

So das man bei so einer Variable

X : Array[0..12] of Integer

auch sowas nutzen könnte

X.IndexOf ; X.Add ; X.Delete usw

PS.: So langsam bräuchte ich zugriff aufs SVN und ggf deine email =D
PPS.: Wie wäre es wenn du SEII mal im Lazarus-Forum und/oder in der Mailliste präsentierst?^^ Dann würden diese bestimmt auch viele Nutzen ggf bei einigen Problemen helfen :)
PPPS.: Mach weiter so, diese Script Engine stellt so langsam alle anderen in den Schatten -> Ich glaub ich sollte mal ne Übersicht machen, =D habe solangsam so viele Script Engines ausprobiert mit Lazarus =D

So und nun gute Nacht =D,
Eugen

[EugenB]

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE :)

Dave ist wohl wieder sehr beschäftigt ^^.

Mal sehen ob auch eigene Plugins laufen. *test*

MfG,
Eugen

[EugenB]

Zitat:

Zitat von EugenB

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE :)

Dave ist wohl wieder sehr beschäftigt ^^.

Mal sehen ob auch eigene Plugins laufen. *test*

MfG,
Eugen

Zufrüh gefreut....


Die Plugins die man mit Lazarus Kompiliert egal ob mit "{$MODE DELPHI}" oder "{$MODE OBJFPC}{$H+}" funktionieren sowohl in der vorkompilierten IDE als auch bei selbst erstellten Programmen nicht.

Folgende Meldung versuche ich schon seit Tagen zu beseitigen:

Code:

Error: [Streams] [Line 14]: Unexpected end of file
Error: [Streams] [Line 0]: Could not compile the unit "Streams"
Error: [Collections] [Line 6]: Could not add the unit "Streams"
Error: [Collections] [Line 0]: Could not compile the unit "Collections"

Wenn ich mir jetzt diese Streams angucke, wie sie in der IDE aussieht, sehe ich kein "Unexpected end of file", alle Quellcodes sind normal angezeigt. :(

Also gibt es wohl noch ein paar Bugs mit Packages unter Lazarus :(

Hoffe das sich Dave in absehbarer Zeit wieder meldet und diesen fiesen Käfer bekämpft. :stupid:

PS: Die Events funktionieren jetzt auch unter Lazarus =D (nebenbei mit getestet :stupid:)

MfG,
Eugen

[littleDave]

Zitat:

Zitat von EugenB

Moin

Ich freue mich das diese Bugs gefixt wurden, hatte jedoch noch keine zeit diese zu testen. Da ich seit Samstag Windows 64 Bit benutze konnte ich SEII unter FPC bisher nicht lauffähig "machen". Es sind 2 Fehler (vllt sogar mehr aber kamn nur bis zum zweiten^^) nur bei den Assembler funktionen:

- Wechseln von EBP, ESP auf R*; Funktioniert nach paar Recherchen -> lässt sich Compilieren bis ->;
- PutOnFPUStackExtended (gibt es vllt eine andere lösung als dieses FLD zu nutzen?)

Da ich von Assembler generell kaum was verstehe (und nie verstehen werde^^) konnte ich da nur das erste Problem lösen. Werde mir aber so schnell wie möglich Lazarus auf 32Bit umstellen damit ich dann auch endlich mal die Events & Packages testen kann :).

Mal sehen wie lange es dauert bis man die IDE & Packages auch unter FPC kompilieren kann (falls es noch nicht funtkioniert)

MfG,
Eugen

Die Script-Engine ist unter 64-Bit nicht lauffähig. Das liegt zum einen daran, dass ich mich noch nicht mit den 64-Bit-Assembler-Code auseinander gesetzt habe. Zum anderen kann ich das nicht testen, da ich "nur" ein 32-Bit-System habe. Daher wird sich bis auf weiteres an der 64-Bit-Unterstützung nichts ändern können :-?

Zitat:

Zitat von EugenB

Soo, habe mir jez die 32Bit Lazarus auf 64Bit Windows installiert, nun kann ich auch ganz normal wieder kompilieren. Die Packages habe soweit auch ganz einfach Konvertiert, soll ich die Patches dir zuschicken? Das selbe für die Samples? damit man nicht immer wieder die Samples neu per hand konvertieren muss ^^

Das kannst du gerne machen. Ich werde die Änderungen dann einpflegen.

Zitat:

Zitat von EugenB

Zu dem bei der IDE kann man diese leider nicht komplett auf Lazarus laufen lassen da zB TSynCompletionProposal (müsste die klasse sein) es bei Lazarus nicht gibt, ich wollte diese mal implementieren =D aber dazu hab ich zuwenig SynEdit erfahrung =D. Vllt eine IDE erstellen die für Delphi als auch für Lazarus (vom Quelltext her) funktionieren würde?

Das übersteigt im Moment mein Zeitkontingent. Ich bin im Moment bis oben hin ausgelastet, daher ist es für mich im Moment nicht möglich, eine komplett neue IDE zu erstellen. Mich wundert es aber, dass es kein TSynCompletionProposal unter Lazarus gibt :-?

Zitat:

Zitat von EugenB

Mhm hätte da noch ne Frage zu den Packages, laut dem Quellcode der IDE werden alle Packages einmal am Start geladen, könnte man es nicht so machen das man die Packages erst lädt wenn diese im Script benötigt werden?

Das wird nicht so wirklich gehen: in den Packages ist da der Quelltext für die Script-Engine drinnen. Somit würde die Script-Engine das Script nicht kompilieren können, da der Quelltext fehlt.

Zitat:

Zitat von EugenB

Btw, wie wäre es wenn man die Convert-Klasse fast genauso wie in .Net macht ^^ Convert.ToString() welche dann fast für alle Typen den String dazu ausgibt und das selbe für Int, Double usw

Das könnte man sich mal überlegen. Ich muss mal schauen, wie ich das am besten umsetze ... Wahrscheinlich wird es einfach so sein, dass man für die jeweiligen Basistypen eine Helper-Klasse erstellt.

Zitat:

Zitat von EugenB

Btw 2nd, es fehlt eigentlich nur Arrays OBWOHL man kann ja auch einfach zB TIntegerList nutzen, also wäre es dann nicht vllt besser einfach anstatt arrays im script zu implementieren die Listen nutzen?

So das man bei so einer Variable

X : Array[0..12] of Integer

auch sowas nutzen könnte

X.IndexOf ; X.Add ; X.Delete usw

Es fehlen noch ein paar weitere wichtige Dinge: so kann man z.B. noch keine Records aus der Script-Engine heraus oder in die Script-Engine hinein zu schicken. Arrays wird es auf jeden Fall geben, jedoch weiß ich noch nicht, wann ;-). A

Zitat:

Zitat von EugenB

PS.: So langsam bräuchte ich zugriff aufs SVN und ggf deine email =D

Klären wir per PN

Zitat:

Zitat von EugenB

PPS.: Wie wäre es wenn du SEII mal im Lazarus-Forum und/oder in der Mailliste präsentierst?^^ Dann würden diese bestimmt auch viele Nutzen ggf bei einigen Problemen helfen :)

Leider fehlt mir im Moment die Zeit sowas zu leiten, daher muss ich damit noch etwas warten.

Zitat:

Zitat von EugenB

PPPS.: Mach weiter so, diese Script Engine stellt so langsam alle anderen in den Schatten -> Ich glaub ich sollte mal ne Übersicht machen, =D habe solangsam so viele Script Engines ausprobiert mit Lazarus =D

Danke für das Lob, jedoch fehlt da wie gesagt noch das ein oder andere.

Zitat:

Zitat von EugenB

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE :) Dave ist wohl wieder sehr beschäftigt ^^. Mal sehen ob auch eigene Plugins laufen. *test* ...

Zitat:

Zitat von EugenB

Zufrüh gefreut....

Die Plugins die man mit Lazarus Kompiliert egal ob mit "{$MODE DELPHI}" oder "{$MODE OBJFPC}{$H+}" funktionieren sowohl in der vorkompilierten IDE als auch bei selbst erstellten Programmen nicht.

Folgende Meldung versuche ich schon seit Tagen zu beseitigen:

Code:

Error: [Streams] [Line 14]: Unexpected end of file
Error: [Streams] [Line 0]: Could not compile the unit "Streams"
Error: [Collections] [Line 6]: Could not add the unit "Streams"
Error: [Collections] [Line 0]: Could not compile the unit "Collections"

Wenn ich mir jetzt diese Streams angucke, wie sie in der IDE aussieht, sehe ich kein "Unexpected end of file", alle Quellcodes sind normal angezeigt. :(

Also gibt es wohl noch ein paar Bugs mit Packages unter Lazarus :(

Das liegt wohl daran, dass (soweit ich weiß) Lazarus UTF-8-Strings verwendet und der Compiler an der Stelle wahrscheinlich abbricht. Muss aber da nochmal genauer schauen. Jedoch gibt es zuerst ein ganz wichtiges Update:

:arrow: Version 0.4.3.0

Ich habe die Script-Engine bereits in einem großen Projekt im Einsatz und bin somit auf ein paar große Bugs gestoßen:

• Da ein Unit ja aus mehreren Dateien bestehen kann, ist es wichtig, die einzelnen Dateien in der richtigen Reihenfolge zu kompilieren. Dafür gibt es bei nativ eingebundenen Units bereits eine Priorty-Property. Diese Priorität gab es bisher in den Packages nicht. Daher habe ich eine optionale Funktion in die Package-API hinzugefügt. Diese Funktion heißt ganz einfach "IsExtender". Wenn diese Funktion "True" zurück gibt, wird die Unit erst später kompiliert. Hier mal ein Beispiel:
  
  Package 1: Streams: Dieses Package stellt die Basis-Klasse "TStream" in der Unit "Streams" zur Verfügung.
  Package 2: IO: Dieses Package stellt "TFileStream = class(TStream)" ebenfalls in der Unit "Streams" zur Verfügung.
  
  Wenn jetzt das Package IO mit der Unit "Streams" vor der Basis-Units "Streams" aus dem Package 1 zuerst kompiliert wird, kann das Package nicht kompiliert werden, da TStream noch nicht bekannt ist. Daher kann jetzt das Package 2 einfach bei der Unit "Streams" einfach sagen "IsExtender = True". Dann wird der Unit aus Package 2 erst nach der Unit von Package 1 kompiliert. *puh* - hoffe das war jetzt ein wenig verständlich ;-)
• Wenn man eine Klasse als "forward" deklariert (also TMyKlasse = class;), und man diese Klasse in einer anderen Klasse als Variable speichert, kam es zu Zugriffsverletzungen
• try-except und try-finally Blöcke haben die Optimierung des Linkers nicht wirklich überstanden. Somit haben die Sprungadressen an eine falsche Stelle gezeigt.
• Es gab einen Fehler, wenn man Script-Methoden als TMethod benutzt und diese Script-Methoden strings in den Parametern hatten
• In der Runtime wurde das "not" bei boolean-Werten nicht immer korrekt ausgeführt
• Wenn man aus dem Programm heraus eine Script-Methode aufruft und diese dann eine Exception wird, wird der Script-Stack wieder hergestellt, damit man das Programm trotzdem noch weiter verwenden kann.
• Das exit-Statement sollte jetzt funktionieren
• Es gab einen Stack-Overflow wenn eine Unit sich selbst in die Uses-Liste mit aufgenommen hat.

Den Download gibts wie immer im ersten Post.

[littleDave]

Neues Update :arrow: Version 0.4.4.0

Nach langer Zeit gibt es mal wieder ein Update. Changes:

• Neue Features
  • Es gibt eine neue Include-Unit: uSE2IncTypes. Darin ist bisher TPoint und TRect mit einigen Funktionen deklariert
  • Für jeden Standarttyp gibt es jetzt eine .ToString - Methode
  • Mann kann jetzt Konstanten zu Records, Klassen und Helper-Klassen hinzufügen
    Nun ist es möglich aus Records aus der Host-Anwendung an die Script-Engine zu übergeben - und zurück. Jedoch gibt es dabei leider noch ein paar Einschränkungen:
    • Alle records in der Host-Anwendung müssen als packed record deklariert sein
    • Es können noch keine verschachtelten Records übertragen werden.
    • Records, in denen sich strings befinden, können ebenfalls leider noch nicht übertragen werden
    • Die Funktionalität wurde noch nicht mit FreePascal getestet.
  • Man kann nun externe Methoden auch zu Records hinzufügen
• Änderungen im Script-Quelltext
  • Farbkonstanten (cl*) sind jetzt in die Colors-Klasse (z.B. Schwarz: Colors.Black)
• Behobene Bugs
  • Bei überladenen Methoden gab es ein Problem, sobald verschiedene Rückgabetypen verwendet wurden
  • Single oder Double-Konstanten waren immer NaN
  • Wenn bei Konstanten ein Typ mit angegeben wurde, wurde dieser nicht verwendet
  • Bei überladenen Methoden gab es ein Problem mit der Konvertierung der Parameter
  • Bei der Code-Completion konnte es vorkommen, dass der selbe Eintrag mehrmals vorkommt
• Performance
  • Die Ausführungsgeschwindigkeit wurde um bis zu 50% verbessert

Der Download befindet sich wie immer im ersten Post

Grüße