Feature Request: Inspect variable while debugging

[JanetC]

Most debuggers allow you to hover over a variable while stepping through the code in order to inspect the contents of the variable. This would make my life so much easier!

[Crimson Wizard]

Most debuggers allow you to hover over a variable while stepping through the code in order to inspect the contents of the variable. This would make my life so much easier!

The HUGE problem of AGS is that compiled code has very limited reflection. In plain language this means that when engine runs the script, it does not always know what exactly it deals with, it does many things blindly according to instructions. For example, variables are saved not as variables, but as a big array of bytes. The engine is not explicitly told what are those variables and where in this array they are located. For the engine there is no "int a", there is, say, address "50" where it must read 4 bytes. It is possible to deduce some things from instructions, as script runs, but still no way to know variable names.

UPDATE: I just remembered that compiled script stores names of imported and exported variables for some reason. That's a good start, but not enough for general case.

So, this is not only a task of making engine tell some information on the script it runs, but making engine being able to gather such information first.
On other hand, if I am right, I believe that it should not be too hard to add such information about global variables into compiled script. I am not that certain about local ones (the way they are dealt with is somewhat different).

[Crimson Wizard]

There is yet another way this may be solved.
If Editor will write down table of variables when compiling scripts, remembering names of variable and their addresses for the debugging times, then it may ask engine not about certain names, but certain memory addresses, which engine does know.
I cannot tell whether that would be easier or harder to do. Pro is that in such case you do not need to change compiled script format, con is that this probably introduces new kind of temporary output for the project (because Editor needs to keep these tables somewhere). (also engine still won't know what it works with)

[RickJ]

I would think having a symbol table containing name, type and address would be the way to go (at least for variables with statically assigned memory addresses).  Why not have an option to generate the symbol table and include it in the game file(s)? It would be a small step further to have script commands that access the table so that debug utilities could be implemented in script.

[JanetC]

UPDATE: I just remembered that compiled script stores names of imported and exported variables for some reason. That's a good start, but not enough for general case.

Just that would be a big help, because usually the problem variables for me are imported/exported variables (I use them a lot.)

[Crimson Wizard]

This task includes number of things to consider and research.

From user interface side:
- how the watched variables are displayed? Should there be a pane with list of those, or floating hints.

From script side:
- The compiled script must have a table of variables with offsets and names, or at least only offsets (but in latter case Editor must keep the lookup table to find offset by variable name).

Data transfer:
- There is already a pipe between engine and debugger, to send commands (breakpoints sent to engine, line numbers and callstack sent to the debugger). What protocol would be optimal for this, and when the information is sent. Should each variable value be sent by request from debugger, or should engine send variable values itself, e.g. when they are modified.

[RickJ]

I don't know if Janet agrees but I would think that if there were a symbol table from which a script command could return a reference to a named variable then people could write their own debug functions.  It could be useful for other things as well.

[JanetC]

From user interface side:
- how the watched variables are displayed? Should there be a pane with list of those, or floating hints.

Whichever is easiest to code XCode includes both.

[Crimson Wizard]

This is old... things always progress slow in AGS.

For the reference, after RTTI feature was merged in AGS, it might be possible to similarly generate a table of variables with names and write along the compiled script, as an optional block of data (which may be enabled or disabled).

If this data is accessible by the engine, then the engine may return an information about variable and its current state.


An alternate approach is still viable too (as was years ago):

There is yet another way this may be solved.
If Editor will write down table of variables when compiling scripts, remembering names of variable and their addresses for the debugging times, then it may ask engine not about certain names, but certain memory addresses, which engine does know.

The meaning of this is to ask engine to return a data at offset X of size N from a script memory.