RUTIS Engine (Scripting) [WinCE spinnt]

[olee]

DIES IST DIE ALTE VERSION VON RUTIS
Die neue Version gibts hier: RUTIS v2
----------------------------------------------
Hi,
Hier möchte ich euch eines meiner größten Projekte vorstellen.

RUTIS

Die "RunTime Script Engine" (RUTIS Engine) dient dazu, Scripte zur Laufzeit zu compilieren und auszuführen, um z.B. Die Funktionen von Programmen zu verändern, ohne diese neu zu compilieren.
Durch eine sehr hohe Geschwindigkeit lassen sich sogar ganze Programme allein mit einem solchen Script erstellen.
Die RUTIS Engine kann mehrere Compiler unterstützen wobei der Standardcompiler mit einem Delphi/Pascal Syntax arbeitet.

- - - HINWEIS: INFOS ETWAS VERALTET - WERDEN BEI GELEGENHEIT KORRIGIERT - - -
RUTIS bietet eine große Funktionsvielfalt:

• Globale sowie lokale Variablen
• Verschachtelbare Funktionen und Methoden, die auch rekursive Algorithmen lösen können.
• Beliebige Deklaration von Records
• Unterstützung von Pointern und Arrays
• Einfache Verknüpfung von Hostprogramm und Script mittels speziellen, beliebig erstellbaren Verbindungsfunktionen.
• NEU: Methode-Variablen (bisher jedoch nur parameterlose Prozeduren)
• NEU: Formular Interface, wodurch sich ganze Anwendungen mit GUI erstellen lassen! :mrgreen:
• NEU: Aufruf von DLL-Funktionen über die deklaration im Script als 'external' ! (Hier ein DANKE an 'Astat')
• uvm.

Das sollte vorerst an Informationen reichen.

RUTIS PROJEKTSEITE (Downloads, Infos usw.)
SVN-Portal: http://www.xp-dev.com/sc/77518

INFO : RUTIS unterliegt einer Creative Commons BY-NC-SA (DE) Lizenz
INFO 2: Die nachfolgenden Links könnten des öfteren nicht funktionieren, da sie nach jedem neuen Upload ungültig werden. Auf der Projektseite dagegen sollten
die Downloadlinks immer funktionieren. Ich entschuldige mich hier auch für eine solche Faulheit, die Links nur selten zu aktualisieren ^^
RUTIS Setup 1,04 MB RUTIS (zip) 1,28 MB RUTIS (Source) 2,08 MB

MFG

[omata]

Es fehlt: File_Manager.pas und myUtils.pas

[olee]

Danke für den Hinweis ich habe die Dateien mit angehängt.

ANBEI: RESTLICHE DOWNLOADS, DIE NICHT MEHR IN DEN ERSTEN POST GEPASST HABEN

MFG

[EugenB]

Was ist an deiner Script-Engine besser als an Sysygy Script Engine oder PascalScript?

Wie ich das bisher sehe sind se alle fast gleich.

Was ich schon lange suche ist eine ScriptEngine die OOP unterstützt und leichtes kommunizieren zwischen Script<>Programm und unter Lazarus läuft ^^, hab schon langsam alle ScriptEngines durch (Python, Lua, PascalScript, Sysygy ScriptEngine) ^^

[mschaefer]

Muß Sie dass denn sein? Für ein Schulprojekt ist das doch eine Prima Sache? // Grüße / Martin

[EugenB]

Stimmt auch wieder.

I'm sry.^^

Es ist schon wahnsinnig das das ein Schul-Projekt ist. Kommt mir bekannt vor^^, ich nahm auch immer extreme Projekte an und schaffte diese sogar.

Einerseits Lob an dich.

Anderseits wenn es OOP kann, bin ich begeistert und werde sehr schnell der erste Tester ^-^.

MfG,
Eugen

[alzaimar]

Versuch mal DWS "Delphi Web Script" (gibts bei Sourceforge)... Geht aber nicht mit Lazarus, dafür OOP und 99.9% kompatibel zu Delphi (ältere Versionen).

Ich muss auch sagen: Eine Leistung, vor der ich den Hut ziehe.

[olee]

Erstmal Danke für eure Antworten.

Aber @EugenB:
Ich finde das etwas verletzend, in so einer Art darauf hinzuweisen, was denn
jetzt bei meiner Engine besser wär, als bei der eines anderen.
Wenn es so ginge wieso sollte man dann überhaupt noch sowas programmieren...
Ich nehms dir aber nicht übel :wink:

Aber als Antword darauf:
Die Geschwindigkeit!
Ich habe mir mal die Sysygy angekuckt und gesehen, dass die mit Variant arbeitet, was nicht gerade
schnell ist.
Ich habe es zuerst auch der einfachheit wegen mit Variant gemacht, danach aber einen eigenen Datentyp
geschrieben, der wie Variant arbeitet.
Dieser ist aber SEHR viel schneller, da er auf die Aufgaben in der Engine optimiert ist.

Delphi-Quellcode:

  TRutisStackItem = record
    case VTyp : TRutisVarType of
      vArray,
      vPointer  : (VPointer : PRutisStackItem);
      vInteger  : (VInteger : Integer);
      vSingle   : (VSingle  : Single);
      vBoolean  : (VBoolean : Boolean);
      vString   : (VString  : PAnsiString);
  end;

Die Geschwindigkeit ist dadurch um einiges gestiegen.
Insgesamt ist die Engine stark auf Geschwindigkeit ausgelegt.

Doch am wichtigsten: Die Engine ist NOCH NICHT FERTIG !!

Das habe ich ja schon erwähnt und deswegen ist es nicht verwunderlich, dass es noch kein OOP gibt :wink:

Wer sich mal für die Geschwindigkeit interessiert, kann ja mal das Script "TEST Speed.rutis"
ausführen.
Da ist auch nochmal ein Vergleich von den zwei Typen von Externen Funktionen, die die
Engine unterstützt
(Die Eine macht einen Umweg über Variant, die Andere schreibt direkt auf den Stack)

MFG

[EugenB]

Hallo olee,

Ich entschuldige mich, das es so verletzend rüber kam. :( Wird nicht mehr vorkommen.^^

Zitat:

Zitat von olee

Aber als Antword darauf:
Die Geschwindigkeit!

Ich werd mir mal die Tests durchgucken, hört sich doch jetzt gut das es sogar Schneller als die Sysygy Engine ist =)

Zitat:

Zitat von olee

Doch am wichtigsten: Die Engine ist NOCH NICHT FERTIG !!

So etwas darf nie fertig werden, wirst du dieses Projekt, auch nach dem die Schulzeit vorbei ist, auch weiter "pflegen" updates posten etc? Denn dann würde es große Konkurrenz zu PascalScript machen :)

Zitat:

Zitat von olee

Das habe ich ja schon erwähnt und deswegen ist es nicht verwunderlich, dass es noch kein OOP gibt :wink:

Ui, also ist OOP geplant? =) :wink:

MfG,
Eugen

[EugenB]

Ich hab mich etwas mehr mit RUTIS auseinander gesetzt, vorallem mit dem Quellcode.

Nach 300 $IFDEFs konnte ich es auch unter Lazarus Compilieren, musste dabei leider OpenGL aus kommentieren, deswegen gehen auch einige Tests nicht mehr

Aber der Speedtest funktioniert, immerhin^^.

Wie wäre es wenn du für das Projekt, da es ja OpenSource ist, bei code.google.com oder bei xp-dev.com einen kostenlosen svn server dir dort erstellst, dann könnten man leichter die ganzen änderungen zuschicken^^

PS:
Funktioniert dieser FPC Code auch unter Delphi? (hab keins zum Testen):

Delphi-Quellcode:

//Delphi Code
fCode := @ScriptData.Code;

//FPC Code
fCode := @ScriptData^.Code;

Wenn dies auch Funktioniert, dann würde man sich 200 solcher IFDEFs Sparen

Delphi-Quellcode:

fCode := @ScriptData{$IFDEF FPC}^{$ENDIF}.Code;

Es gibt ja auch einen $MODE DELPHI, aber ich habe gelesen das es dann irgendwo zu größeren Problemen führt oder sowas.

PPS:
Bei überfliegen des Codes, kam mir die Frage, könnte man mit dieser ScriptEngine dann wohl auch andere Sprachen nutzen? also zb
Script im C-Style, PHP-Style o.ä?

Ich mein jetzt nicht das es auch andere Scritpsprachen sein sollen (Pascal reicht völlig aus ^^), ich will es nur wissen ob es möglich wäre^^

MfG,
Eugen

[olee]

Ganz recht!

Es sind mehrere Scriptsprachen möglich.

Es gibt immerhin eine TRutisCompiler Klasse, von der dann z.B. TRutisCompilerDelphi abgeleitet ist, und
sogar eine Variable ScriptLanguage, wo man später eine sprache auswählen könnte.

Ich bin mir nur noch nicht sicher, ob und welche Syntax ich einbauen sollte (Vllt. auch einen eigenen).

Delphi-Quellcode:

fCode := @ScriptData^.Code;

Funktioniert auch in Delphi und ich habe es kurzerhand in den Code eingebaut.

Aber die OpenGl-demos kannst du doch mit der schon kompilierten Version testen :wink:

Aber nochmals DANKE für das Interesse und deinen Beitrag :mrgreen:

Ich werde demnächst eine neue Version uploaden.

Was ich noch vorhabe:

• Freie Typendeklaration d.h. z.B. TInfoInteger = Integer
  Pointer-Typen (PBall = ^TBall) wird es wohl nicht geben, da sie unnötig sind.
• Mit 1. -> Methodenvariablen (var proc: TDoSoThProc) und Vorausdeklaration von Methoden (also über implementation)
• Finalization für Objekte/Vars (also freigeben von Arrays (Strings werden schon automatisch freigegeben^^))
• String und Char Support (z.B. AString[i] := #13)
• Sobald es möglich wird OOP :cyclops:

MFG

[littleDave]

Ich wollt mich auch mal zu der Script-Engine äußern.

Also erstmal: ein wirkliches Lob - ich weiß was für ein Aufwand es ist, so was zu schreiben. Ich hab mir das Testprogramm angeschaut und finde es wirklich gut.

Jedoch wollt ich noch kurz was sagen (jedoch wirklich ohne Konkurenzgedanken!):

Zitat:

Zitat von olee

Ich habe mir mal die Sysygy angekuckt und gesehen, dass die mit Variant arbeitet, was nicht gerade
schnell ist.

Bei meiner Script-Engine gibt es den Delphi-Typ Variant nicht und er wird auch nicht benutzt. Die einzige Funktion, die Variant unterstützt ist die "Call"-Methode, die als Rückgabewert den Typ Variant hat (die Funktion ist dazu da, um einzelne Script-Funktionen ausführen zu können). Mein Datentyp hat zwar im Namen zwar "Variant" stehe, jedoch ist der Typ an sich (wie bei dir) nen Record mit ner case-anweisung variabel gestalltet ist.

Delphi-Quellcode:

type
  PSygScript_Variant = ^TSygScript_Variant;
  TSygScript_Variant = record
     ...
     case Byte of
      btU8             : (tu8         : TbtU8);   // byte
      btS8             : (ts8         : TbtS8);   // shortint
      btU16            : (tu16        : TbtU16);  // word
      ....
  end;

Nur um das mal richtig darzustellen.

Ich denke, dass die Engine viel potential hat. Noch mal zum OOP: eine Script-Engine ist in meinen Augen nicht dazu da, um Datentypen zu definieren, sondern nur um den Programmablauf zu steuern. Ich will zwar in meiner neuen Script-Engine irgendwann mal OOP unterstützen, jedoch ist das wirklich nur zweitrangig.

Ich wünsch dir auf jeden Fall viel Glück und Erfolg mit der Script-Sprache und hoffe, dass es gut für dich weiter geht - und das Beste ist immernoch: man weiß sehr viel besser über die internen Abläufe des Compilers, über die CPU usw. bescheid :-).

Ach ja, was mir noch aufgefallen ist:

Delphi-Quellcode:

var i: integer;

implementation

begin 
  i := 2.1; // <- das sollte nicht funktionieren
end.

Zudem würd ich noch die Operatoren mod shr und shl einbauen - das ist schon relativ wichtig.

Grüße

[olee]

Hm vllt. war das auch nur eine etwas alte Version der Sysygy oder ich hab mich geirrt sry :wink:

Aber ich habe noch eine Menge Arbeit vor mir.

Am meisten zerbreche ich mir momentatn den Kopf darüber, wie ich geschickt die Typen abspeichere.
Ich möchte dabei möglichst EIN array mit allen Typen haben... :?


MFG

[olee]

Mal eine kleine Info, die bestimmt einige interessieren wird:

Die Engine wird ebenfalls mit FPC kompilliert für PocketPc :-D

In einer älteren (sehr viel älteren :-D) Version hatte ich es sogar schon mal auf dem PPC laufen

MFG

[olee]

So ich habe mal eine neue Version hochgeladen.

Neuerungen:

• Bugfixes
• Conditions werden nun als Ausdrücke erkannt.
  (Bsp: Bool := Bool2 and (X = 3);)
  Vorher gab es eine eigene Funktion zur erkennung von Conditions, sodass Anweisungen wie
  die genannte nicht möglich waren.
• Break und Continue stehen nun zur Verfügung
• Length, High und SetLength für Strings
• uvm.

Außerdem habe ich eine zweite Version hochgeladen, die die komplette benötigte Source enthält
und so direkt kompilierbar ist (Wenn doch noch eine Unit fehlen sollte bitte melden).

Derzeit empfohlene Scripte:

• Skeleton gl 2.rutis
• DEMO_Gravity_OpenGl.rutis
• GAME ICY TOWER.rutis
• DEMO_Gravity_Canvas.rutis

MFG

[olee]

So ich habe mal die "IDE" vebessert - sowohl in Funktion, als auch Design.

Ich hoffe es gefällt euch.

MFG

[olee]

So ich habe nochmal einige kleine Bugfixes gemacht und die IDE verbessert.

Wer will darf selbstverständlich auch mal selbst erstellte Scripte hier hochladen.

Mich würde es auch mal interessieren, wie gut ihr die Bedienung u.a. findet.

Also wer Lust hat: Einfach mal ein geschriebenes Script hochladen :stupid:

MFG

[mimi]

Das Projekt ist von der Idee her nicht schlecht. Für ein sehr Aktuelles Projekt, suche ich genau sowas.
Eine universale Script Engine.

Du hast geschrieben, dass die Sprache egal ist. Prima. Also könnte ich zum testen theoretisch, erst einmal die Objekt Pascal Sprache nehmen und später weitere die ich benötige hinzufügen z.b. wie JavaScript, JScript, VBScript und soweiter oder sogar eine Eigene.

[olee]

So nach langem Schweigen darf ich mal wieder meine Konkurrenz gegenüber
der Sysygy Engine ankündigen :twisted:

Ok (fast-) Spaß beiseite:

Ich habe natürlich nicht an der Arbeit an RUTIS aufgehört, aber nur ne kleine Pause gemacht.

Ich habe mich in der Zeit mal meinem anderen laufenden Projekt LOZ zugewandt.

Jetzt aber kehren ich und RUTIS zurück ... mit neuen Ideen :-D

Ich werde mich jetzt von ein paar Sachen trennen, und neue geniale Funktionen einbaun.

--------------------------------
Dabei die größte Änderung:
--------------------------------
Ich werde jetzt nichts mehr in den Stack als "Selfmade-Variant" ablegen, sondern
ich werde die Daten unmittelbar als (wenn man es so nennen kann) "Datenstream" abspeichern.
D.h. die Daten liegen so im Speicher, wie es auch bei Delphi der Fall ist.
Der Vorteil:
Man kann ganze Records aus dem Hauptprogramm direkt in das Script laden oder sogar
aus dem Script (über Pointer) heraus bearbeiten.

Das bedeutet im Klartext:
MEHR GESCHWINDIGKEIT UND FUNKTIONALITÄT ... und das nicht gerade wenig ^^

Was noch kommt:

• Die Typen werden vollkommen neu abgespeichert.
• Es werden neu Variablen zur Verfügung stehen:
  Von Byte über ShortInt biz zu Integer und Cardinal...
  Von Single über Real bis zu Extended
  Vermutlich kann man später eigene Varaiblentype (sowas wie ein TVector) definieren, die eigene Operatorenfunktionen ("Vector := Vector1 + Vector2" oder "Vector := Vector1 * Vector2") besitzen, deklarieren (aber nur aus dem Hauptprogramm raus)
• Es sind dann auch solche Konstrukte möglich:
  "TMyInteger = Integer",
  "TIntArray = Array of Integer" usw.
• Methoden werden auch als Typen deklariert -> es kann wie in Delphi Methoden-Variablen (events) geben.
  "TUpdateProc = procedure(time: Single);" usw.
• UVM.

Ich werde euch sicherlich weiterhin auf dem Laufenden halten.

MFG

[mimi]

Kling gut.

Wenn ich deine Script Engine auch unter FPC zum laufen bekomme, wenn es soweit ist. Im Moment habe ich noch keine Verwendung dafür, allerdings später währe so eine Script Sprache nicht schlecht. Inzwischen habe ich theoretisch vier zur Auswahl, mal sehen, welche ich als erste einbaue *G*.

[olee]

Dann wird es dich freuen zu hören, dass RUTIS schon unter Lazarus zu kompillieren ist.

Wie ich bereits erwähnt haben, habe ich es mit Lazarus sogar für PocketPC kompilliert,
sodass ich unterwegs kleine Programme schreiben und testen kann.

Bisher komme ich super vorran nur eine Sache bereitet mir noch Kopfzerbrechen:
--> Ich habe Probleme mit der Typkonvertierung bei Ausrücken.
Z.B. "x := 3.5 / 7;" usw.

Aber ich denke ich werde es schaffen.

MFG

[mimi]

Prima. Dann warte ich mal die nächste Version ab

[olee]

So!

Wie versprochen halte ich euch mal auf dem Laufenden:

Ich komme sehr gut vorran.

DIe Engine lässt sich (mit teilweise auskommentierten Teilen) wieder kompillieren.
(Das soll eine gute Nachricht sein :wink: )

Außerdem klappen simpelste Scripts sogar schon

Bsp:

Delphi-Quellcode:

begin
  write 'Ein String';
  write EinSmallIntWert;
  write EinIntegerWert;
  write EinSingleWert;
  write EinExtendedWert;
end.

Als nächstes werde ich arithmetische Operationen wieder ermöglichen (+, -, *, /) mit den
dazugehörigen Konvertierungsfunktionen (Single->Double, Double->Extended, ShortInt->AInteger, usw.)

MFG

[mimi]

Zitat:

write 'Ein String';

Hast du hier nicht die Klammern vergessen ? Oder ist das deine eigene Scrip Sprache jetzt ?

[olee]

Dieses Code-Beispiel stammte aus der Script-Engine :wink:

Achja ich bin weiter gekommen:

Es funktionieren jetzt die arithmetischen Operationen also:

Delphi-Quellcode:

begin
  write 5 + 2;
  write 5 - 2;
  write 5 * 2;
  write 5 / 2;
end;

Output:
"7" "3" "10" "2"

Als nächstes kommt das Wichtigste und auch das Schwerste:
Die Variablen (i := 5; usw.)

Ich werde mich beeilen, sodass RUTIS möglichst bald wieder einigermaßen funktionstüchtig ist

MFG und bis bald

[olee]

So ich darf wiedermal eine tolle Nachricht überbringen:

Es funktionieren die Variablen und Externen-Methoden wieder eingeschränkt.

Also Sachen wie dies hier

Delphi-Quellcode:

begin
  i := 2+3;
  write i*2;
end

(Output = "10") funktionieren schon!

Ich denke ich werde die Engine morgen halbwegs fertig bekommen,
vor allem da ich heute zwar nur wenig daran gearbeitet habe, aber trotzdem wieder so weit kam.

Als nächstes werde ich auch de Debugger wider aktivieren (momentan auskommentiert).

Vor allem der wird euch bestimmt gefallen.

Durch das neue System zur Speicherung der Variablen und Typen werden die Infomationen die dieser
liefern kann viel detaillierter sein.

Auch eine "Auswerten / Ändern" Funktion wird es geben
(wobei Auswerten ja schon immer sogar zur Laufzeit des Scriptes klappte)

MFG

[olee]

So es sieht sehr gut aus.

Inzwischen funktionieren mansche Scrips schon wieder, und und ich habe auhc viele der Externen Methoden
wieder "einkommentiert".

Leider ergeben sich noch Probleme mit Strings.

Vorher konnte ich einfach beim laden auf den stack eines Strings diesen kopieren, bearbeiten, auf den String speichern, wo dieser später sein soll und die Kopie anschließend löschen.

Das war sehr unkompliziert, weil der Datentyp der jeweiligen Variable immer mit auf dem Stack lag.

Nun ist das ein wenig komplizierter, aber ich denke ich bekomme es hin.

Wenn nun bald Arrays und Strings wieder einwandfrei funktionieren, werde ich vermutlich das erste release der Version 2.0 rausgeben.


MFG

[olee]

So ich denke ich bin euch ein paar Update-Infos schuldig :oops:

Inzwischen darf ich stolz verkünden, dass seit gestern RUTIS wieder (vllt. noch fast) vollständig funktionsfähig ist!

Es klappen nun wieder Arrays, Records, Pointer, interne Proceduren und Funktionen, externe Funktionen und eben der ganze Rest.

Ich werde als nächstes wohl folgendes machen:

• Bug: Es gibt manchmal noch Speicherfehler in Scripts.
  D.h. es werden zugewiesene Speicher von Strings oder Arras nicht wieder freigegeben.
• Eigene Typen (außer Records) deklarieren:
  type
  TMyInteger = Integer;
  PMyRecord = ^TMyRecord;
• Bessere Fehlermeldungen bei falschen Eingaben.
• MENGENTYPEN!
• Methodenvariablen (var Proc: TProcedure)
• uvm.

Der Download der aktuellen Version befindet sich wie gewohnt im ersten Post!

Viel Spaß!

MFG

[olee]

So ich habe nochmal ein Update hochgeladen, da in dem letzten ein Fehler war.

Nun sollte alles funktionieren.

Ich würde mich über etwas feedback sehr freuen.

MFG

[olee]

Hmm ...
etwas still hier geworden.

Wie auch immer.

es gbt nun eine NEUE VERSION!

• Stark verbesserter Script-Editor mit Suchen/Ersetzen u.a.
• Runtime-Anwendung
  --> Führt Scripte nur aus, ohne deren Code anzuzeigen u.a.
• Code Verschlüsselung
  Scripte können nun in einer (bisher einfachen) verschlüsselten Version abgespeichert werden,
  sodass sie nur noch ausgeführt, und nicht mehr abgeändert werden können.
• Bugfixes uvm.

If würde mich über etwas Feedback so langsam wirklich sehr freuen... :mrgreen:

MFG

[olee]

UPDATE

Ich hab nochmal etwas an RUTIS gearbeitet und vor allem die Funktionen im 3D-Bereich überarbeitet.

Ich würde mich freuen, wenn jemand mal etwas zu der neuen Funktionsweise etwas sagen würde, da dies
seitdem schon das 3. Update ist, ohne das jemand zumindest seine Meinung bekannt gegeben hat.
(Auch die Downloadzahlen standen im Keller (2-4 Downloads).)

Also ich würde mich sehr über etwas Feedback freuen.

MFG

[olee]

Ich baue nun ein Textur-Interface für die OpenGl Schnittstelle ein, sodass bald Texturen benutzt werden können.

Außerdem empfehle ich euch mal das Script "2.6D Simple.rutis" zu testen,
das die OpenGl funktionen bisher am ausführlichsten vorführt (bzw. "DEMO Gravity Gl.rutis").

PS: Warum testet das keiner ich hab 0 Downloads da stehen?

MFG

[olee]

UPDATE

ES IST ENDLICH WIEDER SOWEIT!

Ich kann nun stolz verkünden, das die NEUE VERSION von RUTIS draußen ist!!

Es gibt viele Neuerungen:

• Formular-Interface, das es einem erlaubt ganze GUI-Anwendungen zu schreiben
• Etliche Verbesserungen im Editor
• Neue Anwendung: Die RUTIS-EXe
  Sie erlaubt einem, ein Script in eine EXE zu kompillieren, damit die Source nicht mehr ausgelesen kann und man das Programm bequem ausführen und weitergeben kann.
• Anpassungen:
  Es ist nun Sichergestellt, das z.B. ein Array in RUTIS mit einem Array in Delphi kompatibel ist.
  Das heißt: Man kann, nachdem man sich den Pointer des Arrays in RUTIS geholt hat, dieses Array in RUTIS verwenden und bearbeiten, sodass diese Änderungen auch im Hauptprogramm auftreten!
  Uvm...
• Bugfixes
• uvm.

Es lohnt sich wirklich dieses Update mal genauer anzuschauen!
Der Download befindet sich wie immer im ersten Post.

DERZEIT EMFOHLENE SCRIPTS:
-"RUTIS Form Test.rutis"
-"Desktop_Painter.rutis"
-"Billard.rutis"

MFG

[olee]

Wegen ein paar (zusammenhängenden) Bugs hab ich nochmal eine gefixte Version hochgeladen, da einige Scripte nicht liefen.

Wie immer im ersten Post.

PS: Hat einer es denn schon getestet? Wie findet ihr es? Ich würde mich über etwas Feedback mal sehr freuen. :|

MFG

[DelphiBandit]

Hallo Björn,

ich habe mir das Projekt gerade mal geholt und angesehen. Ziehe ebenfalls meinen Hut vor solch einem komplexen System wie einem kleinen Quasi-Compiler. Besonders gefallen haben mir die OpenGL-Möglichkeiten in den Demo-Scripts. Leider benötige ich momentan noch keinen Script-Compiler.

Allerdings steht Mitte nächsten Jahres eine dynamisch auszuwertende Regelwerks-XML ins Haus. Ein Ansatz wäre dieses Regelwerk mit einer Art Source-Generator in ein dynamisches abzuarbeitendes Script umzuwandeln. Aber wiegesagt ist dies nur ein Ansatz. Der andere wäre das direkte Einlesen und Parsen der XML-Datei und die Regeln innerhalb von Klassenhierachien zu verarbeiten.

Auf jeden Fall von mir erstmal einen Gruß und :thumb:

[olee]

Hi,

Erstmal DANKe für das LOB sowas sollte es öfters geben in der DP denn das motiviert unglaublich ;)

Naja aber zu der Aufgabe, die du da angesprochen hast:

Meinst du damit im Grunde eine Verarbeitung von Strings mit RUTIS?

Denn ausgerechnet das habe ich zwar eingebaut (also die einzelnen Buchstaben eines Strings indizieren), aber noch nicht gut ausgebaut und getestet.

Jetzt habe ich aber einen guten Grund das mal zu tun. :mrgreen:

MFG

[Neutral General]

Hey olee,

Hatte gestern Abend auch mal nen kurzen Blick drauf geworfen. Ist schon ziemlich cool geworden :)
Allerdings sind vorallem die Formular-Skripte ätzend langsam :?
Das müsste auf jeden Fall schneller gehen..

[mleyen]

Ich hab es jetzt auch mal kurz angetestet und ich muss sagen es gefällt mir ganz gut.
Gerade die ScriptToExe-Funktion finde ich seehr geil. Sozusagen hat man jetzt wieder eine neue kostenloste 'mini'-Alternative zu Delphi. :lol:
Werde das Projekt auf jedenfall weiter verfolgen. :thumb:

[olee]

Hi,

DANKE und DANKE mal wieder an euch beide das freut mich sehr!

@Neutral General: Also ich hab nicht gemerkt, das die Formularscripte irgendwie langsam sind. Könntest du mir mehr Infos geben z.B. welches Script du getestet hast?

@mleyen: Da stimme ich dir zu. Ich finde auch die ScriptToExe Funktion (der Name gefällt mir ;)) sehr praktisch ist.
Das tolle ist auch, das die RUTIS EXE nochmal sehr viel schneller ist, als wenn man die Scripte im Editor oder in der Runtime ausführt.
Das könnt ihr selbst mit dem Script speed.rutis testen. Bei mir gibt das so 8Mio Befehle/sec für Editor und 13Mio für EXE aus!

Und natürlich ist die Source eines Programms in der EXE sicher und kann nicht mehr ausgelesen werden.

Ich werde gleich auch ein Update rausbringen, mit ein paar kleinen Bugfixes und einen neuen (über die Nacht erwirtschafteten) tollen Scripts!
Das reizt mal die Möglichkeiten von OpenGl in RUTIS so richtig aus ;)

MFG

[DelphiBandit]

Zitat:

Zitat von olee

Naja aber zu der Aufgabe, die du da angesprochen hast:
Meinst du damit im Grunde eine Verarbeitung von Strings mit RUTIS?

So ähnlich, also im Prinzip ist es eine ca. 100 kByte grosse XML-Datei. In der stehen jede Menge Regeln drin, welche Erfassung nicht neben welcher vorkommen darf und welche sich gegenseitig einschliessen müssen. Die ganzen Bedingungen noch mit ODER und UND ineinander verschachtelt. Ist relativ kompliziert das ohne XML-Schema zu erklären ;)

Für das Script bauen wäre dann z.B. der MS-XML-Parser notwendig der aus diesen Regeln eben ein Script macht. Momentan befinden wir uns da aber noch in der "Findungsphase", wie wir das am cleversten (und in der Folge wartungsfreiesten) umsetzen.