AutoIt3 Interpreter.

[JRowe]

Intercept the keystrokes as you go, allow "shift + enter" to create a newline and enter to execute anything that's been entered since the last execute, so you could even paste an entire script, then run it.

[wraithdu]

Maybe make multi-line code look special as well, like

@{Func _MyMsg();MsgBox(0, "Function", "Hi there.");EndFunc;_MyMsg()}

So you could then just do something like

@{_ArrayDisplay($a)}

Of course then, you'd have to be able to pass variables stored in memory to the external script...

[Mat]

I had an idea for executing multi-line code this morning while driving to work. It would be kind of a one shot deal, but... the idea is to have a line continuation character that your interpreter would process, then write out a temp script in @TempDir or something, then execute the script. I would think that ; (semicolon) would work, since a shell has no use for comments. Then you could do something like this:

> Func _MyMsg();MsgBox(0, "Function", "Hi there.");EndFunc;_MyMsg()

You'd have to watch out for ; in literal strings, but you get the idea.

I had another idea... but it will take more work. I already check for function definitions and print an error.

Au3Int -> Func _MyMsg()
MyMsg -> MsgBox(0, "Function", "Hi there.")
MyMsg -> EndFunc
Au3Int -> _MyMsg()

but this is going much more into a serious parser rather than a wrapper...

[crashdemons]

Very nice script, I love being able to check/use my expressions in a prompt!

I'm really looking forward to multiline capability being added.

Also, I know I wasn't supposed to do this, but I had to just for fun:

execute(eval('INTERNALVAR_000A5792_sInput'))

One way to catch this might be to make execute(),eval(),assign() wrapper functions that detect internal variable names... but it's not like it's a pressing matter.

Edit: wording

Edited May 14, 2010 by crashdemons

[Mat]

Very nice script, I love being able to check/use my expressions in a prompt!

I'm really looking forward to multiline capability being added.

Also, I know I wasn't supposed to do this, but I had to just for fun:

execute(eval('INTERNALVAR_000A5792_sInput'))

One way to catch this might be to make execute(),eval(),assign() wrapper functions that detect internal variable names... but it's not like it's a pressing matter.

Edit: wording

There was something about embedded executes failing a few months back as well...

I don't think its worth the bother. If they want to open up the insides then they can deal with the consequences.

[crashdemons]

There was something about embedded executes failing a few months back as well...

I don't think its worth the bother. If they want to open up the insides then they can deal with the consequences.

Actually, that code fails because it was specifically crafted to create an infinite recursion in your script. (yes, evil me.)

Here's what I made happen:

• $INTERNALVAR_000A5792_sInput contains the inputted string
• $INTERNALVAR_000A5792_sInput is executed by the script
• - The string "execute(eval('INTERNALVAR_000A5792_sInput'))" is executed
• - - eval('INTERNALVAR_000A5792_sInput') is executed, producing the original input string
• - - execute("execute(eval('INTERNALVAR_000A5792_sInput'))") is executed
• - - go back to the 3rd bullet.

But, as I was saying, in this type of condition either Execute(), Eval(), or Assign() will have to come into direct contact with a variable name - creating wrapper/replacement functions could detect internal variable names easily. But, it's not like anyone else is going to bother trying to manipulating internal variables here.

However, if you plan on changing to an external script, there is no longer an issue.

Either way, I was not trying to make an important point.

Edited May 15, 2010 by crashdemons

[Mat]

Actually, that code fails because it was specifically crafted to create an infinite recursion in your script. (yes, evil me.)

I know, I was saying that there has been problems with executes in executes before, and was wondering if that would be another problem.

But, as I was saying, in this type of condition either Execute(), Eval(), or Assign() will have to come into direct contact with a variable name - creating wrapper/replacement functions could detect internal variable names easily. But, it's not like anyone else is going to bother trying to manipulating internal variables here.

However, if you plan on changing to an external script, there is no longer an issue.

Either way, I was not trying to make an important point.

I disagree that it would be easy to make a wrapper... You would have to go through and check each statement (executing the parameters as well) and making sure its not inside a string...

About the external script... That could be an idea, and I did consider it to begin with, but it would need yet more work.

Of course I could release the exe with the names mangled and the source code not mangled... That would mean you wouldn't be able to find out the names

Mat

[Mat]

Updated the code... And added a project page on google.

Project page

Changelog

Downloads

Edited May 24, 2010 by Mat

[wraithdu]

I thought I should point out... if you include all of AutoIt's include files when compiling this project, you gain the use of ALL UDF functions from the console That's a pretty snazzy feature. However you'll have to disable obfuscator so it doesn't strip the functions and variables and doesn't mangle the names...

[wraithdu]

After doing the above, I thought I should be more specific about how to do it successfully. Ideally you need to have the original source obfuscated (to obscure internal variables and functions, while keeping the included UDF's un-obfuscated. The solution is to pre-obfuscate the source, then compile with the includes WITHOUT obfuscation.

1) Create a temp script with the main source in Obfuscator's directory.

2) Remove all #include lines and other directives.

3) Add the following two directives:

#Obfuscator_Parameters=/cs=0 /cn=0

#Obfuscator_Ignore_Variables=$AINTERNALARRAYWAT

4) Run Obfuscator on the temp script from the cmd line (ignore the errors): obfuscator.exe temp.au3

5) Create a new script and paste in the original Au3Int source.

6) Insert all the AutoIt include files using #include statements.

7) Set the #AutoIt3Wrapper_Run_Obfuscator to NO: #AutoIt3Wrapper_Run_Obfuscator=n

8) Replace the actual source code with the new obfuscated code.

9) Compile.

The resulting script should be like ~1.8 MB. I know, huge and slow to start, but you now have the entire AutoIt UDF library at your disposal.

[Mat]

After doing the above, I thought I should be more specific about how to do it successfully. Ideally you need to have the original source obfuscated (to obscure internal variables and functions, while keeping the included UDF's un-obfuscated. The solution is to pre-obfuscate the source, then compile with the includes WITHOUT obfuscation.

1) Create a temp script with the main source in Obfuscator's directory.

2) Remove all #include lines and other directives.

3) Add the following two directives:

#Obfuscator_Parameters=/cs=0 /cn=0

#Obfuscator_Ignore_Variables=$AINTERNALARRAYWAT

4) Run Obfuscator on the temp script from the cmd line (ignore the errors): obfuscator.exe temp.au3

5) Create a new script and paste in the original Au3Int source.

6) Insert all the AutoIt include files using #include statements.

7) Set the #AutoIt3Wrapper_Run_Obfuscator to NO: #AutoIt3Wrapper_Run_Obfuscator=n

8) Replace the actual source code with the new obfuscated code.

9) Compile.

The resulting script should be like ~1.8 MB. I know, huge and slow to start, but you now have the entire AutoIt UDF library at your disposal.

The question is... Do we need the entire library? I would think the GUI*.au3's should not be needed, but I am not sure since they all work with external controls as well and so may be useful.

I think in the long run this is going to have to write to a file and execute it. There is no other way to get the full functionality of AutoIt such as UDF's and nested statements.

The logistics of rewriting the entire code to write to a file is pretty big, but I think its possible. As far as writing outputs, the problem will be the examples where I have practically written a new parser (variable declaration etc) as they do not have a return value, and can't be placed inside a ConsoleWrite function.

I will think about it... I want to keep it portable as it is now, so having the includes would be nice, but a 1.8mb file? I will have a look though as I agree it would be nice.

Mat

[wraithdu]

I wasn't at all suggesting you do this for your releases!! I had a desire to run some UDF functions for myself, so came up with a way to do it. Obviously each user would do this on their own and could include as much or little extra functionality as they require. The most I would think you could / should do is provide the method of integration in your documentation.

Edited June 18, 2010 by wraithdu

[Mat]

I wasn't at all suggesting you do this for your releases!! I had a desire to run some UDF functions for myself, so came up with a way to do it. Obviously each user would do this on their own and could include as much or little extra functionality as they require. The most I would think you could / should do is provide the method of integration in your documentation.

Kk... I get it. You want better docs Typical isn't it. Here I am trying to write a nice little program and all they ever want is docs. This thread is a great example. The user first asks what it actually does, and the second user asks where the helpfile is.

The fact no completely decent helpfile maker can be found that does what I want it to do is also rather irritating. But I think I've got it sorted now.

I understand now, and I'm writing it up, but I still think that I'm going to have to change the way the interpreter works in the future.

[wraithdu]

I'm not crying for better docs either. I'm just saying I came up with a method to do something cool with your interpreter, and you may include it in docs if you so wish. Or point people to my post. Doesn't matter to me. I just thought it was a cool idea that worked out and others may find useful.

[Mat]

I'm not crying for better docs either. I'm just saying I came up with a method to do something cool with your interpreter, and you may include it in docs if you so wish. Or point people to my post. Doesn't matter to me. I just thought it was a cool idea that worked out and others may find useful.

I have written up a more inclusive version of what you described... Which should be easier to understand. It'll be there with the next version.

Thanks for the help

Mat

[Mat]

Decided I'd release it now.

Version 1.0.2.2

Download

Changes

The helpfile is now respectably minimalist, rather than empty

Mat

[Mat]

Version 1.0.2.3

Ok, I've done a lot of work today on this, as I happened to need something exactly like this to sort out a few problems on my brothers computer. As a result there are a lot of new things, some of which are pretty big things which I didn't think I'd be able to do.

Changes this version (1.0.2.3): ^{[ see full changelog ]}

• Added: Support for @error and @extended macros.
• Added: Ability to run the source code uncompiled. (NB: Must not be run from SciTE)
• Added: You can now clear all variables set using the interpreter. The variables page (helpfile) has been updated with more info on how this works and possible work arounds to stop a variable being destroyed.
• Added: "cls" as an alternative for "clr" as it was misleading being similar but not the same as the cmd command.
• Fixed: Error on variable declaration where either the variable was not being initialized or was initialized as a blank string.
• Added: Returned strings are now enclosed in double quotes.
• Added: Arrays within arrays are now supported
• Added: AutoItInfo command.
• Added: SciTEInfo command.
• Fixed: Error when declaring variables using functions with multiple parameters.
• Added: Full array support when declaring, re sizing, modifying and comparing.

The first big thing I did was finally get AllocConsole to work properly, meaning that the interpreter no longer has to be compiled in order to work. This makes testing a lot easier, and also solves some of the problems with includes. Furthermore I think I have a nice way to get functions working... But It's going to take a lot of testing. I have tried various ways to break away from SciTE in order to get the console but none work, so don't run from SciTE. Since the name mangling occurs at compile time using obfuscator the script will not have them mangled. It does print an error but just be warned.

Next big thing is arrays. They are now completely working up to 6 dimensions. I can add more but I don't see the point since the buffer fills up quickly when using large arrays. The only thing not working is initialization (Local $a[5][2] = [[00, 01], [10, 11], [20, 21], [30, 31], [40, 41]]) so any attempt to do so will be ignored by the interpreter.

The "autoitinfo" and "sciteinfo" are designed to be the first of a series of keywords that will help the user use AutoIt through the interpreter on machines without AutoIt installed. I am intending to add commands that will build the *.au3 association using Au3Int as AutoIt3.exe and the user can then remove it later.

Behind the scenes the source code is (hopfully) a bit cleaner, with the introduction of the _Console_* functions. I intend to release them as part of a larger set later, but this is a good example of using some of them, which could be useful to many people.

Overall... not bad for a days work. The interpreter should be even more useful now.

download

Mat

[FuryCell]

Just gave this a try. Awesome work. This definitely has a place in my scite tools menu.

[Mat]

Just gave this a try. Awesome work. This definitely has a place in my scite tools menu.

Funny, I haven't used it much at all on my computer apart from testing, I've been keeping it on a memory stick to do all the little jobs on other peoples machines. I have used it a few times to test functions etc. though.

Thanks for testing

Mat

[FuryCell]

Funny, I haven't used it much at all on my computer apart from testing, I've been keeping it on a memory stick to do all the little jobs on other peoples machines. I have used it a few times to test functions etc. though.

Thanks for testing

Mat

NP. I'm gonna put it on my memory stick. It would be a nice shell for working with settings and stuff. Is there a feature to udfs into the program so I can call them from the prompt?