ScriptEngine II (v. 0.6.1)

[littleDave]

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 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 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 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 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 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 von EugenB:

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

Klären wir per PN

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

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.