Beiträge von minx

  • RosettaCode Sammelthread

    Sammelthread zum RosettaCode Wiki.

    Foruminterne Infos zu RC
    Bereits implementierte Aufgaben
    Aufgaben, die eine dringende Überarbeitung brauchen
    Nicht-implementierte Aufgaben

    Was hier gepostet werden kann:

    • Neu implementierte Beispiele
    • Überarbeitete Beispiele


    Wir sollten hier vor allem bei neu geschriebenen Beispielen diskutieren, ob diese perfekt sind und sie falls nötig verbessern. Danach können wir sie ins Wiki stellen ;)


    Ich beginne mal:

    Art: Neu-Implementierung
    Task: http://rosettacode.org/wiki/Arithmetic/Integer
    Beteiligte: minx
    Script:

    Spoiler anzeigen
    [autoit]

    $iA = InputBox("Integer Arithmetic", "a?")
    $iB = InputBox("Integer Arithmetic", "b?")

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

    MsgBox(0, "Integer Arithmetic", "Results are:" & @CRLF & _
    "a + b = " & $iA + $iB & @CRLF & _
    "a - b = " & $iA - $iB & @CRLF & _
    "a * b = " & $iA * $iB & @CRLF & _
    "a / b = " & Floor($iA / $iB) & ", remainder is " & Mod($iA, $iB))
    ;

    [/autoit]

  • AutoIt Live-Debugger und wie man ihn benutzt

    Tach!

    Eine Programmiersprache sollte einen Debugger haben. Jetzt bekommt AutoIt auch einen, einen "echten".

    Davor


    Das Skript wurde ursprünglich von Heron geschrieben. Ich habe es etwas handlicher gemacht und unnötige Funktionen / Ressourcen entfernt und hier und da etwas aufgeräumt. In diesem Tutorial geht es aber weniger um das Skript, als um die effektive Nutzung desselben.

    1. Was


    Der Debugger ist ein Einzelschritt Debugger, der mit SciTe kommuniziert. Es werden beim Ausführen des Skripts automatisch Breakpoints eingefügt. An diesen Stellen bleibt der Debugger nach einem Schritt stehen. Man hat die Möglichkeit per Einzelschritt [1] vorzugehen, das Skript bis zur Cursorposition in SciTe auszuführen [2] oder das Skript einfach laufen zu lassen [3]. Das ausgeführte Skript kann jederzeit pausiert werden [4]. In einem Listview werden alle Variablen und Makros mit Typ, Wert und Scope angezeigt [5]. Der Debugger hat zudem eine eigene Kommandozeile [6], um Befehle am aktuellen Breakpoint auszuführen. Dazu gibt es zur Eingabe ein Input, zur Ausgabe eine Console [7]. Der allgemeine Status des Debuggers kann über die restlichen Labels [8] abgelesen werden (wie Ausführungszeit, Änderungen, Errors, Calls während des Ausführens).

    Die aktuelle Position wird in SciTe immer mit einem Punkt in der linken Leiste markiert. Über "Exit all" beenden wir das Skript + den Debugger. Beendet sich das Skript, schließt sich auch der Debugger automatisch.

    [Blockierte Grafik: http://j04.img-up.net/lolz22b78.jpg]

    2. Wie

    Gehen wir mal durch wie man ihn benutzen könnte.

    Um das Skript zu debuggen, welches wir vor uns haben, müssen wir einfach nur #include <Debugger.au3> an den Anfang setzen. Das entfernen wir vor dem Kompilieren einfach wieder. Wenn man jetzt das Skript startet, dann öffnet sich das Debuggerfenster und das Skript ist pausiert. Wir können nun einfach per Druck auf "Step" das Skript bis zur nächsten Zeile ausführen.

    Man sieht nun, dass die Variablen die vorhanden sind in einem Listview angezeigt werden, und wir nach einem Step sehen wie sie sich ändern. Drücken wir jetzt auf Run, dann deaktivieren wir das Debuggen für eine unbestimmte Zeit oder bis wieder ein Druck auf "Stop" erfolgt. In dieser Zeit werden die Variablenwerte nicht aktualisiert, um die Performance des Skripts nicht zu beeinflussen. Nach dem Stoppen werden die Werte wieder angezeigt.

    Wenn wir den Debugger für einen Codeabschnitt komplett ausschalten wollen, setzen wir an den Anfang des Abschnitts einfach "#Debugger_Stop" und danach ein "#Debugger_Start". Der Debugger überspringt diese Zeilen ganz.

    Probiert einfach ein wenig herum, es sollte selbsterklärend sein ^^

    3. Integrierte Kommandozeile

    Dieses Feature hat zwei Hauptfunktionen. Zum Einen können damit am Breakpoint AutoIt-Befehle ausgeführt werden (die natürlich auch das Skript affektieren können) und zum Anderen können damit die Werte der Variablen live geändert werden (Bsp: "$var = 4"), beim nächsten Breakpoint sind die Änderungen dann durchgeführt.

    Aber die Konsole hat noch eine Funktion. Gibt man nur eine Variable ein "$Var", werden alle Infos zu dieser Variable ausgegeben. Auch zu Arrays, dort wird jedes Element aufgerollt!

    Danach

    Dieser Debugger funktioniert nur mit der aktuellen Stable. Mit den Betas kommt er nicht klar. Da es aber in absehbarer Zeit keine neu Stable geben wird, ist das kein Problem. Wenn etwas unklar war / ist unbedingt fragen!

    Installation: Die angehängte Datei in den Autoit-Inlcude-Ordner packen. ERST alles oben lesen!

  • AutoIt Compiler (Project Perseus)

    Kleines Syntax-Update. Variablenpointer können jetzt direkt angesprochen werden:

    Code
    Call [hBrush] = CreateSolidBrush(&H0000FF00)

    Update 3:
    Man muss nun nicht mehr manuell Funktionen aus der WinAPI importieren (durch extern "user32", MessageBeep ). Alle benutzten WinAPI Funktionen werden automatisch erkannt und eingebunden.

  • AutoIt Compiler (Project Perseus)

    Zitat von AspirinJunkie

    Optimierender Compiler von Zwischensprache in Maschinencode existiert schon.


    Tut er doch auch hier schon :P. Spaß beiseite, ich finde es einfach spannend eine Programmiersprache von Grund auf aufzubauen. Der Assembler bzw. der Übersetzer Zwischensprache zu Assembler (LASM) existiert ja schon. Da liegt jetzt der Vorteil in der Entwicklung der Zwischensprache, die kann man nämlich schon richtig in Richtung AutoIt biegen. ^^

    Das ist auch das Grundprinzip von C-- (Ja, Minus) etc. Wenn man aber was eigenes hat, ist das doch viel besser ^^.

    Zitat von Marthog

    Wie viel hast du davon schon gemacht?


    Also nochmal etwas ausführlicher. Der Assembler ist fertig (http://apaste.square7.ch/lasm). Die Zwischensprache an sich ist in der Entwicklung, wann man sie als fertig bezeichnen kann weiß ich nicht ^^.

    Aber danke alle ^^

  • AutoIt Compiler (Project Perseus)

    Dern Sinn kann sich in die nächste Ecke stellen ^^.

    Ich glaube es gibt schon dadurch einen Vorteil, dass es bereits Typenlos geschrieben werden kann. Natürlich kann man nie den ganzen Funktionsumfang umschreiben, man muss den Au3 Code sehr sauber verfassen (was auch die Var-Deklaration angeht). Richtig an den Speed geht es dann bei grafischen Dingen. Dort ist man dann nur noch durch den Speed der API Calls beschränkt (obwohl diese direkt mitassembliert werden).

    Klar ist die Personengruppe, die sich noch um Dateigrößen schert extrem klein, aber wenn man dann mal ein paar Photoshop Effekte in 5KB darstelen kann, viel schneller als es eine AutoIt exe mit ihren mind. 300KB oder eine VC++ mit 1MB+ schaffen könnte, erweckt man dann doch Interesse :D

    Schon allein die Größe meines Assemblers. 52KB. Davon passen Dutzende Kopien auf eine Diskette :whistling:

    Wenn ich ein OP-Problem hab nerv ich dich sowieso :D

  • AutoIt Compiler (Project Perseus)

    Du weißt schon was ein Interpreter ist? Der interpretiert den Code und hat nichts mit einer ausführbaren Datei zu tun ^^

    Wie wird aus Perseus Maschinen-Code, na indem er übersetzt / assembliert / compiliert wird. Wie nunmal EXE Dateien erzeugt werden ^^

    ___________

    Ein Assembler nimmt Text-Instruktionen und wandelt sie in OP-Code um. Der OP-Code wird dann in eine .exe Datei geschrieben (einfach FileWrite). Perseus ist als ein Assembler wie FASM, MASM oder TASM, bloß mit einfacherem Syntax.