AutoIt3 Compiler/Parser

Also ich habe mir mal gerade die ISMS (Link von Greenhorn) von TheShadowAE angeguckt Ist ja echt beeindruckend! Ich hätte mit einem viiiel höheren Aufwand gerechnet... So gesehen ist die Idee garnicht mal so abwiegig!

Also der AutoIt Interpreter wurde mit C++ geschrieben, und jetzt soll AutoIt erneut in C / C++ verfasst werden?? Nunja ich selber habe mir ja schon sehr langwierige AutoIt Funktionen in C geschrieben und der Geschwindigkeitszuwachs lag bei mir bei bis zu 1000%.
Wenn man das jetzt weiterspinnt, und eben die Autoit Funktionen in Templates packt, einen 'AutoIt Source-Reader' verwendet der erst den AutoIt Source ausliesst, dann die benötigten Templates auswertet, und aus der Summe wird ein C++ Code erstellt. DANN kann man noch etwas mit den Compiler Tricksen, SSE & Co - ausserdem kann man auf eine gewaltige Auswahl von freien Compilern zugreifen! Dadurch Evtl dann sogar Linux&Co...

Also ich kann C - muss es aber erst wieder etwas Trainieren; und Arbeiten muß ich auch, Familie und Kinder hab ich auch - bleiben meißt nur 1-2 Stunden am späten Abend. ...Ich Denke das ist zuwenig.
Prinzipiell kann man ja auch C++ mit C mischen, sogesehen ist es gar nicht so schlimm mit welcher Sprache programmiert wird.

Grüsse!

Schön, dass es jetzt wenigstens Leute gibt, die meine Idee gut finden.
In einem vorherigen Post habe ich auch schon erwähnt, dass man ja erstmal mit den Build-in-AutoIt-Funktionen anfangen könnte.

Zitat von progandy

Wenn der Parser und Übersetzer gut genug ist, kannst du auch die UDFs konvertieren lassen ...

Stimmt, da die UDFs ja auch nur auf den Build-in-Funktionen basieren, muss man da gar nichts manuell machen.

Zitat von progandy

Kein Vorteil bei .NET, da hier das Framework installiert werden muss. Du könntest auch AutoIt als .a3x kompilieren um das gleiche Ergebnis zu errreichen.

Auf jedem Windows der letzten Jahre ist meines Wissens nach eine Version von .NET installiert (ich persönlich hätte aber auch nichts gegen C oder C++; Selbst Visual Basic würde schon einen Geschwindigkeitsvorteil bringen, oder?).

MfG, James C.

Ich bin grade dabei, mir C# beizubringen, von daher wäre ich sehr gespannt, den Entwicklungsverlauf mitzubekommen. Wenn dann irgendwas kommt, wobei ich helfen kann, würd ich das auch gerne machen

Hier findet man alle Dateien von AutoIt, auch den Source-Code.

In der Lizenz steht:

Zitat

1. GRANT OF LICENSE.

You may:

- Customize the design and operation of the AutoIt source code to suit
the internal needs of your organization except to the extent not
permitted in this Agreement

You may not:

- Distribute the AutoIt source code and/or compiled versions of AutoIt
created with the AutoIt source code.
- Create derivative works based on the AutoIt source code for distribution
or usage outside your organisation.
- Modify and/or remove any copyright notices or labels included in the
AutoIt source code.

Alles anzeigen

Das heist aber nicht, das man nicht aus dem Code lernen darf um die Arbeit an diesem Projekt zu erleichtern.

MfG, James C.

Mit dem .Net Framework stehe ich sowieso auf Kriegsfuß (genau wie mit Java^^).

Die Nicht einsehbaren Funktionen kann man zum Teil relativ leicht nachbauen (die Ini-Funcs z.B. sollten doch nicht soo hart sein.).
Bei den Anderen muss man eben etwas Kreativität walten lassen um an ein möglichst vergleichbares Ergebnis zu kommen.

lg
Mars(i)

Zitat von progandy

Der Code ist zwar hilfreich, aber sehr alt. Die neuen Features (InetRead, BinaryToString, ...) und Bugfixes sind alle nicht vorhanden

Die meisten Funktionen basieren fast direkt auf der Winapi (MsgBox, GUIs) oder sind sehr einfach (BinaryToString).

Die Ini-Funktionen sind ganz leicht und auch aus dem alten AutoIt-Quelltext herauszulesen. Die API-Funktionen dazu heißen GetPrivateProfileString und WritePrivateProfileString. Auch die meisten anderen Funktionen sind kein Problem.

Das Problem ist wirklich der Parser selbst, wie z.B. macht man den Unterschied zw. Messege-Mode und OnEvent-Mode oder in AutoIt können in jeder Funktion globale Variablen erstellt werden und nicht nur außerhalb von Funktionen, usw..

Mitlerweile ist mir egal, ob jetzt C#, C++, C, oder irgendeine andere Sprache verwendet wird (z.B.: VB).
Ich bin offen für Vorschläge.

MfG, James C.

So ist es. Die Funktionen, seien es nun Standard oder auch UDF kann man wohl recht leicht portieren, gibt schliesslich in jeder Sprache Funktionen die vergleichbares tun. Das Hauptproblem werden die Variablen sein, da es in autoit eben keine fixen Datentypen gibt. Versuch mal sowas automatisiert in C zu portieren:

[autoit]

#include <array.au3>

[/autoit][autoit][/autoit][autoit]

$test=test()
_ArrayDisplay($test)

[/autoit][autoit][/autoit][autoit]

Func test()
$test = 123
$test += 10
$test &= "test"
Local $test2[3]=[$test,2,3]
$test=$test2
return $test
EndFunc

[/autoit]

Erst ist $test ein int, danach plötzlich ein string bzw. eine kette aus chars und später dann wird $test durch eine simple Wertzuweisung zum Array das strings und int enthält. Dürfte wohl äusserst schwer werden solche sachen abzufangen. Auch die GUI Konvertierung ist sicher nicht ganz so simpel.

Immer die Leute die auf die fehlenden Variablentypen hinweisen und darauf herumhacken.

Durch die Operatoren wird doch vorgegeben was als nächstes passiert.

Versuch mal in AutoIt zwei Strings zu Addieren mit + ( 'Hallo' + 'Leute' = 0)
Da kommt 0 dabei heraus, da AutoIt eben DOCH Variablentypen kennt, besitzt und benutzt.
Es wird nur automatisiert gecastet.

Bei C++ kann man das mit Objekten lösen, die je nachdem was angefordert wird ihren Wert als int, float, string, etc. zurückgeben. Dann sollte auch das kopieren von Arrays in dieses Objekt ohne weiteres machbar sein.
Wie man das in C machen kann weiß ich nicht. Aber da gibt es sicherlich auch umsetzbare Lösungen.

lg
Mars(i)