Jump to content

[WIP] Cross Platform Autoit Interpreter


Recommended Posts

Hi all,

Over the past few weeks I have been working on an Autoit intepreter for multiple platforms. This is one of its pre-releases. I want to nail out bugs before I proceed adding more functionality.

Eventually (months to years) I hope to have all keywords/control blocks supported, and most functions replicated.

I intend to eventually have builds for windows, linux and mac.

Currently I have builds for windows and mac, as the linux one is not building for some reason.

The mac one is not working entirely correctly - everything executes except the output window doesnt appear.

Windows one works 100%.

Anyway the following is supported:

Dim, Global, Local
Multiline If - Else
Assignment: =
Comparison (in control blocks): = => >= <= =< <>
Operators: *+-/()
ConsoleWrite
StringLen
StringLeft
StringRight
Nested Function Calls
Nested Control Blocks(If statements)
Array Initialisation. <- thou nothing else with arrays works yet.
Comments.

Thats enough to do some stuff, as you will see in the example script provided.

Currently, the interpreter works by reading from a file in the same directory

called 'execute.au3', and 'executing' it. Execution details below.

MOAR DETAIL:

1. Interpreter reads file in.

2. PreProcessor normalizes - Capitalize vars + functions, remove whitespace and comments

3. Interpreter directives - parser Tells interpreter final intentions of each line EG: IF statement, var assignment etc

->This speeds up runtime greatly.

4. Tokenized, lexed and parsed - lines processed into high speed memory structures for easy runtime interpretation

5. Expression processing (shunting yard algorithm) - Expressions rewritten into RPN to increase speed.

6. (TODO - NOT IMPLEMENTED YET) Partially evaluate static expressions.

So yeah.

This project will take time, but at my age, I have time, and I have motivation.

Download Link: Windows and Mac Builds attached. Source code available upon request..

Please Let me know what you think,

-Hyperzap

Edited by hyperzap

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

Source code available upon request..

Yes please :unsure:

Some of your descriptions of what happens makes no sense though... When last I checked, using shunting yard to turn infix to postfix was a hassle that you don't have a choice about (after all, that's what its for), not a speed increase... Most of what your preprocessor does is stuff the lexer should be doing. And the parser is telling the interpreter what to do before its even run :> Apart from that: Why does everything need to be about speed?

Link to comment
Share on other sites

Yes please :unsure:

Some of your descriptions of what happens makes no sense though... When last I checked, using shunting yard to turn infix to postfix was a hassle that you don't have a choice about (after all, that's what its for), not a speed increase... Most of what your preprocessor does is stuff the lexer should be doing. And the parser is telling the interpreter what to do before its even run ;) Apart from that: Why does everything need to be about speed?

I mean that most of the lexing is done at compile time as upposed to at runtime to increase speed significantly. A true interpreter probably should do these things at runtime but I like to do all the lexing prior to the execution.

I i do shunting yard at compile so i dont have to do it at runtime. thus speed. The algorithm itself does not speed things up, rather the decision to do it prior to runtime.

Whilst most of the lexing is done at compile time, the interpreter still supports unprocessed code anywhere in the script. When it reaches it, it will preprocess the line as in the description, and dynamically cache it, so that that line will never need to be lexed/preprocessed again.

This behaviour will greatly optimize loops.

And the parser is telling the interpreter what to do before its even run :D

These are just initial directives to help speed things up. If the parser tells the interpreter its an IF control block then the interpreter does not have to scan through and investigate code to see if its an assignment expression; does it?

It can skip straight to the three memory representations (first expression, comparison operator, second expression) and perform the comparison.

Yes Please :>

Ill drop you a PM with the source in a few hours. Bear in mind that it is very dirty. The interpreter is wrapped up in a class called AutoITinterpreter and all its modules are in the same, or child directories. Most modules are not used anymore; they are remnants of the old parser I had.

Some of the interactions are dirty too, the instance of the variable namespace and the interpreter object get passed around the evaluator and function handling like whores.

Edited by hyperzap

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

I am already disappointed in this project.

Thats actually a really depressing thing to say.

What dont you like about it? What needs to be included/changed?

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

It's an interpreter. Doing things in a different order brings no speed changes as you have to do them at some point. Besides, everything you describe is standard interpreter behaviour anyway. I think instead of saying that everything is speedy, say that everything works as intended without faults, and is easy to expand on later.

Link to comment
Share on other sites

Thats actually a really depressing thing to say.

What dont you like about it? What needs to be included/changed?

Well, I didn't mean it to be as rude as it probably sounded. I tried to delete it but the forum is weird.

Mostly, the cross platform part of it is what I dislike. It's a Windows scripting language.

Link to comment
Share on other sites

Well, I didn't mean it to be as rude as it probably sounded. I tried to delete it but the forum is weird.

Mostly, the cross platform part of it is what I dislike. It's a Windows scripting language.

I think that autoit should not simply be limited to a single platform because that was its original intention. It is the autoit Syntax and easy-to-learn--simple-to-do nature that makes autoit good, not the fact it is a windows scripting language.

EDIT: I am referring to the basic syntax of Autoit and programming prior to encountering functions like DllCall(), as Valik has pointed out.

The windows part of Autoit should not be personified as a feature, but rather a limitation. (IMHO)

I agree there will be many functions which I will not be able to port as they are too windows reliant - however, once again I am interested in porting the syntax, and going from there if you get what im saying.

Edited by hyperzap

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

It's an interpreter. Doing things in a different order brings no speed changes as you have to do them at some point. Besides, everything you describe is standard interpreter behaviour anyway. I think instead of saying that everything is speedy, say that everything works as intended without faults, and is easy to expand on later.

Ok.

I have no Idea about this, this is not something I study in maths class and I only know as much as what people tell me, and what I have read.

I was under the impression that I was being super shify with the lexing prior to runtime :> obviously that is standard and not the case. :unsure:

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

I think that autoit should not simply be limited to a single platform because that was its original intention. It is the autoit Syntax and easy-to-learn--simple-to-do nature that makes autoit good, not the fact it is a windows scripting language.

The windows part of Autoit should not be personified as a feature, but rather a limitation. (IMHO)

I agree there will be many functions which I will not be able to port as they are too windows reliant - however, once again I am interested in porting the syntax, and going from there if you get what im saying.

This is going to sound rude but that's not the intent, it's simply my honest assessment: You have no fucking clue what makes AutoIt AutoIt so that right there dooms any attempt to "port" the language anywhere.

You take the key feature of the language and dismiss it as a limitation. You take one of the more flawed aspects (the syntax) and treat it as if it's the reason the language is so awesome. You have these two things reversed. The syntax of AutoIt is awkward at the best of times. It's pretty good for beginners as it does tend to be simple and easy to use. However, the moment you enter the advanced realm it quickly becomes annoying. Take a look at DllCall() and the unwieldy syntax. Take a look at how data structures are faked in the language. Non-trivial GUIs all but require one or more global variables due to a lack of user-defined callback parameters (and arguably a lack of objects to encompass the whole thing). I personally find Python or Lua or even C++ a less frustrating coding experience because those languages are consistent. The difference between AutoIt and those languages is that AutoIt starts out simple and gets harder the more you want to do where-as those language start out a bit harder and that level of difficulty maintains or actually becomes less as complexity is added.

Taking away the Windows automation portion of AutoIt is taking away it's heart. Yes, the language has evolved to be a more generalized scripting language over the years but it's clear the initial focus was on Windows automation. That's where the magic happens. That's where all the clever code to hide annoying Windows quirks from the user is. Take that away and you're left with just another language with a sometimes archaic and obscure syntax.

Link to comment
Share on other sites

This is going to sound rude but that's not the intent, it's simply my honest assessment: You have no fucking clue what makes AutoIt AutoIt so that right there dooms any attempt to "port" the language anywhere.

All I am trying to say is that I personally do not see why autoit should be limited to just a windows automation language when It has the capability to be much more. I understand that a windows automation language was the original intention of developers and I respect that; Im not asking anyone to become involved in my little project.

You take the key feature of the language and dismiss it as a limitation.

I dont understand; Apart from the fact that autoit is characterised as a windows language, why is it such a key feature?

You take one of the more flawed aspects (the syntax) and treat it as if it's the reason the language is so awesome. You have these two things reversed. The syntax of AutoIt is awkward at the best of times.

I see what you mean. I was, as you were saying, referring to 'beginner' level of Autoit programming. Yes; parts of Autoit syntax are inconsistent and clumsy. Ive never considered the clumsiness of DLLCall() before, but once again you are right.

To correct my previous post, I mean that the autoit syntax generally, at its basic level, is nice and easy to use.

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

I dont understand; Apart from the fact that autoit is characterised as a windows language, why is it such a key feature?

You have no idea how much code it takes to implement seemingly simple features. We hide Windows bugs and obscure quirks. We will call multiple API functions and abstract all that non-sense away behind the scenes so that you are left with only a single function that behaves logically. Our wrappers around the Windows API range from thin to incredibly complex. You have no idea how much code it takes to make RunAs() work, for example. It's over 1,000 lines counting whitespace/comments. The files that contain the STDIO redirection stuff are over a thousand as well. All told there's 2500+ lines for Run(), RunWait(), RunAs() and RunAsWait(). 4 functions, 2500 lines.

You're more or less trivializing all the hard work that goes into hiding the details from the user. In one respect I guess it's good that it can be trivialized since it must mean we are hiding things well. However, you cannot ignore that the strength of AutoIt lies in it's ability to automate. When you start looking at other platforms automation looks different. Flavors of Unix are still heavily command-line based which tends to make it easy to automate things. AutoIt, however, is suited more towards automating GUIs which isn't usually necessary on Unix . I'm not familiar with Mac OS but I do know that is is based on Unix so it wouldn't surprise me if power users weren't able to use some Unix automation tricks there as well.

The point I'm trying to make is that other platforms do not benefit from AutoIt very much. The best part about AutoIt is entirely irrelevant on those platforms. That relegates AutoIt to just another language with no remarkable features on those platforms.

Edited by Valik
Link to comment
Share on other sites

And before anybody jumps on Valik for the duplicated function name in his list, one of the RunWaits should have been RunAsWait() so the count is still 4 and not 3

George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Link to comment
Share on other sites

My first use of AutoIt was back when it used GoTo and lacked any GUI capabilities. It was not till later when I was trying (failing) to get certain behaviors out of windows APIs that I re-found AutoIT with GUI capabilities. The things it abstracts out of windows APIs are truly amazing and is what makes AutoIt AutoIt. Valik nailed that perfectly, and I only have a clue due to my failures. I do not find the language that archaic until more complex programs are attempted, but it is doable. But then I do not use includes, even the basic ones. I have a script that will pull values from the includes I use in place of global variables in the actual script. Not the most readable after the fact but removing the globals is worth it to me. For me the biggest strength of AutoIt it that I can be working on a project and run into some repetitive crap that would take hours. I can then spend 10 minutes to write a throwaway script that then does several hours of work in less than a minute.

Oh yes, AutoIt works pretty good on Linux under Wine with some understandable limitation. But I was able to work around every issue, and it can even be integrated with Linux scripts. Even the window properties I failed to implement myself worked flawlessly under Wine. So unless a particularly elegant implementation with far slimmer and faster code can be produced I am not seeing the point. I do not see that happening either without ripping out those API wrappers that makes AutoIt AutoIt.

Build it and I will check it out, but label me skeptical. Not one of the supported capabilities mentioned is any special enough to warrant actually using it over *anything* else. Even the array limitations of Linux scripts can be worked around. I wish you luck, but do try to figure out what many of us find so special about AutoIt.

Link to comment
Share on other sites

You have no idea how much code it takes to implement seemingly simple features. We hide Windows bugs and obscure quirks. We will call multiple API functions and abstract all that non-sense away behind the scenes so that you are left with only a single function that behaves logically. Our wrappers around the Windows API range from thin to incredibly complex. You have no idea how much code it takes to make RunAs() work, for example. It's over 1,000 lines counting whitespace/comments. The files that contain the STDIO redirection stuff are over a thousand as well. All told there's 2500+ lines for Run(), RunWait(), RunAs() and RunAsWait(). 4 functions, 2500 lines.

You're more or less trivializing all the hard work that goes into hiding the details from the user. In one respect I guess it's good that it can be trivialized since it must mean we are hiding things well. However, you cannot ignore that the strength of AutoIt lies in it's ability to automate. When you start looking at other platforms automation looks different. Flavors of Unix are still heavily command-line based which tends to make it easy to automate things. AutoIt, however, is suited more towards automating GUIs which isn't usually necessary on Unix . I'm not familiar with Mac OS but I do know that is is based on Unix so it wouldn't surprise me if power users weren't able to use some Unix automation tricks there as well.

The point I'm trying to make is that other platforms do not benefit from AutoIt very much. The best part about AutoIt is entirely irrelevant on those platforms. That relegates AutoIt to just another language with no remarkable features on those platforms.

My apologies. I had no Idea.

I found AutoIT in my first year of middle school during one boring technology class. I had no idea at all about programming, and could not tell an IT guy from a programmer to save my life. My first script created a tooltip which said 'rawr!' and opened the CD tray a few times.

Over the next few years I used autoit for anything and everything gradually learning and getting better - progresssing to GUI, then to _Inet, then TCP, and everything else - without knowing its original intentions and rarely using the automation functions. Only three years later did I actually ever download and start to learn another language and IDE. That was a year ago.

I guess what im trying to say is that I _learnt_ programming off Autoit. I always saw it as a programming language, and not just automation; thou as you say it is the heart. Everything I did with programming in my first years, I did in autoit. I have always understood autoit as a general programming language and that has stuck with me. That is where my understanding of autoit has come from.

A beginners perspective.

Edited by hyperzap

ongoing projects:-firestorm: Largescale P2P Social NetworkCompleted Autoit Programs/Scripts: Variable Pickler | Networked Streaming Audio (in pure autoIT) | firenet p2p web messenger | Proxy Checker | Dynamic Execute() Code Generator | P2P UDF | Graph Theory Proof of Concept - Breadth First search

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...