29 replies to this topic

[Nutster]

What do people want for debugging behaviour? I am looking at the following:
AutoItSetOption("Debug", flags)

Flags
Add together numbers for each option
0 - Turn off all debugging
1 - Display debug output in on-screen window
2 - Save debug output to log file
If neither of the above options are not used, each debug message appears in a msgbox.

16 - Output command lines before they are executed
32 - Output function names as they are called
64 - Output function argument values are functions are called.
128 - Output variable values after assignment.

Anything else?

Edited by Nutster, 10 February 2004 - 06:29 PM.

[bcording]

It sounds complete...only i think the idea of individual msgboxes would get old fast.

[CyberSlug]

Maybe status of the @error flag? Also, how about stack depth and/or memory usage?

P.S. I'd like to see "256 - Correct all bugs before running script"

[trids]

And perhaps the values of any variables referred to in each line, before execution? Similar to 128, but not quite the same.

[Nutster]

Ok, here is my updated list:
AutoItSetOption("Debug", flags)

Flags
Add together numbers for each option
0 - Turn off all debugging

Display options
1 - Display debug output in on-screen window
2 - Save debug output to log file
If neither of the above options are used, each debug message appears in a msgbox.

Output extras
4 - Display active script name (#include file will be shown if running code inside #include file)
8 - Display line number.
16 - Display structure/function depth
32 - Output value of @Error after line executed.

When/What to output
64 - Output command lines before they are executed
128 - Output function names as functions are called
256 - Output function argument values are functions are called.
512 - Output variable values after assignment.
1024 - Output variable values as referenced.

Notes:

• To output to both debug window and debug log file, use 1 + 2 = 3
• To have function arguments appear with the function names, you will need 128 + 256 = 384, not just 256.
• To have all uses of variables displayed, use 256 + 512 + 1024 = 1792.

Add a couple of functions that output to the debug stream:
Assert(expression, [False text]) - test expression. If true, do nothing. If false (numeric 0), output False text or a default phrase if not given. Format of default message?

DebugOut(expression) - Print the results of expression using the current debug output method.

Sorry, the option of "Correct all bugs before running script" is going to be a bitch to implement.

Ok, now what I left out?

Edited by Nutster, 11 February 2004 - 07:56 PM.

[trids]

I like it I like it !

Only other extra I can think of might be the ability to set Watch Expressions. But that's far from essential .. and I can't even suggest how you might implement it!

Looking forward to developments in this area, Nuttie

[trids]

Hmmm .. come to think of it .. perhaps the Watch Expressions might be controlled with precompiler directives .. ?

#watch
    $aValue < 0
    @error<>0
#watchend

[prpldodge]

I am not sure what this might be worth it or if possible but how about some way to step through each line in the script. I use multiple monitors so on one I could be viewing the script and on the other viewing the results. This would help trouble shoot or even understand what each line of code does. My 2 cents

Thanks

Alan

[Nutster]

Add:
2048 - Enable watch expressions

Watch expressions are done like this.

Watch($answer <= 0, $Answer) ; Display $Answer if $Answer<=0 change state/value
Watch(@Error)  ;Display @Error if the value changes
Watch($state,, "Local")  ;Display $State  if the value changes, but keep it local to the current function only
Watch($Answer <= 0, $Answer, "Disable"); Disables the watch specified.

Step-by-step debugging is likely to be a or . I see it making a VERY large increase in executable size, with only a few of us using it. Hmm,
32768 - Enable step-by-step debugging.
F5 - run without stopping
F6 - run to cursor
F9 - toggle break-point on cursor line
F10 - execute next statement
F11 - execute next statement, stepping into user-defined functions
F12 - complete current user-defined function. Stepping resumes at function call.

Yeah, this would not be small. So much for the 100K executable size limit.

[trids]

Perhaps the debugging would achieved better by passing the au3 source through a debug version of Autoit.exe?

The debugger could provide for stepping, log window, etc. And there would be no debug code to bloat the distributed exe.

Just an idea

[Nutster]

Perhaps the debugging would achieved better by passing the au3 source through a debug version of Autoit.exe?

The debugger could provide for stepping, log window, etc. And there would be no debug code to bloat the distributed exe.

Just an idea 

(This gets a little technical) You have been warned!

I can see how to make that work. There are currently 2 result files being created by the VC6 project: AutoIt.exe and the file to be included in the executable of compiled scripts, which should never get debug code. We could add one more file to be created: AutoItDbg.exe. In the C++ code, there would be #IfDef AutoItDebug code to include or exclude the debugging version of code or the non-debugging version. The #Define would be placed in the configuration definitions.

Just to be clear, I am not talking about the debug executables for use with the VC6 development environment.

Let's see: Things that cause things to happen outside the main execution stream, like HotKeys and Adlib would have to be suspended in step-by-step mode.

Any thoughts? Jon?

Edited by Nutster, 15 February 2004 - 05:54 AM.

[Jon]

That was always the plan.

[Nutster]

Ok, here is another updated list:
AutoItSetOption("Debug", flags)

Flags
Add together numbers for each option
0 - Turn off all debugging

Display options
1 - Display debug output in on-screen window
2 - Save debug output to log file
If neither of the above options are used, each debug message appears in a msgbox.

Output extras
4 - Display active script name (#include file will be shown if running code inside #include file)
8 - Display line number.
16 - Display structure depth
32 - Display function depth and current function name
64 - Output value of @Error after line executed.

When/What to output
128 - Output script lines before they are executed
256 - Output user-defined function names as functions are called
512 - Output user-defined function argument values as functions are called.
1024 - Output variable values after assignment.
2048 - Output variable values as referenced.
4096 - Enable watch expressions

Step-by-step execution
32768 - Enable step-by-step debugging. Next statement will be paused waiting for key to move on. During Step-by-step HotKeys and Adlib are suspenced.
F4 - show stack dump/trace (seperate window)
F5 - run without stopping
F6 - run to cursor (requires display of source)
F8 - toggle window to display source as it is executed. Display is only updated during a pause. Does not stop other displays from happening.
F9 - toggle break-point on cursor line (requires display of source)
F10 - execute next statement
F11 - execute next statement, stepping into user-defined functions
F12 - complete current user-defined function. Stepping resumes at function call.

Notes:

• To output to both debug window and debug log file, use 1 + 2 = 3
• To have function arguments appear with the function names, you will need 256 + 512 = 768, not just 512.
• To have all uses of variables displayed, use 512 + 1024 + 2048 = 3584.

Add a couple of functions that output to the debug stream. These are ignored by the non-debugging versions without error.
Assert(expression, [False text], [Abort(0/1)]) - test expression. If true, do nothing. If false (numeric 0), output False text or a default phrase if not given and abort execution if Abort=1 (default). Format of default message: "Assert Failed: expression"

DebugOut(expression) - Print the results of expression using the current debug output method(s).

Non-debugging version totally ignores Opt("Debug", ...) values without error.

Ok, now what is needed?

Edited by Nutster, 25 February 2004 - 06:04 PM.

[CyberSlug]

Ok, now what is needed?

A way to get this included in the 3.0.100 release?

[Nutster]

How about a way for me to get enough time to make the changes? I expect to be working on this stuff with JP after we have the release version (3.1?).

[trids]

This is looking better and better all the time

Just an idea about the function keys: can we make the mapping user-definable please? I mean, the ability to assign the functionality that you've desrcribed .. but to our own mapping of function keys

[jpm]

How about a way for me to get enough time to make the changes?  I expect to be working on this stuff with JP after we have the release version (3.1?).

I assume you mean 3.0.100 not 3.1 which could be the relase after the February one.
I am ready

BTW did you find a solution to have F10 working at thr dbg-bastard time I was not able to do it

[Nutster]

I assume you mean 3.0.100 not 3.1 which could be the relase after the February one.
I am ready

BTW did you find a solution to have F10 working at the dbg-bastard time I was not able to do it

You are ready. I am ready. Is Jon ready for us?

I have not looked at the F10 problem. I can look at it on the weekend. What was the problem?

[Nutster]

Just an idea about the function keys: can we make the mapping user-definable please? I mean, the ability to assign the functionality that you've described .. but to our own mapping of function keys 

And in 1961, the some of the people at NASA thought that Kennedy was nuts too. He wants us to do WHAT? I just thought I would throw that out there.

I believe this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth.

Actually adding a few debug flags in Opt() should be able to do it. The defaults would be as I specified, but they could be overridden with calls to AutoItSetOption(). The keys specified would be the same as specified for SetHotKey. I expect to be using that mechanism behind the scenes anyway. So the defaults would be:
Opt("DebugKeyStackTrace", "{F4}")
Opt("DebugKeyRun", "{F5}")
Opt("DebugKeyRunToCursor", "{F6}")
Opt("DebugKeySourceWindow", "{F8}")
Opt("DebugKeyBreakpoint", "{F9}")
Opt("DebugKeyStep", "{F10}")
Opt("DebugKeyStepOver", "{F11}")
Opt("DebugKeyStepOut", "{F12}")

[jpm]

And in 1961, the some of the people at NASA thought that Kennedy was nuts too.  He wants us to do WHAT?  I just thought I would throw that out there. 

I think pretty soon we will ,be on the moon again with AutoIT V3.10.100

that's the next version to start the next release beta version (simplification of AutoItVersion checking)

to be serious the Opt(...) is good for me.

The F10 problem is that F10 was never reaching the Prochandler that the reason I choose another key.