[Release] AAL, an Open-Source AutoIt Alternative

[Shadow992]

Heyho together,

in this thread I want to finally present my created programming language called AAL (=Advanced Automation Language), an Autoit-Alternative.

You also may have a look at Warfleys AAL-Editor:

GitHub-Link:

German

 Spoiler

Was soll das sein, eine AutoIt-Alternative und warum?
An AutoIt haben mich schon sehr lange sehr viele Dinge gestört. AutoIt macht vieles richtig aber genau so viel falsch.
Mit AutoIt ist das Automatisieren von Windows sehr einfach und schnell gemacht.
Zusätzlich bietet AutoIt über die Automatisierung hinaus viele Funktionen, die es erlauben auch komplexe Programme zu schreiben.
Eine Sprache, die ähnlich einfach und dennoch derart mächtig ist, gibt es meiner Meinung nach nicht.

Dennoch fehlen AutoIt viele Sachen, um auch für komplexe Probleme benutzt werden zu können.
Manche Sachen wurden in AutoIt meiner Meinung nach auch vollkommen falsch oder sehr lasch und inkonsistent implementiert.
Mein Ziel ist es also mit AAL eine ähnlich einfache Automatisierung wie AutoIt zu bieten und trotzdem mit dem Strom der Zeit zu schwimmen und Sachen wie OOP, Multithreading u.ä. zu ermöglichen.

Punkte, die ich versuche explizit besser zu machen/konsistenter/anders zu implementieren, also Sachen, die ich an AutoIt schlecht finde:

- Fehlende Klassenunterstützung (nur über Umwege möglich z.B. per UDF und selbst dann ist es nur beschränkt nützlich)
- Relativ langsame Ausführungszeit
- Sehr einfach zu decompilen und es ist fast unmöglich bestehende Decompiler aus dem Konzept zu bringen
- Keine Chance für echtes Multi-Threading
- Sehr komplizierte Hardwarenahe Programmierung (z.B. komplizierte Structs und Pointer)
- Manchmal komisches Verhalten und inkonsitente Keyword-Nutzung (z.B. "While" und "WEnd" aber "If" und "EndIf" oder "For" und "Next").
- Fehlendes Inline-ASM
- Code ist nicht als DLL-kompilierbar

All diese Dinge will ich besser und anders machen bzw. allgemein überhaupt ermöglichen.

Was steht bisher?
AAL ist was die Basis Konstrukte angeht schon weit fortgeschritten, konkret heisst das, dass folgende Funktionen ohne Einschränkungen (abgesehen von Bugs) benutzbar sind:

- If ... EndIf
- While ... EndWhile
- For ... To ... Step ... EndFor
- Do ... Until
- Func ... EndFunc
- Variablen ($var = ...)
- Arrays erstellen/benutzen (bisher nur erstellbar über Dim)
- Default Parameter bei Funktionen
- übergabe der Funktionsargumente per Referenz
- Ein paar vordefinierte Funktionen (siehe dazu auch beiliegende AAL-Dokumentation)
- OR, AND, usw.
- Klammerung/etc.
- Ein paar grundlegende Code-Optimierungen (z.B. Sachen wie 10*10 gleich ausrechnen)

Alles schön und gut, aber was genau willst du jetzt von uns?
Ich veröffentliche die komplette AAL-Sprache inklusiver Dokumentation, als Open-Source-Projekt.
Damit will ich nicht nur erreichen, dass ihr von dem Code lernen könnt und auch einmal seht wie man prinzipiell so einen Compiler/Interpreter umsetzt, sondern ich erhoffe mir auch Hilfe in Form von Source-Code und Bugfixes.
Diese Projekt ist ein großes Projekt, zu viel für eine Person alleine. Ich bin überzeugt, wenn wir alle zusammenhelfen, dann können wir eine Sprache kreieren, die sowohl einen leichten Einstieg ermöglicht, viele Funktionen anbietet und dennoch schnell in der Ausführung ist.
Aber nicht nur Source-Code Beiträge sind wichtig, sondern auch alle anderen Arten von Hilfe.

Konkret bin ich noch auf der Suche nach folgenden Unterstützern:

- Ich freue mich auf jeden, der mich länger als nur kurzzeitig unterstützen möchte, wenn jemand ernsthaft Interesse an einer längeren Mitarbeit hat, könnt ihr mich gerne anschreiben, dann versuche ich euch eine Einführung in den Code zu geben und helf euch dabei mit dem Code besser klar zu kommen (Ich werde keine C/C++ Einführung geben, sondern nur die Idee hinter den Algorithmen/Design-Fragen, etc. klären)
- Wenn du nicht die Zeit oder Lust hast regelmäßig am Projekt mitzuarbeiten, kannst du auch nur kleine Funktionen oder einmalige Features beisteuern (z.B. ImageSearch, Beschleunigung von bestehenden Algorithmen, usw.). Ich werde die Funktionen dann bei Gelegenheit hinzufügen und feedback liefern
- Solltest du keine Ahnung von C/C++ haben, kannst du auch etwas Beisteuern, indem du AAL-Funktionen (in AAL) schreibst (Dies ist natürlich ein sehr riskantes Verfahren, weil man sich in der alpha-Phase nie sicher sein kann, ob der Fehler im Interpreter/Compiler liegt oder in seinem eigenen Code).
- Hilfe beim Bugs finden/suchen
- Wenn du überhaupt nich programmieren kannst, freue ich mich auch, wenn du mir hilfst falsches/schlechtes englisch/deutsch zu finden und auszubessern
- Auch einiges an Übersetzungsarbeit steht an (sowohl deutsch -> englisch als auch englisch -> deutsch)
- Auch einen Webseitendesigner (+ überhaupt einmal eine Webseite/einen Server) wäre ein weiterer wichtiger Punkt

Wenn du dich dadurch also angesprochen fühlst und Lust hast in einem derartigen Projekt (und wenn es nur für 1 Tag ist) mitzuwirken, dann nur zu, verfasse einen Post oder schreib mir eine Privatenachricht.
Ich bin auch per E-Mail erreichbar:
m (dot) rupprecht (at) gmx (point) net

Ohne Leerzeichen und die entsprechenden Ausdrücke in den Klammern durch die richtigen Zeichen ersetzen (wobei point dasselbe Zeichen ist wie dot).
Ich schreib das hier so komisch, um die ganzen Spambots fernzuhalten oder zumindest grob auszusortieren.

Was muss ich bei der Benutzung von AAL in der alpha-Phase beachten?

Sehr wichtig ist es seinen AAL-Code, den man programmiert hat auf Fehler zu prüfen.
Das Fehlerhandling im AAL-Compiler ist nur sehr rudimentär und erkennt nur rund 60% aller möglichen Fehler.
Das soll sich mit der Zeit zwar enorm bessern, aber für den Moment muss man mit dieser Einschränkung leben.
Das heißt, bevor ihr einen Bug vermutet oder ähnliches, schaut erst einmal ob euer AAL-Code vor dem Kompilieren richtig ist, weil wie erwähnt nicht alle Fehler gefunden werden.

Was gibt es sonst zu beachten?

Es gibt zwei Versionen von AAL, die Debug-Version und die Release-Version.
Wenn man irgendwo einen Bug vermutet oder nachvollziehen möchte, was AAL der Reihe nach macht, sollte man die Debug-Version benutzen.
Die Debug-Version schreibt Informationen in die Dateien "compiler.debug.txt" und "interpreter.debug.txt", dafür läuft sie natürlich langsamer. Die Release-Version läuft dementsprechend schneller, schreibt aber keine Daten raus.

English

 Spoiler

This is not a 1:1 translation, but a rough summary of the german version (1:1 translation is in work):

What is AAL?
AAL tries to give the possibility to do basic and also complex automation tasks based on an easy syntax and semantic.
So AAL tries not to be as similar to AutoIt as possible but tries to get the best out of AutoIt and mix it with things that are kind a missing or done worse in AutoIt, e.g.:

- Missing class support (only possible with UDF and then still quite strange to use)
- Quite slow
- Very Easy to decompile and nearly impossible to break existing decompilers
- No possibility to use real multithreading
- Missing or very complicated hardware near programming (e.g. complicated pointer and structs)
- Sometimes strange behaviour and inconsistent keywords (e.g. "While" and "WEnd" but "If" and "EndIf" or "For" and "Next").
- Kind of missing inline ASM
- Missing possibility to compile as DLL

AAL is open-source and I will try to keep it as long open-source as possible.
So you can lear from the project. That is also why I tried to document many things as good as possible.
You should not only learn from this project, but I am also happy to see people helping together to reach the goal of "being a mighty AutoIt alternative".
You do not only have to be familar with coding, I am searching for all kind of help, e.g.:

- I am always happy to see guys helping me finding bugs/errors/strange things. So if you want to help me not just with some short texts/functions, you can write me an email and I will help you getting familiar with code. I will not explain fundamental C/C++ things (so I will not act as a kind of teacher/tutor but will help to answer all unclear codes and explain the basic ideas of the algorithms)
- If you are having not enough time to work regulary at the project but you still want to contribute, you can also send me some pieces of C/C++ code (e.g. PictureSearch-Algorithms, faster implementation of existing functions, ...) and I will add them on occasion.
- If cou can not program C/C++ at all, you can also help to write new functions by using AAL-Code (this of course is, especially in alpha stage, a risky method because if something does not work, you can not be sure if it is your code or the AAL-Interpreter/Compiler).
- You can also help by finding bugs/making suggestions.
- If you are not able to program at all (neither C/C++ nor AutoIt/AAL), you can still help by finding undocumented functions/writing mistakes/bad english.
- Another possibility to help is by translating english texts into other languages (esepcially into german).
- Last but not least, I am also looking for a website and a website layout. I would be able to do it by myself (and I guess I will do the backend by myself) but I really hate HTML/CSS/JS.

What do I have to take care of when using AAL in alpha stage?

The compiler is not able to detect all kind of errors. It only can detect some basic errors in Code (around 60%).
So it is possible to write a code where the compiler is not complaining at all, but the Interpreter still crashes because the compiled Code is not valid. This means whenever you think there is a bug, you have to double check if really every line of your code is correct.
This will be fixed in some feature versions but for alpha stage we have to live with this.

What else to know?

There are 2 versions of AAL, a Debug version and a Realease version.
The Debug-Version will write some information to the file "compiler.debug.txt" and "interpreter.debug.txt".
So whenever you think you found a bug or you want to understand what is going on, use the debug version.
The debug version is of course much slower than the release version, but helps to debug the generated code.

Documentation files (all files can be reached by using the CompileAndRun.exe file):

./Getting Started/aal_functions.html - This file gives an overview of already implemented AAL standard functions and their arguments (english)
./Getting Started/aal-developer-manual.pdf - This file will help to understand what is happening inside AAL-Compiler/Interpreter (only german at the moment)
./Sourcecode-Doc/index.html - This file is the main file of doxygen documentation for C/C++ Sourcecode (english)

Getting Started:

Just start "CompileAndRun.exe", then click on the button "Select file" and select the file you wrote (or navigate to Examples folder and select an example file). After that press "Run Debug" or "Run Release" (whatever you want to do). The first showing window is the compiler and the second window the interpreter. If you want to see the output of interpreter/compiler just have a look at e.g. "interpreter.release.txt"

zLib License:

 Spoiler

Copyright (c) 2015 M. Rupprecht

This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

This means, to sum up:
Use it for whatever you want, but do not hide the real author(s).

Changelog:

Planned Features for next Version

 Spoiler

0.0.2alpha

- Expand documentation (especially for compiler which is documented very weak at the moment)
- Fix bugs
- Add some more basic functions
- Optimize code for speed
- Create GitHub Entry

0.0.3alpha

- Make compiler interface easier and more flexible
- Add include-directive
- Fix errors in documentation
- Fix bugs

0.0.4alpha

- Rewrite parts of Compiler to make syntax checking easier and fix some issues/ugly things
- Fix bugs

0.0.5alpha

- Expand documentation (especially for compiler which is documented very weak at the moment)
- Fix bugs
- Optimize code for speed (mainly by optimizing generated ByteCode)

Known Bugs

I hope to find many people who are interested in this project and want to help me. Thanks in advance for all kind of help!

[Tasiro]

Gut gemacht! Wo ist der GitHub-Link?

[Strew]

Erstmal vor weg, ich bin sehr begeistert von der Projekt Idee.
Ich habe zwar noch kleine Zweifel wie das ganze weitergehen soll,
aber ich bin da relativ offen und werde dich definitiv dabei unterstützen
wenn du möchtest. Wie und in welcher Form muss ich mir allerdings noch
überlegen, da könnte man dann ja aber auch via PN drüber quatschen.

Natürlich wünsche ich dir viel Erfolg damit und drücke dir die Daumen.

Liebe Grüße, Strew

[Shadow992]

Originally Posted by Tasiro

Gut gemacht! Wo ist der GitHub-Link?

Der kommt in der nächsten Version (sprich 0.0.2alpha).

Originally Posted by Strew

Erstmal vor weg, ich bin sehr begeistert von der Projekt Idee.
Ich habe zwar noch kleine Zweifel wie das ganze weitergehen soll,
aber ich bin da relativ offen und werde dich definitiv dabei unterstützen
wenn du möchtest. Wie und in welcher Form muss ich mir allerdings noch
überlegen, da könnte man dann ja aber auch via PN drüber quatschen.

Natürlich wünsche ich dir viel Erfolg damit und drücke dir die Daumen.

Liebe Grüße, Strew

Ich freue mich über jegliche Hilfe, egal in welcher Form und wenns nur psychisch ist.

Wer will kann mich ja unter Skype hinzufügen (wundert euch nicht über den Namen ist ein uralter Account und war ein Insider damals ):

Stalaktiten

[[Beatrice]]

Great. I guess it'd be awesome to add an editor. Also to make DllCalls. Keep it up

[Shadow992]

Originally Posted by [Beatrice]

Great. I guess it'd be awesome to add an editor. Also to make DllCalls. Keep it up

Yep this will also come when the basic functions are working without any bugs.
But until then it is a long way.

[Else]

Der Schritt zur eigenen Sprache ist getan. Hut ab! :-)

[alpines]

Sehr schön, wird interessant das ganze mitzuverfolgen.

[Moneypulation]

Daumen hoch. Gibts einen weg das Bild von CaptureWindowByName() zu sehen bzw. es zu speichern? Und kriegst du es hin, dass man den WindowHandle den man als Parameter braucht, in eine Variable zu speichern, da sich der Titel ja ändern könnte. Außerdem wie siehts mit einer GUI aus?

[Shadow992]

Originally Posted by Moneypulation

Daumen hoch. Gibts einen weg das Bild von CaptureWindowByName() zu sehen bzw. es zu speichern? Und kriegst du es hin, dass man den WindowHandle den man als Parameter braucht, in eine Variable zu speichern, da sich der Titel ja ändern könnte. Außerdem wie siehts mit einer GUI aus?

- Bild speichern kommt in der naechsten Version (0.0.2 alpha)

- WindowHandle speichern kommt ebenfalls in der naechsten Version (nur momentan gibt es ja noch keine Moeglichkeit ueberhaupt dieses Handle zu benutzen, deswegen gibt es momentan noch keiner derartige Moeglichkeit)

- GUI wird noch ein gutes Stueck dauern. Vielleicht fuege ich ganz simple und billige Controls schon in der naechsten oder uebernaechsten Version hinzu (sprich Window, Button und Inputbox). Fuer GUI-Programmierung braucht es aber tatsaechlich noch viel ausenrum, wo ich noch nicht sicher bin ob es "einfach so klappt".

[Shadow992]

This time I want to release the second alpha version of AAL.
I did not expect to find that few bugs, but I actually only found 2 big bugs.
So the new version focused on new features and updating/expanding documentation. However I just did little work on documentation.

Changelog:

 Spoiler

- Added GitHub-Link:
- Removed a bug where searchForImage and similar functions crashed
- Removed a bug where "while(1) ... WEnd" crashed
- Added GUI-Elements and functions
- Added some more Image-Functions
- Added really basic string functions
- Expanded documentation a little bit
- Restructured Sourcecode a bit
- Expanded examples

New version was added to first post (0.0.2alpha).

For the next version I plan to focus on optimizing generated ByteCode.
This can speed up the complete execution time alot.

[warfley]

Wann kommt die Möglichkeit andere Dateien zu includen? Habe grade mit einem kleinen Formeditor angefangen, und ich muss sagen es wäre deutlich schöner wenn man den Formcode einfach in eine separate Datei auslagern könnte.

PS: Habe die neuen Funktionen jetzt im Editor, aber dabei ist mir aufgefallen dass du bei vielen Funktionen im Summary immer noch die Funktion CaptureWindowByName angibst,

[Shadow992]

Originally Posted by warfley

Wann kommt die Möglichkeit andere Dateien zu includen? Habe grade mit einem kleinen Formeditor angefangen, und ich muss sagen es wäre deutlich schöner wenn man den Formcode einfach in eine separate Datei auslagern könnte.

PS: Habe die neuen Funktionen jetzt im Editor, aber dabei ist mir aufgefallen dass du bei vielen Funktionen im Summary immer noch die Funktion CaptureWindowByName angibst,

Inoffiziell gibt es die Möglichkeit schon.
Also eine include-Direktive gibt es bereits und sie sollte auch einigermaßen funktionieren.
Momentan gibt es noch zwei kleine "Unschönheiten" an dem Ganzen:

- Da das Kompilieren der Dateien noch etwas "umständlich" passiert, muss man höchstwahrscheinlich die zu inkludierenden Dateien auch in das "bin" Verzeichnis verschieben.
- Die Funktion wurde bisher nur einmal ganz am Anfang getestet, ich weiß also nicht wie es momentan aussieht und ob sie überhaupt läuft.

Aber prinzipiell ist sie benutzbar, indem man folgendes schreibt:

#include("file_to_include.aal1")

Ich werde mir das morgen und übermorgen mal genauer anschauen und dabei auch die Dokumentation noch anpassen. Zusätzlich werde ich auch das Kompilieren endlich "sinnvoller" und intuitiver machen (mit Flags u.ä.).
Spätestens Montag wird also die Include-Direktive definitiv unterstützt.

[warfley]

Originally Posted by Shadow992

Inoffiziell gibt es die Möglichkeit schon.
Also eine include-Direktive gibt es bereits und sie sollte auch einigermaßen funktionieren.
Momentan gibt es noch zwei kleine "Unschönheiten" an dem Ganzen:

- Da das Kompilieren der Dateien noch etwas "umständlich" passiert, muss man höchstwahrscheinlich die zu inkludierenden Dateien auch in das "bin" Verzeichnis verschieben.
- Die Funktion wurde bisher nur einmal ganz am Anfang getestet, ich weiß also nicht wie es momentan aussieht und ob sie überhaupt läuft.

Aber prinzipiell ist sie benutzbar, indem man folgendes schreibt:

#include("file_to_include.aal1")

Ich werde mir das morgen und übermorgen mal genauer anschauen und dabei auch die Dokumentation noch anpassen. Zusätzlich werde ich auch das Kompilieren endlich "sinnvoller" und intuitiver machen (mit Flags u.ä.).
Spätestens Montag wird also die Include-Direktive definitiv unterstützt.

Nice dann werde ich das mal implementieren. Damit kann ich auch schon das Projekt System anfangen
Ich hätte dann noch eine Frage, wie funktioniert das mit cirkulären Referenzen also wenn ich die forms in einer separaten Datei A erstelle, und diese dann in B include funktioniert es dass ich sowohl über die Datei B die Variablen von a verwende aber in A die Funktionen von B als Event setze, wie muss ich die includes setzen?

[Shadow992]

Originally Posted by warfley

Nice dann werde ich das mal implementieren. Damit kann ich auch schon das Projekt System anfangen
Ich hätte dann noch eine Frage, wie funktioniert das mit cirkulären Referenzen also wenn ich die forms in einer separaten Datei A erstelle, und diese dann in B include funktioniert es dass ich sowohl über die Datei B die Variablen von a verwende aber in A die Funktionen von B als Event setze, wie muss ich die includes setzen?

Alles was das Include macht ist die Anweisung durch den Inhalt der Datei zu ersetzen. Wenn man Die Includes zirkulär definiert, also in etwa so:

File1.aal1

#include("File2.aal1")

File2.aal1

#include("File1.aal1")

Wird der Compiler in eine endlos Rekursion übergehen.
Um das mehrmalige Einbinden (und damit solche Fehler zu beheben/unterdrücken) zu verhindern, gibt es die Direktive "#include-once".
Aber auch das wurde logischerweise (wie das #include) nur einmal am Anfang getestet.
Das heißt der funktionierende Code sähe so aus:

File1.aal1

#include-once
#include("File2.aal1")

File2.aal1

#include-once
#include("File1.aal1")

Ansonsten gibt es keinerlei Probleme bei bisher undefinierten Funktionen o.ä.
Dynamische Sachen (also so etwas wie onEvent, was auch zur Laufzeit zusammengebastelt werden könnte), werden erst zur Laufzeit validiert und wenn der Interpreter zur Laufzeit eine Funktion nicht auflösen kann kracht es. Wenn das jedoch zur Compile-Zeit passiert gibt es maximal eine Warnung (wobei selbst das momentan noch nicht implementiert ist, also momentan wird der Compiler überhaupt nicht meckern).
Auch die Reihenfolge der Funktionen u.ä. ist egal.

Auf gut deutsch:
Wenn es kracht, dann nur zur Laufzeit, der Compiler geht also davon aus, dass du richtigen Code (zumindest was den dynamischen Teil angeht) schreibst. Das Verhalten soll auch so bleiben (eventuell wird es an einigen Stellen Warnings geben, aber Errors werden es nie). Sind Variablen also nur in einer Include-Datei definiert und sie werden aber in beiden Dateien verwendet, meckert der Compiler kein Stück, egal ob mit oder ohne Include.

Es ist nur wichtig, dass beim Ausführen des Codes die Variablen auch zuerst zugewiesen werden und dann verwendet werden.

Edit:
Ganz konkret, wäre es also so richtig/möglich:

GUI.aal1

$win=CreateWindow(...)
$button=CreateButton($win, ...)
SetOnEvent($button, "onClick","Button1Clicked")

Main.aal1

#include("GUI.aal1")

; Do something with $win or $button

While 1
   Sleep(10)
Wend

Func Button1Clicked()
     ConsoleWrite("It worked!")
EndFunc