SynSug - Syntaktischer Zucker für AutoIt (Update v1.1.0 Dictionaries)

  • Hi!

    Der ein oder andere hat ja vielleicht schon den Link zum git-Repo in der Shoutbox gesehen. Ihr wisst schon, worum es geht. Hier trotzdem - bevor es zum Wesentlichen geht - einmal die Vorgeschichte.

    In letzter Zeit arbeite ich regelmäßig mit den verschiedensten Programmiersprachen, von Assembler über C und Java bis hin zu PHP. Nun, manche dieser Sprachen können ein paar coole Sachen, die ich dann prompt beim Programmieren in AutoIt vermisst habe. Als einfaches Beispiel sei hier mal die Postfix-Inkrementierung ($i++) genannt.
    Aus dieser "Problematik" heraus ist dann ein kleiner Präprozessor entstanden, der gewisse Ausdrücke (meistens mit Hilfe von RegEx) in andere Ausdrücke umwandelt. Es wird also streng genommen nicht die Funktionalität von AutoIt erweitert, sondern nur eine alternative Schreibweise für bereits vorhandene Mechanismen angeboten. Das nennt man dann Syntactic Sugar. In der README-Datei ist (mehr oder weniger genau) beschrieben, welche Spielereien im Einzelnen verfügbar sind. Dabei wird es aber ziemlich sicher nicht bleiben.

    Noch dazu kommt, dass die Pattern noch nicht perfekt sind. Es kann durchaus zu Parsing-Fehlern kommen. Daher erscheint nach der Installation auch ein Punkt namens "Syntactic Sugar (Debug to File)" im Tools-Menü von SciTE. Dann kann man genau nachvollziehen, wie der eigene Quellcode verändert worden ist.

    Um gewisse Probleme bei der Arbeit mit SynSug zu vermeiden, muss jedes Skript die Zeile #SynSug_Enable=yes enthalten. Sieht im ersten Augenblick zwar aus, wie übertriebene Formalität, hat aber den netten Nebeneffekt, dass man veröffentlichte SynSug-Skripte als solche identifizieren kann.

    Naja, mehr muss ich, glaube ich, dazu nicht sagen, alles weitere steht in der README-Datei. :D

    Link zum Repo: bitbucket.org/chesstiger/synsug-autoit

    Grüße!

  • Coole Sache auf jeden Fall.
    Ist das Zwischenergebnis verfügbar, bevor es kompiliert wird? Wäre sonst recht unnütz, wenn man seinen Code verbreiten will...

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal

  • @Xori
    Dazu war eigentlich die Zeile #SynSug_Enable=yes gedacht. Wenn irgendjemand das Skript in den Weiten des Internets findet, kann er mit dem Stichwort "SynSug" entweder den Thread hier oder auch das Repository finden und dann entsprechend damit arbeiten.

    Davon ab ist es natürlich möglich, das bearbeitete Skript zu speichern. Dafür kann man die oben angesprochene "Debug to File"-Funktion verwenden. "test.au3" wird dann übersetzt und als "test_synsug.au3" im gleichen Verzeichnis gespeichert. Sieht nur leider momentan ziemlich bescheiden aus, danach müsste man nochmal mit Tidy drüber gehen.

  • Ist natürlich ne Idee, wenngleich es eben kein Standard ist und nicht jeder sich einen Overhead runterladen will..

    Bsp: ich entwickle eine Lib und es ist weit angenehmer diese durch die Kürzel zu schreiben, dann will ich das logischerweise für alle bereitstellen OHNE den SynSugar Inhalt.

    Es gibt sehr viele Leute, die glauben. Aber aus Aberglauben.
    - Blaise Pascal

  • Jetzt hab ich mich endlich aufgerafft, auch mal bissl C zu schreiben, da kommst du mit dem Gedöns in AutoIt! :Face:

    Aber sonst...ein klares :thumbup:

  • @Xori
    Ist schon was dran, dafür ist dann eben die Debug2File-Option. Momentan muss man halt noch manuell Tidy drüberlaufen lassen, aber ich hab das mal auf die Todo-Liste geschrieben.

    @Andy
    Wenn C dich einmal hat, lässt es dich nie wieder los. Dazu macht die Sprache zu viel Spaß. Vor allem, wenn die Java-Leute bei Betrachtung deines Codes die Hände über dem Kopf zusammenschlagen. :D

    • Offizieller Beitrag

    Momentan muss man halt noch manuell Tidy drüberlaufen lassen

    Nach Debug2File kannst du doch die erstellte Datei automatisch in SciTE öffnen und Tidy aufrufen, was dann auf die aktuelle Datei angewendet wird. Schicker wäre natürlich, wenn Tidy einen /file - Parameter hätte - aber das ist leider nicht der Fall (bzw nicht in der Doku).

  • UPDATE

    Die bereits angesprochenen Erweiterungen für Debug2File wurden umgesetzt: Das entstandene Skript wird nun automatisch durch Tidy gejagt und dann mit dem voreingestellten Editor (meistens SciTE) geöffnet.

    Weiterhin ist noch die Referenz-Foreach-Schleife aus PHP dazugekommen. Das ist im Prinzip eine For-In-Next-Schleife, bei der man das aktuelle Element auch bearbeiten kann. Dafür sind zwei Schreibweisen erlaubt. Einmal Original-PHP:

    [autoit]


    For &$e In $a

    [/autoit]


    Und dann noch eine schöner zu lesende, an AutoIt angepasste Schreibweise:

    [autoit]


    For ByRef $e In $a

    [/autoit]

    So. Das letzte Update für dieses Jahr. :D

  • Update v1.1.0

    Da mir hier eben ein Thread mit dem Thema Dictionaries ins Auge gesprungen ist, habe ich da mal flugs was für gebastelt.
    Dictionaries können nach dem Schema Local/Global/Dim Dict $oDict erstellt werden. Auch eine Initialisierung wie aus PHP (Local Dict $oDict = ["foo" => "bar"]) ist möglich. Im ganzen weiteren Skript kann auf die Dictionary-Einträge mit eckigen Klammern zugegriffen werden. Außerdem wird UBound($oDict) durch $oDict.count ersetzt.

    Weiteres in der Readme-Datei, Quellcode ist im Repository.

  • Huhu!

    Irgendwie überfällt mich immer im Januar die Lust, etwas an diesem Stück Software zu machen. Daher ist jetzt das "schöne" Definieren von Strukturen dazugekommen. Mich nervt es immer ziemlich, Strukturen als Strings schreiben zu müssen. Das wird irgendwie schnell unübersichtlich, finde ich. Denkbar wäre noch ein GetAddress-Operator (also statt DllStructGetPtr($tMyStruct) ein ByRef $tMyStruct oder so)...

    Kurzes Beispiel (aus der README):


    Alles wie immer im Repo!