Debugger

[pekster]

I have created a script that will take any existing AutoIt script and add in a debugger. The resulting script will write a line to a "debug.txt" file after each line in the script has executed. It also supports creating debug scripts from the command line. This means you can even drag a file onto a compiled version of this script and it will create your debug script.

One small note: the line numbers in the debug file correspond with your original script and not the debug script. The debug script is for execution purposes only as the line numbers do not match.

The next release of this function will support debugging specific lines. I'll get around to that when I have the time. For now it will log every line after it is executed.

Download it via the web interface in my signature.

[OhMyGod]

When I tried to download from Your ftp-server with latest firefox it asked me for a password. I just klicked 'OK' and it worked well without a password.

So thank you for the script I will surely need it.

[pekster]

When I tried to download from Your ftp-server with latest firefox it asked me for a password. I just klicked 'OK' and it worked well without a password.

Thanks for the feedback, but I did already knew this. My FTP server does not require a password for that user, but some browsers will ask for one anyway. At least Firefox can access the FTP directory; I've had many more problems with IE. If you were to use a standard FTP client, you could just leave the password blank and it would work.

[Jos]

Pekster, this is a very nice script you made for debugging.

Only thing to watch is the endless loops and ADLIB functions in your program to comment the debug statement out.

Very usefull to track the programs steps.

[pekster]

Only thing to watch is the endless loops...

Well, my code won't create any additional endless loops. If the programmer created an unescapeable loop, the log will just keep writing and writing as the execution goes on and on. In either case, you'd have to right click the tray icon and exit, or kill the process. Nothing has really changed except that there is now a log file being written.

I suppose version 2 could give a max size to the log and kill the logfile after that limit. I could just put some extra "added" code at the top to launch a 2nd instance to sit there and watch the log size and kill the first script if the log limit was reached.

...and ADLIB functions in your program to comment the debug statement out.

I don't understand this. The whole point is to track program execution, so you want it even durring the AdLib calls.

The only thing that my script will not do correctally is scripts that depend on the @error macro. With my debug calls in between every line, this will cause any @error setting to get lost. In the next day or two I'll fix this with a default option to skip debug writes above lines that use the @error macro. A current workaround is to save @error to a variable and use the variable instead. Edit: actually, you'll need to comment out the debug call between the two lines.

Edited July 10, 2004 by pekster

[Jos]

I don't understand this.  The whole point is to track program execution, so you want it even durring the AdLib calls.

The reason for mentioning is that the function called by the ADLIB Function will be called a couple of time a seconds, so will generate a lot of output records in the debug log and i am not sure how much overhead the filewrites will create...

Didn't test it myself but thought it was worth mentioning...

[Clown007]

Hello Pekster

The Debugger is a great Idea, but it Clears the @error Variable. So every Script that use the @error Variable goes wrong.

Martin

[pekster]

The Debugger is a great Idea, but it Clears the @error Variable. So every Script that use the @error Variable goes wrong.

Yea, I realised that too, and posted about it just a couple of replies up from yours. Version 2 will fix that. In the mean time, a workaround is to comment out any debug call between the function you wish to test, and the use of @error on the next line.

I'll get around to a default enabled option to skip debug writes when an @error call appears below in a couple of days at most.

[pekster]

The reason for mentioning is that the function called by the ADLIB Function will be called a couple of time a seconds, so will generate a lot of output records in the debug log and i am not sure how much overhead the filewrites will create...

Didn't test it myself but thought it was worth mentioning...

I did some testing myself, and the overhead is very small. I used 3 tests, each one with the original script, and then with my debug copy. Test 1 was a 1 second sleep call in a for loop 60 times, and should have "ideally" been excatally 60 seconds. Test 2 was the same thing, but with a default adlib call (so 250 ms, or 4 times a second.) Test 3 had the same adlib call every 50 ms (for 20 times a second.) The adlib call itself was just a "do nothing" test, but it still had to be recalculated each time. Benchmark information is as follows (rounded to 0.001 seconds):

Original script

Test1: 60.125

Test2: 60.217

Test3: 60.096

Debug script

Test1: 60.151

Test2: 60.253

Test3: 60.142

The numbes varied a bit from run to run, but not by more than 0.5 seconds at most. This is probably due to other CPU usage durring the script execution.

[WLGades]

You do realize you have this line

$slient = 1

near the beginning, right? I assume you want "silent"?

[pekster]

I assume you want "silent"?

Thanks. This has been corrected and will be reflected in the next version when I upload it. The bug doesn't actually hurt anything, but it will give you message from the command prompt when otherwise it would silently fail with an error code. It wasn't designed to give interactive error messages from the command-line interface.

[pekster]

Version 1.1 has been posted to my FTP. Changes include:

• Option to skip lines to make the @error macro work (as well as lines that end in an underscore to join them.) It is enabled by default. A command line option also exists to disable it.
• Silent bug fixed.

Eventually I'll add in support for debugging specific lines, or excluding a range of lines from being debugged. That probably won't happen for a bit, but at least this current version will work with all scripts. Version 1.0 would break scripts that used @error or _ to combine lines.

[Guest rons199]

Pekster

Hey thanks for the debugger! I haven't done much with AutoIt, but am about to start. I noticed it was missing a debugger.

I downloaded 1.1 and ran it. I get a msg box that says "Error reading the file c:\Program File\AutoIt3\Include\GuiConstants.au3. I checked the directory and sure enough, I don't have that file.

Any ideas?

Ron

[pekster]

I downloaded 1.1 and ran it.  I get a msg box that says "Error reading the file c:\Program File\AutoIt3\Include\GuiConstants.au3.  I checked the directory and sure enough, I don't have that file.

You need the unstable build to compile it.

[Guest rons199]

Pekster

I take it I must install the beta version to get it to work. Is that correct?

If yes, can both the versions of autoit 3 coexist on the same PC?

Ron

[emmanuel]

Pekster

I take it I must install the beta version to get it to work.  Is that correct?

If yes, can both the versions of autoit 3 coexist on the same PC?

Ron

yeah, just install the unstable into a seperate folder, or just download the individual files and put them in a different folder like autoit3unstable or something.

[pekster]

I take it I must install the beta version to get it to work. Is that correct?

If yes, can both the versions of autoit 3 coexist on the same PC?

You don't need to install the beta unless you want to use that as your primary install. You can have both at the same time, but you need to manually place the files for the beta in a seperate directory.

If you have AutoIt 3.0.101 (the stable release) install to AutoIt3, you could create a new folder called AutoIt3-beta. Then, you'll need to download the following files into that directory: AutoIt3.exe, AutoItSC.bin (if you want to compile), Aut2Exe.exe (a GUI frontend to compile), and place the GUIConstants.au3 file in your current version's include directory (so that my include directive will find it.) You could also put the GuiConstants file in the directory where you are compiling my script from.

This method will not overwrite your current install of version 3.0.101, but will allow you to use the 3.0.102 beta to compile scripts that use those features.

[pekster]

yeah, just install the unstable into a seperate folder...

Well, you could run into problems with this since the current installed version keeps some info in the registry. Includes could get pretty messed up as well as confusion about which compiler you're using if you compiled via the right-click context menu.

Another solution that I use is to just install the beta over my stable copy, and if I ever need to compile using 3.0.101, I just re-isntall with the stable release. It only takes about 30 seconds, and it allows me to never have to worry about which version I might be using when I compile.

[emmanuel]

Well, you could run into problems with this since the current installed version keeps some info in the registry. Includes could get pretty messed up as well as confusion about which compiler you're using if you compiled via the right-click context menu.

Another solution that I use is to just install the beta over my stable copy, and if I ever need to compile using 3.0.101, I just re-isntall with the stable release. It only takes about 30 seconds, and it allows me to never have to worry about which version I might be using when I compile.

You're right, I spoketh out of my arse. I too just run the Unstable most of the time knowing that if I had to, I could grab the stable to compile.

[Jos]

I prefer to just download the files needed for unstable into a seperate directory and have special shortcut defined in Scite. In this way I can choose which version i want to run/compile the script with. In this case Alt+F5 to RUn and Alt+F7 to Compile and Alt+F1 for the Beta Helpfile.

i got these lines in the SciTe userfile to support it....

command.21.*.au3=C:\WINUTIL\AutoIt3\au3beta\autoit3.exe /ErrorStdOut "$(FilePath)"
command.name.21.*.au3=Run Debug 
command.save.before.21.*.au3=1
command.shortcut.21.*.au3=Alt+F5
command.22.*.au3=C:\WINUTIL\AutoIt3\au3beta\aut2exe.exe /in "$(FilePath)"
command.name.22.*.au3=Compile Debug
command.save.before.22.*.au3=1
command.shortcut.22.*.au3=Alt+F7
command.23.*.au3=C:\WINUTIL\AutoIt3\source\autoit\bin\autoit3.exe /ErrorStdOut "$(FilePath)"
command.name.23.*.au3=Run My Debug 
command.save.before.23.*.au3=1
command.24.*.au3=$(CurrentWord)!C:\WINUTIL\AutoIt3\au3beta\autoit.chm
command.name.24.*.au3=Debug Help
command.subsystem.24.*.au3=4
command.shortcut.24.*.au3=Alt+F1
command.save.before.24.*.au3=2