AutoHotkey Community

YES PLEEEEEASE!!

An IDE debugger for AHK could surely be optional for the many who don't want or need it.

I spent two days trying to write an AHK script with just 6 variables and got none of the suggested debug methods to work. In less than hour with an oldish copy of WinBatch. I had an alternative that did the job.

I have no experience outside scripting, but my model would be WinBatch Studio - improved of course. It would be an excellent learning medium for newbies like myself and would almost certainly REDUCE the number of posta with requests for help.

_________________
oldie

You forgot to set the poll...
Writing an IDE from scratch is a very big task!
Now, it doesn't need to be sophisticated: a simple Scintilla-based editor (I have to work more on that lexer! ), and some buttons/item menus/keyboard shortcuts to compile and run, and set breakpoints and go step by step and look at variable contents...
Obviously, since the later part (debugging) isn't not here, it will be the harder to make. But Chris repeated he thinks about this, he is well aware of the need of a good debugger.
I feel that somebody else should write the IDE (GUI) part. Because people will keep asking to improve it ("I want to change the toolbar", "I want this feature") and it will keep Chris away from his main job: to improve the language!

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Yes, Chris shouldn't do this.

I want to create an IDE, and I think that new SGC that toralf is making now can be extended to be entire IDE. I even wanted to ask him about that, to create some automatic code generator for some things, for instance adding GUI events like KeyPress, OnExit etc, scripts that are well organised and using witch you can edit GUIs all the time, not just when you create them etc... I didn't ask for this since I relised that it is small probability he will be interested (don't know why, just a feeling).

Debugger is another story.... but I guess it can be done by combining IDE creating efforts with some small debuging capabilities integrated directly in AHK witch can be called with messages (for instance message to start the script in one line at the time mode and to execute next line, and message to get the data of desired variable , IDE can do the rest - ie breakpoints highlighting etc...)

_________________

That's an interesting approach. When you get further along in your IDE plans, we can talk about it more (if it still interests you then).

Yes. Currently, I debug a big Java program, with hundred of classes, and I am happy that NetBeans has a good debugger. I like also Visual Studio (6) debugger.
NetBeans allows to debug a running Java program by "connecting" to it, provided the program is run with some options.
For this, it can use either TCP/sockets (kind of overkill, but good for cross-platform or remote) or shared memory.
Actually, for AutoHotkey, we can use any of the numerous IPC (interprocess communication) available on Windows, from plain messages to shared memory or named pipe (seems to be the three most interesting methods).

I would like to share my vision of what a debugger for AHK should be able to do.

There are two possibilities for such debugger, that can coexist:
- Add a menu item in the standard menu, opening a window showing the code in read-only mode.
Read-only because otherwise, as I wrote, people would see it as a full editor and would ask for more features...
This window would allow base debug operations, as detailled below.
- Provide an API (probably via IPC as we saw) to allow an external IDE / debugger to connect to a live AHK script. Perhaps with a new directive enabling debugging mode, in case such mode would slow down running (or just disable it if SetBatchLines command is set at -1 or -2?).

Debug operations:

- Of course, set (and disable/remove) a breakpoint. And IDE should be able to list all breakpoints with their status and to jump to a chosen one.
Conditional breakpoints are cool, but perhaps an overkill (I rarely use them...).

- Once an active breakpoint is reached, we want to be able to view (access) data:
. global variables
. local variables if in a function
. call stack if in a function too.

- Step Over (execute functions, don't enter in them)
- Step Into (go inside a function when called)
- Step Out (run to the end of the current function, jumping just after its call)

- Run to cursor (easy to do: set a breakpoint there, run and on stop, remove the breakpoint)
- Jump to cursor (kind of direct Goto, skipping normal flow of program. Can be useful in some cases)
- Run (continue execution up to next breakpoint or end of program)
- Stop the script
- Stop debugging, let the program continue

An issue with AHK is with hotkeys and timers. I think they should be disabled, so we have a use for the Jump to cursor as it would allow to simulate them.

As you see, there is a lot to do, and it might even need a major change in the internals of AutoHotkey... But it would be a powerful tool, better than spreading ToolTip, MsgBox, FileAppend or OutputDebug lines through the code. (We still do something like that in Java anyway... traces can help too.)

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

This sounds good, especially if someone else is willing to do the IDE/GUI part. I could then make the debugging internals a higher priority to match the other developer's timeline.

I don't think the internals would be very difficult because most of the foundation is already there (namely the underpinnings of ListLines and the Pause command). In addition, a new directive or mode of SetBatchLines might not be needed because I think it could be done via IPC in a way that doesn't hurt performance. For example, if a script receives a "enter debug mode" message, that could just turn on a boolean variable that tells it to take all its execution instructions from the debugger.

Global and local variables seem easy due to the existing ListVars function. What is a little harder are the following:

1) Call stack. It might impact performance slightly to maintain this, but I doubt by more than 0.5%. In addition to the functions, the call stack could also include threads and subroutines. This might allow timers to be left running if the user wishes to debug how they interact with the rest of the script.

2) Showing the contents of the variables in a more convenient way in the debugger. For example, it would be great if the debugger could show a tooltip when the mouse hovers over a variable in the code-viewer itself. And of course there probably needs to be a watch-list so that there's some way to reduce the number of variables being monitored. The debugger could query AHK to get the contents of the variables it needs.

The primary control in the debugging GUI might be a ListView and/or TreeView. A custom control is also a possibility, and it would be a lot more flexible -- but it would probably more work than anyone would want to put into it.

Thanks for all the ideas. When/if anyone has time to work on a debugging front-end, please let me know.

well, IDE doesn't have to do anything with this, although it will be very cool to have one studio for AHK. This can be done in any editor, using AHK script as debug driver.

If I want to simulate some poor form of debuging (it is still better then nothing) I could run debug driver (DD) script. This one will have Run & Next hotkeys. So, when I call Run, it will start the debagy in single line execution mode (or N line execution mode - N is dynamic paramter to how many lines you want to be executed), where AHK should stop after executing first line of the script. DD asks AHK via IPC about all variables used in last command and those are returned and displayed in some docked window (or it can ask for some specific variable, for instance, the one bellow the mouse, or selected one). Then the user calls Run again to move the execution line.
Some events can be also exposed by AHK, like "entering function", "exiting function" etc.. so those can be used to Jump in or out of fucntions.

So, in order to have basic debuging things AHK should implment following:


1. start in single line execution mode
2. execute next line
3. get variable X
4. get the current line and its number.

Other things can be done by DD;
5. Run up to the cursor ( get cursor line N, 2 until 4 returns N )
6. Run up to the end of the current function (run until current line is }, or return)
7. get set of variables used in last command (parse 4 for varialbes and call 3 for eatch)
8. Breakpoint (2 until 4 returns N)
7. Step over (2 until 6 - will not work for recursive funcs)
9. Step into (2)

So this can be used as basic setup in order to create simple but useful DD. I guess it is not much work on your side, but on the other hand, since AHK script are precompiled, it may be... it will be good to hear some initial thoughts about complexity of integration in current AHK architechture. And ofcourse, I don't have any experience with this kind of thing, this just sound logical to me. Maybe we can summon our programming expert Lazslo for opinions, thoughts, implementation procedures, theoretical discussions, or even to glance at all this and say "this is nonsense"

EDIT: Crhis posted in the same time as me so I go reading now

_________________

What troubles me the most about IDE is intelisense. To be done correctly (ie, with user functions variables etc..) it must have integrated AHK parser, and that is a big job. Maybe current AHK parser if contained as a separate modul can be used. Or we can even forget about this, use ISense I wrote and integrate editor and debuger into Smart Creator (this new one that is currently being worked by toralf)

The problem is that bunch of us have its own AHK environment (UltraEdit, EditPlus, SciTe, Metapad...) and people will probably not want to change it, so DD script sounds like more interesting (but both solutions can also be maintaned).

To completely replace 3th party editors, IDE will have to implement:
1. customizable syntax highliting (mandatory)
2. intlisense (not so mandatory, we can use existing scripts but still...)
3. outlining (optionaly)

There are already freeware syntax highligting control out there, but I didn't hear for 2 and 3. Maybe those things can be taken from SciTe source code or even better, entire code can be addapted to be integrated in this environment.

So, we can work on 3 fields separately: GUI, Editor & Debuger.
I am certanly very interested and I will know in next few months how much of time I have for that.

_________________

I think it would be nice to have folding code blocks too to help w/ navigating bigger scripts (evan if the blocks are just #includes..)

_________________
.o0[ corey ]0o.

If such IDE uses Scintilla, this will come automatically, with a kind of intellisense, flexible syntax highlighting, and lot of other goodies.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Yes, it even has debuging capatibilities.

_________________

Uh, no, but it is able to show breakpoints (markers), current line, etc. I suppose that's what you mean.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

I read on official site that it has support for highlighting current debug line and things like you mention. I guess this has to be enabled in the source.

_________________

Hey, what about using Eclipse, and code a plugin for it.

This is something that can be achieved easily if we get ctags working with ahk (the go to- part; the parser is still up in the air). See this post:

(editor-independent) function list, find function definition